On (19/01/16 17:52), Sumit Bose wrote:
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.
I would like to apologize that I'm asking to late in process but
I'm not sure I understand in correctly.
The design page says:
https://fedorahosted.org/sssd/wiki/IdmapAutoAssignNewSlices
-> Overview of the solution
-> After primary slices for all domains are generated. Secondary slices
should be generated:
* Secondary slices should be computed at the start up of back end but
after primary slices for all domains are computed (to avoid potential
collision of primary slices with previously created secondary slices).
* Secondary slices should be created in round-robin manner meaning that
we first try to allocate #1 secondary slices for all domains,
then #2 secondary slices for all domains ... and finally
#$ldap_idmap_extra_slice_max secondary slices for all domains.
It looks like there is an expectation that we will have all domain parts of
SIDs available on start up of sssd. But I'm not sure it's correct expectation.
If this expectation is met then the algorithm should be deterministic.
But how can we guarantee that on two different machines (in the same domain)
there will be the same initial count of domains.
If I remember correctly we do not add id-mapping for each sub-domain.
Correct me if I'm wrong. But this is what I remember from analyzing log
files.
I'm sorry that I'm playing devil advocate so late.
(but still better then have undeterministic UIDs by default on different
machines)
LS