From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 02:40:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D08116A4D0 for ; Tue, 28 Sep 2004 02:40:15 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id C070A43D2F for ; Tue, 28 Sep 2004 02:40:14 +0000 (GMT) (envelope-from juhasaarinen@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so3254217rnk for ; Mon, 27 Sep 2004 19:40:11 -0700 (PDT) Received: by 10.38.171.50 with SMTP id t50mr750154rne; Mon, 27 Sep 2004 19:40:10 -0700 (PDT) Received: by 10.38.73.29 with HTTP; Mon, 27 Sep 2004 19:40:10 -0700 (PDT) Message-ID: Date: Tue, 28 Sep 2004 14:40:10 +1200 From: Juha Saarinen To: Doug Barton In-Reply-To: <20040927184543.I911@bo.vpnaa.bet> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1096042856.24267.6.camel@purgatory.ceribus.net> <20040924222550.F6548@URF.trarfvf> <1096064849.1047.7.camel@server.mcneil.com> <20040925001835.U7126@URF.trarfvf> <20040927184543.I911@bo.vpnaa.bet> cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= cc: freebsd-current@freebsd.org Subject: Re: Proper way to run bind9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Juha Saarinen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2004 02:40:15 -0000 On Mon, 27 Sep 2004 18:54:01 -0700 (PDT), Doug Barton wrote: > 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. Humm, that does seem like the right way to do it, instead of working around the issue by changing the PID file location in two different places. > 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. True -- however, this is likely to bite people who migrate from other platforms where you don't have to specify the PID file location in named.conf, unless you want it in a non-default location. But, people have plenty of toes I suppose... :-) > 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? Well, rndc is the vendor-supplied tool for controlling the operation of named. The man page for named(8) says: "In routine operation, signals should not be used to control the name- server; rndc should be used instead." Correct me if I'm wrong, but doesn't /etc/rc.subr use signals? Incidentally, shouldn't the 'rcvar" command print out all the options used in rc.conf for running named? $ sudo /etc/rc.d/named rcvar # named $named_enable=YES /etc/rc.conf named_enable="YES" # Run named, the DNS server (or NO). named_program="/usr/sbin/named" # path to named, if you want a different one. named_flags="-c /etc/namedb/named.conf -u bind" # Flags for named -- Juha