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.> >> 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.>> 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 Rowland> > Cheers - Michael
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).> >>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 :-DYeah, that is pretty unrealistic to have any time soon... Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://lists.samba.org/pipermail/samba/attachments/20151108/3e2c2173/signature.sig>
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