-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/17/2013 08:05 PM, Russell Jones wrote:
On 4/17/2013 5:52 PM, Dmitri Pal wrote:
Slices are not given out by the clients.
Let me try to illustrate. Imagine that your slices are storage containers in a storage facility. Each slice has a number. You come in and you want to use a container. Which one? We then take you name, SSN, eye color, DOB etc. and hash. As a result we get a number. This number is the number of your storage container. Same here. The part of the SID is the unique identifier that identities the domain. The hash of it will always have number X. This number will always define which storage container (slice) would be used for your domain. There is a chance that some other domain would have the same number but the probability is very low.
No you can configure how big slices are. The bigger the slice the smaller the number of the slices. So X might map to a different container if you start re-configuring things and reducing the width of the slices.
HTH.
Thanks Dmitri!
By "given to the clients" I meant by the SSSD daemon. Sorry for the confusion with how I typed up my scenario. What I am not understanding is how setting the default domain in the configuration prevents non-deterministic handling of slice collisions. The man page states:
"NOTE: It is possible to encounter collisions in the hash and subsequent modulus. In these situations, we will select the next available slice, but it may not be possible to reproduce the same exact set of slices on other machines (since the order that they are encountered will determine their slice). In this situation, it is recommended to..... <snip> ..... configure a default domain to guarantee that at least one is always consistent."
How does having one domain always be slice 0 resolve the other domains possibly not being consistent? Or is the "at least" in the man page saying that users of the domain assigned to slice 0 will always have the same UID's, but not necessarily users in the other domains?
Yes, this last sentence is correct. What we are recommending is that you would normally set the "primary" domain (the one which the client is directly enrolled in) to the default domain. Then you know that at least for that domain, it's always guaranteed to be the same value on all systems.
Samba's autorid plugin behaves similarly to ours, except that it is *always* based on order of encounter. We added the hash trickery in order to significantly increase the likelihood that it would come up as the same on two different systems. In the case of hash collisions, we fall back on something close to the autorid behavior (where we just assign it the next first free value).