sam replication
José Luis Tallón
jltallon at adv-solutions.net
Wed Sep 17 16:02:12 GMT 2003
At 22:57 17/09/2003 +1000, Andrew Bartlett wrote:
>On Wed, 2003-09-17 at 22:38, José Luis Tallón wrote:
> >
> > now, if we want to add new users, we are in the situation that the RIDs
> > they would be assigned are already being used by machines. Therefore, i
> > propose separating the RID ranges for machines and users ( though it is
> > different from what Win does )
>
>RID allocation should be independent of UID allocation, if you want it
>that way. However, if you are allocating a UID for translation into an
>algorithmic RID, then it's up to you to avoid conflicts.
>
>You are going to need to create UID (posixAccount) entries for all your
>machines anyway,
well, you( the Samba Team ) made it possible to have NUA machine accounts,
so that's what i used
>so why not just make your scripts avoid adding
>duplicate entries?
For users, they surely do. I create their user accounts "by hand" in LDAP.
For machines, i relied on Samba's auto-creation on join. It has all worked
fine.
My mistake was that i configured idmap ranges for winbind ( which i later
decided against, once i checked it didn't work -- probably due to
misconfig, but i didn't have the time to check and it was only beta1 ) and
now, my new users would collide with the RIDs assigned to machines.
It is my fault( short term vision ), by i thought this might help others in
a similar situation.
As long as Samba needs an UID to write files ( that is, until files are
owned by SIDs stored in EAs in the filesystem ), i believe that algorithmic
RIDs are actually an advantage[ from the sysadmin point of view], as well
as NUA machine accounts with a separate RID range to avoid collisions. This
could be implemented as a separate entry in the 'domain' ( sambaDomainName=
) entry in the LDAP tree.
I'm very sorry that i don't know enough of Samba's internals nor do i have
the spare time to provide a patch for this :-| ( provided you find it
reasonable )
Thanks for your time.
Regards,
J.L.
>Andrew Bartlett
More information about the samba-technical
mailing list