Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

named, VARMFS=yes and FILESDIR

4 views
Skip to first unread message

Harald Schmalzbauer

unread,
Nov 29, 2009, 2:34:00 PM11/29/09
to
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}"

signature.asc

Doug Barton

unread,
Nov 29, 2009, 10:54:15 PM11/29/09
to
Harald Schmalzbauer 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.

There are lots of standard options that are not compatible with each
other.

> 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?

> P.S.: named_conf definitions in rc.conf get lost.

Yes, that's something that needs improvement. I have it on the list
but since it's not common for people to alter the path to the conf
file, and since in the past in order to do so you've had to add -c to
named_flags anyway, I don't regard it as urgent.


Doug

--

Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/

_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

Michael Proto

unread,
Dec 7, 2009, 12:51:38 PM12/7/09
to
On Sun, Nov 29, 2009 at 2:34 PM, Harald Schmalzbauer
<h.schma...@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.


-Proto

0 new messages