[systemd-devel] proper way for shutdown script

Xen list at xenhideout.nl
Wed Oct 5 19:13:05 UTC 2016

Mantas Mikul─Śnas schreef op 05-10-2016 18:34:

> If you mean "would not perform lookups _below_ a certain ID", then
> sure, that exists. In /etc/nslcd.conf you can specify "nss_min_uid
> 1000", for example, to avoid lookups for all system UIDs.

Thank you. It seems interesting. I just think that they created the 
exactly bad design.

libnss_ldap and nscd (or unscd) already provides most of the benefits 
that the author is decribing on his homepage. The caching daemon (nscd) 
already provided (in all likelyhood) the abstraction that was needed to 
keep the system functional while also allowing direct connections from 

Now he has put everything into one package, but the (debian) maintainers 
have split it into 3 parts. As a better reflection of what it is.

He's created (Arthur de Jong, apparently a TU Delft computer science 
grad) two modules that apparently aggregate requests by sending them to 
the daemon, who aggregates it and sends it to the LDAP server over a 
single connection. That seems helpful but the daemon is now the 
gatekeeper. It's also a caching daemon that you can't turn off. Or at 
least, maybe it doesn't cache but you still cannot turn it off. I had 
previously run into problems when nscd propagated names from UID lookups 
and then used those names from the cache (without qualification) when 
name lookups were being done, which created problems for users that were 
named identically on LDAP as on local.

Then unscd solved that problem by not doing that :p. The problem was 
that name lookups would first start with "compat" and only then do 
"ldap" but this means that local names (that exist) would *never* cause 
ldap lookups to happen. However, any required for an UID that was found 
with a name that was also in the local database *would* propagate the 
name to the name cache.

Since unscd didn't do that, suddenly no more problems :p.

And since I cannot know in advance whether it will do that... and if it 
does do that, I'm screwed instantly.

"Note that if the LDAP server is unavailable during start-up nslcd will 
not start."

Another problem. My LDAP server on some systems will only be available 
after VPN connect. Normally this would be at system boot but you can 
imagine also wifi-connected systems that don't have internet straight 

"Alternatively, the value ALLLOCAL may be used. With that value nslcd 
builds a full list of non-LDAP users on startup."

This is the answer to the behaviour that I started this thread with.

This means nss_ldapd doesn't need that script because it does it itself 
(nslcd does it itself). I guess that could be a superior solution if 
done right...

As an upside nslcd contains a nested group feature that I very much 
would like to have.

So I think that for my own system I am going to use it after all :).

Or at least give it a shot.

> If you mean "would not perform lookups _below_ a certain ID", then
> sure, that exists. In /etc/nslcd.conf you can specify "nss_min_uid
> 1000", for example, to avoid lookups for all system UIDs.

Actually it still uses nss_initgroups_ignoreusers for that, as said, but 
now allows a parameter that will do it on startup.

I just think the design is bad...

- it caches entries, but only for LDAP, and hence doesn't have a lot of 
caching abilities
- it is the gatekeeper for all LDAP queries and everything is channeled 
through it, making it a point of failure (single point of failure).
- nscd / unscd already ensured that 90% of the design imperative of this 
program was already being catered to
- the only thing that remains as a reason is ease of maintenance.

And in this case (a library) causing programs to be connecting on their 
own just seems superior. Instead of having... ;-) a middle man.

But that's just me.

Any case, thank you for your answer, this helped me in any case to know 
how libnss_ldapd would be different in this regard.

(Of course there is no ldapd, the d is in nslcd) (it would more properly 
be called libnss_ldapc or something).

More information about the systemd-devel mailing list