@Tom-Elliott no stress, with so many posts it’s normal to miss some

Solved with http://forums.fogproject.org/post/157456

@Petrushka hello!!

In our firewalld rules we have

services:
      - ftp
      - http
      - mountd
      - nfs
      - rpc-bind
      - tftp
    ports:
      - { port: 20048, proto: tcp }  # nfs
      - { port: 20048, proto: udp }  # nfs
      - { port: "35350-36350", proto: udp }  # tftp
      - { port: "49512-65532", proto: udp }  # multicast

@DBCountMan said in Secure LDAP authentication:

Do I need to have a cert that is trusted by my domain’s root CA in the FOG’s root store?

As far as I know, no.

@DBCountMan said in Secure LDAP authentication:

BTW the screenshot at the bottom of that thread you linked shows “Use LDAP SSL” but I do not have that option.

The last screenshot is from the 1.6-alpha version of FOG Server.

The screenshot in https://forums.fogproject.org/post/155590 is from the current stable 1.5.10.xxxx version and as you can see it uses 636 port.

Hello @DBCountMan ,

the ldap plugin works fine with the secure port 636. Check https://forums.fogproject.org/topic/17632/fog-1-5-10-1604-ldap-plugin

HP desktop are a pain in the …

we had similar issues and the current solution we use is to deploy the FOG updates but keep refind to v0.11.0.

@sideone

hello! You can migrate the ssl certificates from the old server to the new. Read the wiki and you will be ok.

@MarkG Hello and happy new year.

First of all, I hope you have taken backup the database and files from the old server. Everything you need for the migration are documented in https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

@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.

@Tom-Elliott

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?

@pilipp_edv

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.

@pilipp_edv

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?)

@PatrickL

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.

@Fog_Newb

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:

• https://man.archlinux.org/man/systemd.mount.5
• https://wiki.archlinux.org/title/Fstab#Bind_mount

@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

@Fog_Newb

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.