Atomic RID allocation in LDAP
Andrew Bartlett
abartlet at samba.org
Sat Oct 12 09:56:01 GMT 2002
Ignacio Coupeau wrote:
>
> Andrew Bartlett wrote:
> > I've been thinking about the problem of allocating RIDs in LDAP.
> >
> > We need a race-proof scheme to allocate RIDs, and I would prefer not to
> > need to use a local TDB - I would like it all 'in ldap', if at all
> > possible.
>
> yes, and is better because several PDC may share the same ldap samba
> accounts... an several sources of rids may be a bit dangerous.
>
> > While the real solution is an LDAP server that imposes restrictions on
> > attributes (like uniqueness constraints), we will have to settle for
> > what we have...
> >
> > Could we use LDAP DNs for this purpose? An LDAP distinguished name must
> > be unique - so why don't we have a separate 'allocation suffix'
> >
> > so cn=rids,dc=example,dc=com would contain:
> >
> > nextRid,cn=rids,dc=example,dc=com
> >
> > rid=1000,cn=rids,dc=example,dc=com
> > rid=1001,cn=rids,dc=example,dc=com
> > rid=1002,cn=rids,dc=example,dc=com
> >
> > A program wanting to allocate a RID would first read nextRid, and
> > attempt to add that RID. If it succeeds, it updates nextRID. If it
> > fails, it re-reads nextRid, and if unchanged adds 1 to the RID, and
> > tries again.
>
> I read in the OpenLdap list (Kurt, Chu) that the solution is modify
> *after* delete with previous value required, this ensures the atomicity:
> ----
> dn: cn=rids, o=smb, dc=example,dc=com
> changetype: modify
> delete: nextRid
> nextRid: 15000
> -
> add: nextRid
> nextRid: 15001
> -----
> also runs with ldap_mod and so.
OK, that make much more sense. But what to do in between the delete and
the add? Spin, and hope the entry 'comes back'?
Andrew Bartlett
--
Andrew Bartlett abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team abartlet at samba.org
Student Network Administrator, Hawker College abartlet at hawkerc.net
http://samba.org http://build.samba.org http://hawkerc.net
More information about the samba-technical
mailing list