# desperate over LDAP

## smart

Hi all,

i'm retrying again and again, follwoing advices first without success, adding common sense, tweaking fiddling, anything. I get nowhere.

I can't get beyond a pure non TLS running LDAP server. I cannot make it to be useful.

From the Gentoo guide, i get as far as migrating into the files (leaving out the security stuff since otherwise the whole thing will stumble over the selfsigned certificate).

So i have this running openLDAP server and have those LDIF files. Just that the migration tools add a lot of fields and some are not supported by the schemas.

Anyways, i wanted to start with the basics, so i remove what seems unnexcessary for a simple login support. Whatever way i put the data into the directory (it's browseable/searchable whatever you wnat there) it will NEVER show up with getent, and i'm in serious doubt my system tries that at all.

And yes, i have the relevant entries in /etc/nsswitch.conf and  i emerge nss_ldap and pam_ldap (whereas i think the latter is not relevant for getent...).

For any description it is simply assumed that after changing /etc/nsswitch.conf there's a big puff and getent shows the ldap users. In my case, that's only smoke. No ldap users. And i dunno where to start tickling...

----------

## Janne Pikkarainen

Have you modified /etc/openldap/ldap.conf, hoping that would resolve all your worries? Then go and check that there IS NOT /etc/ldap.conf lurking around, because OpenLDAP tends to check the existance of /etc/ldap.conf and if it exists, it decides to use it. And if /etc/ldap.conf is filled with default values, well, that's probably not gonna work.

----------

## smart

Thanks for that, but

i noticed the duplication of these files, however i did not exactly do what you siuggested, but instead backed up /etc/openldap/ldap.conf and replaced it with a link like to ../ldap.conf so that it points to /etc/ldap.conf making the two identical. I've configured /etc/ldap.conf according to the instructions in Gentoos howto and i think the ldap* commands use it already without a glitch.

Is there sth. i can/should do to make sure that this nameresolving mechanism actually is able to obey the "ldap" entry in /etc/nsswitch.conf ? This ones my biggest concern. Is my system capable of using ldap as a source for it's pasword entries by the mere run of emerge nss_ldap and adding the ldap entry to this file ? Wouldn't i have to reconfigure/recompile sth. that would now be in charge to accept this configuration and execute the lookup ? Or how could i verify that it IS capable of doing that ?

----------

## Janne Pikkarainen

```
Is there sth. i can/should do to make sure that this nameresolving mechanism actually is able to obey the "ldap" entry in /etc/nsswitch.conf ?
```

I've always taken the hardcore route and used strace command to verify if nss_ldap.so is really used during the query. Configuring nss_ldap should be pretty straighforward, most of the time the problems I encounter are due too strict access control lists in slapd.conf.

You may also raise loglevel in /etc/openldap/slapd.so and check the LDAP logs to see, if any queries actually come up and possibly see the reason why they fail. Add a line "loglevel 255" to your slapd.conf and restart slapd.

Please note that OpenLDAP uses DEBUG4 syslog facility in its logging, so not seeing any log entries could also be because of missing OpenLDAP configuration entry in your syslog config file. For example, syslog-ng needs these to /etc/syslog-ng/syslog-ng.conf

```

destination ldap { file("/var/log/ldap/ldap.log"); };

filter f_ldap { facility(local4); };

log { source(src); source(net); filter(f_ldap); destination(ldap); };

```

... to actually get any data into your LDAP logs.

----------

## smart

Hi again, and thanks for continuing..

I use vcron and add to /etc/syslog.conf :

local4.* /var/log/ldap.log

I added to /etc/openldap/slapd.conf :

loglevel 255

I can't emerge strace here, since i've got no network connection for the target machine. Anyways, the above changes should give me a hint.

I can see the startup sequence finishing in /var/log/ldap.log

After that, when i do getent passwd, nothing is added to /var/log/ldap.log while doing ldapsearch, loads of stuff is dumped there.

I guess,  this does prove that my system doesn't try ldap to resolve usernames.

Assuming it would not be able to, what could be done to enable it ?

Assuming it would be able to and timed out on an earlier request... would it refuse to try again earlier than some given time ? Would i have to somehow encourage it to retry using ldap ?

----------

## smart

I am investigating the libraries/dependencies currently. Doing so, i found my file from nss_ldap in /lib having a strange naming, that is:

libnss_ldap-.so ( <- take notice of missing version numbering)

libnss_ldap.so. (<-take notice of the trailing dot)

Can somebody confirm that as correct in spite of strangeness or confirm that this is an error ?

----------

## smart

Seems i'm right lads  :Smile: = this is boogy.

i copied libnss_ldap-.so to libnss_ldap-2.1.1.so and linked from libnss_ldap.so.2 to my copied libnss_ldap-2.1.1.so and puff, the LDAP username appeared in getent.

Will raise an entry on bugs.gentoo.org...

EDIT: https://bugs.gentoo.org/show_bug.cgi?id=33442

----------

## indros

This is actually due to a change in the implementation of tail. The way it used to work, tail -somenum, is the way it is implemented within nss_ldap's Makefile. After a certain version of coreutils, tail -somenum doesn't work anymore, and it's now tail -n somenum. Just some more info for the curious.

----------

## raker

I have just installed nss_ldap-215 on my test box...

/lib/libnss_ldap-2.3.3.so is created... 

i removed the no-longer-utilized ssl configure option and upped the db dependancy to >=db-3

I really wanted to up the dependancy to >=db-4...

anyway, you should see the package in portage soonly.

----------

## raker

nss_ldap-215-r1 is in portage and fully supports db4 configurations.  This is really the most complete nss_ldap as of yet... 

Has anyone tried this build?  Any luck?  *tumbleweed rolls by*

----------

