From owner-freebsd-current@FreeBSD.ORG Wed Jan 6 09:11:59 2010 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 963CB106566C for ; Wed, 6 Jan 2010 09:11:59 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 155108FC1B for ; Wed, 6 Jan 2010 09:11:58 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o069Bv57045502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jan 2010 10:11:58 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B4453DC.7080405@omnilan.de> Date: Wed, 06 Jan 2010 10:11:56 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Michael Proto References: <4B12CCA8.7050808@omnilan.de> <1de79840912070951p1abf7dbfxdf7d5ea5ab5903cd@mail.gmail.com> In-Reply-To: <1de79840912070951p1abf7dbfxdf7d5ea5ab5903cd@mail.gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig81060E156A7DAEE181872C1D" Cc: freebsd-current@freebsd.org Subject: Re: named, VARMFS=yes and FILESDIR 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: Wed, 06 Jan 2010 09:11:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig81060E156A7DAEE181872C1D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Michael Proto schrieb am 07.12.2009 18:51 (localtime): > On Sun, Nov 29, 2009 at 2:34 PM, Harald Schmalzbauer > wrote: >> Hello, >> >> while building an embedded slave DNS I recognized that running named o= ut 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=3DYes 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, bu= t we >> don't have the needed files outside of /var. >> >> My idea is to create a namedb directory in /usr/share (like there's on= e for >> sendmail) with duplicate entries of src/etc/namedb >> >> Unfortunately I couldn't find out where FILESDIR is processed in the b= sd >> 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 c= ould >> 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=3D"$named_chrootdir" # if it is set, it must exis= t >> pidfile=3D"${named_pidfile:-/var/run/named/pid}" >> -command_args=3D"-u ${named_uid:=3Droot}" >> +command_args=3D"-c $named_conf -u ${named_uid:=3Droot}" >> >> >=20 >=20 > 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=3D"YES" rc.conf tunable. >=20 > /etc/fstab: > md /var mfs rw,async,-s12m 2 0 >=20 > /etc/rc.conf: > populate_var=3D"YES" >=20 > With these settings a chrooted named into /var/named works just as expe= cted. If you have a valid /var from the base install that's true. But I'm=20 unhappy that the design is to have essential files outside in the /var=20 filesystem without duplicates to automatically restore a working state=20 if something goes wrong. I think these files should not rely on a link=20 from /etc and duplicating 15kByte is cheap these days. I'm unsure how to best solve the "config files outside /etc" problem... Thanks, -Harry --------------enig81060E156A7DAEE181872C1D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAktEU90ACgkQLDqVQ9VXb8jX5wCeOD+YuYv9ucaHVGPEM1C5PSZH VUgAn1TpO1ZUNbeic8p6+BPgkl7VbM+1 =hKYo -----END PGP SIGNATURE----- --------------enig81060E156A7DAEE181872C1D--