Idea: Two "next-servers" coexisting on the same vlan
-
I am wondering if it is possible for a FOG and SCCM server to both be available on the same VLAN. So my idea is to do the following:
Create an tftp server that loads an ipxe menu. On this menu, we will be met with two options: FOG and SCCM. So our DHCP server will tell pxe clients that this initial tftp server will load the menu.
Now I believe that ipxe can chain another tftp server and load files. So I am pretty sure that this can be done via menu scripting. Kind of like how FOG can have custom ipxe entries for stuff like PMagic and WinPE. What I am unsure of is how ipxe will handle sending clients to the respective servers for loading files. I know that booting FOG ipxe via USB works without the DHCP server specifying where the next-server is, because the bootx64.efi image already has the menu scripts in place that tell the client “OK the FOG server is here at 1.2.3.4, boot”.What are your thoughts? Would be really cool to have SCCM and FOG because we use SCCM for our stock Windows image and we use FOG for department-specific customized Windows images.
-
@brakcounty I know I worked this out just recently. Luckily I was able to find this port from the near past: https://forums.fogproject.org/post/146970
It shows how to create a custom FOG iPXE menu. It auto selects the right windows boot loader for the hardware platform. Its not clear from that thread if there was a problem with the ipxe menu or not. But it should get you started.
Now you may need to turn off the netboot service in WDS/SCCM. This is a proxydhcp service that will override the settings of dhcp options 66 and 67. This WDS netboot service is the equivalent to dnsmasq in the linux world.
-
@george1421 said in Idea: Two "next-servers" coexisting on the same vlan:
@brakcounty I know I worked this out just recently. Luckily I was able to find this port from the near past: https://forums.fogproject.org/post/146970
DUDE! Did that work for you?? That looks so simple and perfect!
And I did not know about the WDS netboot service, as I never really had access to a WDS box to see. I’m not the super-sysadmin at my job
-
@brakcounty said in Idea: Two "next-servers" coexisting on the same vlan:
Did that work for you??
I can’t answer if that worked, I don’t have WDS/SCCM on my campus. But it should work.
FWIW SCCM is an umbrella program that includes many other services like WDS and MDT into one package.
-
@george1421 Well that I knew about SCCM. But after talking with my network team, they did not have option 66/67 set on the DHCP server. They only defined the SCCM server as a DHCP-Relay, no filenames or DHCP options set. So right there I knew something was different about how files were served from dnsmasq vs WDS netboot service. But yeah that post is more than just a start!
Now I could go that rote and add WDS to the FOG ipxe menu, OR be ambitious and build a “main” tftp server menu that can chain FOG and WDS. Thinking maybe a raspberry pi or something. But for now using the FOG to chain WDS is an excellent start.
-
@brakcounty said in Idea: Two "next-servers" coexisting on the same vlan:
Now I could go that rote and add WDS to the FOG ipxe menu, OR be ambitious and build a “main” tftp server menu that can chain FOG and WDS. Thinking maybe a raspberry pi or something. But for now using the FOG to chain WDS is an excellent start.
I’m not sure I’d add anymore hardware to the mix for no real benefit. One might think about creating a custom default.ipxe file (understand that the fog installer will overwrite this file) with a “pre” fog menu. Asking if the admin wants to turn left or right. If the answer is wds then press option 1 then chain load into WDS. if fog then press option 2 and chain load into boot.php. The default.ipxe file is just a text file that could be customized to your needs, but again make sure if you tweak that file you have a backup because when you upgrade FOG that file will be rewritten. If you want to see the magic that goes on behind the FOG iPXE menu just point your browser to
http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00and use that code for the basis of your custom default.ipxe script. -
@george1421 Yeah I’ll just keep the FOG server as the primary PXE server. Question though: Since my primary FOG server has two interfaces in use, one for imaging (offline imaging switch) the other for management (prod network), I’d have to first disable DHCP and I’d have to tell dnsmasq to serve tftp on the prod interface right?
-
@brakcounty Actually your issue is a bit more complex, but not impossible. Your imaging and business networks have different IP addresses. Normally dnsmasq will bind to all interfaces it sees when it starts. In your case you only want to bind dnsmasq to your dedicated imaging network. If you want to run dnsmasq on the business network you will need a new ltsp.conf file that has the details in it that defines the business lan interface on the fog server. For PXE booting this isn’t aproblem, you you create a new dnsmasq instance and point to the ltsp.conf file that is specific to the business network interface. The problem will be with FOG in that it only will post the Ip address of its imaging network, event if the pxe boot comes from the business network. FOG wasn’t designed to image with multiple interfaces.
-
@george1421 Yes and there is also the nfs server that would have to bind to the other interface. Looking at the boot.php I see the “set fog-ip 10.0.0.10” string. I’d have to change any instance of “10.0.0.10” to my prod network interface IP address. Or is it not that simple?
EDIT: So NFS isn’t affected. I just mounted my FOG’s NFS share via prod interface.
-
@brakcounty Yes the only stumbling block is FOG program that only references a single interface the other services can and do bind to multiple interfaces or specific interfaces with different config files being used.
-
@george1421 Would it be easier to re-run the FOG setup script and just change the FOG IP and disable DHCP? I could also define our existng DHCP server during the setup.
-
@brakcounty said in Idea: Two "next-servers" coexisting on the same vlan:
Would it be easier to re-run the FOG setup script and just change the FOG IP and disable DHCP? I could also define our existng DHCP server during the setup.
Probably good idea to check out the docs on changing a FOG server’s IP: https://docs.fogproject.org/en/latest/reference/change_fog_server_ip_address.html
-
@george1421
Just tested it with my USB boot method to load ipxe in a vm, the menu item was present but when I tried to boot it, I got this error:
These are the parameters I have set as per the your post:
set next-server our SCCM serveriseq ${platform} efi && goto is_wds_efi || goto is_wds_bios
:is_wds_efi
set wds-bootfile \boot\x64\wdsmgfw.efi
goto wds_boot:is_wds_bios
set wds-bootfile \boot\x64\wdsnbp.com:wds_boot
set filename ${wds-bootfile}
set net0.dhcp/filename ${wds-bootfile}
set proxydhcp/filename ${wds-bootfile}
chain tftp://${next-server}${wds-bootfile} || goto MenuAfter looking at the folder structure, I see a folder that our sysadmin setup that has a folder called Boot, but no file called “wdsmgfw.efi” exists.
-
Actually found the files but it keeps saying the same error message. I corrected the path in the script. We disabled the PXE service on the SCCM server, so I am wondering if that also disabled TFTP which is why the files can’t be found.
-
@brakcounty said in Idea: Two "next-servers" coexisting on the same vlan:
but no file called “wdsmgfw.efi” exists.
So if you search that path what files end in .efi? Is there something like bootmgr.efi ?? I don’t have SCCM so I can’t reverse engineer the answer.
-
@brakcounty said in Idea: Two "next-servers" coexisting on the same vlan:
Actually found the files but it keeps saying the same error message.
From a windows computer install the tftp client feature and then temporarily drop the windows firewall (or do this from the fog server) use tftp get command to see if you can pull the file from the wds/sccm server. That will tell you if the needed service is running.
-
@george1421 We just re-enabled PXE on the SCCM server so it takes a minute to reinstall the features. I was going to run Wireshark to see what is being requested from where. I did that testing ipxe in my lab and found out that ipxe requests autoexec.ipxe if you don’t embed or specify a menu file. Learn something new everyday.
-
I think when we disabled PXE on the WDS it also removed everything else that made it work. I think that includes the proxyDHCP service. Our prod DHCP server had our WDS server’s IP listed as DHCP Relay. But I don’t think we still need PXE if we chain from FOG.
-
So while the script @george1421 made in that post didn’t work right and threw errors, I have FOG scripted to allow to drop to shell if an error occurs. Once I got into the shell, i just typed “autoboot” and hit enter. I then got prompted to press Enter to boot WDS. Then it stopped here. I think I still have to define a boot.wim on the WDS Properties. But I feel like I am getting closer. I could just throw in the “autoboot” command under the FOG’s ipxe item setting parameters.
-
@brakcounty OK As I mentioned before SCCM has a service that I thought was called netboot or something like that, if you stop that service it will turn off the proxydhcp service (udp port 4011) on the server. That functions much like the dnsmasq service does to provide pxe boot infomation only leaving the rest of the settings to come from your dhcp server. Yes you would add the proxydhcp server as the last server in the dhcp-helper/relay service on your IP router.
So having the proxydhcp option in one method, the other method is using dhcp options 66 and 67. To use this option with SCCM you need to set dhcp option 66 to the IP address of the SCCM server and dhcp option 67 to the boot file to use. Once we can get this method to work (without FOG in the picture) then we can introduce FOG into the chain. So IMO you need to find the name of the boot file that ends in .efi That file should be on the SCCM server, I think in the boot directory, but I can’t remember from that long ago when I last touched SCCM.
