|Summary:||passwd hangs if ldap is selected but not configured|
|Product:||Red Hat Enterprise Linux 5||Reporter:||John Summerfield <debian>|
|Component:||nss_ldap||Assignee:||Nalin Dahyabhai <nalin>|
|Status:||CLOSED WONTFIX||QA Contact:|
|Version:||5.1||CC:||dpal, mattdm, me, pvrabec|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-05-05 19:29:24 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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:126.96.36.199) Gecko/20060614 Fedora/188.8.131.52-1.2.fc5 Firefox/184.108.40.206 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): shadow-utils-4.0.16-3 How reproducible: Always 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: packages @ core postfix -sendmail anaconda anaconda-runtime -apmd lslk lynx vim-enhanced 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://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
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. 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
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.