DHCP problems on storage nodes

[george1421]

@greg-plamondon This looks right.

So a little bit more background on this. Are all target computers at this location doing this or only just this one computer?

[Greg Plamondon]

@george1421

Its doing this at all locations. I have 30 locations

[Greg Plamondon]

@sebastian-roth

Sorry it took so long it takes a good 5 minutes for the page to display.

[Sebastian Roth]

@Greg-Plamondon Sorry my fault. Take a look at FOG Configurations -> FOG Settings -> Web Server -> WEB HOST…

And check /opt/fog/.fogsettings before running the installer again.

[Greg Plamondon]

@sebastian-roth

[Greg Plamondon]

I have a tech @ the remote location but he will be heading to the Airport at 3PM Eastern Time. Testing will be limted after that, if anyone has a fix or suggestion please dont hesitate

[Greg Plamondon]

i have backup folders:
“fog_web_1.5.0-RC-9.BACKUP”
"fog_web_1.4.4.BACKUP "
“fog_web_1.5.0-RC-10.BACKUP”

how do I roll back to this with GIT?
and what one should I roll back to?

[Greg Plamondon]

@sebastian-roth
If I set the “Location” to use the main management fogserver it works but I am pulling a lot of data across the wire consuming the entire circuit.

[Wayne Workman]

@greg-plamondon I just got done skimming through this thread, I’m unsure of the problem now? Is it still DHCP related or what?

[george1421]

@greg-plamondon Sorry for the delay on this, I needed some time to research this issue. I think I have a test for us to understand what is going on here.

Hopefully you have a virtualization environment at one of the remote locations. Assuming you do, this is what I want to test.

1. Create a new (tiny) virtual machine. This just needs to be the bare minimum, it needs to be able to pxe boot.
2. Manually register that virtual machine with fog.
3. Schedule a capture / deploy (doesn’t matter) but be sure to enable the debug option.
4. PXE boot that target computer. It should boot to a command prompt. It may complain about the same ip address thing but it should display a bunch of commands and then drop you at a linux command prompt.
5. At the linux command prompt I want you to key in the following command. set | grep web. The hope is the response will be web=http://192.168.10.238/fog/
6. Now try to ping your main fog server ip address at 192.168.10.238

Something should fail above. I looked at the script where its going sideways in FOS. That script is here: https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/etc/init.d/S40network specifically at line 40. FOS will make a curl call back to your master FOG server to test if the link is up. FOS uses this command
curl -Ikfso /dev/null "${web}"/index.php --connect-timeout 5
Expanded the command is
curl -Ikfso /dev/null http://192.168.10.238/fog/index.php --connect-timeout 5

curl flags decoded
-I Doc Info
-k allow ssl connection, ignore cert
-f fail silently
-s silent
-o output file /dev/null

The other thing that could be stopping the works could be the 5 second timeout. But I would hope your fog server can respond within 5 seconds…

Wait didn’t you comment it was taking a long time to call up a web page? If your master fog server is overloaded and doesn’t respond with the index.php page within 5 seconds the remote clients will give up pxe booting. The curl command calls up a web page and not just a simple ping to see if it can reach the fog server.

[Greg Plamondon]

@george1421
I ran the command you requested on the TEST client PC.

I didn’t get any out from the command I rand…
I was able to ping the fogserver.

There are parts of the web interface that take a VERY long time to load and those are the “Storage” and “Fog Configuration” pages. The fogserver dashboard is very responsive.

[george1421]

@greg-plamondon This vm is at one of the remote locations?

[Greg Plamondon]

@wayne-workman

Yes as far as I can tell.

[george1421]

@greg-plamondon As for the output of the curl command we probably want to remove the “fso /dev/null” from the command so it prints out the results on the screen. The script uses the error level generated by curl to know success or fail.

Make the command now curl -Ik http://192.168.10.238/fog/index.php --connect-timeout 5

[Greg Plamondon]

@george1421

yes,

[Greg Plamondon]

@george1421

[george1421]

@greg-plamondon you want to change the option switches as in the command I posted. That error threw me for a second.

[Greg Plamondon]

@george1421

[george1421]

@greg-plamondon OK, that isn’t exactly what I expected. I expected a 200 code, not 302 returned (may show my ignorance). The 302 code means success but redirect which is what is happening in FOG.

I just tried this on my fog server running 1.4.4 and I got the same 302 return code. So yours is normal. That doesn’t explain why the target computer can’t access the fog server during startup.

[george1421]

@greg-plamondon Well I think we need to get better debugging information into the inits to see exactly what is going wrong.

There is a wiki page that explains how to unpack the inits. Copy the init.xz (virtual hard drive) from /var/www/html/fog/service/ipxe to /tmp on your fog server then follow the instructions in the wiki: https://wiki.fogproject.org/wiki/index.php?title=Modifying_the_Init_Image

cp /var/www/html/fog/service/ipxe/init.xz /tmp
cd /tmp
xz -d init.xz
mkdir initmountdir
mount -o loop init initmountdir

Then change into /tmp/initmountdir/etc/init.d

I’m going to work on updating S40Network to add more info so we know what its doing (wrong).