@Tom-Elliott no it’s not. The server itself is named fogserver at the OS level, and I have DNS entries that resolve fog-server, fogserver and fog (just covering my bases), all resolve to the correct IP.
That fog-server entry in the logs is due to me being lazy and next nexting with installing the client in this case.
When browsing to Task Management: http://fogserver/fog/management/index.php?node=task
if I select one or multiple tasks listed and click on “Delete all selected s?” (Typo on button text, also);
1.) the page refreshes over to http://fogserver/fog/management/index.php?node=task&sub=save_group
2.) the task(s) remain uncancelled and present
3.) the pause auto update button present at the top now has blank text
I’m on SVN 4393 Cloud 5445 too, and not seeing any issues with registration, all of my location nodes show up no problem when doing a Full Registration.
@Tom-Elliott Confirmed, tasks are pulling down the boot files and image data from the correct node consistently, and updating nodes pulls from the newly set node as well. Awesome work, thanks!
@Tom-Elliott I can tell you that after upgrading to the SVN 4393 (latest as of this post) , /var/www/html only contains the default apache2 index.html, still consistent with the behavior noted in my OP
@Sebastian-Roth
It looks like whatever is causing the flip is changing the taskNFSMemberID column in the task (in tasks table) to 1 (the master server in my case) or to 3 (the correct location storage node)
I would be willing to capture a dump somehow if you feel it would be helpful, but I’m very certain that there are not multiple DHCP servers, as there’s no other noted issues in my environment.
Got something concrete that I picked up on finally!
When a host with a pending task boots, it pulls down bzimage and init (and then the image) from the master server, and then if I shut off the host halfway through the task and reboot it, it boots and pulls bzimage and init/image from the correct storage node location, rinse repeat and pulls bzimage and init/image from master, rinse repeat from node etc.
This flipping action happens very consistently once the task has started.
OK! Now, if I power off the host before the bzimage and init pulldown finishes (so, before the screen flashes and clears over to the imaging process itself), booting the host again will pull everything down from the same server just as before. So it’s almost like something gets toggled in the database side of things, perhaps in the task itself right as the image kicks off that might be causing this?
@Tom-Elliott Yes, the location plugin is installed. bzImage and init.xz being pulled from the specified location is exactly something that I desire, so I’m not off my rocker (yet) so far, even if my initial understanding of what Tftp enabled was a bit off!
Each storage nodes referenced by a given location are local to all clients in that location, unfortunately sometimes the client does boot and pulls down bzimage and init (and then the image) from the master server which is not local to that client.
Location plugin is the only one installed, and it lists its location as “…/lib/plugins/location/”
Not 100% sure if this is a “bug report” or not, and not sure how to even write this one out as I like to provide as much info as possible but…
I’m having the darndest time getting a fog client to TFTP boot (and more importantly, pull down the image itself locally) consistently from a storage node in a remote subnet. Sometimes boot.php on the master install will direct clients to image from the local storage node which is 100% the desired behavior, and sometimes boot.php will direct the client to pull down bzimage etc from the master server.
On each storage node, I am replacing the storage node IP in the chain line of /tftpboot/default.ipxe with the IP of the master install. This is per some documentation I read once upon a time for an older version of fog, and it’s worked fine up until recently.
Poking around the database in the location table, I’m noting that the lTftpEnabled column entries all contain o (as in lowercase orange, not zero) for locations that appear as TFTP Boot Enabled in the GUI, rather than 1 which is what I would expect?
In fact, changing this “o” to any value at all appears to retain the TFTP Boot Enabled setting in the GUI. Changing this value to 0 does change TFTP Boot Enabled in the GUI to “unchecked” as one would expect. Unchecking it in the GUI and saving the change actually blanks out this field, rather than changing it to zero.
I don’t know if the databse oddity noted is relevant at all, but the expected behavior from my end is if the location is set for a host, then it needs to pull boot and image files strictly from that local tftp-enabled storage node.
Sorry if this is rambling. I’m having a difficult time nailing down problem duplication steps because it doesn’t seem to be acting consistently either way.
Ubuntu 14.04.3
SVN 4380 Cloud 5419
On a fresh install, an upgrade to newer trunk version, or a reinstall of the existing fog_trunk contents, FOG clients will begin to throw 404 errors for everything;
11/18/2015 12:50 PM Middleware::Communication URL: http://fog-server/fog/service/servicemodule-active.php?moduleid=clientupdater&mac=90:B1:1C:7D:6B:FF||00:00:00:00:00:00:00:E0&newService=1
11/18/2015 12:50 PM Middleware::Communication ERROR: Could not contact FOG server
11/18/2015 12:50 PM Middleware::Communication ERROR: The remote server returned an error: (404) Not Found.
Going off of constant refreshing the folder view while running a couple installs, I’m guessing the symbolic link (which I had to manually create in the first place) gets wiped out right around this area here:
* Backing up old data.........................................OK
* Copying back old web folder as is...........................OK
* Copying new files to web folder.............................OK
Here’s the fix, just needs to be run once install.sh has finished completely:
Make a symbolic link at /var/www/html for fog, and point it at /var/www/fog
ln -s /var/www/fog /var/www/html/fog
Ta-da, no more 404s!
May or may not be relevant, we noticed as of a few revisions ago that imaging things based on location would try to pull the image from the wrong location. Uninstalling the plugin sort of worked, but left behind the Location column in the hosts view which listed them all as a location variable. Trying to re-install it gave similar results as trying to install it on a fresh install. (failed oddly)
I can’t be more specific on what SVN this started with, sorry. We jumped up 2-300 on the Cloud counter last week, and I’ve pulled down SVN more than once in the last few days as commits have been made (i watch the activity log like a hawk). I apologize for my lack of concrete data to report here.
Freshly installing Ubuntu 12.04.5 (also tried 14.04.3), installing all from apt-get upgrade (also tried with/without doing apt-get dist-upgrade), and pulling down fog_trunk, running a default normal installation…
Enable plugins: Ok
Activate Plugins, selecting location: Ok
Install Plugins, selecting location: It ends up going to a white screen with just the plugin information on both Chrome and Firefox (see likely unhelpful screenshot at bottom), and never actually installs.
Within /var/log/apache2/error.log I see the following:
PHP Fatal error: Call to a member function getRunInclude() on null in /var/www/fog/lib/pages/PluginManagementPage.class.php on line 91, referer: http://IPADDRESS/fog/management/index.php?node=plugin&sub=install
PHP Fatal error: Call to a member function getRunInclude() on null in /var/www/fog/lib/pages/PluginManagementPage.class.php on line 91, referer: http://IPADDRESS/fog/management/index.php?node=plugin&sub=install&run=d5189de027922f81005951e6efe0efd5&plug_name=location&install=d5189de027922f81005951e6efe0efd5&plug_name=location
Where’d I go wrong? This is about as close to a fresh, clean install as I’m going to get to try to rule things out.
It’s awesome that we can put notes on a particular host via the Host Description field.
Could data in this field (if present) be included on the Image Task Completed emails underneath Mac Address?
This would be useful for such notes as “Please install XYZ software manually after imaging, licensing info is 123”, or other host specific details.