MJ J wrote:
> You don't need a special object class or schema, you can use this:
> dn: cn=user,ou=increment,dc=foo,dc=bar
> objectClass: top
> objectClass: account
> objectClass: posixAccount
Ouch! Depending on the config of your LDAP server and client systems
this is a visible user account with username 'user' and *changing* and
*conflicting* uidNumber. This is bad design. No wonder if you're running
into problems with nss-pam-ldapd (nslcd) or sssd later.
You have been warned.
> And here is a python method to do the job for you:
>
> def increment_uidnumber(l, base):
> """ Perform LDAP modify-increment operation on uidNumber tracking object """
> modlist = [(ldap.MOD_INCREMENT, "uidNumber", "1")]
> l.modify_s("cn=user,{0}".format(base), modlist)
> r = l.search_s(base, ldap.SCOPE_SUBTREE, "(objectClass=posixAccount)",
> ['uidNumber'])
> next_number = r[0][1]['uidNumber'][0]
>
> return next_number
Using MOD_INCREMENT is good but the above read-after-write is prone to
race conditions. Since you're using Python you can look at file
Demo/pyasn1/readentrycontrol.py to learn how to use the PreReadControl
or PostReadControl class (see also RFC 4527) for incrementing *and*
reading the new ID within a single atomic modify operation.
Also note that you should only do this on a single provider or "primary"
MMR-enabled provider (ITS#8757 would be nice for that).
BTW: That's how it's done in Æ-DIR but with a special object class:
https://demo.ae-dir.com/web2ldap?ldapi://%2Fopt%2Fae-dir%2Frun%2Fslapd%2Fldapi/ou=ae-dir??base??bindname=aead,X-BINDPW=CorrectHorseBatteryStaple
One of the unsolved problems is that IDs consumed from the pool might
not really be used by the client application possibly resulting in gaps
in your ID space.
Ciao, Michael.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature