Red Hat Bugzilla – Bug 240605
useradd with large ldap directories
Last modified: 2009-11-02 07:24:17 EST
Description of problem:
We use useradd to create custom local accounts for "special" folks or for
testing, package building, etc. However, our machines are also configured to
pull password/group information from LDAP which contains over 60,000 accounts.
Our LDAP server is also configured to never return more than 500 entries per
search. With this setup running
will never complete. It appears to want to strcmp() "slack" to every username
in the database. A tcpdump session shows that useradd via nss-ldap has run an
ldap search of
Ummm...this is bad. It also appears that useradd is unable to handle the
condition where the ldap search only returns a partial answer.
It also seems to do something similar for groups.
The only way I've been able to create my build accounts is to edit
/etc/nsswitch.conf to use "password: files" rather than "password: files ldap".
I then create the account and change nsswitch.conf back.
Version-Release number of selected component (if applicable):
Created attachment 155025 [details]
strace of adduser
Well, filing a bug always helps me to figure out what's going on.
It appears if I give the command enough time to complete it will, and create the
account successfully. It just takes a while.
Being that my LDAP directory is so large, folks are sensitive to doing LDAP
searches like the above. Perhaps this is more related to adduser wanting to
examine all usernames?
This is same problem as in #236871. Could you test my patch from comment #19.
Unfortunately, I don't seem to have the propper permissions to access bug #236871.
I have a problem to reproduce it :(
running ldap server with 8000 account on fedora6 (xen host)
client is RHEL-5
(shadow-utils-18.104.22.168-14 is more optimized - the patch I have mentioned)
I've tested 4.0.18-1.15 from rawhide. Well, its down to 2 minutes from 4.
Its still issuing system calls that translate into nss_ldap running an
(objectClass=posixAccount) search on my LDAP directory. The slowness comes from
this really expensive query running on the LDAP server and useradd waiting for
the results. (We have some extra information in with our posixAccount entries.
Its not much by itself, but times 60K and its very large.)
If we can run queries for the numerical ID, and the user ID string I just don't
see how its feasible for this tool (and many others) to think that they can pull
in a list of all users and "do stuff." Universities have quite a few users and
LDAP doesn't handle these large searches well. (We are migrating from hesiod
were such searches were impossible to do.) In fact, our LDAP servers will only
send back a max of 500 entries per request so useradd isn't getting a complete
list to begin with.
*** This bug has been marked as a duplicate of bug 236871 ***