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. 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, the cure is to have the same idmap.ldb on all DCs. 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? Rowland
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.> 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...> 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. Cheers - 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/75b7b6e7/signature.sig>
Hi, On 8 November 2015 at 10:49, Michael Adam <obnox at samba.org> wrote:> This is how it works in rsync:[...]> 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.This is the major area I have had problems with in the past, same as Rowland and many others I expect. I should probably look into it in a little more detail to be honest; last time I tried it it was a little bit of a black art but I ended up fixing it by a combination of - switching to rfc2307 - allocating all groups and users a GID/UID, including the 'BUILTIN' ones - copying idmap.ldb between my DCs Despite all this, I still have files owned by 'raw' UIDs on my DCs (these map to 'BUILTIN\Authenticated Users' and 'BUILTIN\Local System') e.g. [root at dc ~# getfacl /usr/local/samba/var/locks/sysvol getfacl: Removing leading '/' from absolute path names # file: usr/local/samba/var/locks/sysvol # owner: root # group: administrators user::rwx user:root:rwx user:3000013:r-x user:3000140:rwx [...] [root at dc ~]# net cache list | egrep "(0013|00140)" Key: IDMAP/GID2SID/3000140 Timeout: Sun Nov 15 04:04:35 2015 Value: S-1-5-18 Key: IDMAP/UID2SID/3000013 Timeout: Sun Nov 15 03:23:23 2015 Value: S-1-5-11 but replication does seem to work across DCs via rsync at the moment. I suspect this is another thread entirely from the bug we have been discussing, though :) Maybe there's a way I can add the rfc2307 attributes to these two SIDs (although I haven't found it yet) We should probably update the 'sysvol rsync howto' wiki entry with our findings. I should actually update it anyway, as I have a working multi-DC configuration using lsyncd that lets me update GPOs on any DC (as long as I only update on one at a time)>> 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.Agreed, that would be great :) But I think until we have this in the kernel, it would be good if we can work around it within Samba, if possible - e.g. rfc2307 support for example. Cheers, Jonathan -- "If we knew what it was we were doing, it would not be called research, would it?" - Albert Einstein
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