Idea: Two "next-servers" coexisting on the same vlan
-
@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.
-
@george1421 Actually since I added a standard boot.wim file from a Windows install disc, pxe booting works as it did before we disabled PXE on the WDS server. Now its just a matter of finding the original custom boot.wim we had in place. Then we can move on to modifying the os.WDS-Boot parameters to make it work from FOG. If I remember correctly, FOG also works with the autoboot command. I remember I saw this when I was experimenting at the ipxe shell from a remote location when I loaded ipxe from USB. I typed autoboot and since the next-server was predefined as my FOG IP, it loaded FOG.
As far as finding the efi file, I did find it. I see this error now followed by two No such file or directory errors when attempting to load from the FOG menu:
tftp://wds ip/SMSBoot/x64/wdsmgfw.efi…Error 0x3d126083Followed the link and it is “Error: Inappropriate I/O control operation”.
-
This post is deleted!
