Bug#331405: Accidential activation of nscd is too simple
After some time of random dns failures I started tracking the problem
today, the first time I found a reproducable way to trigger it.
Obviously something has automatically dragged nscd into my system as one
of it's dependencies. (It's marked A in aptitude) And having a software
cacheing dns lookups from disconnected moments doesn't really make a
laptop very useable when being connected.
I would really like to make this severity critical, since I think it
does break unrelated software in an unacceptable manner. But I'm
setteling for important for now.
One could say that I should have better knowledge of exactly what
software that is on my system, and how it is configured. However I've
always found the debian way to be having software installed with
reasonable defaults. Which I don't think this behaviour is, considering
it simple to get installed without realizing it.
My suggestion would be that nscd was configured by default to not start
or to never cache any data until explicitly told so by a simple, but
active act from the system administrator.
This could either be done by changing the defaults in /etc/nscd.conf or
maybe more elegantly by creating a /etc/defaults/nscd sourced by the
init.d script (Something what like dropbear does). If one would wan't
to, asking the activation question with debconf would make using nscd
really simple, but not too simple, as it is now.
Inspired by the festival init.d script I'm attaching a patch with the
most simple approach.
Please let me know if you would wan't me to do any other active work to
help closing this bug.
--- glibc-2.3.5/debian/debhelper.in/nscd.init.org 2005-10-03 12:14:17.688927948 +0200
+++ glibc-2.3.5/debian/debhelper.in/nscd.init 2005-10-03 12:22:19.261055543 +0200
@@ -7,6 +7,9 @@
# query. You should start this daemon only if you use
# slow Services like NIS or NIS+
+# Comment out the next line to start a nscd at boot time.
# Sanity checks.
[ -f /etc/nscd.conf ] || exit 0
[ -x /usr/sbin/nscd ] || exit 0