[Samba] idmap & migration to rfc2307

[Rowland Penny]

On 08/11/15 11:53, Michael Adam wrote:
> On 2015-11-08 at 11:14 +0000, Rowland Penny wrote:
>> On 08/11/15 10:49, Michael Adam wrote:
>>> On 2015-11-08 at 09:29 +0000, Rowland Penny wrote:
>>>> On 07/11/15 23:28, Michael Adam wrote:
>>>>> rsync will work if not using --numeric-ids.
>>>> OK, I know that logins will work on all the samba machines, but I am not
>>>> sure what you say about rsync is correct, this is what 'man rsync' has to
>>>> say about '--numeric-ids':
>>>>
>>>> --numeric-ids           don't map uid/gid values by user/group name
>>>>
>>>> So by my reading, if you don't use it, your uid/gids are mapped to the
>>>> user/group and if you do, they aren't.
>>> This is how it works in rsync:
>>> - If you don't use --numeric-ids, then rsync will transfer names
>>>    and let sending and receiving side each do its own name<->id
>>>    translation. This is to be chosen if users/groups of the same
>>>    name are present on each side, but not necessarily with the
>>>    same IDs.
>>> - Using --numeric-ids instead, the numerical IDs are transferred.
>>>    This is potentially slightly cheaper, and it will also create
>>>    perms/acls for users/groups that do not need to exist on the
>>>    receiving side.
>>> My warning was just that --numeric-ids can not be used in
>>> the case when we do not have identical unix ids on the various
>>> involved servers in the unix domain.
>>>
>>>>  From the problems that arose with
>>>> trying to rsync Sysvol (yes I know this is useless on a Unix machine) where
>>>> the xidNumbers are usually different from DC to DC, I am fairly sure this
>>>> isn't going to work,
>>> I don't know what problems these were.
>>> I have always used rsync to replicate the sysvol.
>>> And always used local xids. But being mainly a
>>> file-server guy, I have also not managed many Samba
>>> AD/DC environments. So I am really more than willing
>>> to learn from others' experience here.
>> If you have two DCs, the contents of idmap.ldb is different on each DC, so
>> when you rsync sysvol from one to the other, it ends up with the wrong
>> ownership.
> It fails if you use --numeric-ids.
> Otherwise, it works (is at least my experience).

Well, it didn't work previously for me, note that I said previously, I 
am mid setup of a new test domain and previously when I examined sysvol, 
I got this:

ls -la /var/lib/samba/sysvol/example.com/
total 56
drwxrwx---+ 7 root 3000000 4096 Nov  9 08:52 .
drwxrwx---+ 3 root 3000000 4096 Aug 12 10:40 ..
drwxrwx---+ 4 root 3000000 4096 Aug 12 10:41 Policies
drwxrwx---+ 2 root 3000000 4096 Aug 12 10:40 scripts

Note that the group is a number and this was using 4.1.9

My new domain is using 4.3.1 and I now get:

ls -la /usr/local/samba/var/locks/sysvol/samdom.example.com/
total 32
drwxrws---+ 4 root BUILTIN\administrators 4096 Nov  6 11:56 .
drwxrws---+ 3 root BUILTIN\administrators 4096 Nov  6 11:56 ..
drwxrws---+ 4 root BUILTIN\administrators 4096 Nov  6 11:56 Policies
drwxrws---+ 2 root BUILTIN\administrators 4096 Nov  6 11:56 scripts

The group is now a name!

on the second DC I got this:

ls -la /usr/local/samba/var/locks/sysvol/samdom.example.com/
total 12
drwxr-sr-x 3 root staff 4096 Nov  6 15:52 .
drwxr-sr-x 3 root staff 4096 Nov  6 15:52 ..
drwxr-sr-x 2 root staff 4096 Nov  6 15:52 scripts

after running 'rsync -e 'ssh' -XAavz --delete-after 
/usr/local/samba/var/locks/sysvol/ 
dc2.samdom.example.com:/usr/local/samba/var/locks/sysvol/' on the first 
DC, I now get this on the second DC:

ls -la /usr/local/samba/var/locks/sysvol/samdom.example.com/
total 32
drwxrws---+ 4 root BUILTIN\administrators 4096 Nov  6 11:56 .
drwxrws---+ 3 root BUILTIN\administrators 4096 Nov  6 11:56 ..
drwxrws---+ 4 root BUILTIN\administrators 4096 Nov  6 11:56 Policies
drwxrws---+ 2 root BUILTIN\administrators 4096 Nov  6 11:56 scripts

I think we need to re-write the wiki :-)

Rowland


>
>>>> the cure is to have the same idmap.ldb on all DCs.
>>> The conceptual failure with sysvol is that we don't support
>>> the AD protocol replication (FRS or DFSR) yet. Only therefore,
>>> we need the band-aid of replicating under the hood with unix
>>> file system level tools like rsync. I think that problems with
>>> sysvol synchronization rather originate in this circumstance
>>> than in the use of rsync w/o identical ids on both side.
>>> But I may be missing something...
>> Well, yes it would be nice to have sysvol replication etc, but the ID number
>> problem needs to be fixed first.
> I am still not convinced we strictly need it. :-)
> (We would even need it less with sysvol-replication.)
> But it would be convenient sometimes.
>
>>>> There is also the problem of when a user creates a tarball on one machine
>>>> and then copies it to another and unpacks it, they may find that all the
>>>> files no longer belong to them.
>>>>
>>>> If you log into *any* windows domain machine, you will get the same SID-RID,
>>>> why should Unix be any different?
>>> Because the windows sids are by design worldwide unique, while
>>> the unix pattern is to use the same unix id space on each machine
>>> and fill it individually.
>>>
>>> I completely agree that it may be nice to have it.
>>> But the real solution would be to have sid-like
>>> unix IDs in the linux kernel.
>> I will let you talk to Linus about that :-D
> Yeah, that is pretty unrealistic to have any time soon...
>
> Michael