Bug 240605

Summary: useradd with large ldap directories
Product: Red Hat Enterprise Linux 5 Reporter: Jack Neely <jjneely>
Component: shadow-utilsAssignee: Peter Vrabec <pvrabec>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-11-02 12:24:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
strace of adduser none

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

   (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
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

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