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



  • First, something I’ve been meaning to get off my chest for a while. A huge THANK YOU to the FOG Team for all the hard work and for making such an incredible imaging solution available to the masses! I’ve never seen such a flexible, free, easy to use solution and it’s become my default, even over all the expensive/enterprise alternates out there.

    I don’t know whether or not anyone else has asked before, I’m not sure what search term to use in the forums. I use FOG in many different deployments, including as a Linux Mint VM w/Vmware Workstation on my primary laptop. It’s often that I need to use FOG at different office locations with different private network subnets. It’s really not a big deal for me to spin up several different FOG vm’s, each with their own unique static IP address but I was wondering if there’s an easy way I could quickly switch the static IP address and corresponding address defined in FOG so that I can use a single FOG-VM instead of multiple? I believe I ran across instructions in the forums a while back for re-IP’ng a FOG install but it seemed too complex/time consuming to get working right and when I was trying to do it, eventually threw up my hands and just re-installed Mint/FOG. Maybe this is more of a feature request and maybe it’s already been added but I’d appreciate it if someone could respond and tell me if this would be possible or not. I’d rather not have to edit the FOG configuration in multiple places and a bunch of configuration files in LM to accomplish this each time.



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

    I changed the network configuration for my vm in VMware Workstation from Bridged over to NAT’d in order to test

    Yeah that would be why. Broadcast messages do not traverse to different broadcast domains by default - because that would create network storms (yes, that’s a real technical term). You need the VM to be in bridged mode so it can hear DHCP requests.

    You do not need to ‘burn things down’. Just switch it to bridged. The MakeFogMobile scripts will reconfigure everything for you when a new IP is received.



  • Thanks George/Wayne, so the DHCP server at the office I was at yesterday didn’t have options 66/67 set so it’s not that and the ltsp.conf showed the correct IP addresses. I thinking now I may have been shooting myself in the foot because I previously mentioned that I changed the network configuration for my vm in VMware Workstation from Bridged over to NAT’d in order to test. I think that’s somehow related because I did that yesterday shortly before leaving and noticed default.ipxe was getting served from a new address, …from the NAT’d LAN address my vm was assigned when I switched over to a NAT’d connection. A NAT’d network configuration won’t work because clients I try to PXE-boot can’t see the FOG server, even when connected to the same switch. The only network configuration under VMware Workstation I’ve ever been able to get FOG working correctly with is a Bridged connection. At this point I’m probably just going to burn things down and start over, i.e., re-run the FOG install and also the dnsmasq installer. But this time I’ll leave it on the Bridged connection and won’t switch it. I’ll let you know how it goes after that.



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

    I’m at a loss where it’s getting that from.

    If the DHCP server in that broadcast domain has options 66 & 67 configured, machines may decide to use that rather than the proxy DHCP options provided by dnsmasq. Each machine’s firmware is different - there’s really no consistency here (yes, shame on you manufacturers Dell, HP, IBM).

    So, check the DHCP server settings. Try removing options 66/67 and see what happens.


  • Moderator

    @lof Can you get a clear video of what its doing wrong?

    What IP address do you see? Is it something from this server’s past?

    FWIW, the .fogsettings file is only updated when the fog installer is used.

    Ah, I found it.
    https://github.com/FOGProject/fogproject/blob/master/src/ipxe/src/ipxescript

    the iPXE kernel has a script built in, the last line of the above link is the answer.

    chain tftp://${next-server}/default.ipxe
    

    So the dhcp server (or dnsmasq) is telling the iPXE kernel where to go next. So check your ltsp.conf file to see if there is an old address in there.



  • @lof I spent a little time searching the forums and I checked every configuration file my searches referenced. I checked /tftpboot/default.ipxe and it’s got the right IP. I also checked /opt/fog/.fogsettings and it had the correct IP but wrong router/dns addresses I changed those to reflect my current environment and restarted my FOG server VM but it still tries serving up default.ipxe from the wrong IP. I’m at a loss where it’s getting that from. On the bright side, I’m getting a really good CLI/Vi refresher. ;-)



  • @wayne-workman Thanks Wayne, so I don’t think that’s the problem. sudo ufw status shows inactive so it’s not the firewall. I decided to test at a different office location today and just discovered that tftp is trying to serve up from the IP from the LAN I was on yesterday via http://xxx.xxx.xxx.xxx/default.ipxe even though /etc/dnsmasq.d/ltsp.conf is showing the correct IP for my current DHCP lease for the LAN I’m on now. Where could it be getting that old address from? I logged into the FOG console and checked the settings and didn’t see it in there.



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

    That got me further but now I get “Connection timed out” when trying to get to http://fog_server_ip/default.ipxe

    Possibly firewall, possibly SELinux. Look at the CentOS 7 pre-config here:
    https://wiki.fogproject.org/wiki/index.php?title=CentOS_7#Continue_pre-config



  • @george1421 Yeah so I was looking here https://wiki.fogproject.org/wiki/index.php?title=Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server …and saw where it shows how to make the symbolic links toward the bottom. undionly.0 already existed so I used cp undionly.kpxe undionly.0 ipxe.0 didn’t exist so ln -s ipxe.efi ipxe.0 worked. After doing that I tried pxe-booting a laptop and it failed saying no tftp file found so I realized I hadn’t modified my /etc/dnsmasq.d/ltsp.conf file. Here’s what I currently have in that file:

    #port=0
    tftp-root=/tftpboot
    dhcp-boot=undionly.kpxe,fog_server_ip,fog_server_ip
    dhcp-option=17,/images
    dhcp-option=vendor:PXEClient,6,2b
    dhcp-no-override
    pxe-prompt=“Press F8 for boot menu”,60
    pxe-service-X86PC,“Boot from network”,undionly
    pxe-server=X86PC,“Boot from local hard disk”,0
    dhcp-range=fog_server_ip,proxy

    After I modified that file, removing the .kpxe at the end of the 3rd line up from the bottom, I issued sudo service dsnmasq restart That got me further but now I get “Connection timed out” when trying to get to http://fog_server_ip/default.ipxe

    Any ideas?


  • Moderator

    @lof Does undionly.0 already exist?

    I can tell you no matter which way I type in the ln command I always get the parameters backwards. So I’m not the best at first time right. The ln command should be ln -s /path/to/sourcefile /path/to/symlink so your example looks right. You might have to use sudo for your OS to create sym links if the destination sym link doesn’t already exist.



  • @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?


  • Moderator

    @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 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 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



  • 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. :)



  • @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



  • @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.



  • @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. ;-)


  • Moderator

    @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.



  • @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?


 

583
Online

5.4k
Users

12.6k
Topics

118.7k
Posts