The method usernextfreeuid of diradm.common.sh looks incorrect, and doesn't work for me. Used on an empty system just moved to LDAP, it generates an empty result, because it can't find an existing user with UID > UIDNUMBERMAX. Used on an LDAP with a "valid" user (UID = 1001), it return the highest UID found, but doesn't increment it, resulting in a duplicated UID. Reproducible: Always Actual Results: 1) Empty if no user is in the range ]UIDNUMBERMIN, UIDNUMBER MAX[ ; 2) Highest UID in this range otherwise. Expected Results: 1) UIDNUMBERMIN + 1 (or UIDNUMBERMIN?) if no user is in the range ]UIDNUMBERMIN, UIDNUMBER MAX[ ; 2) Highest UID in this range + 1 otherwise.
Created attachment 178266 [details] diradm.common.sh that work for me
Oops, wrong version, I was on "stable". I'm testing the ~x86 one (2.9.6)
The situation is a bit better. The "no user in range" case (1) still returns empty but it's handled correctly in diradm.user.sh. The "no user" case would return $UIDNUMBERMIN, so it's OK but... But the uidNumbers are still duplicated for the second user, because the "-gt" test that should be a "-ge" (see patch attached). I still think there's an inconsistency because for a list of uids like say "1 2 3" will return empty, while with an empty list it will return "1001". So I did another change to get the same behaviour for "no user" : removing check for empty list. This way, it will return the same value for "no user in range" AND "no user at all". Hope I'm clear...
Created attachment 178300 [details, diff] patch for diradm.common.sh#usernextfreeuid
Created attachment 178301 [details] Modified ebuild (maybe not in the best way but works)
The patch does not seem to work for me, in my case the new userid is always 1000 even if 1000 is already used by one (or more) users.
Nevermind, my fault... Any chance that this patched version could be stabilized as 2.9.6-r1?
2.9.7 in the tree with this fix (and no other code changes, just buildsystem cleanups).
