nsswitch.conf(5): recommend placing cache after files

[asomers]

Summary

nsswitch.conf(5): recommend placing cache after files

When cache precedes files, and nscd is configured to allow negative caching,
commands like "pw groupadd" can fail. The sequence of events looks like:

1. A command like pkg(8) looks up the group, and finds it absent.
2. pkg invokes pw(8) to add the group
3. pkg queries the group, but nscd says it doesn't exist, since it has a negative cache entry for that group.

https://lists.freebsd.org/pipermail/freebsd-current/2012-January/031595.html

[bcr]

Can you check the man page with textproc/igor and "mandoc -Tlint" for any warnings?

share/man/man5/nsswitch.conf.5

233 ↗

(On Diff #76212)

Maybe we should use "ldap" instead of nis here?

[se]

I have added the configuration option "negative-confidence-threshold" to nscd in r238094 (in 2012), but since the default was kept at "1", this change has not become visible in practice.

It should work (did at that time in my tests), but I have received neither negative nor positive reports of its fitness for the intended purpose.

A value of 2 for this parameter ought to prevent the issue of entries being probed, not found, added, and then still not found due to the negative cache entry from the first probe.

This adds the cost of one additional negative lookup for each non-existent entry, which might be or might be not preferable to first looking up the file.

But it should help if new entries are added to other database types than local files (e.g., to NIS), a case not covered by the suggested change to the lookup order. (And having "cache" behind "nis" would negate its usefulness.)

I'm not opposed to changing the order from "cache files" to "files cache" (assuming that the file being read is on a local file system, not on e.g. NFS in case of a disk-less client), but I'd want to suggest that the "negative-confidence-threshold" was tested (in different settings) and proposed as a possible solution for this use case, too.

[asomers]

In D26184#581938, @se wrote:

I have added the configuration option "negative-confidence-threshold" to nscd in r238094 (in 2012), but since the default was kept at "1", this change has not become visible in practice.

It should work (did at that time in my tests), but I have received neither negative nor positive reports of its fitness for the intended purpose.

A value of 2 for this parameter ought to prevent the issue of entries being probed, not found, added, and then still not found due to the negative cache entry from the first probe.

This adds the cost of one additional negative lookup for each non-existent entry, which might be or might be not preferable to first looking up the file.

But it should help if new entries are added to other database types than local files (e.g., to NIS), a case not covered by the suggested change to the lookup order. (And having "cache" behind "nis" would negate its usefulness.)

I'm not opposed to changing the order from "cache files" to "files cache" (assuming that the file being read is on a local file system, not on e.g. NFS in case of a disk-less client), but I'd want to suggest that the "negative-confidence-threshold" was tested (in different settings) and proposed as a possible solution for this use case, too.

shouldn't negative-confidence-threshold be documented in nscd.conf instead?

@bcr unfortunately, mandoc has much to complain about with this man page. But none of its complaints were introduced by my change. Would you approve this PR as is, and then I can submit a separate one to fix the issues?

share/man/man5/nsswitch.conf.5

233 ↗

(On Diff #76212)

I think the change is equally relevant for both. I used nis just because unlike LDAP it's builtin to the base system.

[bcr]

In D26184#585678, @asomers wrote:

@bcr unfortunately, mandoc has much to complain about with this man page. But none of its complaints were introduced by my change. Would you approve this PR as is, and then I can submit a separate one to fix the issues?

Sure, It's not required to fix other mistakes that are outside of your patch. A follow-up commit is totally fine. As long as your patch does not add anything new, I'm totally fine approving it.
Thanks for checking.