..and one FOG-VM to rule them all.

[george1421]

@lof For your dnsmasq configuration.

1. Make sure that dnsmasq version 2.76 or newer is installed with dnsmasq -v command.
2. Use the following config file for dnsmasq. Save it in /etc/dnsmasq.d and save it as ltsp.conf

# 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

Make sure you change <fog_server_ip> to the current IP address of your FOG server. The make fog mobile script (only needs to be run once since it sets up a cron job) will modify this file when it runs. This dnsmasq configuration will give you dynamic boot file name based on the pxe booting client. (bios or uefi).

[Wayne Workman]

@george1421 the scripts re-configure dnsmasq every time the IP of the box changes. See line 216 in the script.

[LOF]

@george1421 Thanks George/Wayne, so won’t the MakeFogMobile install.sh script install the current version of dnsmasq? Are you saying to run that script and then put the ltsp.conf with the content you listed into /etc/dnsmasq.d/ ? Will there already be a ltsp.conf file in there that I’ll need to overwrite? Just want to get all my ducks in a row before I try this.

[george1421]

@lof you need to install dnsmasq manually. Its not a direct function of fog.

[LOF]

@george1421 Thanks George, so the mobile script doesn’t install dnsmasq as Tom said yesterday? Sorry, that’s where I got the idea that the dnsmasq install would already be covered during the MakeFogMobile install.

[george1421]

@lof Mmmmm. I’m pretty sure that dnsmasq is not added by the script, but the script will manage dnsmasq if its installed. Wayne wrote the script so he would know for sure. But, if it was me, I would just install dnsmasq and be done with it.

[LOF]

@george1421 Oh ok, I’m looking at the tarballs now: www.thekelleys.org.uk/dnsmasq/ Look’s like dnsmasq-2.78.tar.gz is what I need. The software manager in Linux Mint has it listed but it’s only showing version 2.75 It says I already have the Dnsmasq-base (executable/docs) installed but its version 2.75 Do you think I should uninstall that?

[george1421]

@lof well you need the fixes in 2.76. I’m a bit surprised that mint is not current.

[edit] I just checked and ubuntu 16.04 is a bit behind. They only support 2.75 as you noted. Newer versions of ubuntu do support later releases of dnsmasq. I do have instructions on compiling your own copy. It should work with the tarball you found. I have not tested it with 2.78, but I guess try: https://forums.fogproject.org/topic/8725/compiling-dnsmasq-2-76-if-you-need-uefi-support

[LOF]

@george1421 When I created the initial VM a few weeks ago, I installed all available updates before installing FOG but haven’t installed any after. I remember a couple years back when I had FOG installed, I installed available updates for Mint and it broke my FOG install. Re-running the FOG install fixed the issue but I’ve been afraid of installing OS updates ever since.

[Wayne Workman]

@george1421 said in ..and one FOG-VM to rule them all.:

I’m pretty sure that dnsmasq is not added by the script,

It does install the latest version of dnsmasq available from the OS’s package manager.

If 2.76 is required for UEFI, this can be manually installed before hand.

[LOF]

@george1421 Thanks George, so what if I don’t need UEFI support? I haven’t encountered a situation yet where I couldn’t do my deployments with UEFI disabled. I usually disable it, enable legacy, deploy the image and then turn UEFI back on. Would dnsmasq 2.75 suffice for that?

[george1421]

@lof yes, if no uefi then you don’t need 2.76 and also don’t use my configuration. You need the older 2.75 config and earlier. In your case you will need to create a link from undionly.kpxe to undionly.kpxe.0 and ipxe.efi to ipxe.efi.0 since the older releases always added .0 onto the end of what ever the configuration file calls for.

[LOF]

@george1421 Ok great, then in my case I just do the MakeFogMobile install, create those links and go with that. Thanks for all the help. I know others out there definitely want UEFI support, especially since it was announced that hardware vendors will eventually pull the plug on legacy. I’ll cross that bridge when it happens, hopefully by that time Linux Mint will include a more current version of dnsmasq

One last question, should I be concerned about installing OS updates after installing FOG? Do OS updates still break things like PHP? Does doing a re-install of FOG still address those issues? Ok that’s three questions, …sorry.

[sudburr]

@wayne-workman In an enterprise environment with established DHCP and DNS one would quickly have their ass hauled onto the carpet if multiple roaming rogue DHCP and DNS servers were deployed using the combined solution offered for mobilizing FOG.

I think it would be better to also offer a FOG-centric version of the mobile FOG solution that doesn’t involve tacking on unnecessary and potentially career-damaging services.

I’m hoping the development of 2.0 hasn’t strayed from a long lost posit that promised to stay focused on FOG first. Compartmentalize solutions by addressing DNS and DHCP services as separate non-FOG accessories.

[Wayne Workman]

@sudburr said in ..and one FOG-VM to rule them all.:

In an enterprise environment with established DHCP and DNS one would quickly have their ass hauled onto the carpet if multiple roaming rogue DHCP and DNS servers were deployed using the combined solution offered for mobilizing FOG.

Understood. Good thing the project lists exactly what it does so that one’s ass can avoid being hauled to the carpet. Also, the community scripts is open for all to contribute. You can edit the existing code or create an entire copy and modify it.

@sudburr said in ..and one FOG-VM to rule them all.:

I think it would be better to also offer a FOG-centric version of the mobile FOG solution that doesn’t involve tacking on unnecessary and potentially career-damaging services.

A good starting point for this would be the updateIP script:
https://github.com/FOGProject/fog-community-scripts/tree/master/updateIP

[LOF]

Thanks for all the help so far. I ran the mobile install as root and it finished. I also did some initial testing to ensure I could access the FOG console after changing my VM’s network settings to use DHCP. It worked fine and even worked when I switched from a bridged to a NAT connection in VMware Workstation. I didn’t have time to try PXE-booting a test machine yet but will do that next.

Also, re: what @sudburr said, …I definitely see the concern and already took that into consideration before pushing ahead with this. In my particular situation it won’t be an issue since the locations I’ll be using this at don’t have any hardware set to PXE-boot other than VOIP phones and those operate on a separate VLAN. Also, I’ll be using my FOG VM very infrequently and it will only be in operation when I’m imaging new machines. Anyway, I think this is going to be the best/easiest way to go for me.

[LOF]

@george1421 Hi George, quick question for you… where are the undionly.kpxe and ipxe.efi files supposed to reside? I see two versions of undionly.kpxe in /Downloads/fog_1.4.4/packages/tftp and /Downloads/fog_1.4.4/packages/tftp/10secdelay ipxe.efi = /fog_1.4.4/packages/tftp /fog_1.4.4/packages/tftp/10secdelay /fog_1.4.4/packages/tftp/10secdelay/i386-efi /fog_1.4.4/packages/tftp/i386-7156-efi and /fog_1.4.4/packages/tftp/i386-efi

Which location should I create the symlink from? i.e., symlink to undionly.kpxe.0 / ipxe.efi.0

[Wayne Workman]

@lof said in ..and one FOG-VM to rule them all.:

where are the undionly.kpxe and ipxe.efi files supposed to reside

After you install fog, they are located on the server in /tftpboot

[george1421]

@lof Wayne is right, both are in /tftpboot. That is where you need to create the symbolic link between undionly.kpxe and undionly.0 (note the name change from before) as well as ipxe.efi and ipxe.0. Then in your config file for dnsmasq you only include the base names of undionly and ipxe not with the extension. Its a quirk with version 2.75 and older that you have to accept.

Also note the i386 directory is for 32bit efi images. Those systems are not very common any more. Many of the early Apple systems were 32 bit only uefi requiring special boot kernels.

[LOF]

@george1421 Thanks for the info, so forgive my rustiness at the CLI but when I try ln -s /tftpboot/undionly.kpxe /tftpboot/undionly.0 I keep getting “ln: failed to create symbolic link ‘undionly.0’: File exists” What am I doing wrong?