Thanks for your reply

I create users whis this scripts: add_user.sh ----------------- #!/usr/bin/expect -f

log_user 0 set force_conservative 0

if {$force_conservative} { set send_slow {1 .1} proc send {ignore arg} { sleep .1 exp_send -s -- $arg } }

set ADMIN_PASSWD (*********) set timeout -1 spawn -noecho luseradd [lrange $argv 0 0] -P[lrange $argv 1 1] -c "#[lrange $argv 3 3] @[lrange $argv 2 2]" -d [lrange $argv 4 4] -s [lrange $argv 5 5] #stty raw -echo expect { -re "LDAP Bind Password: " { send -- "$ADMIN_PASSWD\r" exp_continue } -re "Already exists." { exit 1 } }

---------------

And this asign automaticaly UID and GID

the parameters of the script are:

./add_user.sh user1 PassWord123 hostname_server cloud1 /home/user1 /sbin/nologin

On 19/02/15 17:31, Dan White wrote:

On 02/19/15 11:54 -0300, Fabián M Sales wrote:

...

I am creating users in LDAP and I assign different UID and GUI. For example.

What utility or process are you using to create these entries?

...

uid = _16661_ (user1) gid = _16664_ (user1) groups = _16664_ (user1)

I need that when the user is created is created with the same UID and GID for user created.

as I do this?

I would love for it to be so:

uid = _16664_ (user1) gid = _16664_ (user1) groups = _16664_ (user1)

The values entered for uid/gid into your ldap directory are up to you (and the tools you use). If you wish to limit or restrict the values that can be used, see slapo-constraint(5) and slapo-unique(5).

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.

Ulrich Windl wrote:

...

...

...

Michael Strödermichael@stroeder.com schrieb am 21.02.2015 um 20:06 in

Nachricht 54E8D726.30503@stroeder.com:

...

Bernd May wrote:

[...]

...

...

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.

But that's somewhat "performance-heavy" I guess. What could help here would be transactions (actually nested transactions). Consume a UID/GID and assign it to a new entry in one transaction.

This would only help in case the second write operation fails.

But the more likely problem is that the user might abort the use-case. Of course it depends when the client actually generates the id. In case of my web2ldap I present the generated id in the input form so the user could manually change it if needed. But the user might not hit the submit button.

YMMV.

Ciao, Michael.

On 21.02.2015. 19:45, Bernd May wrote:

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.

If one has a special entry to track the highest uid, reuse of the uid value by multiple processes can be avoided by a ldapmodify operation which combines deleting the existing value with adding a new value. E.g., if the highest uid is in the uidNumber attribute of cn=maxUid,dc=example,dc=org, one would perform (in a pseudo-shell syntax):

maxuid=$(ldapsearch cn=maxUid uidNumber...) nextuid=$((maxuid+1))

ldapmodify <<! cn=maxUid,dc=example,dc=org changetype: modify delete: uidNumber uidNumber: $maxuid - add: uidNumber uidNumber: $nextuid !

If another process manages to update the entry between ldapsearch and ldapmodify, the delete operation will fail and the entry will be unchanged. The operation can then be retried with updated values.

(Not tested with multimaster replication and heavy write load/split-brain situations.)