I tried to change the FQDN with the procedure in the manual (local AD): http://docs.nethserver.org/projects/nethserver-devel/en/latest/nethserver-sssd.html#change-the-fqdn
But this doesn’t work. Tried it on an upgraded machine and on an fresh installed one.
To leave the realm and clear it, works. After that it’s possible to chance the FQDN, but you can’t join the realm again, because there is no more realm to join.
With realm join -U administrator $(hostname -d) you get realm: No such realm found
I think there is something missing in this procedure.
So I tried to manually set the db values for realm, workgroup and provider and did expand-template /etc/samba/smb.conf systemctl restart smb systemctl restart realmd
and was joind to the new realm.
So far so good, but I still have no connection to the ldap server and got stuck. signal-event nethserver-sssd-save and a reboot do not help also.
Can someone give me a hint which is the right order of commands to do this?
o.k. I spent some time with that and now I found a procedure that worked for me
signal-event nethserver-sssd-remove-provider (this causes backups of users and groups)
change FQDN in GUI
reinstall AD from GUI
rpm -qd nethserver-sssd
in /usr/share/doc/netsherver-sssd-1.3.0/scripts you find the scripts to import users and groups. Copy the files in that folder to /var/lib/nethserver/backup (only for easyness)
in /var/lib/nethserver/backup you find the backups users.tsv and groups.tsv
perl import_users users.tsv and perl import_groups groups.tsv
Now I have a new FQDN and all my users and groups are back.
For all these servers their FQDN at server installation was set to server#.mydomain.com
For unknown reasons I could not at the time create the ad domain mydomain.com and thus went with the domain ad.mydomain.com. The FQDN of these servers was server#.MYDOMAIN.COM
The fileserver was an exception, I had been playing with that. It’s FQDN was already effortlessly changed after unbinding, to server3.ad.mydomain.com and then succesfully rejoined to ad.mydomain.com after some persuasion.
During this I changed the FQDN on 1 server, 3 times in a row with rebinding and unbinding in between, and even completely recreated the domain. This went all with just one error which did not repeat when the same action was tried again (bind the fileserver to the domain).
I did not try to restore the users or the groups, as I had none that mattered. I recreated the same users, and all the configuration on the other servers started working again.
This included SOGo mailboxes still working, still containing the test mail, etc.
This also includes the home-shares.
During testing of having the same FQDN as the domain you are trying to create, I first changed the FQDN from server1 to server1.ad.mydomain.com and recreated that domain succesfully, and then reverted back to server1.mydomain.com to create domain mydomain.com
So the FQDN of the Nethserver running the samba container, was changed as well.
There is very little custom config in there, so the process outlined two posts back seems to have improved.
Not tested where custom ACL’s set through the UI or custom righst set through RSAT.
Some users seem to have a password, some are shown as locked. Befroe all user had a pasword and non were locked!
But,…no user can login with the old password. So all passwords has to be changed manually.
In my case not that big problem with 15 users. In a bigger company it would be a big problem.
Note: In this test I changed also the domain. I’ll test with only changing the FQDN and will report later.
Did the procedure again with only changing FQDN.
Same result as before, but this time some other users are locked.
Tried to login with old password and standardpassword, but non worked.
So all-in-all in a realistic scenario it’s not really possible to change the FQDN, because all passwords are gone or messed in some way.
So all passwords has to be changed manually.