[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
programs.
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
away.
"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