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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature