On Tue, Jan 19, 2016 at 11:08:50AM -0500, Simo Sorce wrote:
On Tue, 2016-01-19 at 16:27 +0100, Lukas Slebodnik wrote:
> I'm not sure about the defualt value.
>
> Simo wrote few comments on IRC few days ago that this feature is not
> deterministic among more machines.
> e.g.
> there are few users
> jakub -- S-1-5-21-100-200-300-12809
> simo -- S-1-5-21-100-200-300-212809
> sumit -- S-1-5-21-300-200-100-12809
>
> Let say that S-1-5-21-100-200-300 will be mapped to the slice 10
> and S-1-5-21-300-200-100 to the slice 11
>
> machine A:
> * getent passwd jakub -> slice 10 is created
> * getent passwd simo -> slice 11 is created based on this feature
>
> machine B:
> * getent passwd jakub -> slice 10 is created
> * getent passwd sumit -> slice 11 is created
>
>
> And user 'simo' will have the same UID on 'machine A' as user
> 'sumit' on 'machine B'. It can be a problem on nfs.
>
>
> So I'm not sure we should enable this feature by default.
> But on the other hand this feature might fix many users complications.
Sumit explained to me the slice selected was going to be determined by
the murmur hash, is it not ?
Are slices selected linearly as a first come - first serve basis ?
That is not workable, the code must try *hard* to come up with the same
slices regardless of the order in which users "appear".
no, the slices are selected based on the SID of the object. The domain
part is used as a prefix. The RID is divided by the range size which
gives you the number of the slice of this domain. E.g. if the range size
is 1000 and the rid is 3456 the number is 3 and this slice will map the
RIDs from 3000 to 3999. The first RID of the slice is appended to the
domain SID and the result is fed into murmurhash to get a matching slice
of POSIX IDs which is equivalent to what we already do. This scheme is
reproducible and can cover holes in the RID range as well. In the
examples above, if there are no RID between 2000 and 2999 we will not
allocate a range for this RIDs. But if later an object with a RID with
e.g 2345 is added then the range can be added as well without changing
any of the existing ones.
HTH
bye,
Sumit
>
> Simo.
>
> --
> Simo Sorce * Red Hat, Inc * New York
> _______________________________________________
> sssd-devel mailing list
> sssd-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org