@Jim-Graczyk obviously your setup is more complex than others and will happily wait for the steps you took to migrate.
In our case we migrated from CentOS 7 to Ubuntu 22 following the migration guide (for images, ssl certs, didn’t create new CA https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG#If_old_server_was_FOG_1.3.0.2B ) with new server name, ip (same cname) and by only resetting encryption data on all hosts the fog clients worked smoothly.
@jaoyer hello. Everything is well documented on https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG give it a read.
We have it implement with the below code. See if it helps.
kernel http://${fog-ip}/fog/service/ipxe/ltsp/casper/vmlinuz
initrd http://${fog-ip}/fog/service/ipxe/ltsp/casper/initrd.lz
imgargs vmlinuz ip=dhcp root=/dev/nfs netboot=nfs nfsroot=9.9.9.9(replace with your real ip):/images/ltsp locale=en_US.UTF-8 keyboard-configuration/layoutcode=us mirror/country=US boot=casper ipv6.disable=1
boot || goto failed
@MarkG hello, the wiki has you covered. We migrated to new FOG server (new hostname, new ip) added a cname to match the old server and everything worked like a charm.
As always in this situations test with 1-2 hosts by manually setting the new server (hosts file) to simulate the migration.
today I had to add some hosts (manually) and the force reboot was indeed checked when I added the hostname and mac address.
Is it possible that the registration from the FOS client doesn’t apply it on host creation?
for the record the Active Directory is working only for the Windows clients as described in the FOG client repo but as you said you don’t want them to join only rename. Since we are discussing for linux clients maybe that is the clue for not being enabled by default.
The database cells hostUseAD and hostEnforce are the ones that enable the procedure to occur. Another test would be to add a host and check what value it has on the dB for hosts.hostUseAD and hosts.hostEnforce without adding the host to the group or changing anything from the dashboard.
can you check the services tab on your dashboard? Is the hostname changer ticked?
also how is the host created in the first place (manually, autoregister, api?)
you might want to check https://forums.fogproject.org/topic/17648/massive-cpu-usage-from-a-service
also please state the FOG version you are using. If its before 1.5.10.41 there were some security issues that were patched.
try the below
/dev/disk/by-uuid/d61ab2ae-b79a-4b07-bfc5-4678ab0902f4 /images ext4 defaults 0 1
/dev/disk/by-uuid/3d7874cb-8c59-4e6d-8735-fb8361994590 /imagesdev ext4 defaults 0 1
/imagesdev /images/dev none defaults,bind 0 0
Sources:
@Fog_Newb said in FOG has issues if the temp image location is on another drive. FOG 1.5.10.1612 Ubuntu Server24.04.1 LTS:
/dev/disk/by-uuid/d61ab2ae-b79a-4b07-bfc5-4678ab0902f4 /images ext4 defaults 0 1
/dev/disk/by-uuid/3d7874cb-8c59-4e6d-8735-fb8361994590 /images/dev ext4 defaults 0 1
based on the reddit post you should try
/dev/disk/by-uuid/d61ab2ae-b79a-4b07-bfc5-4678ab0902f4 /images ext4 defaults 0 1
/dev/disk/by-uuid/3d7874cb-8c59-4e6d-8735-fb8361994590 /images/dev auto bind,x-systemd.requires=/images 0 0
I believe the issue relates to /etc/fstab parameters because the mounts must reside in order.
Check the comment in reddit and try the proper parameters.
as described in https://www.reddit.com/r/linux4noobs/comments/119i2vy/is_it_possible_to_mount_one_drive_as_a_subfolder/
probably its best to move everything away from the mount points and then create the new structure. Also as always in this occasions BACKUP before testing.
99% it will work. The path /images/dev is the tmp location for image creation, so if you mount a 3rd drive you can achieve the expected result.
Hello,
for the second part you can mount anything (e.x. /sdb, /storageip, /nasdrive ) in /images and keep the storage independent from the VMs primary disk.
@Tom-Elliott couldn’t wait till tomorrow… tested with 1.6 and works with the below settings.
also in 1.6 you need to change Subree on line 988 also.
Thank you once more for your time and effort.
@Tom-Elliott I will test your new code from working-1.6 branch on our dev server and report back (tomorrow).
@Tom-Elliott being explicit helped me better understand the verification process.
Similarly your ‘admingroup’ (I know you’ve masked it) but do you have a group in your LDAP that has a full name of: https://entitlements.it.auth.gr/<adminGroupName>?
yes it’s a full html path
I used the filter from the original code and the results are:
Admin search
Filter: (&(|(name=https://entitlements.it.auth.gr/<adminGroupName>))(edupersonentitlement=uid=usename,ou=People,o=auth,c=gr)); Result: 0
Mobile Search (empty group)
Filter: (&(|(name=))(edupersonentitlement=uid=username,ou=People,o=auth,c=gr)); Result: 0
The correct filter should be (that is what I implemented):
Admin search
Filter: (&(|(edupersonentitlement=https://entitlements.it.auth.gr/<adminGroupName>))(uid=username))
Mobile search
Filter: (&(|(edupersonentitlement=https://entitlements.it.auth.gr/<userGroupName>))(uid=username))
@Tom-Elliott said in FOG 1.5.10.1604 ldap plugin:
@AUTH-IT-Center After some pretty serious testing I think I finally got the ldap plugin working on 1.6 as well.
Basically the problem with your current filter is you only check if the group exists and the username = username, not that the username actually is a member of that group.
We do have logic, I think that double checks but I hope you can see the issue here?
Hello @Tom-Elliott and thank you in advance for your time and effort. The changes that we tried to implement came from this post.
To better give you the concept we are trying to achieve let me explain with our setup and attributes.
What we want is that if a user trying to login to FOG server with his uid = username and is member with specific eduPersonEntitlement(s) can login to FOG server and be member of the FOG admins.
@Tom-Elliott Ι did try the 1.6 branch but didn’t work… that’s when I started debugging on 1.5.10.1064 dev-branch. I made the changes based on our LDAP needs. It would be proper if all the parameters came from the LDAPServers table and dynamically used in the code (even the filter maybe?)
@Tom-Elliott though I deployed it on our production server (from my fork), of course when you push the changes I can test it on the staging server. Just let us know.