Bug 201557

Summary: passwd hangs if ldap is selected but not configured
Product: Red Hat Enterprise Linux 5 Reporter: John Summerfield <debian>
Component: nss_ldapAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5.1CC: dpal, mattdm, me, pvrabec
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-05-05 19:29:24 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
This is created by running the useradd command under strace none

Description John Summerfield 2006-08-07 13:12:29 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20060614 Fedora/ Firefox/ pango-text

Description of problem:
I have a freshly-intalled FC6 beta system, and I first found this problem in my kinkstart %post script.

Examinaton showed the useradd command was hung.

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

How reproducible:

Steps to Reproduce:
1. Kickstart-install Fedora Core 6 Beta 1
2. Enable ldap in the auth statement
3. Add a user.

Actual Results:
Install stops, running useradd.Discovered by using the shell provide.d

Expected Results:
Useradd should complete in under a second.

Additional info:

This command can be used after install to get the same problem.
authconfig --useshadow  --enablemd5  --nostart --enableldap --enableldapauth --update

In the ks file, it was this:
auth  --useshadow  --enablemd5  --nostart --enableldap --enableldapauth

Here is my actual packages list:
@ core

This is the actual statement that hangs:
chroot /mnt/sysimage useradd -u 1000 admin

Comment 1 John Summerfield 2006-08-07 13:21:58 UTC
Created attachment 133727 [details]
This is created by running the useradd command under strace

The tracer shows useradd trying to connect to an LDAP server (and not
responding correctly qwhen it can't).

Comment 2 Peter Vrabec 2006-08-07 15:25:06 UTC
(gdb) bt
#0  0xb7ff1402 in __kernel_vsyscall ()
#1  0x419d6520 in __nanosleep_nocancel () from /lib/libc.so.6
#2  0x419d637b in sleep () from /lib/libc.so.6
#3  0x00a629c0 in _nss_ldap_next_entry () from /lib/libnss_ldap.so.2
#4  0x00a6351c in _nss_ldap_search_s () from /lib/libnss_ldap.so.2
#5  0x00a641a7 in _nss_ldap_getbyname () from /lib/libnss_ldap.so.2
#6  0x00a648d0 in _nss_ldap_getpwnam_r () from /lib/libnss_ldap.so.2
#7  0x419d56a3 in getpwnam_r@@GLIBC_2.1.2 () from /lib/libc.so.6
#8  0x419d516d in getpwnam () from /lib/libc.so.6
#9  0x0804d2b6 in main (argc=2, argv=0xbfd6b7b4) at useradd.c:1780
#10 0x41961214 in __libc_start_main () from /lib/libc.so.6
#11 0x08049ba1 in _start ()

This is nss_ldap problem, isn't it?

Comment 3 John Summerfield 2006-08-11 03:23:10 UTC
It also happens later if one enables LDAP using authconfig.

I don't see any tool at all to help set up ldap properly; authoconfig should not
enable ldap unless it can contact a working, configured server.

Comment 4 Matthew Miller 2007-04-06 19:48:21 UTC
Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no longer
test releases. We're cleaning up the bug database and making sure important bug
reports filed against these test releases don't get lost. It would be helpful if
you could test this issue with a released version of Fedora or with the latest
development / test release. Thanks for your help and for your patience.

[This is a bulk message for all open FC5/FC6 test release bugs. I'm adding
myself to the CC list for each bug, so I'll see any comments you make after this
and do my best to make sure every issue gets proper attention.]

Comment 5 John Summerfield 2008-03-08 14:35:09 UTC
the problem exists in CentOS 5.1

I've been starting an install (testing %post) and then going about other
matters, maybe returning hours later. The useradd takes about 14 minutes.

Comment 6 John Summerfield 2008-03-08 14:40:49 UTC
I really ought have added this:
+ authconfig '--ldapbasedn=dn=greenmount;dn=wa' --update
+ useradd -u 1000 admin

real    14m28.424s
user    0m0.161s
sys     0m0.019s
+ useradd summer

real    14m28.249s
user    0m0.159s
sys     0m0.021s
+ authconfig --test
caching is disabled
nss_files is always enabled
nss_compat is disabled
nss_db is disabled
nss_hesiod is disabled
 hesiod LHS = ""
 hesiod RHS = ""
nss_ldap is enabled
 LDAP+TLS is disabled
 LDAP server = "ldap://"
 LDAP base DN = "dn=greenmount;dn=wa"
nss_nis is disabled
 NIS server = ""
 NIS domain = ""
nss_nisplus is disabled
nss_winbind is disabled
 SMB workgroup = "MYGROUP"
 SMB servers = ""
 SMB security = "user"
 SMB realm = ""
 Winbind template shell = "/bin/false"
 SMB idmap uid = "16777216-33554431"
 SMB idmap gid = "16777216-33554431"
nss_wins is disabled
pam_unix is always enabled
 shadow passwords are enabled
 md5 passwords are enabled
pam_krb5 is disabled
 krb5 realm = "EXAMPLE.COM"
 krb5 realm via dns is disabled
 krb5 kdc = "kerberos.example.com:88"
 krb5 kdc via dns is disabled
 krb5 admin server = "kerberos.example.com:749"
pam_ldap is enabled

 LDAP+TLS is disabled
 LDAP server = "ldap://"
 LDAP base DN = "dn=greenmount;dn=wa"
pam_pkcs11 is disabled

 use only smartcard for login is disabled
 smartcard module = "coolkey"
 smartcard removal action = "Ignore"
pam_smb_auth is disabled
 SMB workgroup = "MYGROUP"
 SMB servers = ""
pam_winbind is disabled
 SMB workgroup = "MYGROUP"
 SMB servers = ""
 SMB security = "user"
 SMB realm = ""
pam_cracklib is enabled (try_first_pass retry=3)
pam_passwdqc is disabled ()
Always authorize local users is disabled ()
Authenticate system accounts against network services is disabled

Comment 7 Bug Zapper 2008-04-04 03:27:53 UTC
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

Comment 8 John Summerfield 2008-04-04 23:25:59 UTC
Did you not read that it occurs also in CentOS5?

Comment 9 petrosyan 2008-04-05 00:19:52 UTC
CentOS bugs should be reported at http://bugs.centos.org/

Is this bug present in Fedora 7, 8 or rawhide?

Comment 10 Jon Stanley 2008-04-05 02:27:34 UTC
John -

Computers can't read :)  I'll change the product to RHEL - though that is really
some interesting triage going on.  If this occurs in later Fedora, then please
open a new bug.

Comment 11 John Summerfield 2008-04-06 00:04:42 UTC
When Jon (I think it was) raised the idea of autoclosing bugs on Fedora test
recently, I said it wasn't a good idea.

This illustrates my point. The key issue is this: if a program fails. It's a bug
in _every_ distro and branch and clone and respin where that program appears.

The use of Bugzilla is one of the things wrong with the idea (from the RH POV)
of Fedora: software quality is a key issue in any OS or distribution, and RH is
relying on volunteers to solve its software problems.

But Fedora test is a better forum for this discussion.

Comment 12 Nalin Dahyabhai 2010-05-04 22:22:09 UTC
Am I reading it right that after timing out attempting to contact the server (repeatedly, while attempting to check if a given UID is unused), the right thing ends up happening?  This should be something that's resolved either by nss-pam-ldapd or sssd, both of which cause the calling application to return immediately when their respective local daemons aren't running.

Comment 13 Dmitri Pal 2010-05-05 19:29:24 UTC
5.6 and 6.0 will have SSSD that addresses this issue.
So this problem will not be fixed in the nss_ldap.