22 Nov
2012
22 Nov
'12
12:01 a.m.
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