Emmanuel Dreyfus wrote:

On Mon, Jun 09, 2008 at 09:30:24PM -0700, Howard Chu wrote:

...

Interesting. Perhaps instead, your overlay should just maintain a fixed entry with a copy of the largest uidNumber in it, instead of searching the entire tree all the time.

FWIW, I had the same need, plus allocating gidNumber, sambaSID and whatever. I do with with a dirty hack that filters the output of an accesslog overlay directed to a shell backend.

When I'll have some time, I'd like to write on a slapo-exec, to run external scripts on various conditions. That would be much cleaner.

fork() is rather hazardous in a threaded program (which is one of the major problems with back-shell). Better to take the approach that back-sock uses, or just wrap some overlay glue around back-sock itself. (Much like slapo-chain is a simple wrapper around back-ldap.)

Emmanuel Dreyfus wrote:

On Mon, Jun 09, 2008 at 09:30:24PM -0700, Howard Chu wrote:

...

Interesting. Perhaps instead, your overlay should just maintain a fixed entry with a copy of the largest uidNumber in it, instead of searching the entire tree all the time.

FWIW, I had the same need, plus allocating gidNumber, sambaSID and whatever. I do with with a dirty hack that filters the output of an accesslog overlay directed to a shell backend.

When I'll have some time, I'd like to write on a slapo-exec, to run external scripts on various conditions. That would be much cleaner.

We've also had a similar need. Our solution was to randomly generate the uidNumber and gidNumber, between values of 70000 and 2000000, and then make the attributes unique with the unique overlay. Also, we use the constraint overlay to prevent the value from accidentally getting set to something dangerous (< 100).

Our user base is relatively small, but in the case we randomly generate an existing uid, we just start over.

Our user generation perl script looks something like:

sub new_random_uid { my $range = 1999929999; my $minimum = 70000; return int(rand($range)) + $minimum; }

my $gid_number = new_random_uid(); my $g_samba_number = $gid_number * 2 + 1001; my $uid_number = new_random_uid(); my $u_samba_number = $uid_number * 2 + 1000;

- Dan

On Tuesday 10 June 2008 06:30:24 Howard Chu wrote:

Joel Reed wrote:

...

The attached uidnumber.c overlay intercepts ADD requests for entries with a posixAccount objectclass that do not have a uidNumber. When such ADD requests are found, the overlay searches the directory for the largest uidNumber, then automatically adds a uidNumber attribute of largest+1 to the entry being added.

Interesting. Perhaps instead, your overlay should just maintain a fixed entry with a copy of the largest uidNumber in it, instead of searching the entire tree all the time.

It may be even nicer if it could be configured to use the sambaUnixIdPool method, which is supported by a number of LDAP frontend tools (such as smbldap-tools). Then the use of both wouldn't result in breakage.

If you don't know how this works, I can provide some details ...

However, this is quite nice ...

Regards, Buchan

joel reed wrote:

Howard Chu wrote:

...

Joel Reed wrote:

...

The attached uidnumber.c overlay intercepts ADD requests for entries with a posixAccount objectclass that do not have a uidNumber. When such ADD requests are found, the overlay searches the directory for the largest uidNumber, then automatically adds a uidNumber attribute of largest+1 to the entry being added.

Interesting. Perhaps instead, your overlay should just maintain a fixed entry with a copy of the largest uidNumber in it, instead of searching the entire tree all the time.

I did consider this, but didn't implement it because I was thinking about running in an N-Way Multi-Master configuration. On further reflection, this scheme would probably still not support such a configuration under load.

Obviously, the approach I took doesn't scale well as you point out. I think I will punt on supporting N-Way Multi-Master configs and either use the approach you note above or the sambaUnixIdPool approach noted elsewhere in this thread.

It seems the sambaUnixIdPool approach is essentually the same thing, they just have a dedicated entry with uidNumber and gidNumber attributes, recording the next available values.

Thanks to everyone who provided feedback. Greatly appreciated.

In a multimaster scenario the only sane way to handle things is to partition the namespace such that each master is allocating numbers from a totally disjoint range. I would try an approach like this:

Each server allocates uids in blocks, say 1000 at a time. There is an attribute that records the last used (or next available) block. This attribute resides in a dedicated entry that is read and written by all the servers. Each server then records, in a server-specific entry, the last used (or next available) number within that block. You can use the slap_serverID variable to obtain the current server's ID.

so, with 3 masters:

dn: cn=idblock,dc=example,dc=com objectclass: idblock cn: idblock uidNumber: 3000

dn: cn=server1,dc=example,dc=com objectclass: idblock cn: server1 uidNumber: 5

dn: cn=server2,dc=example,dc=com objectclass: idblock cn: server2 uidNumber: 1003

dn: cn=server3,dc=example,dc=com objectclass: idblock cn: server3 uidNumber: 2008

When a particular server allocates all 1000 of the IDs in its current block it will have to go back to the idblock entry and bump that up to the next range. At that point there's the potential for two servers to try to grab the same range, and the resulting conflict would create a big mess.

Another alternative, if you will never change the number of servers involved, is to do away with the central idblock entry and just allocate every-other-Nth ID. E.g., with 3 servers, server1 will allocate 0, 3, 6, 9 ... server2 will allocate 1,4,7,10,... server3 will allocate 2,5,8,11...

That guarantees there will never be conflicts, unless you decide to change the number of masters.