Bernd May wrote:
I faced the same problem a year ago and came to the same conclusion as Dan.
OpenLDAP does not offer you a mechanism to duplicate attribute values upon entry or change (e.g. like triggers in a MySQL DB might do for you). So you have to make sure, during entry creation, that the proper values are assigned to the required attributes, e.g. by querying the OpenLDAP DB first, filtering for assigned numbers and selecting an unassigned uid and gid pair inside your user creation tool.
Yes, the LDAP client has to generate appropriate data. Personally I'm making heavy use of slapo-constraint to ensure that the data sent by the client is correct.
You could also create a dummy user account that stores the next usable gid/uid pair (which you acquired once with the previous algorithm) and then query that account each time you create a new user, increase its gid and uid values and create your new user. This assumes some kind of conflict free numbering scheme of your users by which you can infer the next free number pair automatically.
The problem with id pool entries (kind of a sequence generator) is that ids might be consumed without being really used. Therefore for numeric ids it's a better approach to search for all entries, use reverse server-side sorting and only query one result to get the highest id.
For user names one could also use a time-based generation scheme.
What OpenLDAP does offer is the possibility of checking this constraint for you by employing the slapo-unique overlay (to make sure you do not assign a number that is already in use) and the slapo-constraint overlay (to make sure the gid and uid attribute have the same value).
Yes! When assigning unique ids with concurrent clients one must use slapo-unique. Any other approach will fail. You have to implement proper error handling with retry at the client side.
Ciao, Michael.