Something seems to have gone wrong with my bind installation. There was an upgrade to this: Version: 1:9.7.3.dfsg-1~squeeze10 when the upgrade ran, the owner on /etc/bind/rndc.key got changed to bind:bind. The service can't start until I change it to root:bind, as discussed in Debian Bug 386791. However the package then sits at partially installed (because it couldn't start). Any time I try to install other software, this post-install script runs, changes the ownership on rndc.key again, and bind fails to start. I've tried tinkering with what I think is the postinstall script: /var/lib/dpkg/info/bind9.postinst but I can't much debug output. and it seems if I try to install the latest bind with dpkg, my edited version of that script gets overwritten. What is the right approach to solving this? Regards, Andrew.
Andrew Spiers <andrew@andrewspiers.net> wrote:
What is the right approach to solving this?
You could put the package on hold, but you would then be responsible for manually handling the upgrade if there are relevant security bug fixes. On the positive side, you would have a chance to make that decision; the package wouldn't be automatically upgraded. At some convenient moment you could then upgrade the entire system to testing, which is closer by the day to the 7.0 release, or you could wait for the actual release before upgrading if you're very cautious or if critical infrastructure depends on it.
hacked the postinst script to set the permission I wanted, so bind9 installs properly. Probably going to be broken with the next upgrade to that package. I diff --git a/debian/bind9.postinst b/debian/bind9.postinst index 98c4cd3..68e7f3b 100644 --- a/debian/bind9.postinst +++ b/debian/bind9.postinst @@ -116,7 +116,7 @@ if [ "$1" = configure ]; then uid=$(ls -ln /etc/bind/rndc.key | awk '{print $3}') if [ "$uid" = "0" ]; then - [ -n "$localconf" ] || chown bind /etc/bind/rndc.key + [ -n "$localconf" ] || chown root:bind /etc/bind/rndc.key chgrp bind /etc/bind chmod g+s /etc/bind chgrp bind /etc/bind/rndc.key /var/run/bind/run /var/cache/bind Although perhaps it should be something like + [ -n "$localconf" ] || chown $(getent passwd $uid | cut -d ':' -f 1):bind /etc/bind/rndc.key which just looks like a mess.
On 07/04/13 18:12, Andrew Spiers wrote:
hacked the postinst script to set the permission I wanted, so bind9 installs properly.
diff --git a/debian/bind9.postinst b/debian/bind9.postinst
I find myself having to make hacks like that all the time. The Debian pre/postinst scripts are notoriously fragile, particularly when working within chroots or if it tries to talk to something via D-Bus. Often it's faster to put a "exit 0" up the top of the pre/postinst and then manually fix up what's wrong, than to decipher the horrible scripts. Working around problems in packaging is an incredibly unrewarding experience.
On 07/04/13 18:12, Andrew Spiers wrote:
hacked the postinst script to set the permission I wanted, so bind9 installs properly.
diff --git a/debian/bind9.postinst b/debian/bind9.postinst
I find myself having to make hacks like that all the time. The Debian pre/postinst scripts are notoriously fragile, particularly when working within chroots or if it tries to talk to something via D-Bus.
Often it's faster to put a "exit 0" up the top of the pre/postinst and then manually fix up what's wrong, than to decipher the horrible scripts.
Working around problems in packaging is an incredibly unrewarding experience.
I've had to do that before too. It would be nice if there was a --force-preinit-success or --force-postinit-success or something. James
Brain dump follows, sorry if it's not very cohesive. Andrew Spiers <andrew@andrewspiers.net> writes:
Something seems to have gone wrong with my bind installation. There was an upgrade to this: Version: 1:9.7.3.dfsg-1~squeeze10 when the upgrade ran, the owner on /etc/bind/rndc.key got changed to bind:bind. Any time I try to install other software, this post-install script runs, changes the ownership on rndc.key again, and bind fails to start.
I've tried tinkering with what I think is the postinstall script: /var/lib/dpkg/info/bind9.postinst but I can't much debug output.
It is wrong to edit this file. It belongs to the DD. Perhaps you want dpkg-statoverride(8), although from bind9.postinst:144 as at 1:9.8.4.dfsg.P1-6+nmu1, it looks like that will not help as the postinst (which unusually and appallingly bad) simply ignores that and calls chown/chmod/&c directly.
The service can't start until I change it to root:bind, as discussed in Debian Bug 386791.
It is unfortunate that the maintainer doesn't appear to have replied to that ticket -- nor do I see any reference to any of the merged ticket numbers in debian/changelog. Did you already try the suggestion on that ticket? | 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 bind. | | To fix on my etch box I changed my /etc/default/bind9 to match lenny: | OPTIONS="-u bind"
However the package then sits at partially installed (because it couldn't start).
You can work around this by writing a policy-rc.d that says "don't restart named if you're upgrading" or something. Probably not worth the hassle unless there are montly security updates to named.
What is the right approach to solving this?
Since a ticket has already been filed, but has not been acknowledged, the correct procedure is to pester the maintainer about it (by writing to NNNNNN@bugs.debian.org). If he continues to ignore you, I suppose you could take it up with higher -- if he is ignoring ALL communications you should follow the MIA procedure (ref. wiki.debian.org). db.debian.org indicates the maintainer of bind9 may be on irc.debian.org as "lamont", so you can also try reaching in in real time. You may also be able to increase the priority of the issue by finding it in violation of Policy, as documented in the debian-policy package. That postinst is messy enough I would not be surprised if it's violating a hard requirement. In the short term, you're screwed. Personally I'd recommend nsd3, unbound and dnsmasq -- I've never been enthusiastic about ISC code. Regarding postinst issues in chroots -- please report these, they are legitimate bugs. I have had reasonable success getting such issues fixed. It depends on the maintainer, but being civil and taking the time to isolate the issue and ideally submit a patch, will usually improve your chances. PS: please note that Debian is currently in the final stages of a release, and very little attention will be paid to anything not directly related to releasing Debian 7. Things should be back to normal by June.
Hi, On 7/04/2013 4:42 PM, Andrew Spiers wrote:
There was an upgrade to this: Version: 1:9.7.3.dfsg-1~squeeze10 when the upgrade ran, the owner on /etc/bind/rndc.key got changed to bind:bind.
Strange.... none of my name servers had any trouble with the upgrade to this version -- my key file has always had bind:bind ownership. In fact, I religiously make sure ALL files in the bind directory tree are owned as bind:bind /var/lib/named/etc/bind I do run bind in a chroot environment with a symbolic link with /etc/bind pointing to /var/lib/named/etc Cheers A.
participants (6)
-
Andrew McGlashan -
Andrew Spiers -
James Harper -
Jason White -
Jeremy Visser -
trentbuck＠gmail.com