nis should recommend nscd

feature-freeze exception justification:

 1. proposed changes:
  -> have nis recommend the nscd package

 2. rational/benefits:
  -> ensure enterprise users with NIS, experience good performance through processes not getting frequently blocked (also causing context switches) for short periods (the order of 5-15ms, and causing unnecessary network and NIS server load
 (ie why perform expensive I/O, when the result is available in a shared memory segment?)

 3. risks:
  -> minimal packaging-only change
  -> affecting non-home/personal users

Not only do I not think this warrants a freeze exception, I think it's an incorrect change to make to the package. Other NSS backends that rely on network services only Suggest: nscd. I think nis should do the same.

Installing nscd causes it to be used automatically, and my past experience is that this causes its own reliability problems due to nscd wedging itself. Maybe it's more reliable now; but this is certainly not the time in the release cycle to be finding that out. So we should not do anything that would cause nscd to be pulled in automatically onto users' systems.

Any issue of nscd being unstable is (and should be) a separate issue to optimal performance/operation, and achieving this through package recommends tags is the right mechanism.

The key problem is non-networking experts won't naturally somehow know to reach for nscd - in fact, it's counter-intuitive, as the package doesn't recommend or suggest it. To say that it shouldn't be used because of a bug, is a shade of "oh, there's a race in the linux pagecache. let's ship with it disabled..." (bad example I know).

Enabling it before the beta seems not unreasonable, as we can revert it before release, if there is issue; how much exposure will early alpha releases have in an enterprise environment with NIS? I've been running nscd with nis on ubuntu each of the past releases, which is why I'm driving this, and I want to ensure enterprise users see optimal performance through no special know-how.

A particular 'find' command on a small work dir of mine repetitively performs 9929 lookups over network. With nscd, it drops to 9. The average response time for each request is 2.02ms (fast, quiescent nis server), so a whole 2 seconds has been wasted waiting for NIS lookups, especially worse when all the dentries are in cache.

Should I add a debdiff adding it as a suggests field for now?

No debdiff required here, the change is trivial once it's agreed upon.

I have a hard time believing that using NIS without also knowing about the existence of nscd is a common scenario at all. NIS itself is an unlikely technology to be deploying, and I would indeed expect the deployment to involve one or more experts who would be familiar with nscd. Which is not to say that I think that these experts would automatically choose to *install* nscd; my experience is that it is not at all a reliable technology, and even when using nss_ldap (which is a more expensive network operation than nis lookups) I have avoided deploying nscd whenever other options were available (such as local caching LDAP servers).

Adding it as a Suggests: is certainly fine with me; as I said, it's consistent with what other packages are doing.

BTW, the nis package is also the package providing the nis server. Pulling nscd in by default (as would happen with Recommends:) could cause NSS lookups to *slow down* on the server...

FWIW I'd expect there are more NIS installs out there that don't use nscd than do; performance problems on any substantial scale are not the common case and nscd has issues of its own. I'll consider adding nscd as a suggests but I'll not take a change to recommend it in the Debian package.

Unmarked attachment as patch, as a result of comment #5

Let's get this addressed for Karmic, and have nis suggest nscd.

Since this is aligned with what Steve L and Mark B are happy with, we can go ahead.

This bug was fixed in the package nis - 3.17-18ubuntu2

---------------
nis (3.17-18ubuntu2) karmic; urgency=low

  * Have nis Suggest nscd. LP: #345137.

 -- Steve Langasek <email address hidden> Mon, 01 Jun 2009 11:35:25 +0000