misc/161456: on a system bound to an LDAP server, top tries to get the whole LDAP content to resolve uids
>Synopsis: on a system bound to an LDAP server, top tries to get the whole LDAP content to resolve uids
>Arrival-Date: Mon Oct 10 09:30:10 UTC 2011
>Originator: Patrick Proniewski
>Release: 7.3-RELEASE-p7 and 8.2-RELEASE-p3
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.1135220.127.116.119", 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.
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:
- 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):
- 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.