lists.arthurdejong.org
RSS feed

Re: pynslcd problems

[Date Prev][Date Next] [Thread Prev][Thread Next]

Re: pynslcd problems



On lördagen den 7 juli 2012 18:23:40 Arthur de Jong wrote:
> :-(
> That is weird. I cannot reproduce that (though using an i386 sid test
> environment here). You could try removing /var/run/nslcd/cache.sqlite*
> (and perhaps lock files there) and restarting pynslcd. It should
> recreate the database if it is missing. Still weird that sqlite3
> command-line found the table but pynslcd didn't.

Removing the db doesn't help (already tried it). However, some further digging 
shows that this is a bad error message from sqlite :-(, and the problem is 
really elsewhere.

The problem isn't that the table don't exist, but that it is empty, which in 
turn is because something is wrong with tls support in pynslcd, so it never 
receives any data from ldap to put in the cache.
If I change the config file to use "ldap://"; uris rather than "ldaps://" uris, 
and remove the tls_reqcert and tls_cacertfile configurations in favor of "ssl 
off", pynslcd works (almost) as advertised.

I did find a some additional problems though:

If the network connection is removed from a running pynslcd, any subsequent 
"getent" call will hang indefenitely. If I then restart pynslcd, the first 
"getent" call will hang for several seconds before returning the cached entries 
from the sqlite db, but further "getent" calls works just fine. Untill I 
connect to the network again, at which point it will continue to serve the 
cached data, untill I restart pynslcd yet again.
 
Oh, and the stop action of the debian init script "/etc/init.d/nslcd" don't 
work after just changing NSLCD_BIN to /usr/local/sbin/pynslcd, I also had to 
remove "--name nslcd" from the "start-stop-daemon --stop" calls, or it wouldn't 
actually kill pynslcd...

Best Regards
Jon Severinsson
-- 
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users/