From owner-freebsd-stable Sat Sep 21 14:42:15 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 321C137B401 for ; Sat, 21 Sep 2002 14:42:13 -0700 (PDT) Received: from lariat.org (lariat.org [63.229.157.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 543AE43E6A for ; Sat, 21 Sep 2002 14:42:12 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp1000.lariat.org@lariat.org [63.229.157.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id PAA29426; Sat, 21 Sep 2002 15:41:58 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook is dangerous and makes your system susceptible to Internet worms. Message-Id: <4.3.2.7.2.20020921145846.026efc50@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 21 Sep 2002 15:41:55 -0600 To: The Anarcat From: Brett Glass Subject: Re: Suggested modification to default install Cc: freebsd-stable@freebsd.org In-Reply-To: <20020921171445.GA308@lenny.anarcat.ath.cx> References: <4.3.2.7.2.20020920095347.00b15f00@localhost> <20020510194022.D77057@lpt.ens.fr> <000701c1f804$47d5dc00$6401a8c0@penguin> <20020510140222.M57329@lpt.ens.fr> <15580.1017.276905.556906@guru.mired.org> <20020510194022.D77057@lpt.ens.fr> <4.3.2.7.2.20020920095347.00b15f00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 11:14 AM 9/21/2002, The Anarcat wrote: >I keep DNS data in /var/db/namedb, I don't know why it always seemed >fundamentally just right to me. Well, it's sort of a judgment call, because DNS data is part configuration (e.g. zones for which you're the master) and part ephemeral database (slave zones, the DDNS portions of master zones, and cache). There's a good argument that the ephemera ought to go out in /var while the more permanent or configuration-like stuff (e.g. master zones) belongs in /usr. The problem with this is that it's desirable to sandbox (chroot) BIND. This, in turn, requires all the data it reads and writes to be under the home directory of its UID. So, given this constraint, I figure that /usr/local/etc/namedb is probably the best place all around -- and that's where I put everything. The important thing is to keep anything that's updated often out of the root, so that the root file system can be made fully synchronous. /usr is the default location of users' home directories, so it can be expected to be written more frequently. I mount it with softupdates, as is already the default. I also do turn hardware write caching off. Softupdates mitigates the effects of doing this, so I don't see significant performance loss. In fact, sometimes I see a gain, because the drive -- when told that it shouldn't cache writes -- often devotes all of its RAM to read-ahead caching instead. This is a big win for multimedia playback. Turning off write caching shouldn't be a default, but should be easily do-able. (Right now, it requires a bit of arcane knowledge to accomplish. I found out by trial and error -- it isn't documented anywhere in the loader.conf man page -- that you can set sysctl variables prior to the last stage of the bootstrap in /boot/loader.conf. So, I put the command hw.ata.wc=0 there. When the kernel loads, the ATA driver sees the sysctl variable and sends the drive the appropriate command to nuke ATA write caching. It does not appear that changing that sysctl variable has any effect after the drive is attached. I've done a quick grep of /sys/dev/ata, and there doesn't appear to be a SYSCTL_PROC macro covering that flag. (Soren? Jeroen? Would this be tough to add?) In any event, back to my original suggestion. What I suggest is that we make the root partition synchronous by default, and reconfigure BIND to use /usr/local/etc/namedb instead of /etc/namedb by default. While we're at it, let's create a "sandbox" directory structure (similar to the one described in the Handbook) for BIND and sandbox it by default. There's no reason not to make sandboxing the default on every system, since as far as I know it won't break anything to do so. Only thing is, I'm not a committer. If I get the changes ready, could someone look at committing them to -STABLE? --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message