Bug 511813 - useradd -r loops when talking to ldap server
useradd -r loops when talking to ldap server
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: shadow-utils (Show other bugs)
11
All Linux
low Severity urgent
: ---
: ---
Assigned To: Peter Vrabec
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-15 04:00 EDT by stef
Modified: 2009-08-12 16:53 EDT (History)
4 users (show)

See Also:
Fixed In Version: 4.1.4.1-5.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 466794
Environment:
Last Closed: 2009-08-12 16:53:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description stef 2009-07-15 04:00:14 EDT
+++ This bug was initially created as a clone of Bug #466794 +++

Created an attachment (id=320205)
don't call getpwent after first NULL is returned 

Description of problem:

When trying to do a 'useradd -r ...' and nsswitch.conf contains 'passwd: files ldap',
the command hangs in an infinite loop.

Version-Release number of selected component (if applicable):

shadow-utils-4.1.1-4.fc9.i386



How reproducible:

Always

Steps to Reproduce:
1. useradd -r -s /some/shell -d /some/dir -M -g some_group some_user

  
Actual results:

Infinite loop

Expected results:

User added

Additional info:

The reason seems to be that getpwent() returns NULL once, and then restarts delivery of results from the LDAP database.

--- Additional comment from anders.blomdell@control.lth.se on 2008-10-13 13:27:54 EDT ---

Actually, it doesn't enter an infinite loop. It only loops through the LDAP database once for each entry in the local password database, due to the fact that in the following loop the first time getpwent returns NULL, pw_next returns the first local entry, then on the next iteration getpwent restarts reading the LDAP database.

       while (   ((pwd = getpwent ()) != NULL)
              || ((pwd = pw_next ()) != NULL)) {


but with 30 machines trying to add the same user, a local passwd with 50 users and a LDAP database with 12000 users, it all boiled down to 30 * 50 * 12000 = 18000000 LDAP lookups, which takes a very long time.

--- Additional comment from anders.blomdell@control.lth.se on 2008-10-14 08:30:15 EDT ---

Filed bug against upstream libnss_ldap as well:

http://bugzilla.padl.com/show_bug.cgi?id=376

--- Additional comment from lex.lists@gmail.com on 2009-03-03 19:12:33 EDT ---

Upstream bug has been closed.
Is this still an issue for the reporter?

--- Additional comment from fedora-triage-list@redhat.com on 2009-06-09 22:57:10 EDT ---


This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from stephane.tranchemer@devinci.fr on 2009-06-16 11:31:13 EDT ---

I can see the same trouble with FC11 final.

Trying to install the akmods package from RpmFusion, the package sits forever and does not install.

I could look into the package seeing it was blocked at the %pre step :

useradd -r -g akmods -d /var/cache/akmods/ -s /sbin/nologin -c 'User is used by akmods to build akmod packages' akmods


I also have a Ldap server for authentication.

--- Additional comment from stephane.tranchemer@devinci.fr on 2009-06-18 05:59:02 EDT ---

this can be seen too when trying to install the package "partimage-server"

the following is involved :

D:   install: %pre(partimage-server-0.6.7-7.fc11.i586)	execv(/bin/sh) pid 21938
+ /usr/sbin/useradd -M -r -s /sbin/nologin -d /var/partimaged -c 'Partition imaging utility' partimag

--- Additional comment from stephane.tranchemer@devinci.fr on 2009-06-29 07:49:41 EDT ---

I got additional infos,

using strace I have 'listened' to what happens to the useradd command and it showed me this :

# strace useradd -r -g akmods -d /var/cache/akmods/ -s /sbin/nologin -c 'User is used by akmods to build akmod packages' akmods

then we can see that useradd tries to browse THE WHOLE ldap directory

*extract*

rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {0x1, [], 0}, {SIG_DFL, [], 0}, 8) = 0
gettimeofday({1246276038, 201210}, NULL) = 0
poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=4, revents=POLLIN}])
read(4, "0\202\1\214\2\1\3d"..., 8)     = 8
read(4, "\202\1\205\4%uid=anedroum,ou=User,dc=devi"..., 392) = 392
time(NULL)                              = 1246276038
rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {0x1, [], 0}, {SIG_DFL, [], 0}, 8) = 0
gettimeofday({1246276038, 201877}, NULL) = 0
poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=4, revents=POLLIN}])
read(4, "0\202\1\210\2\1\3d"..., 8)     = 8
read(4, "\202\1\201\4$uid=abaghor,ou=User,dc=devin"..., 388) = 388
time(NULL)                              = 1246276038
rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {0x1, [], 0}, {SIG_DFL, [], 0}, 8) = 0
gettimeofday({1246276038, 202563}, NULL) = 0
poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=4, revents=POLLIN}])
read(4, "0\202\1\204\2\1\3d"..., 8)     = 8
read(4, "\202\1}\4#uid=bbalan,ou=User,dc=devinc"..., 384) = 384
time(NULL)                              = 1246276038
rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {0x1, [], 0}, {SIG_DFL, [], 0}, 8) = 0
gettimeofday({1246276038, 203231}, NULL) = 0
poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=4, revents=POLLIN}])
read(4, "0\202\1\214\2\1\3d"..., 8)     = 8
read(4, "\202\1\205\4%uid=hbouichm,ou=User,dc=devi"..., 392) = 392
time(NULL)                              = 1246276038
rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {0x1, [], 0}, {SIG_DFL, [], 0}, 8) = 0
gettimeofday({1246276038, 203883}, NULL) = 0
poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=4, revents=POLLIN}])
read(4, "0\202\1\214\2\1\3d"..., 8)     = 8
read(4, "\202\1\205\4%uid=hbounekt,ou=User,dc=devi"..., 392) = 392
time(NULL)                              = 1246276038
rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {0x1, [], 0}, {SIG_DFL, [], 0}, 8) = 0
gettimeofday({1246276038, 204537}, NULL) = 0
poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=4, revents=POLLIN}])
read(4, "0\202\1\214\2\1\3d"..., 8)     = 8
read(4, "\202\1\205\4%uid=lcouliba,ou=User,dc=devi"..., 392) = 392
time(NULL)                              = 1246276038
rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {0x1, [], 0}, {SIG_DFL, [], 0}, 8) = 0
gettimeofday({1246276038, 205199}, NULL) = 0
poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=4, revents=POLLIN}])
read(4, "0\202\1\210\2\1\3d"..., 8)     = 8
read(4, "\202\1\201\4$uid=scourty,ou=User,dc=devin"..., 388) = 388
time(NULL)                              = 1246276038

*extract*

of course doing so can be very long... 

this behaviour should be fixed

--- Additional comment from stephane.tranchemer@devinci.fr on 2009-06-29 07:52:30 EDT ---

as a reminder, the problem I describe in comment #5 #6 #7 are in Fedora Core 11

So this is an ACTUAL problem, not a end-of-life distro.

This bug should be re-qualified as actual too

--- Additional comment from stephane.tranchemer@devinci.fr on 2009-06-29 07:53:14 EDT ---

since relevant infos are provided

--- Additional comment from pvrabec@redhat.com on 2009-06-30 05:11:32 EDT ---

loop mentioned in comment #1 is not present in shadow-utils >= F11.

Q. is what you want to  fix. useradd has to iterate thru LDAP. 
man page:
"You may not add a user to a NIS or LDAP group. This must be performed on the corresponding server.
Similarly, if the username already exists in an external user database such as NIS or LDAP, useradd will deny the user account creation request."

--- Additional comment from stephane.tranchemer@devinci.fr on 2009-06-30 05:25:25 EDT ---

(In reply to comment #10)

I don't get your question, if it is one.

So to you it is perfectly normal that you have to wait for several minutes for a simple "useradd", or a RPM installation that creates a user account in its 'pre' commands ?

for the record, our LDAP server only has accounts with UID number over 5 digits to not mix with 3 digits system ones.
So logicaly it should find very fast an available UID number right after looking into /etc/password, not spending aeons to browse a identification server with very high,therefore not interesting, numbers.

--- Additional comment from pvrabec@redhat.com on 2009-07-01 05:44:33 EDT ---

Unfortunately, it's not that easy, because:

1. getpwent() doesn't return entries in chronology 
example:
UID: 1 4 3 100

2. in case of user accounts it's always looking for for max first unused values
example:
UIDs: 1 4 3 100 -> 101 is the one

But there is a possibility to change alg. a bit. in a way that  getpwuid() is used for system accounts. Let me ask upstream what they think about it. This could solve the problem at least for system accounts. :)

--- Additional comment from fedora-triage-list@redhat.com on 2009-07-14 13:15:06 EDT ---


Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 1 stef 2009-07-15 04:00:53 EDT
reoppening a new bug tagged as FC11 since the problem still remains
Comment 2 Peter Vrabec 2009-07-15 08:39:10 EDT
here we go, Stefan could you please test this new package:

http://people.redhat.com/pvrabec/rpms/shadow-utils-4.1.4.1-2.fc11.src.rpm

If it works, I'm ready to push it into repo. thnx.
(I have tested it, but not on the box against BIG LDAP)
Comment 3 stef 2009-07-15 08:47:59 EDT
(In reply to comment #2)
> here we go, Stefan could you please test this new package:
> 
> http://people.redhat.com/pvrabec/rpms/shadow-utils-4.1.4.1-2.fc11.src.rpm

justa question : it's a .src.rpm so it's source and I have to create the corresponding RPM package myself, right ?

I must admit that I'm not really familiar with the RPM creation process, could you create a binary package please ?
Comment 4 Peter Vrabec 2009-07-15 11:34:29 EDT
no problem:
http://kojipkgs.fedoraproject.org/scratch/pvrabec/task_1476033/
Comment 5 stef 2009-07-16 03:54:38 EDT
Sorry for the late answer
I could test your package and I'm happy with it.

I can make users with a delay of only about 3 seconds now and it still detects if an account already exists on the LDAP.

it's okay for my needs, maybe someone else (like the reporter of the original bug) could test to confirm too.
Comment 6 Fedora Update System 2009-07-17 10:31:02 EDT
shadow-utils-4.1.4.1-4.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/shadow-utils-4.1.4.1-4.fc11
Comment 7 stef 2009-07-20 07:09:19 EDT
(In reply to comment #6)
> shadow-utils-4.1.4.1-4.fc11 has been submitted as an update for Fedora 11.
> http://admin.fedoraproject.org/updates/shadow-utils-4.1.4.1-4.fc11  

I have not seen this package in the updates servers, is there a problem preventing the push?
Comment 8 Fedora Update System 2009-07-22 18:02:13 EDT
shadow-utils-4.1.4.1-4.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update shadow-utils'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-7891
Comment 9 Fedora Update System 2009-08-05 10:18:09 EDT
shadow-utils-4.1.4.1-5.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/shadow-utils-4.1.4.1-5.fc11
Comment 10 Fedora Update System 2009-08-07 00:54:38 EDT
shadow-utils-4.1.4.1-5.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update shadow-utils'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-8306
Comment 11 Fedora Update System 2009-08-12 16:52:51 EDT
shadow-utils-4.1.4.1-5.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

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