PXE Boot stopped working
-
OK.
The only thing I saw that looked different was this:
If I search for wol.php I find it in two locations.
/var/www/fog/wol
/home/pmusfog/desktop/fog_1.2.0/packages/web/wolThe path in FOG Configuration->FOG Settings->General Settings->FOG_WOL_PATH = /fog/wol/wol.php.
Tom said that it was correct though.
-
Yes that is correct the other is in the folder on your desktop where you decompressed the tar.gz so you could install FOG.
The path on your desktop is not necessary, it is only installation material.
Your WOL path should be /fog/wol/wol.php On your FOG Settings page under the General Settings.
-
Thanks. So the /var/www part is implied?
-
Yes because when it (apache) serves the entire FOG web GUI system, it does so from your web path which is /var/www
So the entire path to WOL is /var/www/fog/wol/wol.php
The web path is /fog/wol/wol.php
-
Thanks for the clarification
-
I scheduled a few upload tasks overnight. They did not run.
When I look at the fogscheduler.log I see that the last entry was yesterday morning. I did not stop the services.
[COLOR=#008080]Edit: I did check and none of the FOG services was running.[/COLOR]
How do I troubleshoot this?
Also, does the Windows client have to be at the login screen for the task to run? What if a user is logged in or the machine is locked ?
[COLOR=#008080]Edit: I found that the Auto Log Out module was disabled. I’ll test again tonight. Does the global setting override the setting on the client? The clients were installed with Auto Log Out selected.[/COLOR]
-
I still don’t know why the FOG services stopped…
I did find that the Intel driver installed on the clients did not actually support WOL even though there were check boxes to enable it.
I haven’t fully sorted out the Auto Log Out.
-
ALO (Auto Log Out) doesn’t work on the clients, or at least not properly. It works by forcibly restarting the machines as soon as their “time limits” are met. The problem is the time limits the provided factor. It doesn’t care if a user’s been logged in and active for the last 5 minutes. If the “time is up” the system will reboot. I would recommend, for now, not using this feature until the new client comes out.
The FOG Services have issues. I’ve tried with all of my might to fix them but it’s obviously all been in vein. We saw this with Fedora 20+, CentOS/RH/SL 7+, Debian 7.7+, Ubuntu 12+, etc…
It still hasn’t been corrected. Sure it could be something simple that I’m missing, but as most of the problematic systems are specifically related to systemd over sysvinit (of which has never had any problems that I’m aware of), it seems the best course of action is to disable the services from boot parameters and subject them into /etc/rc.local and/or /etc/rc.d/rc.local.
One of the things I can actually program to happen, somewhat, but it would also make the grand assumption that you haven’t modified the related file (which is why I haven’t done this already).
-
Thanks for the information. What “time limits” are you referring to?
The Intel NIC driver bug had me stumped for a bit.
I am very close to having this all work the way I envision.
If only I could get all users to log out at the end of the day.
SO, is there a way to restart a client if a user is logged on from FOG?
-
If a user is logged on to a client machine the only way I can schedule a FOG upload is to send a shutdown/restart command to the client machine via the Linux scheduler.
