Bug#331405: Accidential activation of nscd is too simple
reassign 331405 libpam-ldap tags 331405 patch thanks > It would be libpam-ldap which suggests libnss-ldap in my case. But > running apt-rdepends and analyzing it's output suggests that there are > 35 packages which depends on nscd in etch today. That's depends as in > any of the relationships that drags a package along, either directly or > as a consequence of a second or higer order dependency. The package description of nscd clearly states when nscd should be installed. A "wrong" dependency on nscd is no bug with nscd, but with the software depending on it. Most packages seem to have changed their behaviour since there are only 5 packages in apt-cache rdepends nscd of which at least one is a conflict. So maybe libpam-ldap could suggest nscd instead of recommending it. Otherwise this bug should be tagged wontfix. Helmut Grohne signature.asc Description: Digital signature
Processed: Re: Bug#331405: Accidential activation of nscd is too simple
Processing commands for [EMAIL PROTECTED]: > reassign 331405 libpam-ldap Bug#331405: Accidential activation of nscd is too simple Bug reassigned from package `nscd' to `libpam-ldap'. > tags 331405 patch Bug#331405: Accidential activation of nscd is too simple There were no tags set. Tags added: patch > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#331405: Accidential activation of nscd is too simple
(Hoping I'm doing things right, first time for me...) Gabor Gombas @ 2005-10-05 (Wednesday), 16:08 (+0200) Also, the default negative-ttl for the hosts map is just 20 seconds which I think _is_ a quite reasonable default. If twenty seconds were the case, I wouldn't have complained. I had the laptop on, without any suspend mode or such, for a full nights sleep of at least eight hours before hunting down and removing the package. Even if I might have guessed the wrong cause, I still had a problem with nscd in it's default configuration. Same situation here. I digged the problem today to nscd, some examples : - `ping` was unable to resolve news.free.fr (ok via nslookup) -> negative TTL problem - unable to update the ip of bashfr.org. For a few weeks now, it was still connecting to the old server -> positive TTL problem I'm using stock config (checked, with 3600/20 ttl), installed via a dependency to libnss-ldap. I'm using testing/amd64. I had to compare strace output between 2 installations to find this problem, so it's quite annoying :). I "resolved" this by setting "persistent" to false (which should not be the direct cause...) Francois -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#331405: Accidential activation of nscd is too simple
Gabor Gombas @ 2005-10-05 (Wednesday), 16:08 (+0200) > What is that "something"? Investigating the output of apt-cache rdepends > nscd, libnss-pgsql1 and libnss-mdns Suggests: nscd, and libnss-ldap > Recommends: it, but nothing Depends: on it. So you should've given a > choice by whatever package installation frontend you've used. It would be libpam-ldap which suggests libnss-ldap in my case. But running apt-rdepends and analyzing it's output suggests that there are 35 packages which depends on nscd in etch today. That's depends as in any of the relationships that drags a package along, either directly or as a consequence of a second or higer order dependency. The fact that the frontend gives me a theoretical chance of hindering additional software from getting installed doesn't help much. > Well, the description of nscd says: "You should install this package > only if you use slow Services like LDAP, NIS or NIS+". If you are not > using one of these services, why did you choose to install nscd? Please reflect over these words: It's not sane to assume users read the descriptions of packages reverse depending on what they actively install. Normally one just wants the functionality of the selected package in question, and don't care all that much about the details of it's dependencies. Add to that the normal cases that removing suggestions and recommendations normally influence the package's usability and that the apt frontends still could need some work on their human computer interaction interfaces. That's reality, I'm afraid. Disk space is cheap, time is limited, and users trust in debian is high. (When did you last read the description of libopencdk8? It's number 100 in popcon, so chances are you have it installed.) I'm not trying to be ignorant or anything. For me personally, the problem is found and solved. What I'm trying to accomplish with this bug report is increased quality in the distribution so that it will not have to happen to anyone else without a good reason. > Also, the default negative-ttl for the hosts map is just 20 seconds > which I think _is_ a quite reasonable default. If twenty seconds were the case, I wouldn't have complained. I had the laptop on, without any suspend mode or such, for a full nights sleep of at least eight hours before hunting down and removing the package. Even if I might have guessed the wrong cause, I still had a problem with nscd in it's default configuration. > Why? You said "I've always found the debian way to be having software > installed with reasonable defaults." The only reasonable default for a > program called Name Service Caching Daemon is to cache name service > calls when installed. Otherwise why did you install it at all? There have been threads about if simply installing a package should automatically start it's services on debian-devel as recently as a month ago, and no clear consensus was reached then as far as I understood. One could have several opinions both for and against, and it's fairly easy to find packages that does not configure or start their daemons by default. Having a debconf question asking about whether to start the daemon or not would not be to much of an annoyance to legitimate users in my opinion. Especially not if it defaulted to Yes and has it's priority set to medium. If you feel that tagging this report wontfix is a sufficient way to deal with the problem, I won't nag you more about it. -- /Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#331405: Accidential activation of nscd is too simple
On Mon, Oct 03, 2005 at 12:33:45PM +0200, Martin Samuelsson wrote: > 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. What is that "something"? Investigating the output of apt-cache rdepends nscd, libnss-pgsql1 and libnss-mdns Suggests: nscd, and libnss-ldap Recommends: it, but nothing Depends: on it. So you should've given a choice by whatever package installation frontend you've used. > 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. Well, the description of nscd says: "You should install this package only if you use slow Services like LDAP, NIS or NIS+". If you are not using one of these services, why did you choose to install nscd? (I don't dare to assume that you haven't even read the package description before letting an unknown and unrequested pacakge installed on your system...) Also, the default negative-ttl for the hosts map is just 20 seconds which I think _is_ a quite reasonable default. > 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. Why? You said "I've always found the debian way to be having software installed with reasonable defaults." The only reasonable default for a program called Name Service Caching Daemon is to cache name service calls when installed. Otherwise why did you install it at all? Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#331405: Accidential activation of nscd is too simple
Package: nscd Version: 2.3.5-6 Severity: important 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. -- /Martin --- 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. +exit 0 + # Sanity checks. [ -f /etc/nscd.conf ] || exit 0 [ -x /usr/sbin/nscd ] || exit 0
