Moderators

@Naline said in Not able to use Legacy on BIOS :

NBP filename undionly.kpxe

Well NBP refers to a UEFI system and you are sending a bios (legacy) mode boot loader to the target computer. Bios and UEFI are not compatible. You should be sending ipxe.efi for a uefi based computer.

When I change the DHCP bootfile name to boot\x64\wdsmgfw.efi

Umm, this is a WDS problem/issue not FOG.

If you are using FOG and have a Windows 2012 or newer DHCP server this document may help you create a dynamic boot file that will support both bios and uefi clients pxe booting.
https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

I don’t think this is a FOG problem. FOG is moving the files from the source computer to the target computer and the target computer boots OK. The problem you see is inside OSX itself. FOG doesn’t step inside the target OS. The only way it can do this is with the FOG Client and that is only to change the workstation name or deploy applications.

Understand the next thing I say is a guess because I don’t know. Its possible that Microsoft has connected user management or maybe password management to the T2 chip. Its possible with a different T2 chip it also protects/encrypts the password file. It may also be possible that changing the computer name does something unexpected with the user accounts. I don’t use Apple computers so I don’t have any experience with them.

From a debugging standpoint, we know that FOS Linux can access the hard drive of the Apple computer (because it can send a computer image). You may be able to use debug mode to access files on the target computer. I don’t know what you can do to reset the password externally but if you need to do things on a file level you can do this with FOS Linux. If you find a solution in debug mode then possibly you can write a FOG Post Install Script to apply those same settings during image deployment.

You know the fog server or the web ui does query (somewhere) to find out the latest version of FOG vs what is installed. Is there a way to send the FOG version number during that query?

What we really need to know (from a demographics stand point) is

1. how many active FOG installs are out there running
2. What version of FOG is currently running
3. What host OS and version is the #2 running on

As long as we stick to those values only I don’t see any infringement on anyone’s privacy. There would be no way to tie the organization name to the data. What is really needed is prospective data. I know we could add that to FOG moving forward, but we really need to know what is already out there.

The other thing is to only support a distro supported OS. When the distro drops support for an OS then FOG should too. i.e. should FOG still support ububntu 12.04 or 14.04? When rhel/centos 7 EOL (hint: June 30th, 2024), does that mean FOG will support centos 7 until 2024? Is that the right thing to do? (asking)

@mwilcox said in Isolated dnsmasq Setup:

My FOG server is running in VirtualBox, do you know if I can change that interface to NAT? I’ve always read not to use NAT for PXE booting.

Ok what you need to do is isolate the FOG Imaging bits from the fog server acting as a router. Two different functions that are not connected.

Normally a linux server with multiple interfaces will not send packets between its interfaces. You can turn on that kernel parameter and it will “act” like a router. For this to work you need to know how to get packets on and off your network. That is why you need to create an static route on your business network so your business network knows how to send data back to the imaging network (such as in windows activation)

So what I’m suggesting is to enable in the linux kernel to act as a NAT router when sending packets between the imaging network and the business LAN. FOG Imaging does not do/use/work by sending packets between the interfaces. SO there will be NO impact to fog imaging or how you have things setup in virtualbox because the NAT is happening inside the linux kernel. With NAT turned on inside the FOG sever’s host OS linux kernel all traffic on the business network will actually look like its coming from the FOG server, when in fact the traffic could be coming from the imaging network clients reaching out to the business network.

@mwilcox The ONLY thing you need to do on the business side is provide a static route on your default route for the business network back to your imaging network. That way when you have packets destined for the 10.0.0.0/24 network and that packet exists on the business network the devices know to send it via the business network interface of the FOG server.

IF you can’t modify the business network at all, then we will need to configure the fog server to do NAT between the imaging network and the business network. You will do that with iptables and mangle (I think).

edit: https://www.revsys.com/writings/quicktips/nat.html

@mwilcox While its not a supported configuration, if your FOG server spans both networks the FOG server can act as a router too.

The setup is pretty simple, on your business network default router you just describe the imaging network and its accessible via the Business network interface of the FOG server.

On the imaging network side, just ensure that the FOG server imaging network interface is configured as the default router.

Then a quick kernel parameter change and your FOG server will be a router.

@p4cm4n You can do that, there is a tutorial (for uefi) to create a boot drive the easy way. This will load iPXE from a usb stick and then boot into FOG. https://forums.fogproject.org/topic/6350/usb-boot-uefi-client-into-fog-menu-easy-way

For those that can’t use iPXE I have FOS Linux on a usb stick too. You lose about 30% of the functionality of FOG but you can image no problem with it. https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image

@p4cm4n Well first of all let me say FOG server is insecure when exposed directly to the internet. Running it in this configuration was never the intent of the FOG developers (speaking not really knowing the actual intent of the developers).

I can say that tftp is / was not very forgiving trying to PXE boot in a routed invironment. In the early days the PXE ROM (what we are dealing with at this point) was not very smart and didn’t know how to deal with routers and such. Its much better now in this era. So what I would do from your home network. From a windows computer can you ping the cloud fog server? If so you have to remember that tftp much like ftp actually opens 2 channels to transfer files. One channel is from the client to the server. This is the command channel. The second channel is the data channel and its opened from the (t)ftp server back to the target computer. If your firewalls are not ftp aware they might block the data channel from being created.

So what I would test next is to install the tftp feature in windows and then allow the tftp program network access through the windows firewall. Then if possible configure your home router to allow tftp traffic through. And then finally test with the tftp program in windows to see if you can download ipxe.efi (or whatever) from the FOG server. Right now you need to test connectivity to download via tftp from the Cloud fog server. If you can do that then the problem is with your home dhcp server. Right now you need to understand where its working and where its not.

@p4cm4n So you are trying to pxe boot across the internet between the cloud provider and the local network? Understand I’m trying to get a picture of how this is setup. Where is your pfsense box in relation to the FOG server and in relationship to the clients?

OK I don’t know what an OVH platform is. I assume its off site? Do you have a full time VPN connection between your cloud environment and the local network?