Re: named, VARMFS=yes and FILESDIR

From: Michael Proto <mike_at_jellydonut.org>
Date: Wed, 6 Jan 2010 15:56:48 -0500
On Wed, Jan 6, 2010 at 3:19 PM, Doug Barton <dougb_at_freebsd.org> wrote:
> Harald Schmalzbauer wrote:
>> Doug Barton schrieb am 30.11.2009 04:54 (localtime):
>> There are kind of "to be expected" incompatible options, of course, but
>> this one hit me some years before. Especcially for newbies, it's not
>> clear why these options shouldn't work together.
>
> Because what you're proposing is very far away from the typical way
> that name servers are configured. My goal is to provide a secure, safe
> default configuration that conforms to current best practices. What
> you want to do is an edge case, and not even something I see as
> reasonable to add an option in the base for given that the code is
> already much more complicated than it should be.
>
>>>> My idea is to create a namedb directory in /usr/share (like there's one
>>>> for sendmail) with duplicate entries of src/etc/namedb
>>>
>>> Why not just set named_chrootdir to /usr/share/namedb ?  It's not 100%
>>> clear to me what you're trying to accomplish. Can you please go into a
>>> little more detail about your goals, rather than potential solutions?
>>
>> I think rc.d/var should be able to populate a named compliant /var.
>> Therefore it needs at least named.conf and named.root.
>> My idea was to save them in /usr/share, where many other (sendmail e.g.)
>> template duplicates also reside. When chrooting to /usr/share/namedb, it
>> also fails if I don't have the original installed /var, like if /var is
>> a freshly populated memory file system.
>
> If you are dead set on this course of action that's fine. What I
> suggest that you do is to create an rc.d script that does what you
> want, and include REQUIRE: var and BEFORE: named. Put this script in
> /usr/local/etc/rc.d and you'll be good to go. Off hand you will
> probably need to use the same mtree invocation that rc.d/named uses to
> create the file structure, but after that copying your files should be
> easy. You can start here for information on how to create your own
> rc.d scripts:
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/rc-scripts.html
>

FWIW, I already created one that does something similar. In my
environment I have a MFS-based var that is populated with
'populate_var="YES"' in /etc/rc.conf. I wrote a quick rc.d script to
copy my saved config and zone files from from flash to
/var/named/etc/namedb before starting named. This works with the
/etc/namedb symlink and a MFS-based var for consistent bootup. Might
save you a bit of time.

In /etc/rc.conf it expects MINIBSD_named_dir to be set to the static
directory on flash where the base config is copied from. Files in this
dir can be updated as needed for named configuration or zone file
changes. It also needs named_enable set to YES to ensure its run. In
my case my /etc/rc.conf looks like this:

MINIBSD_named_dir="/etc/namedb-root"
named_enable="YES"

And my base config and zone files live in /etc/namedb-root/namedb


/usr/local/etc/rc.d/MINIBSD_named:

##START
#!/bin/sh
# Copy ${MINIBSD_named_dir} to /var/named/etc/named at startup for mfs
# -mproto 20060919

# PROVIDE: MINIBSD_named
# REQUIRE: FILESYSTEMS cleanvar
# BEFORE: named syslogd

. /etc/rc.subr

name="MINIBSD_named"
rcvar=`set_rcvar named`
start_cmd="named_copy"

named_copy()
{
	if [ ! -d ${named_chrootdir}/etc/namedb ]; then
		echo "Copying ${MINIBSD_named_dir} to ${named_chrootdir}"
		mkdir -p ${named_chrootdir}/etc
		cp -p /etc/localtime ${named_chrootdir}/etc/
		cp -Rfp ${MINIBSD_named_dir}/namedb ${named_chrootdir}/etc/
		mkdir -p ${named_chrootdir}/var/run
		chown bind ${named_chrootdir}/var/run
	fi
}

load_rc_config named
load_rc_config $name
required_dirs="$MINIBSD_named_dir"

run_rc_command "$1"
##END


Works like a charm for me, and I learned a lot about writing rc.d
scripts (based on your rc.d HOWTO on the FreeBSD documentation site
Doug, thanks very much for that!!)


-Proto
Received on Wed Jan 06 2010 - 19:56:54 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:59 UTC