Openldap client on Solaris almost worksWe had multiple problems compiling and installing PADL's nss_ldap and pam_ldap linked to OpenLDAP under Solaris, but in the face of numerous postings from people claiming it worked, we eventually found a partial solution. Here we document our limited progress. Linker ProblemsThis 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 in that bug report. pam_ldap Problemspam_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 posixAccountto 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 ApplicationsWith Solaris 9 and 10 we have noticed that quite a few applications and utilities using the getgroupbyname() interface fail when referencing Openldap. These include lp, lpr, automount and login. 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 With Solaris 10 SUN has added ldap support to many utilities, but some of these patches seem to ignore the nsswitch file and go unsuccessfully to the Solaris native ldap components inspite of the direction to the open-ldap library. We have no work-around for this. Even if we replace the libldap.so.1 library with a symlink to the openldap library, we still see the problem. The symptoms are:
- uids are displayed, not usernames, when running utilities like 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' ('').
We are living with this situation for now.
ConclusionSolaris 10 cannot at present support Openldap. We are very eager to get any suggestions or comments on this issue. Please write to feenberg at nber dot org.
Alex Aminoff |









