@fog_rob You probably should start your own thread here because your circumstances may be different.

But in general if you follow my guidance below: https://forums.fogproject.org/topic/12116/fog-server-crashing-on-group-deployment/5

of checking in php-fpm (www.conf file) that these settings are in place. You should have a successful group deployment.

pm.max_children  = 50
pm.max_requests = 2000
php_admin_value[memory_limit] = 256

@k-hays Between FOG 1.5.0 and 1.5.1 (or 1.5.1 and 1.5.2 sorry I can’t remember) the developers switched from using the built in php engine in apache to using a dedicated php engine (php-fpm). This was done to address an issue with GUI slowness reported with the new 1.5.x Web GUI on certain distributions. Baseline testing then showed an excellent improvement in GUI responsiveness as well as client check ins were not causing an issue with heavy web server load as they were before.

After 1.5.2 was released the developers started seeing other reports of issues with multicasting and unicasting in larger environment that wasn’t see during development. So certain tweaks to the php-fpm config files were made in 1.5.3 and 1.5.4. Increasing the memory limit even more to 256MB resolved a multicasting issue was discovered after 1.5.4. was released. That setting will be in 1.5.5 when its released in a few months. With these new settings you should see a pretty stable multicasting deployment.

@pa_fog_man said in pxe boot/fog menu:

NBP is too big to fit in free base memory

This tells us that if you sending ipxe.efi and you get this message your target computer is in BIOS/legacy mode. In that case, undionly.kpxe (make sure it spelled right) is the proper boot file for this computer.

You haven’t answer the model of computer in question here.

This setup is not advised at all. FOG is not (currently) configured for public network security. Placing your fog server directly on the internet would surely cause the fog server to be compromised in a very short period of time.

You have several challenges here even if you put a storage node at the remote site.

1. The storage node needs to connect to the FOG server, to use its database. This communication is done over port 3306.
2. During pxe booting, the target computer has to communicate with the main fog server to find the location of its storage node. This communication is done over http.
3. The fog client’s check in to the fog master server to see if there are any jobs to do. This is done over http.
4. Imaging is done over NFS protocol v3 which is inherently insecure.

Thinking about it, you might be better off to deploy a small fog server (like on an intel nuc) to each remote location. Then you could interface with the remote fog server over http/https from your main HQ.

I guess we might need a bit more information on how you plan on imaging.

1. How many systems do you plan on imaging at one time. Understand this may be a by using a multicast or staggered unicast imaging. If you could guess, how many systems that might be imaging at one time?
2. Will the fog server and all clients on the imaging bench be on the same 1GbE network switch? Or is the FOG server in a computer room someplace on its own switch, connect to a network switch on the deployment bench?

From a FOG imaging standpoint the actual system load is not on the FOG server. The FOG server simply moves the image from the hard drives to the network adapter. The heavy lifting in imaging is done at the target computer. The fog server doesn’t need to be a powerhouse server, it does need a good disk subsystem and network connection. FWIW, I have a raspberry pi setup as a fog server. It does work well, but only if you are sending out a single unicast or multicast stream.

@vascomorais said in Fog on Existing DHCP server:

is there a way i could reach my pxe boot from the exterior?

From some place else on the internet? In concept, yes. But you would open both your fog server and target computer up to compromise. Also you would need to configure the remote dhcp server to point/load the boot file from your fog server, plus your fog server would need to have an internet addressable IP address.

Generally, its possible but a bad idea for security reasons.

@pa_fog_man said in pxe boot/fog menu:

No out 60

I’m not sure what that means, maybe no option 60. If so that is good.
What about the target computer, is it in bios or uefi mode? The iPXE boot kernel needs to match the firmware mode of the computer. undionly.kpxe for BIOS and ipxe.efi for UEFI systems.

pfsense is a good option, but not the only one.

If you are using a soho (home router) that doesn’t support dhcp booting options, you can use / install a service on the FOG server called dnsmasq. This is a dhcp proxy service that will supply the boot information only to the pxe booting client.

Just install dnsmasq from your linux distro’s repository. Then edit / create a file called ltsp.conf in the /etc/dnsmasq.d directory. In that ltsp.conf file put in the following :

# Don't function as a DNS server:
port=0

# Log lots of extra information about DHCP transactions.
log-dhcp

# Set the root directory for files available via FTP.
tftp-root=/tftpboot

# The boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,,<fog_server_IP>

# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override

# inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

# Set the boot file name based on the matching tag from the vendor class (above)
dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,<fog_server_IP>
dhcp-boot=net:UEFI,ipxe.efi,,<fog_server_IP>
dhcp-boot=net:UEFI64,ipxe.efi,,<fog_server_IP>

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Booting FOG Client", 1

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
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

dhcp-range=<fog_server_ip>,proxy

Don’t forget to replace <fog_server_ip> in the above text with the IP address of your fog server. The tag appears many times.

If your distro has a config file in that directory, remove it and only place one config file (ltsp.conf) in that directory path.

One other point to check, make sure the version of dnsmasq installed is 2.76 or later. You can find out by using the following command: dnsmasq -v

Interesting, I have not seen that with any Dells we have. For the FOG iPXE menu to “disappear” that would mean the iPXE kernel would either have crashed or you have already register the target computer and scheduled a task for it.

Lets start out with some basics.

1. What you do have configured for dhcp options 66 and 67. Also be sure you don’t have dhcp option 60 set.
2. What model of dell computer is this?
3. Is this computer in uefi or bois mode?
4. Is the target computer and the fog server on the same subnet?

@k-hays Not for the worker threads. We are finding (so far) 256MB per php-fpm worker is working well. Run with these setting and for sure provide feedback. Once we get these number working stable on all that are having issues we will include them in the fog 1.5.5 update.