Bug 201557

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

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

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.

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.]

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.

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://127.0.0.1/"
 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://127.0.0.1/"
 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

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.
http://fedoraproject.org/wiki/LifeCycle/EOL

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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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

Did you not read that it occurs also in CentOS5?

CentOS bugs should be reported at http://bugs.centos.org/

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

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.

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.

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.

5.6 and 6.0 will have SSSD that addresses this issue.
So this problem will not be fixed in the nss_ldap.