Bug#386791:
I am sorry to report that this seems to be happening again. Package: bind9 State: partially configured Automatically installed: no Version: 1:9.7.3.dfsg-1~squeeze10 Priority: optional Section: net Maintainer: LaMont Jones lam...@debian.org Chowning rndc.key to root:bind means I can start up the service again, but the next attempt to install this package re-runs the post-install script, which chowns it back to bind:bind, which means the service can't start, leaving the package partially configured. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#386791: same problem in 2011
It happened just again with the latest security update. Version: 1:9.7.3.dfsg-1~squeeze4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#386791: Come on, fix the package already...
This is several years old now, and the fix is pretty well understood: 1) Add to /etc/bind/named.conf the line
Bug#386791: Let's try again
This bug can be fixed by: 1) Adding a line that says include /etc/bind/rndc.key; to /etc/bind/named.conf and then 2) Making /etc/bind/rndc.key be owner root:bind mode 640 Given the number of years this bug has been outstanding, it would be really nice if someone would fix it.
Bug#386791:
maladireta:/etc/bind# /etc/init.d/bind9 restart Stopping domain name service...: bind9rndc: connect failed: 127.0.0.1#953: connection refused . Starting domain name service...: bind9 failed! No idea why this happen, does any one know how to fix this? email-me please!
Bug#386791: same problem in 2009
We experienced what seems to be exactly the same problem with Debian/ lenny using Package: bind9 Priority: optional Section: net Installed-Size: 636 Maintainer: LaMont Jones lam...@debian.org Architecture: amd64 Version: 1:9.5.1.dfsg.P2-1+lenny1 Our syslog had: open: /etc/bind/rndc.key: permission denied As a result, we would get errors of the form: # /etc/init.d/bind9 restart Stopping domain name service...: bind9rndc: connect failed: 127.0.0.1#953: connection refused. Starting domain name service...: bind9. (Although it claimed to start bind9 up, it would not, and we would not get new configuration changes.) The workaround, as noted by others, was to do: chown root:bind /etc/bind/rndc.key That file had somehow been set to be owned by user identd, group telnetd. This bug report has been open for YEARS now. Any sign of progress? Regards, Steven G. Johnson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#386791: Wrong permissions on /etc/bind/rndc.key break bind with every update
Hello, I experienced the same problem on my two Debian sarge systems after bind9's security upgrade from version 1:9.2.4-1 to 1:9.2.4-1sarge1. On both systems named runs as user 'root' (this is needed because of dynamic network interfaces), /etc/bind/rndc.key was owned by 'root' until the upgrade and rndc was running fine. It seems that bind9's postinst script changes the owner of /etc/bind/rndc.key from 'root' to 'bind' whenever the file /etc/defaults/bind9 already exists, whether it contains -u bind or not. The file existed on my systems, but without -u bind. I observed that named wants /etc/bind/rndc.key to be owned by 'root' when run as root, and accepts /etc/bind/rndc.key to be owned by 'bind' or 'root' when run as root. Isn't there a bug in bind9's postinst script which can change the owner of /etc/bind/rndc.key to 'bind' without checking that named runs as user 'bind' ? Also I don't understand that the choice of writing OPTIONS= or OPTIONS=-u bind in /etc/defaults/bind9 depends on the fact that /etc/bind/named.conf[.local] have been modified or not. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386791: Wrong permissions on /etc/bind/rndc.key break bind with every update
I observed that named wants /etc/bind/rndc.key to be owned by 'root' when run as root, and accepts /etc/bind/rndc.key to be owned by 'bind' or 'root' when run as root. I meant [named] accepts /etc/bind/rndc.key to be owned by user 'bind' or 'root' when run as user 'bind'. Sorry for the mistake. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386791: Wrong permissions on /etc/bind/rndc.key break bind with...
Package: bind9 Version: 1:9.2.4-1 Followup-For: Bug #386791 Hello I can confirm this, it happend on all servers after todays DSA updates: named[2660]: stopping command channel on 127.0.0.1#953 named[2660]: stopping command channel on ::1#953 named[2660]: exiting named[10886]: starting BIND 9.2.4 named[10886]: none:0: open: /etc/bind/rndc.key: permission denied named[10886]: couldn't add command channel 127.0.0.1#953: permission denied named[10886]: none:0: open: /etc/bind/rndc.key: permission denied named[10886]: couldn't add command channel ::1#953: permission denied I don't understand why there is a permission denied as bind itself runs as user bind and should be able to read the file. Maybe it's a kind of security check that prevents bind from starting when the file is writable for the daemon. The daemon itself seems to work correctly, answering on all interface addresses. Probably only the rndc command does not work. Regarding the proposed solution I get a # rndc reload 127.in-addr.arpa rndc: connect failed: connection refused even after chowning the file to root and restarting the daemon :( bye, -christian- -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-3-686-smp Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED]) Versions of packages bind9 depends on: ii adduser 3.63 Add and remove users and groups ii libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an ii libdns16 1:9.2.4-1 DNS Shared Library used by BIND ii libisc7 1:9.2.4-1 ISC Shared Library used by BIND ii libisccc0 1:9.2.4-1 Command Channel Library used by BI ii libisccfg01:9.2.4-1 Config File Handling Library used ii liblwres1 1:9.2.4-1 Lightweight Resolver Library used ii libssl0.9.7 0.9.7e-3sarge1 SSL shared libraries ii netbase 4.21 Basic TCP/IP networking system -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386791: bind: Wrong permissions on /etc/bind/rndc.key break bind with every update
Package: bind9 Version: 1:9.2.4-1sarge1 Severity: important File: bind Wrong permissions in /etc/bind prevent bind from reading the RNDC-key-file. This causes rndc to stop working after an upgrade of bind because the permissions get set to the bad values with every update of the bind package. Bind reports the following errors: none:0: open: /etc/bind/rndc.key: permission denied and couldn't add command channel 127.0.0.1#953: permission denied. The permissions of get set to -rw-r- and user/group: bind. When manually chowning the file to the user root and letting the group bind as it is everything is just working fine. m System Information: Debian Release: 3.1 Architecture: i386 (i586) Kernel: Linux 2.4.18 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages bind9 depends on: ii adduser 3.63 Add and remove users and groups ii libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an ii libdns16 1:9.2.4-1sarge1DNS Shared Library used by BIND ii libisc7 1:9.2.4-1sarge1ISC Shared Library used by BIND ii libisccc0 1:9.2.4-1sarge1Command Channel Library used by BI ii libisccfg01:9.2.4-1sarge1Config File Handling Library used ii liblwres1 1:9.2.4-1sarge1Lightweight Resolver Library used ii libssl0.9.7 0.9.7e-3sarge1 SSL shared libraries ii netbase 4.21 Basic TCP/IP networking system -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
