Openldap client on Solaris works

Under Solaris 9 and 10, we had multiple problems compiling and installing PADL's nss_ldap and pam_ldap linked to the OpenLDAP client libraries (downloaded from sunfreeware.com as a package). But in the face of numerous postings from people claiming it worked, we eventually found a solution. Here we document our progress.

Linker Problems

This issue applies to compiling both nss_ldap-262 and pam_ldap-184 if you are trying to link against libraries in /usr/local/lib (the default location for packages installed from sunfreeware.com).

The Solaris linker, /usr/ccs/bin/ld, by default compiles ELF binaries with a run-time library search path that does not include /usr/local/lib. A plain vanilla ./configure of nss_ldap will therefore fail.

The obvious thing to do is to add some options to ./configure:

 ./configure LDFLAGS="-L/usr/local/lib -R/usr/local/lib"

(you need both -R and -L, see Building Software on the Solaris OS, the "Linking With Libraries" section.)

Now configure will run, but make will fail. If you look at the failed command, you may notice that it seems to be calling the linker but without the LDFLAGS. This appears to be a bug in the Makefile.in that comes in the nss_ldap source. Comparing Makefile.in line 228 to the very next line, which gives the command line for using the GNU linker, you can see that at the end of line 228 "$(LDFLAGS)" is missing.

You can fix this by editing Makefile.in. A more sophisticated option might be to modify Makefile.in to pass those flags to the linker, conditionally when compiling on Solaris, but not being an autoconf expert I did not do that. Not passing LDFLAGS to the linker seems like a clear bug regardless.

As it happens someone else reported this as a bug in the PADL bugzilla: You can see my submission of diffs to fix it in that bug report (apparently applied in ldap-266).

pam_ldap Problems with shadowAccount

pam_ldap on Solaris 9 asks for shadowAccount, here is how to provide it.

pam_ldap, compiled for Solaris 9 with the same workaround as nss_ldap above, wants to look for objects in the LDAP database of objectClass=shadowAccount. The standard PADL migration tools do not create any such objects if you are importing from NIS source files.

A shadowAccount differs from a posixAccount only in that it includes password aging information. Fortunately, all the fields related to password aging are optional. So, the fix is to add:

 nss_map_objectclass shadowAccount posixAccount

to ldap.conf. One could also fix it by including objectClass=shadowAccount in every user's leaf node in the LDAP database, but since pam_ldap works on FreeBSD and Linux without this it seems cleaner to have the mapping just for Solaris.

Utilities and Applications linked against libraries in /usr/lib

The order in which Sun's precompiled binaries of standard utilities and applications, such as ls, top, ps, and so on, is that it looks in /lib and /usr/lib for a library before /usr/local/lib. Or possibly /usr/local/lib is not in those utils' path to look for libraries at all. So if we want these utils to use openldap's version of the ldap client libraries instead of Sun's, we have to replace Sun's libs with symlinks, like so:

cd /usr/lib
mv libldap.so.5 libldap.so.5.DIST ; ln -s /usr/local/lib/libldap.so libldap.so.5
cd /lib
ln -s /usr/local/lib/libldap-2.4.so.2
ln -s /usr/local/lib/liblber.so 
ln -s /usr/local/lib/liblber-2.4.so.2
ln -s /usr/local/lib/libgcc_s.so.1

sendmail and ssh

The sendmail that ships with Solaris 10 is linked to Sun's ldap client libraries directly, rather than going through the nsswitch. So it will not work, whether or not you replace Sun's libraries with symlinks. The solution is to not use Sun's sendmail. Uninstall or delete it and either compile sendmail from source and install, or install something much smaller, such as femail if you only need mail sending capabilities and have a full MTA elsewhere.

We could not get Sun's version of ssh to work correctly with pam_ldap. Whether this is specifically an LDAP related problem is not clear. We recommend installing openssh.

Utilities and Applications and nscd

With Solaris 9 and 10 we have noticed that quite a few applications and utilities shipped with the OS using the getgroupbyname() interface fail when using nss_ldap to call Openldap's ldap client libraries. These include lp, lpr, automount and login. The symptoms are:

 - uids are displayed, not usernames, when running utilities like ls, top and ps
 - syslog sees messages like:
Sep  9 10:16:29 nber6 top[435]: [ID 293258 user.warning] libsldap: Status:
2 Mesg: Unable to load configuration '/var/ldap/ldap_client_file' ('').

It seems that turning off nscd will allow these programs to work. Under solaris 10's FMRI scheme, that is

svcadm disable svc:/system/name-service-cache:default

Perhaps nscd is somehow statically linked to Sun's versions of the ldap client libraries?

Alex Aminoff & Daniel Feenberg
October 2008
updated September 2010