From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 06:11:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAAD3106564A for ; Tue, 31 Mar 2009 06:11:43 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 325128FC13 for ; Tue, 31 Mar 2009 06:11:43 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 1561 invoked by uid 399); 31 Mar 2009 06:11:42 -0000 Received: from localhost (HELO 192-168-15-100.nohostname) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 31 Mar 2009 06:11:42 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <49D1B261.6010406@FreeBSD.org> Date: Mon, 30 Mar 2009 23:04:17 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: New rc.d/named features for testing: auto-forwarding and wait on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 06:11:44 -0000 Howdy, There has been some discussion recently about the idea of adding an option for the rc.d startup process to wait until name resolution comes on line. (There is also room for a more general "wait for the network to come on line" option, but I chose to focus on the named version since my time is limited atm.) The patch below has a fairly simple implementation of this feature with 2 knobs, named_wait to enable it, and the optional named_wait_host to specify what name to look up. It defaults to localhost. Garrett Wollman gets credit for the rough strokes on this one, though I refined it a bit (so blame for bugs goes to me). For a long time now there has also been discussion about configuring the local resolver to automatically forward to those name servers in /etc/resolv.conf. This bit is a lot trickier, primarily because it involves writing to /etc/namedb/ at boot time. However, the default is to chroot the named process to /var/named/ so this should be relatively safe. The patch has an implementation of the feature that works for the few networks I've tested it on. I feel that it is still a bit rough, but it's ready for wider review. The basic idea is that we parse /etc/resolv.conf for lines that begin with "nameserver" and try to make use of the information. It writes a temp file to /var/run/auto_forward.conf, then when it's done it compares the result to what's in [/var/named]/etc/namedb/auto_forward.conf. If it's different, the new one replaces the old. While it's being parsed, if the local named is not the first nameserver line in /etc/resolv.conf that is added, and if the new file differs from the existing one it will be replaced too. This uses roughly the same logic as is used in /sbin/dhclient-script. The part where this has the ability to go wonky is in the named.conf file. The patch has an update to that file with a _commented out_ line that you can uncomment to enable the support (along with enabling it in rc.conf of course). Where this _could_ go sideways is if you uncomment that line in named.conf but then turn off the auto_forward options. Fortunately, named supports 'include'ing empty files, so if either there is no /etc/resolv.conf, or if the named_auto_forward option is off and there is an existing /etc/namedb/auto_forward.conf file, the script empties that file out. I'm not thrilled with the idea of leaving an include of an empty file lying around in the options { }; section of named.conf, which is why it's commented out by default. However given the permissions it's no _more_ dangerous than the named.conf file itself. The user could shoot themselves in the foot if they disable the rc.conf option AND remove /etc/namedb/auto_forward.conf without commenting the line in named.conf, but that error is pretty obvious at named start-time. There is a not-directly-related change in this patch as well that I've had in the wings for a while to add named-checkconf to the pre-start routine. Given that if the named_auto_forward* options are on we will now be frobbing the conf behind the scenes I thought it was a good idea to add this support now. In addition to enabling auto_forward you can also enable auto_forward_only which changes from the default 'forward first' to (you guessed it) 'forward only'. Comments and suggestions are welcome, but remember I said this was rough. :) BTW, you should be able to test this on RELENG_[67] too if you really want to. I haven't tested the patch on those branches but it should apply pretty cleanly, and it's not that much to add anyway. Enjoy, Doug -- This .signature sanitized for your protection