Atomic RID allocation in LDAP

[Andrew Bartlett]

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