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).
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to