Bug 240605 - useradd with large ldap directories
Summary: useradd with large ldap directories
Status: CLOSED DUPLICATE of bug 236871
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: shadow-utils
Version: 5.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Peter Vrabec
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-05-18 18:45 UTC by Jack Neely
Modified: 2009-11-02 12:24 UTC (History)
0 users

Clone Of:
Last Closed: 2009-11-02 12:24:17 UTC

Attachments (Terms of Use)
strace of adduser (32.24 KB, text/plain)
2007-05-18 18:49 UTC, Jack Neely
no flags Details

Description Jack Neely 2007-05-18 18:45:04 UTC
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


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):

Comment 1 Jack Neely 2007-05-18 18:49:06 UTC
Created attachment 155025 [details]
strace of adduser

Comment 2 Jack Neely 2007-05-18 18:57:07 UTC
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?

Comment 3 Peter Vrabec 2007-05-21 08:29:51 UTC
This is same problem as in #236871. Could you test my patch from comment #19.

Comment 4 Jack Neely 2007-05-22 14:39:06 UTC
Unfortunately, I don't seem to have the propper permissions to access bug #236871.

Comment 5 Peter Vrabec 2007-05-22 15:13:03 UTC
I have a problem to reproduce it :(
running ldap server with 8000 account on fedora6 (xen host)
client is RHEL-5

real    0m4.282s
user    0m0.160s
sys     0m0.492s
real    0m6.746s
user    0m0.152s
sys     0m0.960s

real    0m6.383s
user    0m0.352s
sys     0m0.296s
real    0m10.321s
user    0m0.492s
sys     0m0.708s

(shadow-utils- is more optimized - the patch I have mentioned)

Comment 6 Jack Neely 2007-06-08 19:41:20 UTC
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.

Comment 7 Peter Vrabec 2009-11-02 12:24:17 UTC

*** This bug has been marked as a duplicate of bug 236871 ***

Note You need to log in before you can comment on or make changes to this bug.