@jmeyer Myself and another form moderator (Wayne Workman) came up with the concept of a mobile fog deployment server. The concept is that you would load FOG on a portable device (laptop or mini computer) with all of the necessary items for image deployment. IMO if this was going to be a truly portable computer a laptop with the built in screen and keyboard would be a better option. If you functioning as a MSP wanted to sell an imaging service than the mini or micro computer would be a better choice.

So the concept of the mobile fog deployment server is that the portable computer would have a full fog system installed on it. To minimize setup the mobile deployment server will have its IP address assigned by the remote site’s dhcp server. In this case FOG would not be your remote’s site dhcp server but it would function as a dhcp client (more on this in a bit). The next part you need to address is how to get the pxe boot information in the remote sites dhcp environment. You will do that with dnsmasq configured in a proxy dhcp mode (I have a tutorial on how to set this up in fog in the tutorial section). In this mode the FOG server (dnsmasq) will only provide pxe boot details leaving the remote site’s dhcp server untouched. With this configuration once the mobile fog server is removed from the site no pxe booting information is left behind to cause the remote site’s issues.

The issue you will have is that because FOG’s configuration is intended to be static, having the fog server’s IP address being assigned by dhcp will cause the FOG server to fail to pxe boot, to fix that issue Wayne created a script to automatically update the statically defined fields in FOG to make the IP addresses a bit more dynamic (note this is a fog server issue and has nothing to do with the target network or computers) That script is here: https://github.com/FOGProject/fog-community-scripts/tree/master/MakeFogMobile Looking at it that script is 8 years old, I can’t speak to the suitability of that script with the current version of FOG. It may need to be tweaked, but that’s the beauty of opensource software, if it doesn’t do what you need, you can fix it yourself.

It is possible to create a mobile fog deployment server, and back in the day the one I used worked great. So it is possible to do with little effort.

Finally, I did my update.

The problem was that I was running Debian Buster, so I first had to upgrade to Debian Bullseye so that the installer could install the new packages.

Then, I made a copy of the fogproject/ folder, deleted the folder to initiate a git clone
Next, I followed the tutorial and restarted the installer, which restored my old settings. The web interface is working, so I assume my clones will work as well.
Thank you.

@Hojjati I’ve found a solution for this issue that worked for me.
You need to manually edit the Windows hosts file at C:\Windows\System32\drivers\etc\hosts and add an entry with your FOG server’s IP address followed by the name “fogserver”.

This is necessary because SmartInstaller.exe performs a pinning process during installation, if you notice the installer hangs or fails exactly at that pinning stage, it is definitely due to this resolution issue.

Adding the entry ensures the installer recognizes the server and can download the certificate properly.

I’m going around replying to all these old Docker request threads so people can try out my work. Check out my thread here:

https://forums.fogproject.org/topic/18000/unofficial-docker-image-beta

and provide feedback in the comments.

the actual github repo is here:

https://github.com/88fingerslukee/fog-docker

Finally found out why I couldn’t auth over 636, I needed to add my domain’s CA cert to the FOG server’s root cert store. Once I did that I can now use my AD creds over 636 on the web UI and iPXE menu items.

@george1421 Thanks, George.

@george1421 I see now and you’re right as my clients are all legacy boot/BIOS boot non UEFI and would not benefit from the client-arch examination.

I’ve already declarations set for each host in my dhcpd.conf file in terms if MAC to IP and so adding another field of filename “some boot loader file” won’t be impossible.

Thanks you for this exercise as I’ve learned some very important things here.

@george1421 Just seeing if anyone else has had issues.

Haven’t purchased the new models yet.

Was hoping to confirm they’re compatible with FOG first, so thought I’d reach out and ask around.

Thank you!

@alterak If you know how to program linux bash scripts this is possible. You will need to edit a script called fog.man.reg that is in FOS Linux (the OS that runs on the target computer to capture/deploy images). I have a tutorial on modifying that program to set a default hostname. But the concepts you need to do what you ware are listed here: https://forums.fogproject.org/topic/14278/creating-custom-hostname-default-for-fog-man-reg

@alterak said in FOG operation in different network segments:

is there a possibility of automatic separation of locations,

I’m not sure I fully understand the question, but if you are asking can it automatically pick which location to select based on the IP address of the computer being registered. The quick answer is no, FOG doesn’t currently have that capabilities.

The bit longer answer is it could if you can be a little creative and can do a little linux bash script programming. In a nutshell, you can customize the bash script that is setup for full registration of computers. The basics of what needs to be done is covered in this tutorial: https://forums.fogproject.org/topic/14278/creating-custom-hostname-default-for-fog-man-reg

The IP address bit can come from this script: https://forums.fogproject.org/post/69725 This post is for getting the IP address to be used in a FOG postdownload script. But the concept will be the same for the fog.man.reg script.

@ingemedia We just released new experimental kernel/initrd. I included the r8126 drivers. I don’t have any devices to test with so would you be willing to test it and let me know?

@george1421 thanks for continuing to provide such detailed information.

I believe the best way to learn is to do, so i am going to go shopping for an SSD (and perhaps some RAM to be safe). Once I have everything in place, I am going to do a test run on our machines as well as those of an associate just to see what happens when the network changes. Following this, I will check back with you if you don’t mind to go through the results.