The (my) Cluster Network is in the “Trusted Networks” now, but the Problem persits.
Hm…
I understand the Difference in the 389 und 636 Connection. The Nethserver7 Config shows ldap 389 bit the (external) Nexcloud connects via ldaps 636.
Which is the preferred (und maybe first tried) Connection from NETH8 to the Nethserver7 AD?
Most programming languages will not allow ldap access from remote anymore…
Among them: JAVA, PHP…
It must be ldaps. And some actually demand a valid cert!
I would assume so. The migration tool firstly needs to find out which account provider was used on NS7. This entails a remote access, so probably ldaps (636) is first…
Note:
LDAP is LDAP, but AD is also LDAP, just using a slightly proprietary schema.
Both tend to use capitals for URLs and such, wheras DNS remains small caps.
But AD and LDAP are too similiar.
openssl s_client -connect AD_IP:636 -showcerts </dev/null 2>/dev/null | openssl x509 -outform PEM > server-cert.pem
openssl x509 -in server-cert.pem -noout -enddate
notAfter=May 1 23:29:03 2021 GMT
Oups…
How can i renew this Cert without huzzle?
————————————————————
Install LE in AD
————————————————————
cp
/var/lib/machines/nsdc/var/lib/samba/private/tls/
nano /etc/e-smith/events/certificate-update/S80push2ad
Content:
#!/bin/bash
cp -f -p /etc/pki/tls/certs/localhost.crt /var/lib/machines/nsdc/var/lib/samba/private/tls/cert.pem
cp -f -p /etc/pki/tls/private/localhost.key /var/lib/machines/nsdc/var/lib/samba/private/tls/key.pem
chmod 600 /var/lib/machines/nsdc/var/lib/samba/private/tls/key.pem
chmod 644 /var/lib/machines/nsdc/var/lib/samba/private/tls/cert.pem
systemctl -M nsdc restart samba
chmod 750 /etc/e-smith/events/certificate-update/S80push2ad
Afterwards:
/etc/e-smith/events/certificate-update/
————————————————————
This will do the trick!
This uses the valid NS7 cert (Add in an alias for the AD) for the AD…
Your ad name will need to be externally (and internally) accessible for LE to make this work.
Is it really necessary to take this route for the migration, which is not described in the migration instructions and is not part of the Nethserver7 AD standard?
And do all the others who want to migrate do the same? Do they all have a freshly copied LE certificate?
Shouldn’t it be enough to initiate the renewal of the self-signed certificate? And why is/was it not renewed at all?
I’m trying to take the standard route, because this will also be necessary for further migrations.
I quite agree with this.
The above is because several clients have Apps (Web and others) which need an AD connection and this must have a valid cert…
But I’ll also admit I never had to renew the cert on AD manually so I have no idea how to do it.
In NS7, the AD was in it’s own container like jail or something, and used it’s own IP.
So it’s not a simple system wide cert that needs to be renewed.
Let’s try to change the port on NS7 and start again with the migration process:
The migration tool gets the provider information from the following command, see also nethserver-ns8-migration/root/usr/sbin/ns8-join at 0ae2320538a04bf1e077b5cbd9027c99869386f9 · NethServer/nethserver-ns8-migration · GitHub
account-provider-test dump
Check the port:
"port" : 389,
To change the ldap uri to ldapS:
config setprop sssd LdapURI ldaps://nsdc-servername.ad.domain.tld
account-provider-test dump should now show port 636.
Restart the services sssd and nsdc and start over with the migration.
It’s just an idea, I didn’t test it…
I’ll be happy to test it, but do you think it will work with an expired AD certificate?
Do you know a method to renew the AD certificate in the NDSC?
Yes, it should work without valid cert.
The method @Andy_Wismer posted should work. You need a valid LE cert on the NS7 and the script copies it to the samba directory.
But in this case it shouldn’t be needed.
That worked, thank you very much!
Then I’ll test the first migration, thumbs up to you and fingers crossed for me.
The migration of mail and SOGo worked quite well. I only had to correct the hostname of the mail server, which was created with the local hostname of the NETH8 VM and therefore of course did not receive an LE certificate.
The migration of the AD and the SAMBA shares also started quite well. Following your advice, I first moved the contents of a particularly large share to a special folder “.FOLDER” (with a dot) under “/var/lib/nethserver/ibay” in order to transfer its contents later in a different way or to another data carrier with a special mount in the share path (but this path must first exist for this, you remember the problem discussed). Unfortunately, I could not move the contents outside of “ibay” because “ibay” is my mount point. But because the folder “.FOLDER” was neither created by the Nethserver nor shared, I assumed that it would be ignored during the transfer. And it was “correctly” ignored during the sync, great!
The first sync was successful and so was the second sync (just to be on the safe side) - and both times the special folder was NOT transferred. Only at the final step “Finish Migration” did the migration tool start to transfer my special folder. That was unexpected (it should definitely be better documented!) and in my case extremely inconvenient because the VM disk was easily 1TB too small.
What can I do without completely aborting the whole process? Luckily my /home partition was on a btrfs file system, so I was able to increase the size of the virtual disk by 1TB during the transfer. That seems to have worked, I just hope nothing was shredded:
via GUI or Console
echo 1 > /sys/class/block/sdX/device/rescan
lsblk -f
parted /dev/sdX
resizepart 1 100% (partition 1 in my case)
quit
btrfs filesystem resize max /home
(my mount point)
btrfs filesystem usage /home
Now it will probably continue copying to the 1TB for a while. That wasn’t what was intended. The data should be copied to another storage device for a good reason and the whole process should also be as quick as possible so that the shares are accessible again. After the mail migration, the host name must point to the new NETH8, which already delivers mail but no shares. At least that was to be expected, so I wanted to avoid this “downtime”. Unfortunately, it was not possible to predict what the migration tool would do, and I cannot find any documentation for this behavior.
Now I hope that the transfer does not abort for other reasons, e.g. when transferring the AD. That would be the worst case scenario. Because that is already the “finished” process.
Dear community,
the migration of my first Nethserver 7 to NETH8 was successful - with certain difficulties but also special features that I would like to summarize here:
No problems - Mail and SOGo:
The migration of Mail and Sogo went smoothly.
Everything was there, even the calendar shares were transferred (there were no mail folder shares here).
The mail folders were quite sparsely populated, hopefully this will work with large mail folders as well, but the migration tool allows further sync.
Difficulty - SAMBA.
My SAMBA shares were around 300GB and 1TB in size.
I had to “exclude” the 1TB share because of its size in order to copy it later. Its content should not be on the target volume under “/home” but on a separate volume that should be mounted within “/home/samba1/etc_pp”. Since such a mount can only be created after(!) the samba1 app has been created, the content could not be transferred.
To “exclude” this content, I moved it to another folder “.FOLDER” within “ibay” that was not shared.
Result:
So there was still the “finish”.
I assumed that “only” the AD would be transferred during the finish. But that took an unusually long time. A look at the volume usage showed that the previously omitted folder had now been transferred after all.
During the finish, it seems that not only the AD is finally transferred but also other (old?) files still in the “ibay” directory that are no longer or were no longer an explicit share. Actually not a bad idea, just surprising.
The sheer size of the “remaining” files was probably too much for the migration tool, because it stopped after several hours. Although the data was completely copied to the drive under “/home”, which had been enlarged in the meantime. Since no further “sync” is planned for the “Finish”, it did not continue.
But since the 1TB of data was not supposed to end up on the drive anyway, I started again from the beginning. In anticipation, corresponding snapshots were available from Nethserver7 and NETH8.
This time I copied all the data from the 1TB share to a completely separate volume, which was then removed. As a test, I created a folder “.TESTFOLDER” under “ibay” again - to see whether this would be skipped again and only copied during the “Finish”.
The first part of the SAMBA migration ran successfully again (although “.TESTFOLDER” was skipped).
The second part - the “finish” copied this folder again (only a few test contents). The Samba and AD migration was therefore successful.
Since the sync can be carried out multiple times in the “sync” phase of the SAMBA migration, the option arises at this point
(I didn’t know this before) to integrate a separate drive into the new SAMBA path during the migration.
The content of the “TESTSHARE” share could, for example, be moved to “ibay/.NOSHARE” before the first SAMBA sync. The first sync then creates the path to the “TESTSHARE” share, but the content is not copied (the path is needed for the own mount).
In this way, you would have the opportunity to mount a suitable drive in the NETH8 and integrate it directly into the new Samba path, e.g. the “TESTSHARE” share, using a bindmount. Now move the content in Nethserver 7 from “ibay/.NOSHARE” back to “ibay/.TESTSHARE”. The next time you sync, the contents of “TESTSHARE” should be migrated to the desired (large) drive in the NETH8.
In my case, this was no longer necessary because I had already completely outsourced the data. I only copied it to the alternatively set up bindmount afterwards. But in principle it should work like this and I will test it for the next migration and report back here.
What didn’t work - OpenVPN Roadwarrior
After completing the migration, the Nethserver 7 was successfully an AD client for the NETH8. That’s how it should be so that any other services that cannot be migrated still work. Unfortunately, the OpenVPN Roadwarrior clients (AD) no longer worked because they were completely missing from the settings on the Nethserver 7. I hadn’t expected that.
I had no choice but to restore the Nethserver 7 to an earlier state before the AD conversion so that this function would work again. I manually removed the remaining services and blocked AD connections (636, 389) between the old and new Nethserver. The old Nethserver now only acts as an OpenVPN roadwarrior for existing AD clients - that’s enough for me. New AD clients (then on the new NETH8) are assigned other VPN methods.
So these are my first experiences, maybe it will help someone.
Regards
Yummiweb