Date: Wed, 06 Jan 2010 10:11:56 +0100 From: Harald Schmalzbauer <h.schmalzbauer@omnilan.de> To: Michael Proto <mike@jellydonut.org> Cc: freebsd-current@freebsd.org Subject: Re: named, VARMFS=yes and FILESDIR Message-ID: <4B4453DC.7080405@omnilan.de> In-Reply-To: <1de79840912070951p1abf7dbfxdf7d5ea5ab5903cd@mail.gmail.com> References: <4B12CCA8.7050808@omnilan.de> <1de79840912070951p1abf7dbfxdf7d5ea5ab5903cd@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
Michael Proto schrieb am 07.12.2009 18:51 (localtime):
> On Sun, Nov 29, 2009 at 2:34 PM, Harald Schmalzbauer
> <h.schmalzbauer@omnilan.de> wrote:
>> Hello,
>>
>> while building an embedded slave DNS I recognized that running named out of
>> the box with VARMFS enabled would fail.
>> Now I could easily fix it for my device only, but I think it's better to
>> solve it upstream.
>> VARMFS=Yes is a standard option, likewise named_enable.
>>
>> Short description of the problem:
>> When rc detects non-writabel /var or VARMFS is set to yes, a new /var tree
>> gets populated. This comes without config, hint file and likewise for
>> /var/named/namedb, but /etc/namedb is a symlink to /var/named/namedb.
>>
>> rc.d/named could easily be supplemented with the neccessary checks, but we
>> don't have the needed files outside of /var.
>>
>> My idea is to create a namedb directory in /usr/share (like there's one for
>> sendmail) with duplicate entries of src/etc/namedb
>>
>> Unfortunately I couldn't find out where FILESDIR is processed in the bsd
>> build stages.
>> If the idea is plausable, how do I best install /usr/share/namedb?
>> src/etc/namedb is entered at DISTRIBUTION target, right?
>>
>> Id highly appreciate if somebody who's familar with the build stages could
>> give me some hints.
>>
>> Thanks,
>>
>> -Harry
>>
>> P.S.: named_conf definitions in rc.conf get lost. Here's the patch:
>> --- etc/rc.d/named.orig 2009-09-13 20:11:34.000000000 +0200
>> +++ etc/rc.d/named 2009-09-13 21:38:29.000000000 +0200
>> @@ -264,6 +284,6 @@
>> #
>> required_dirs="$named_chrootdir" # if it is set, it must exist
>> pidfile="${named_pidfile:-/var/run/named/pid}"
>> -command_args="-u ${named_uid:=root}"
>> +command_args="-c $named_conf -u ${named_uid:=root}"
>>
>>
>
>
> I think this is likely an ordering issue, as I use a MFS-based /var on
> my home router and named works with the default /var/named chroot just
> fine. My main difference being I define the MFS /var in fstab as
> opposed to the varmfs="YES" rc.conf tunable.
>
> /etc/fstab:
> md /var mfs rw,async,-s12m 2 0
>
> /etc/rc.conf:
> populate_var="YES"
>
> With these settings a chrooted named into /var/named works just as expected.
If you have a valid /var from the base install that's true. But I'm
unhappy that the design is to have essential files outside in the /var
filesystem without duplicates to automatically restore a working state
if something goes wrong. I think these files should not rely on a link
from /etc and duplicating 15kByte is cheap these days.
I'm unsure how to best solve the "config files outside /etc" problem...
Thanks,
-Harry
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (FreeBSD)
iEYEARECAAYFAktEU90ACgkQLDqVQ9VXb8jX5wCeOD+YuYv9ucaHVGPEM1C5PSZH
VUgAn1TpO1ZUNbeic8p6+BPgkl7VbM+1
=hKYo
-----END PGP SIGNATURE-----
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B4453DC.7080405>