Brain dump follows, sorry if it's not very cohesive. Andrew Spiers <[email protected]> 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 [email protected]). 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. _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
