samba - Jun 2024 - move domain member server to new hardware

Am 06.06.24 um 19:51 schrieb Stefan G. Weichinger via
samba:
> Am 31.05.24 um 14:38 schrieb Luis Peromarta via samba:
>> I?d get the new server ready, sync all data including xattrs & ACLs
>> with rsync -AXav
>>
>> You probably use AD or RID. Just use the same idmapping on the new 
>> server. Probably just copy old smb.conf to new machine.
will do more or less

But not sync "/var/lib/samba", right?
>> When all is rsynced just remove the old server from the AD, turn off, 
>> assign name and IP address to new server. Join domain. That should do.
>>
>> If all goes very wrong you can just power on your old server , and 
>> rejoin. Things should be as before.
> 
> thank you, sounds not that scary ;-)
> 
> what about the fqdn in linux itself? I can't change that hostname on
the
> old server until I deactivate it. It should stay some kind of fallback 
> server (with another fqdn and IP) later.
Could I join the domain with another name and IP now ... to be able to 
test things (introducing btrfs snaphots this time) with all AD-features, 
but on a "test name"? And then leave the domain, change FQDN/IP and
rejoin?

I want to avoid any issues coming from doing something wrong NOW. That 
server should be productive for some years from now (sure).

On Fri, 7 Jun 2024 15:35:07 +0200
"Stefan G. Weichinger via samba" <samba at lists.samba.org>
wrote:
> Am 06.06.24 um 19:51 schrieb Stefan G. Weichinger via samba:
> > Am 31.05.24 um 14:38 schrieb Luis Peromarta via samba:
> >> I?d get the new server ready, sync all data including xattrs &
> >> ACLs with rsync -AXav
> >>
> >> You probably use AD or RID. Just use the same idmapping on the new
> >> server. Probably just copy old smb.conf to new machine.
> 
> will do more or less
> 
> But not sync "/var/lib/samba", right?
Provided that you use the same 'global' part of the smb.conf file,
/var/lib/samba will get populated with the correct data, so there is no
reason to sync it.
> 
> >> When all is rsynced just remove the old server from the AD, turn
> >> off, assign name and IP address to new server. Join domain. That
> >> should do.
> >>
> >> If all goes very wrong you can just power on your old server , and
> >> rejoin. Things should be as before.
> > 
> > thank you, sounds not that scary ;-)
> > 
> > what about the fqdn in linux itself? I can't change that hostname
> > on the old server until I deactivate it. It should stay some kind
> > of fallback server (with another fqdn and IP) later.
> 
> Could I join the domain with another name and IP now ... to be able
> to test things (introducing btrfs snaphots this time) with all
> AD-features, but on a "test name"? And then leave the domain,
change
> FQDN/IP and rejoin?
I would create a 'test' machine and join that, once you are sure that
everything is working correctly (and you have documented the
procedure), just create a new machine with the correct FQDN/IP and join
that.
On a Unix domain member, all you need to backup is the smb.conf and the
directories you have shared. If you put the shares in /srv , then all
you need to backup is /srv and the smb.conf

Rowland