@Tom-Elliott okay, i’ll do that.

(idk how to mark the topic as solved)

@NoIPName

I found a solution for this problem:

Apache2 dont care which SSL certificat you use, so you can use another path for your Custom CA on the website
So logicaly you can keep your intern Fog certificat and dont change it :

/var/www/html/fog/management/other/ca.cert.pem /var/www/html/fog/management/other/ssl/srvpublic.crt /opt/fog/snapins/ssl/.srvprivate.key

But you need to recompile the iPXE file for the boot PXE

After that you can check with your fog-client can comunicate with Fog server 😄

In case anyone else is experiencing the same issue, I figured this one out.
routeraddress was missing in .fogsettings

cd /opt/fog vim .fogsettings

enter router/default gateway IP between single quotes

routeraddress='192.168.1.1'

reboot server.

@Jim-Graczyk

The wiki on migration covers migrating a single FOG server using the only workable process, so I’ll leave that alone.

I think my issue with the entire “Server Migration” process is that it requires you take FOG down at the onset of the process - before you attempt to install FOG on the new server. This obviously stops all the PC IT maintenance processes FOG provides IT support, but also FOG’s benefits to the end users of the hosts, until the new server/system is back up and working.

I’ve used FOG on a fairly large scale - some instances have 10+ remote sites, each with its own FOG Storage Node. To say that shutting it down before starting migration is inconvenient to the business is an understatement. Storage node migration didn’t require that the storage node had use the same IP as the old storage node - so that helped.

I hope that my initial post to you comes up when other FOG users search “FOG Migration”, so they don’t waste the time I did trying to build a completely new FOG system, including storage nodes, to cut over to, only to find that you can image PCs and create new hosts, but the exiting host would not talk to the new server system - so all the existing host configuration is lost (a large chunk of work). Ironically, there are numerous FOG wikis that address most issues that I ran into - creating new certs, the ever-present Reset Encryption on the FOG Client, etc., but none mentioned that the CA of the old system HAD to be used in place of the new.

I’m glad there was some way forward without having to reconfigure everything manually, but like many things in FOG wikis, everything in them is true, but context and limitations are not defined at the beginning. Even the migration process link didn’t spell out requirements, nor include remote sites and storage nodes. It needs to spell out that harvesting the CA and certs and using the old server’s IP address are as important as the database, snapins, and images - and this is the ONLY way to migrate.

So - a suggestion to the great minds working on FOG:

Create a way to change the FOG Client CA in one step - delete old and replace new - from within the FOG Client. This could be something issued from the old FOG server, for security reasons. CA deletion should also be built into the FOG Client Installation MSI/EXE. I use FOG to build portable Windows images that are company and FOG server independent. The FOG client is installed at the initial boot and replaced in the image as FOG evolves.

If that capability could be added, migration would be possible such that the new system w database, snapins, images, host configs, could be build out with multi-storage nodes and multi-locations, side-by-side with the old FOG system, gated only by DHCP boot settings at each site (IP broadcast space).

Jim Graczyk

My good, i found it !!!

i the default.ipxe i change the value for my FQDN of my DNS and that work’s !!!

i lost 2 days with this issue :V thanks you !

@bwilli78 my dell machine was wrongly identified as 32bit and sent bzimage32. You can: 1) update to dev-branch 1629 I should help. Or 2) send bzimage to 32bit machines. (Because they are wrongly identified).

This could be your issue. I don’t see FOG sending bzimage32 anyway. Just a gut feeling. May be wrong.

@iljared98 I don’t suppose you’d be willing to share more on this config? What specific rights you gave the service account, did you have to do this whole thing https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1 related to this whole thing https://support.microsoft.com/en-us/topic/kb5020276-netjoin-domain-join-hardening-changes-2b65a0f3-1f4c-42ef-ac0f-1caaf421baf8 ?

I’ve previously attempted to create a standard user with such permissions, but I hadn’t tried a service account, that’s a grand idea. I would love to document the creation of a least privilege service account for fog domain operations.

@fabritrento That’s not how this works. Just saying lol. 6.1.22 works fast for your situation, but that doesn’t mean there’s truly something wrong with the kernel for everybody. So when the next stable release comes out, you should remember to switch back to 6.1.22 and we’ll work to keep trying to update the kernels and hope that you’ll test them to see if it works for your situation so you don’t have to revert it to 6.1.22.

This worked for me :

Domain name: subdomain.domain.tld
OU: OU=Computers,DC=SUBDOMAIN,DC=DOMAIN,DC=TLD
AD DEFAULT USER: adminuser
Domain Password: supersecret
Name Change/AD Join Forced reboot?: cheked

Not sure if I was doing anything wrong, I tried too many things, but this now works. Thanks.

I have the impression this issue has something to do with DHCP server in the gateway competing with proxydhcp in the fog server.

I have updated DHCP settings in Unifi to allow / block DHCP traffic (DHCP Guarding). I have included FOG’s dhcppxory address and seems to be working ok now.

@george1421 This is correct. It works fine. Thanks,

@kbats183 I haven’t looked at the quick registration bit of code but I did have a hack that updated the fog.auto.reg (full registration) option to begin imaging right after registration without a reboot. This involved taking the FOG supplied script updating it to your requirements and then adding a bit of code onto the end and then finally dynamically patching that script on every boot of the target system. It sounds like a lot of steps and its complicated but not if you know how fog works.

I should be able to point you in a direction so you can get started.

When FOG Linux (the os that gets transferred to the target computer for imaging) boots it runs the master fog script stored in the /bin directory in FOS Linux. The scripts bits of that /bin directory is here: https://github.com/FOGProject/fos/tree/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin The file you are interested in is called fog.auto.reg. If you can understand bash script programming you can modify this file to fit your requirements. Once you have the script the way you need it then you can dynamically patch when FOS linux boots using this tutorial (understand this tutorial is for patching fog.man.reg but the concenpt is the same only the file name changes.

https://forums.fogproject.org/topic/13500/dynamically-patching-fos-using-a-postinit-script

I have tutorials that are targeting the manual registration but the concepts are similar. (hint: this is where I tweak the script to give me a custom calculated host name kind of like the auto naming but better. )
https://forums.fogproject.org/topic/14278/creating-custom-hostname-default-for-fog-man-reg

So that’s the background, how do I make it image right after rebooting?
For the fog.man.reg file you append a bit of code that makes the script think the system rebooted and collects the latest imaging info.
(For the life of me I can’t find that tutorial I created but here is the script that I collected from a recent issue with the code in the script.

sysuuid=$(dmidecode -s system-uuid) sysuuid=${sysuuid,,}switch mac=$(getMACAddresses) base64mac=$(echo $mac | base64) token=$(curl -Lks --data "mac=$base64mac" "${web}status/hostgetkey.php") curl -Lks -o /tmp/hinfo.txt --data "sysuuid=${sysuuid}&mac=$mac&hosttoken=${token}" "${web}service/hostinfo.php" -A '' curl -Lks -o /tmp/hinfo.txt --data "sysuuid=${sysuuid}&mac=$mac" "${web}service/hostinfo.php" -A '' [[ -f /tmp/hinfo.txt ]] && . /tmp/hinfo.txt . /bin/fog.download

In the case of fog.man.reg this code would be added at the very end of the script.

Looking at the fog.auto.reg script I would say it should go at the very end of that script too.

ref: https://forums.fogproject.org/topic/17601/deploy-image-right-after-registration-without-a-reboot/3
ref: https://forums.fogproject.org/topic/16378/start-imaging-right-after-the-full-host-registration-without-reboot-possible

@Cristian Any chance you are sending the image out to new/different machines than before? We have just received some new machines into our fleet (Lenovo neo 50q Gen 4), and we are seeing something similar…we get 14GB/min on the older machines, but these new machines are at about 2GB/min. I started a thread on that here:

https://forums.fogproject.org/topic/17698/fog-very-slow-to-deploy-image-lenovo-neo-50q-gen-4/2

Not sure if yours is for the same or similar reasons, but if it is, it might help to know if they are the same machines as we just got.

Thanks!

@fabritrento I’ll be honest, I have no idea what you’re saying is isn’t happening here?

@Tom-Elliott

Yep, that certainly worked. We were avoiding that just so we did not lose all of the location associations that the hosts already had, but if this solves the issue, we will plow through it.

Thanks for the info! This took care of the issue.

@Bhav In addition to what Tom posted, the server response timeout is suspicious too. IF the target computer is in uefi mode and it downloaded undionly.kpxe the target computer should have responded with something about undionly.kpxe is not the right format. But in this case its getting a server response timeout. This makes me think two things. 1) your dhcp opition 66 is set incorrectly or the name of the file has a capitalization issue. For linux Undionly.kpxe and undionly.kpxe are not the same thing. Either way I would start with your dhcp server and make sure dhcp options 66 and 67 are set correctly for a uefi based computer.

@JJ-Fullmer I would mark this one as solved. I didn’t see a way for me to do it. Thanks, again