Posts made by jgiovann

@Sebastian-Roth It turns out I was getting the same issue even with the client and FOG server resided on the same subnet. However not a problem in a virtual environment.

… after capturing port traffic with wireshark and doing some investigation, it turns out that turning off the spanning-tree protocol on the provisioning port allowed the client to register with the FOG server.

In a real production network (where turning off spanning tree is not be allowed), is it therefore possible to re-configure the FOG server to wait longer or retry more times before it gives up the registration retry loop ?

@Sebastian-Roth I rebuilt the server from scratch using the latest stable version of FOG (1.5.5). Also checked the firewall between the 2 subnets - there are no rules blocking communication between the client and FOG server. I also disabled SELinux and stopped the firewall on the FOG server (for the time being).

• Continuous pings to the target client show that the interface is correctly assigned an IP address after it boots into the FOG menu. However as soon as the registration process is launched, the client loses connectivity and is no longer able to communicate with the FOG server

64 bytes from 192.168.2.89: icmp_seq=85 ttl=64 time=40.2 ms
64 bytes from 192.168.2.89: icmp_seq=86 ttl=64 time=28.0 ms
64 bytes from 192.168.2.89: icmp_seq=87 ttl=64 time=0.301 ms
... (at this point the registration process is launched)
From 192.168.2.12 icmp_seq=128 Destination Host Unreachable
From 192.168.2.12 icmp_seq=129 Destination Host Unreachable
From 192.168.2.12 icmp_seq=130 Destination Host Unreachable

• I’m attaching snippets of both the error log

[Wed Dec 12 10:36:40.973608 2018] [core:notice] [pid 5259] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
[Wed Dec 12 16:12:01.720797 2018] [mpm_prefork:notice] [pid 5259] AH00170: caught SIGWINCH, shutting down gracefully
[Wed Dec 12 16:12:34.842582 2018] [core:notice] [pid 5266] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
[Wed Dec 12 16:12:34.852140 2018] [suexec:notice] [pid 5266] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Wed Dec 12 16:12:34.954624 2018] [auth_digest:notice] [pid 5266] AH01757: generating secret for digest authentication ...
[Wed Dec 12 16:12:34.956680 2018] [lbmethod_heartbeat:notice] [pid 5266] AH02282: No slotmem from mod_heartmonitor
[Wed Dec 12 16:12:35.121620 2018] [mpm_prefork:notice] [pid 5266] AH00163: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips mod_fcgid/2.3.9 PHP/5.6.39 configured -- resuming normal operations
[Wed Dec 12 16:12:35.121645 2018] [core:notice] [pid 5266] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'

• … and the access_log (filtered by the target client machine)

192.168.2.89 - - [12/Dec/2018:16:08:04 +1100] "GET /fog/service/ipxe/init.xz HTTP/1.1" 200 19286132 "-" "iPXE/1.0.0+ (960d1)"
192.168.2.89 - - [12/Dec/2018:16:12:41 +1100] "POST /fog/service/ipxe/boot.php HTTP/1.1" 200 2701 "-" "iPXE/1.0.0+ (960d1)"
192.168.2.89 - - [12/Dec/2018:16:12:42 +1100] "GET /fog/service/ipxe/bg.png HTTP/1.1" 200 21280 "-" "iPXE/1.0.0+ (960d1)"
192.168.2.89 - - [12/Dec/2018:16:14:54 +1100] "GET /fog/service/ipxe/bzImage HTTP/1.1" 200 8430224 "-" "iPXE/1.0.0+ (960d1)"
192.168.2.89 - - [12/Dec/2018:16:14:54 +1100] "GET /fog/service/ipxe/init.xz HTTP/1.1" 200 19286132 "-" "iPXE/1.0.0+ (960d1)"

• I double checked the URL redirect, I was meant to say that http://192.168.0.87//fog//index.php is re-directed to http://192.168.0.87//fog//management/index.php
  . Is this the correct URL ? The re-directed URL is the management login page

As a final option, could I add a 2nd network interface on the FOG server which has an IP address in the 192.168.2.0/24 subnet ?

@Sebastian-Roth

Getting closer …

When I enter the URL http://192.168.0.87//fog//management/index.php from a client in the 192.168.2.0/24 subnet (as reported by the host registration step) I get the default FOG Project login screen (not able to attach a screenshot). i.e. I can connect to the URL

Note:

• The URL is redirected from http://192.168.0.87//fog//management/index.php to http://192.168.0.87//fog//management/index.php

• Are the double slashes significant in the URL ?

• I also checked for TCP connections on the FOG server. There are no TCP connections on port 80 via IPv4. The primary DHCP server is configured for IPv4 (not IPv6).

# netstat -ant | grep -v 127.0.0.1 | head -15
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 0.0.0.0:60313           0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:2049            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:20048           0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:38871           0.0.0.0:*               LISTEN     
tcp        0      0 192.168.0.87:22         192.168.2.12:44596      ESTABLISHED
tcp        0      0 192.168.0.87:50226      192.168.0.216:389       ESTABLISHED
tcp        0      0 192.168.0.87:22         192.168.2.12:39532      ESTABLISHED
tcp        0      0 192.168.0.87:22         192.168.2.12:39414      ESTABLISHED
tcp6       0      0 ::1:25                  :::*                    LISTEN     

# netstat -ant6 | grep -v 127.0.0.1 | head -15
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp6       0      0 ::1:25                  :::*                    LISTEN     
tcp6       0      0 :::443                  :::*                    LISTEN     
tcp6       0      0 :::56638                :::*                    LISTEN     
tcp6       0      0 :::2049                 :::*                    LISTEN     
tcp6       0      0 :::39500                :::*                    LISTEN     
tcp6       0      0 :::111                  :::*                    LISTEN     
tcp6       0      0 :::80                   :::*                    LISTEN     
tcp6       0      0 :::20048                :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0 192.168.0.87:80         192.168.2.12:34100      TIME_WAIT  
tcp6       0      0 192.168.0.87:80         192.168.0.87:53770      TIME_WAIT  
tcp6       0      0 192.168.0.87:80         192.168.0.87:53604      TIME_WAIT  
tcp6       0      0 192.168.0.87:80         192.168.2.12:34116      TIME_WAIT  

I can provide more details.

@Sebastian-Roth Thanks for the recommendation. Admittedly the option you’ve mentioned is already in the DHCP config

subnet 192.168.2.0 netmask 255.255.255.0 {
        option routers             192.168.2.1;
        option subnet-mask         255.255.255.0;

The target machine correctly obtains an IP address (statically assigned) when PXE booting into the FOG menu. A truncated snippet of the log files is shown here

Dec 06 16:40:01  DHCPOFFER on 192.168.2.89 to 48:4d:7e:d5:66:a5 via 192.168.2.1
Dec 06 16:40:02  DHCPDISCOVER from 48:4d:7e:d5:66:a5 via 192.168.2.1
Dec 06 16:40:02  DHCPOFFER on 192.168.2.89 to 48:4d:7e:d5:66:a5 via 192.168.2.1
Dec 06 16:40:04  DHCPREQUEST for 192.168.2.89 (192.168.0.20) from 48:4d:7e:d5:66:a5 via 192.168.2.1
Dec 06 16:40:04  DHCPACK on 192.168.2.89 to 48:4d:7e:d5:66:a5 via 192.168.2.1

The problem is when one attempts to register the host that there is no response on the interface eth0

• Perhaps I should step back and not run dnsmasq in the first place, i.e. simplify the setup ? In fact if I stop the dnsmasq service (on the FOG server), I can boot into the FOG menu

• The log files on the FOG server don’t provide any details as to what is going on here. Perhaps I need to tweak the FOG server configuration to explicitly tell it where to find the DHCP server and other relevant details ?

@Sebastian-Roth

Looks like your advice was very useful. In the end I found the following setting allowed the client (from the 192.168.2.0/24 subnet) to boot into the FOG menu (192.168.0.87):

   next-server 192.168.0.87;
    # Select the correct PXE boot file depending on whether Legacy or UEFI booting is requested
    class "pxeclients" {
            match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
            if option architecture-type = 00:07 {
                    filename "intel.efi";
            } else {
                    filename "undionly.kkpxe";
            }
    }

The only issue now is that I’m getting the following message when attempting to do a Quick Registration of the client:

udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: no lease, failing
Either DHCP failed or we were unable to access http://192.168.0.87/fog//index.php for connection testing
No DHCP responce on interface eth0, skipping it.
Failed to get an IP via DHCP! Tried on interfaces(s): eth0
Please check your network setup and try again!
Press enter to continue

Note the DHCP server is not running on the FOG server but the production server.

Perhaps I need to do some more tweaking ?

Thanks to the replies so far. Sebastian, I thought I’d trial the FOG server on a non-production machine first, not to mention the server that runs a DHCP service also runs other critical services.

George, the tips for setting up a dhcp-helper list are very useful. Admittedly I’ll need to work with the network admin to resolve this.

I’ll be happy to provide an update once some progress is made.

Greetings,

I’ve successfully setup a FOG server with a DNSmasq service running, i.e. there is an existing production DHCP server (RHEL 7.4)

• Clients in the same subnet as the FOG server (192.168.0.1/24) can communicate with the FOG server (192.168.0.87) when PXE booting

• However clients on another subnet (192.168.2.1/24) are not able to communicate to the FOG server via PXE booting

• What additional options need to be configured on the DHCP server (not the FOG server) to direct/help clients in the 192.168.2.1/24 subnet to PXE boot off the FOG server ?

Going back to the installation script I can see the following suggestion:

• On a Linux DHCP server you must set: next-server and filename

I can provide more details as required.

John

@george1421 No problem. Admittedly some IT folks don’t mind documentation (I’ll count myself) but am not up to speed with FOG and and just tipping my toes in the water.

Thanks again. By the way I noticed the post is marked as “Unsolved”. Can I change it to “Resolved” or is something you or the moderator are happy to do ?

Thanks for the fast responses.

George, your tips helped. Simply a case of the documentation is not up-to-date (https://wiki.fogproject.org/wiki/index.php?title=ProxyDHCP_with_dnsmasq)

It came down to a number of tweaks and looking at the ltsp.conf file you provided.

1. Confirmed the dnsmasq version running on the FOG server was later than the one you recommended
   dnsmasq -v | head -1
   Dnsmasq version 2.76 Copyright 2000-2016 Simon Kelley

2. Removed the sym links

3. The pxe-service entries didn’t have the full filenames in the last field (e.g. undionly instead of undionly.kpxe)
   pxe-service=X86PC, “Boot to FOG”, undionly.kpxe
   pxe-service=X86-64_EFI, “Boot to FOG UEFI”, ipxe.efi
   pxe-service=BC_EFI, “Boot to FOG UEFI PXE-BC”, ipxe.efi

When I PXE boot the client, I am now presented with the FOG Project boot screen.

Much appreciated

Greetings,

I’m new to the FOG project and seems quite promising with an active community. In any case I was wondering if any one has has success in setting up a FOG server (as a DHCP proxy server) running CentOS 7.5

I’ve followed the guide at: https://forums.fogproject.org/topic/12133/fog-on-existing-dhcp-server, to the point where a client successfully obtains an IP address from the primary DHCP server and subsequently successfully communicates with the FOG server (running the dnsmasq service).

However I get the following from the client side:

Auto-select:
Boot to FOG

BOOT SERVER IP: 192.168.0.85
TFTP.
PXE-T01: File not found
PXE-E3B: TFTP Error - File not found
PXE-M0F: Exiting Intel PXE ROM
Operating system not found.

The documentation specifies the creation of the following symlinks:
ln -s /tftpboot/undionly.kpxe /tftpboot/undionly.0
ln -s /tftpboot/ipxe.efi /tftpboot/ipxe.0

… what else needs to be configured for a successful boot. Is there anything I need to setup on the FOG server ?

Any tips would be welcomed.