nis should recommend nscd

Bug #345137 reported by Daniel J Blueman on 2009-03-18
Affects Status Importance Assigned to Milestone
nis (Ubuntu)
Declined for Karmic by Mathias Gug

Bug Description

Binary package hint: nis

In an enterprise environment, an Ubuntu user (administrator) installs the 'nis' package, for shared passwd and group directories, however, since the information isn't cached, against a busy or remote NIS server, performance suffers with very frequent entry lookup.

A simple example is 'ls -l', which stats every entry in a directory, causing a small storm of NIS requests everytime it is done on a directory with many different entries. Scale this up to an office with a few hundred systems, and the NIS request rate can be wastefully high, particularly on shared login boxes, which would see maximal benefit. nscd prevents processes sleeping for a non-local NIS response every time and is lightweight, and has appropriate record ageing/expiry.

Thus, the package 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

Steve Langasek (vorlon) wrote :

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?

Martin Pitt (pitti) wrote :

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

Steve Langasek (vorlon) wrote :

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...

Mark Brown (broonie) wrote :

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.

Markus Korn (thekorn) wrote :

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.

Launchpad Janitor (janitor) wrote :

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

Changed in nis (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments