From owner-freebsd-hackers Mon Sep 25 20:14:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA07514 for hackers-outgoing; Mon, 25 Sep 1995 20:14:54 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA07500 for ; Mon, 25 Sep 1995 20:14:29 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id XAA14582; Mon, 25 Sep 1995 23:16:25 -0400 Date: Mon, 25 Sep 1995 23:16:25 -0400 From: Coranth Gryphon Message-Id: <199509260316.XAA14582@healer.com> To: gryphon@healer.com, terry@lambert.org Subject: Re: ports startup scripts Cc: freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org, kelly@fsl.noaa.gov Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: Terry Lambert > +> In which case, you've set up a very unique configuration, where > +> you cannot change "motd", cannot edit password files, change mail > +> aliases, add new hosts to DNS, ... > DNS server/caching databases should be in var. A client DNS configuration > is not subject to change by the client. Unless you happen to be running as your domain primary, which a LOT of people do. But then again, why bother keeping track of any data, just let each machine announce itself and configure everything dynamically, seems to work for MS-Windows. > The motd should be in var. > Local passwords not in the NIS database or user IDs needed for boot > should be in var. > Mail aliases should be handled by the mail exchanger host; those that > are local to the local machine should be in the users' personal alias > database. or they should be in var. Ok, so you want to rewrite the entire BSD configuration system, and take anything that might change out of /etc. Fine. I give up. You want to change everything, go ahead. It's not worth trying to fine a compromise when you want a read-only system configuration. > +> These types of changes are at least as common, if not a lot more so, > +> than adding packages. > Only because we have local system information in the wrong damn place, > which is why we don't have the ability to upgrade in the first place > (upgrade/addition-of-options is what started this whole thread). No, the problem is that traditionally, these things went into /etc since that was the configuration directory. You don't want it to be the configuration directory, you want it to be a static system configuration that comes on CD and doesn't change. > An upgrade is a typical user operation. How often? Once every 3-4 months? Do we really want to rewrite everything around /etc being read-only and change every existing configuration utility and script, so that we can go through the entire conversation all over again when the directory is named /var/config? The nice thing about /var right now is that everything there (with a very few exceptions which have already been discussed) is volatile. It can be blown away and replaced with no problem, other than loss of history. Now, it would entail a complete reconfiguration. If you want to rewrite everything go ahead. Just be prepared for the few thousand people being real confused that /etc/passwd is now /var/config/local/passwd. On the other hand, if people want to take a working system (what we have now) and add a bit of flexibilty and functionality to it, let me know so I can help. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa...