On 2012-11-22 10:42, Jason White wrote:
If you're mainly worried that your tool could end up creating two users at once, you could use locking to prevent it, I suppose.
If you're concerned that someone might run useradd/groupadd at the same time as your tool is operating, I don't see how this could be prevented easily other than opening and locking /etc/passwd or /etc/group.
Is there a good reason not simply to spawn useradd/groupadd and let them allocate the ids?
Is it safe to assume that uids/gids appear in ascending order in /etc/passwd and /etc/group? In general, probably not, especially as an administrator might edit those files, so that's out.
Jason, Brian's talking about LDAP; /etc/passwd and /etc/group are irrelevent, as are, probably useradd/groupadd. Brian, I suspect that your predecessor's solution may be the most straightforward; Assuming you don't have a monstrous number of users, and have the uidNumber attribute indexed in the LDAP database, listing current UIDs shouldn't be too expensive. If you were using shell, you could do something like this: ldapsearch -LLLx uidNumber | grep uidNumber | sort -nk2 | tail -2 | head -1 That's ugly and hackish; the tail/head at the end excludes the nobody user whose uidNumber (on my system) is 65534. There are probably slightly more elegant ways to do it, especially if you're not using shell. The way we do it at work is by iterating through getent passwd, incrementing the UID until we find one that doesn't match an existing entry[1]. This would be somewhat slow with lots of users though. 1. while getent passwd $id || getent group $id do [ $id = 9999 ] && die "Ran out of IDs." || : ((id++)) done >/dev/null -- Regards, Matthew Cengia