Atomic RID allocation in LDAP

[Andrew Bartlett]

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.

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.

While this generates a lot of DNs, I think it gives us a unique way to
allocate these...  (Which is much better than the racy stuff we have
now).

It's also a relitivly simple scheme, so we have a fighting chance that
external LDAP admin tools might use this too, when adding Samba
attributes.

Comments?

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