Host seems reachable by fog, but is not reaching PXE fog menu

thebrennan47

Okay, so it looks like the management password is the same for all storage nodes? So I think I have gotten past that, unless there is something that the install script does that I am missing with the manual add. I attempted to do a capture operation, and I am still having an issue. Do you guys see anything wrong with my dhcpd.conf file?

Quick Edit: After some playing around it looks like the client machines are being assigned an IP correctly, but are not able to access the internet. It doesn’t seem like a DNS issue neccesarily because I cannot ping individual IP addresses either. I can only successfully ping the DHCP server. (IPv4 forwarding has also been enabled) So it seems like there is still something wrong, but I am getting close. Any help would be appreciated, thanks!

option space PXE;
option PXE.mtftp-ip code 1 = ip-address;
option PXE.mtftp-cport code 2 = unsigned integer 16;
option PXE.mtftp-sport code 3 = unsigned integer 16;
option PXE.mtftp-tmout code 4 = unsigned integer 8;
option PXE.mtftp-delay code 5 = unsigned integer 8;
option arch code 93 = unsigned integer 16;
use-host-decl-names on;
ddns-update-style interim;
ignore client-updates;

# option definitions common to all supported networks...
option domain-name "xxxx.xxxx.xxxx.com";
option domain-name-servers ###.###.12.30,###.###.12.8;

# Specify subnet of ether device you do NOT want service.
# For systems with two or more ethernet devices.
# subnet 136.165.0.0 netmask 255.255.0.0 {}
subnet 192.168.1.0 netmask 255.255.255.0{
    option subnet-mask 255.255.255.0;
    range dynamic-bootp 192.168.1.10 192.168.1.100;
    option broadcast-address 192.168.1.255;
    default-lease-time 21600;
    max-lease-time 43200;
    option routers 192.168.1.1;
    next-server 192.168.1.3;
    include "/etc/dhcp/worker-reservations.conf";
    class "Legacy" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000";
        filename "undionly.kkpxe";
    }
    class "UEFI-32-2" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00002";
        filename "i386-efi/ipxe.efi";
    }
    class "UEFI-32-1" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00006";
        filename "i386-efi/ipxe.efi";
    }
    class "UEFI-64-1" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007";
        filename "ipxe.efi";
    }
    class "UEFI-64-2" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00008";
        filename "ipxe.efi";
    }
    class "UEFI-64-3" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00009";
        filename "ipxe.efi";
    }
    class "SURFACE-PRO-4" {
        match if substring(option vendor-class-identifier, 0, 32) = "PXEClient:Arch:00007:UNDI:003016";
        filename "ipxe7156.efi";
    }
    class "Apple-Intel-Netboot" {
        match if substring(option vendor-class-identifier, 0, 14) = "AAPLBSDPC/i386";
        option dhcp-parameter-request-list 1,3,17,43,60;
        if (option dhcp-message-type = 8) {
            option vendor-class-identifier "AAPLBSDPC";
            if (substring(option vendor-encapsulated-options, 0, 3) = 01:01:01) {
                # BSDP List
                option vendor-encapsulated-options 01:01:01:04:02:80:00:07:04:81:00:05:2a:09:0D:81:00:05:2a:08:69:50:58:45:2d:46:4f:47;
                filename "ipxe.efi";
            }
        }
    }
}

george1421

@thebrennan47 Well IMO, I wouldn’t do it the way you did it (yes circle talking at its best).

I would still leave the storage nodes setup exactly as they were. The only thing you was missing is the dhcp server service, which can be added manually.

What you have is a hybrid solution that is not supported directly by the FOG Project, but that doesn’t mean it won’t work.

A storage node can pxe boot target computers, no problem. NFS is setup because it can deploy images no problem. The issue you will have is capturing images, that can only be done by the master node (not a storage node), unless you know a trick. The only thing missing is isc-dhcp which can be added from your distro’s repository. If you view the fog wiki page you can find a great example of the config file needed: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Example_1

Now the only caveat with this setup is the caveat with any master node, storage node configuration. The storage nodes and the clients must be able to reach the FOG Master node or the storage node will become useless. The target computers only need to reach the master node if the FOG Client is installed. If the fog client isn’t installed in the reference image then only the storage nodes must be in contact with the master node.

Again, this setup configuration is not a supported configuration by the developers. But that doesn’t mean it won’t work as designed.

BTW: Your picture made it quite clear what you were doing, well done.

george1421

@thebrennan47 Sorry I had your post open from earlier and did not see your latest post.

Did I help you configure this setup? I know I helped someone in the last week or two with a similar setup where each storage node managed a single deployment bench. I only ask just to be sure I’m on the right track because I know it worked (routing) when I was done.

If I didn’t, to turn your storage node into a router, you need to enable the ip_forward kernel parameter, and then make it persistent with sysctl config file.

IN ADDITION, you have to remember that routing is a two way street. In your drawing you didn’t draw an ISP router at each location. If there is one there, you need to create a static route on your ISP router to describe the subnet that exists beyond your FOG-router. The default route for your FOG-router should be your ISP router. The default route for your target computers should be the deployment network interface on your fog server. This will give you the two way routing. At your HQ site, if your target computers need to communicate with the FOG Master node, you may need to create a static route on your ISP router to define each subnet at each remote location. This is a pure routing issue and not related to FOG imaging.

thebrennan47

Hey thanks @george1421 !

I was actually temporarily pulled off of this project for a few weeks – which is why this thread is so old. I don’t believe I am the one you are referring to if it was a couple of weeks ago.

Good news — I made some edits to the ip tables and it looks like the connection is now working in both directions. So it looks like I am getting very close! Thanks for the help with that

I once again tried a capture, but I got the following error. Any ideas?

Also, I looked at the file in a web browser and it contains the following:

#!ipxe
set fog-ip
set fog-webroot
set boot-url http://${fog-ip}/${fog-webroot}
cpuid --ext 29 && set arch x86_64 || set arch i386
goto get_console
:console_set
goto MENU
:alt_console
goto MENU
:get_console
console --picture http:///fog/service/ipxe/ --left 100 --right 80 && goto console_set || goto alt_console
:MENU
menu
item --gap Host is NOT registered!
item --gap -- -------------------------------------
choose --default fog.local --timeout 0 target && goto ${target}
:bootme
chain -ar http:///fog/service/ipxe/boot.php##params ||
goto MENU
autoboot

Also, the following is the TFTP setting in the Web UI for my Fog master server: /var/www/fog//service/ipxe/

george1421

@thebrennan47 Well now after looking at that picture my neck hurts…

There is a whole bunch of craziness in that picture.

What is host 192.168.1.1?
What is host 10.0.80.49?
And the last issue is the line with http///fog/service/ipxe in it. That should have an ip address

I see it tftp booting from 192.168.1.1 then connecting to 10.0.80.49 (which might be a fog server) but then the 10.0.80.49 gives it bad IP address. That should be the IP address of a fog server or a storage node and not be blank.

thebrennan47

@george1421 apologies for the crooked picture. Also I can clear up those ip addresses for you

10.0.88.49 is the DHCP/TFTP/Storage Node on interface #1
192.168.1.1 is the router address for interface #2

This seems correct I think? The weird thing is the file/directory does exist when I browse to it via a web browser
(http://10.0.88.49/fog/service/ipxe/boot.php)

george1421

@thebrennan47 It might help if you updated your picture with IP addresses but I’m going to guess what I see.

The FOG server management console is 10.0.80.49??

I could understand if 192.168.1.1 is on the deployment LAN for a storage node. Because dhcp would tell it to get the iPXE file from 192.168.1.1. The file its getting is default.ipxe. Inside the storage node 192.168.1.1 there is a file called /tftpboot/default.ipxe and it should point to the fog master server. That is where the boot.php is coming from. boot.php will determine what storage node to boot bzImage from. That is where its falling down.

Sebastian Roth

@thebrennan47 Good you posted the iPXE code output here. To me this looks as if FOG_WEB_HOST is not set, see set fog-ip on the second line is also empty. Please check in the FOG settings -> FOG configuration page on the web interface.

thebrennan47

@george1421 @Sebastian-Roth

10.0.88.49 was the DHCP / Storage Node. The fog management console is hosted at 10.0.88.42. I updated the default.ipxe file to point to the correct server and that fixed it! Thanks for the help with that

After a reboot on my client, I now get into the fog upload page and the process begins; but quickly terminates do to a mount failure for the /images folder. I am guessing it is a permissions issue? I am currently looking into but I figure you guys may have seen this one before so I wanted to ask real quick. Sorry for the spam of questions on this thread… I am getting really close to getting this working though it looks like

george1421

@thebrennan47 Boy, you are just full of good news.

OK what is 10.2.102.49? You keep throwing new IP addresses at this poor pxe booting client?

thebrennan47

@george1421

I actually don’t know where it is getting this IP… This particular machine has been moved in the past… so it may be possible that this is the old IP and it needs to be updated somewhere…

Any ideas where/what file this IP is being pulled from? I did a grep for it but had no luck…

george1421

@thebrennan47 Well I would start looking through your storage node configurations.

Slightly off topic, but along the same lines. Do you have the location plugin installed? And do you have your storage nodes assigned to a location?

thebrennan47

@george1421 I haven’t set the location plugin up yet – but that does seem really useful I will likely try to do that next

I found the below post which seems like a similar issue… however the IP address field has the correct value in my case. Is this value cached anywhere? I will try rebooting the fog master node and see if that helps

https://forums.fogproject.org/topic/8828/could-not-mount-images-folder-wrong-ip-setting/3

george1421

@thebrennan47 Well without the location plugin FOG sees all storage nodes at the same location. So it will try to load balance between the storage nodes. So its possible that you might have a client at site D trying to pxe boot and image from Site A. Because as far as FOG is concerned they are at the same location. With the location plugin, you assign storage nodes to locations and then when you register clients, you assign clients to a location so they know what storage node to use.

thebrennan47

@george1421 Alrighty I will go ahead and install the location plugin and see if that helps — but I don’t think that is the issue here because there is no machine that actually exists at this IP Address (10.2.102.49). It is an old ip address from before we moved this machine. So it seems something needs to still be updated somewhere.

I found another post that seems to mention the same problem as well. He mentioned having to change it in two places, 1: The web UI for the storage node, and 2: “a config file”

https://forums.fogproject.org/topic/6764/cannot-mount-ip-images-wrong-ip-is-used

However he doesn’t mention which config file. I have checked interfaces, .fogsettings, dhcpd.conf, the tftp, and also the /tftpboot/default.ipxe config. No luck so far though. Any idea what file he may be talking about?

Sebastian Roth

@thebrennan47 Any news on this? The wrong IP is probably set for the Storage Node in the web UI. Go to “Storage Management” and edit the Storage Node (usually called “DefaultMember”).

Host seems reachable by fog, but is not reaching PXE fog menu

205

11.6k

17.1k

154.6k