Date: Mon, 27 Sep 2004 18:54:01 -0700 (PDT) From: Doug Barton <DougB@FreeBSD.org> To: Juha Saarinen <juhasaarinen@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: Proper way to run bind9 Message-ID: <20040927184543.I911@bo.vpnaa.bet> In-Reply-To: <b34be84204092718334b4b77af@mail.gmail.com> References: <1096042856.24267.6.camel@purgatory.ceribus.net> <xzpsm97v49e.fsf@dwp.des.no> <20040924222550.F6548@URF.trarfvf> <20040925001835.U7126@URF.trarfvf> <b34be84204092718334b4b77af@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 28 Sep 2004, Juha Saarinen wrote:
> The PID file location for currently hardcoded to /var/run in the named binary.
You are correct.
> Is there a good reason for not changing that to /var/run/named/pid as
> the default on FreeBSD, instead of adjusting the location in both
> /etc/defaults/rc.conf and named.conf?
A couple of them actually. We do not want to edit the files as they come
from the vendor without a really good reason, and this isn't one.
I have a long term plan to write some patches to turn the pid file path
into a --configure defineable variable and send it to the ISC folks, but
it's frankly not that high a priority.
> This is error-prone, and easy to forget -- if you do, it means named
> won't start up as it cannot write the PID file to the default
> location.
If you use the system as installed, and/or start from the default files,
it's all there for you. If you choose to vary from that path, it's
pretty much up to you to know what you're doing and why. There are only
so many bullets you can take out of the foot-shooting gun.
That said, I did add a comment to the src/etc/default/rc.conf file which
indicates that if you change the pid file name there, you should change
it in named.conf as well to make it easier for users to do the right
thing.
Finally, the way named fails in this case (totally) is actually the
safest way to handle it. No user can accidentally start named with the
wrong configuration and have it running in a manner other than what they
expect. This is a much more serious problem, and would be worthy of a
better solutino if it existed. The problem you describe here is a
learning curve issue, and BIND has a lot of those.
> Second, shouldn't /etc/rc.d/named be rewritten to take rndc into
> account, and not use /etc/rc.subr?
What would your goal be? With the current behavior, '/etc/rc.d/named
stop' can recover from situations where 'rndc stop' fails. Why would you
want to take that functionality away?
Doug
--
This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040927184543.I911>