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 useradd slack 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 (objectClass=posixAccount) 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): shadow-utils-4.0.17-12.el5
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 results: -------- No TLS shadow-utils-4.0.18.1-14 real 0m4.282s user 0m0.160s sys 0m0.492s shadow-utils-4.0.17-12.el5 real 0m6.746s user 0m0.152s sys 0m0.960s TLS shadow-utils-4.0.18.1-14 real 0m6.383s user 0m0.352s sys 0m0.296s shadow-utils-4.0.17-12.el5 real 0m10.321s user 0m0.492s sys 0m0.708s (shadow-utils-4.0.18.1-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 ***