From owner-freebsd-embedded@FreeBSD.ORG Thu Oct 21 13:19:18 2010 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D2DE106566C; Thu, 21 Oct 2010 13:19:18 +0000 (UTC) (envelope-from fb-embedded@psconsult.nl) Received: from mx1.psconsult.nl (unknown [IPv6:2001:7b8:30f:e0::5059:ee8a]) by mx1.freebsd.org (Postfix) with ESMTP id 1F4078FC1A; Thu, 21 Oct 2010 13:19:17 +0000 (UTC) Received: from mx1.psconsult.nl (psc11.adsl.iaf.nl [80.89.238.138]) by mx1.psconsult.nl (8.14.4/8.14.4) with ESMTP id o9LDJBnK032644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Oct 2010 15:19:16 +0200 (CEST) (envelope-from fb-embedded@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.4/8.14.4/Submit) id o9LDJB4X032643; Thu, 21 Oct 2010 15:19:11 +0200 (CEST) (envelope-from fb-embedded@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to fb-embedded@psconsult.nl using -f Date: Thu, 21 Oct 2010 15:19:11 +0200 From: Paul Schenkeveld To: freebsd-embedded@freebsd.org, embedded@freebsd.org Message-ID: <20101021131911.GA32168@psconsult.nl> References: <1054626238.20101021160152@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1054626238.20101021160152@serebryakov.spb.ru> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Subject: Re: NanonBSD & chrooted named (with zones in /var) - is here any good solution? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 13:19:18 -0000 On Thu, Oct 21, 2010 at 04:01:52PM +0400, Lev Serebryakov wrote: > Hello, Embedded. > > What is proper, NanoBSD-canonic, way to add named to NanoBSD > installation? /etc is overwritten from /cfg (after /conf/base), but > /var is only created from /conf/base, and typical "edit, mount /etc, > copy to /etc, unmount /etc" pattern will not work here, and it will be > overwritten after slice upgrade. What sort of nameserver do you want, a recursive nameserver without authority over any zone could run completely r/o. You need to set WITHOUT_BIND_MTREE while building NanoBSD and manually create the contents of /etc/namedb and copy them over to /cfg/namedb as well. An authoritative nameserver with only zones for which it is master and which you maintain manually could perfectly live in the /etc of a NanoBSD image. Build it like the recursice nameserver above. An authoritative nameserver with zones for which it is slave usually wants writable backing store to copy zones received from a master. This could be done similar to the setup for a recursive or master nameserver as described above but the cached zones will not be copied to /cfg/namedb automatically. Often this is not a problem if it only serves a handful of zones as it will check the serial number of any zones in the slave subdirectory (provided you synchronized to /cfg at some point) and transfer those from the master that are out of date (or not present at all). For nameservers with master zones that need to be changed frequently or by some sort of front-end tool and for nameservers with many slave zones the pure NanoBSD model with r/o root on flash and /etc and /var in a memory disk is not the perfect solution. Some people use NanoBSD on large servers that also have harddisks in them, in such cases creative solutions can be designed to place named data on real hard drives but I get the impression that you are talking about hardware without spinneng drives, right? > I could put all named chroot tree into DATA slice, but it is not > elegant, because it should be mounted r/w. If your drive is a flash disk mounting the data slice r/w for named to write to it completely ignores the whole reason why NanoBSD works the way it works, never automatically write to the flash drive to prevent it from wearing and guarantee that on power-up you always start with a known-to-be-good configuration. > Maybe, here is good customization for this? HTH. Regards, Paul Schenkeveld