Re: --disable-nslcd, nssov, and local user lookups

[Ryan Steele <ryans [at] aweber.com>]

On a related note - what's the accepted approach to disabling nslcd at 
build-time in addition to providing the --disable-nslcd flag?  I ask because 
simply removing the following flags from debian/rules:

                --sysconfdir=/etc \
                --localstatedir=/var \
                --with-ldap-conf-file=/etc/nslcd.conf \
                --with-nslcd-pidfile=/var/run/nslcd/nslcd.pid \
                --with-nslcd-socket=/var/run/nslcd/socket

...and adding this flag:

                --disable-nslcd

...results in the following build error:

dh_install
        install -d debian/nslcd/
        cp -a debian/tmp/etc debian/nslcd//
        install -d debian/nslcd//usr
        cp -a debian/tmp/usr/sbin debian/nslcd//usr/
cp: cannot stat `debian/tmp/usr/sbin': No such file or directory
dh_install: cp -a debian/tmp/usr/sbin debian/nslcd//usr/ returned exit code 1
make: *** [binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary gave error exit status 2


I was able to get the build to succeed by removing debian/nslcd.install, but 
I'm not entirely confident that's the appropriate thing to do.  Happy to hear 
what others are doing here, just for some confirmation.

Cheers,
Ryan

Ryan Steele wrote:
> Hey folks,
> 
> Recently I've been looking into replacing nslcd with the nssov overlay in 
> OpenLDAP.  However, I have yet to figure out how to duplicate the 
> nss_initgroups_ignoreusers functionality.  I've come to view that feature as 
> a critical piece of the architecture, as it prevents NSS lookups for local 
> users.  This is critical in keeping services running smoothly on the system 
> running if/when the local slapd has problems or the network/upstream LDAP 
> server becomes unavailable prior to/during a query.  We keep system/daemon 
> users out of LDAP for this very reason.
> 
> Without it, daemonized services can grind to a halt as wait times skyrocket 
> (during unnecessary LDAP lookups for the local users) during the 
> aforementioned types of outages, due to the fact that lookups get stuck in a 
> blocking wait state and/or eventually time out trying to get an answer from 
> LDAP.  Sure, setting some low timeouts can help, but not having that option 
> at our disposal inevitably results in unnecessary wait times when such 
> outages occur.
> 
> I'd be interested to hear what others do to solve this problem.
> 
> Cheers,
> Ryan
-- 
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users/