>Number: 161456 >Category: misc >Synopsis: on a system bound to an LDAP server, top tries to get the >whole LDAP content to resolve uids >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Oct 10 09:30:10 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Patrick Proniewski >Release: 7.3-RELEASE-p7 and 8.2-RELEASE-p3 >Organization: Université Lyon2 >Environment: FreeBSD foo.univ-lyon2.fr 8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: Tue Sep 27 18:45:57 UTC 2011 [email protected]:/usr/obj/usr/src/sys/GENERIC amd64
and FreeBSD bar.univ-lyon2.fr 7.3-RELEASE-p7 FreeBSD 7.3-RELEASE-p7 #0: Tue Sep 27 13:10:21 UTC 2011 [email protected]:/usr/obj/usr/src/sys/GENERIC amd64 >Description: According to its man page, top(1) will read the whole passwd database at launch time, to resolve numerical uids into user logins. When the system is hooked to an LDAP server for user authentication, top(1) will try to download the whole content of the LDAP database. If the LDAP shutdowns the connection (because of you reach a limit for example), top(1) dies and display nothing but the error message "Broken pipe". That's how it works when I bind the FreeBSD system to our Sun Directory Server: top(1) downloads about 3MB of LDAP data, the LDAP server kills the connection, top(1) dies. If the LDAP sends immediately and error but doesn't kill the connection, top(1) will resolve each foreign uids thru the LDAP, one at a time, and will properly display its output. that's how it works when I bind the FreeBSD system to our LDAP proxy: top(1) tries to download LDAP content, the proxy replies "The server is not configured to pass through control 1.2.840.113556.1.4.319", top(1) send individual request to resolve discrete uids, top(1) displays its output. My FreeBSD systems use nscd, but I made a full cache flush before each test. Note: even without flushing, the first behavior is always true. >How-To-Repeat: 0 - PREREQUISITES: bind your FreeBSD system to an LDAP server - install nss_ldap and pam_ldap - edit /etc/pam.d/sshd to add this line: #auth sufficient pam_krb5.so no_warn try_first_pass #auth sufficient pam_ssh.so no_warn try_first_pass + auth sufficient /usr/local/lib/pam_ldap.so no_warn ignore_authinfo_unavail auth required pam_unix.so no_warn try_first_pass and this line: account required pam_login_access.so +account required /usr/local/lib/pam_ldap.so no_warn ignore_authinfo_unavail ignore_unknown_user account required pam_unix.so - edit /usr/local/etc/nss_ldap.conf and /usr/local/etc/ldap.conf to add proper LDAP binding (provide binddn and bindpw) - edit /etc/nsswitch.conf to add "ldap" and/or "cache" on those lines (cache is for nscd): group: cache files hosts: cache files dns passwd: cache files ldap - check the bind with `id $some-ldap-user" for example. - launch nscd (/etc/rc.d/nscd forcestart, for example) 1 - TEST top(1): If your LDAP database is very small, you can tcpdump on port 389 or 636 to monitor the connection. You can also use ktrace on the top process, to see what's going on. If your LDAP database is big (ours is 140 K records long), the top process will just hung a long time before displaying anything. 2 - TEST top(1) with the -u flag: top -u should display its output immediately. >Fix: >Release-Note: >Audit-Trail: >Unformatted: _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
