I don’t think it’s quite as simple as that.
Original settings:
Restored server:
*** Update ***
Just to add in case it makes a difference, especially in regards to the Samba AD domain with the 10.5.4.0/24 address. My NS8 is migrated from an NS7 instance, not a built from scratch NS8.
Cheers.
Retracted
good and expected
will act the same way like you did
what was the error of samba ad ?
Take a look at the screenshots I pasted above. The original samba1 instance had an address on my internal network: 192.168.0.225. The restored samba1 is on the VPN: 10.5.4.1. Also look at the statistics for the domain. The original had users/groups/provider/File server. The restored samba has only provider.
Note, as I pointed out above, this is a migrated NS7 → NS8 instance, not a built from scratch NS8.
Cheers.
Sorry if I’m getting into another topic at this point.
In your screenshot I see an AD domain structure that is unfamiliar to me.
Base DN DC=domain,DC=tld
Bind DN ldapservice@domain.tld
Was this structure already like this on the old Nethserver7 and was it therefore adopted accordingly? Or is this something new due to the takeover?
How did you even manage to do this on your Nethserver 7? In my opinion, only one AD with sub.domain.tld could be created for domains like domain.tld.
Why am I asking? I have already created various Nethserver7 ADs and also (as a test) various NS8 ADs - but I have not yet adopted any of them into NS8. So I would like to know more about the “before and after” state.
Thanks!
I’m guessing so:
Do you need any further information on this issue other than the screen shots above.
Maybe @davidep also might like to comment.
Cheers.
For what I recall when you do the migration you can either decide to migrate the AD provider to the wiregard IP or the IP of the ns8 server. You do not have the choice to set yourself the IP
You have probably decided to set the wiregard IP like the IP of the provider ?
We recommend to use sub.domain.org like ad.domain.org but you can use also domain.org
In some condition it could solve some issues with ldap and cause also some headaches when domain.org must host different services
Got to say I don’t remember any such option being offered, but you can see from the screenshots that my AD provider following the migration is the IP of the NS8 server, which is running perfectly. Why would you you want it on the the Wireguard IP which is only a bridge for the migration pointing back to NS7.
It’s the disaster recovery that I tried (and failed) that attempts to switch it back to the VPN address.
Cheers.
sorry I was in the migration you are right
True, your Samba DC was a File Server. If its original IP address is not attached to the new machine, it needs also this step: File server — NS8 documentation
It’s not just the IP address, the restored Samba doesn’t have the Users, Groups, or File Server that the original had.
Cheers.
That means no users and groups at all? Missing or different entries?
Sorry, I thought I had replied to this the day you asked the question.
Correct, no users and no groups.
And no File Server.
Cheers.
If I understand correctly, the original domain had some users and groups, and File Server was enabled. However, in the restored domain, there are no users or groups, and File Server is disabled.
After a restore, File Server is expected to be disabled if the original IP address is not attached to the node, as documented in the Admin’s manual. This behavior is sound and safe.
What I can’t explain is the missing users and groups. If the backup were corrupt, the restore should have failed. If the restore finishes without errors, I would assume it is complete, just as the backup was. In other words, I suspect the backup was taken before the domain users and groups were created. Could that be the case?
If possible, try removing the restored domain and attempt the restore again.
Correct
The backed up File Server was on my local network, 192.168.0.0/24. The restored one thought it was on the VPN used to migrate from NS7, 10.5.4.0/24. The “clean” image I restored to was on the same 192.168.0./24 subnet as the backup.
On my next test, I’ll try updating and see what happens when I update the IP.
No, it was a current backup.
I’ll do the complete Disaster Recovery exercise again.
Cheers.
I have restored SAMBA several times in the last few weeks. I have always used a dummy network device with 192.186.1.10 to map the AD to. I always created this beforehand during the migration, both on the leader and on the worker node.
I don’t know if that would be an option for your scenario…
OK, a lot better this time. Maybe it was just that the File Server needed it’s IP correcting. I’d suggest adding a note into the Disaster Recovery section of the manual linking to what’s needed for the File Server.
Checking through everything, the only issues I saw were:
Which appear to be caused by having 2 traefik instances. Which is another reason to stop loki and traefik creating 2nd instances and just update the originals:
Cheers.
Thank you for your suggestion. It will be published soon. Clarify File server restore reqs · NethServer/ns8-docs@01d38a6 · GitHub
This issue has already been discussed and is somewhat off-topic here.
The restore of Loki and Traefik will be fixed in the next project milestone, 8.3.
