Date: Tue, 26 Sep 1995 11:03:20 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: gryphon@healer.com (Coranth Gryphon) Cc: gryphon@healer.com, terry@lambert.org, freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org, kelly@fsl.noaa.gov Subject: Re: ports startup scripts Message-ID: <199509261803.LAA07924@phaeton.artisoft.com> In-Reply-To: <199509260316.XAA14582@healer.com> from "Coranth Gryphon" at Sep 25, 95 11:16:25 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. 1) That's not a client DNS, that's a server DNS. 2) You don't run server DNS's booted diskless, dataless, or off CDROM. > Ok, so you want to rewrite the entire BSD configuration system, and > take anything that might change out of /etc. You're not listening. > 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. I want the *ability* to have a read-only system configuration. A typical configuration would pre-merge the directories, and could merge them to /etc or whatever *you* wanted. > > 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. I want a CD to be usable as a bootable system, which mean I want some acceptable defaults in /etc. I want to seperate configuration data from the scripts that act on it. The scripts that act on it should not typically be changed by end users. > > An upgrade is a typical user operation. > > How often? Once every 3-4 months? Yes. That's the promised distribution frequency. > 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? I don't care what it is named. I think that local password data on an NFS diskless/dataless mount is not mutable data. I included the password data for your benefit. I think that system naming and IP addresses are a function of bootp and DHCP; again, not something that is configured locally. It's perfectly acceptable to have shared configuration data on a read-only partition. It's the people who want to run Lycos servers on diskless systems that have their priorities mixed up. > 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. /var or whatever. All I want is a directory that doesn't get touched on an upgrade so that I can drop in a new distribution sans my /home partition and my system configuration data and be up and running. > 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. You still aren't listening. 8-(. > 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, I want to be able to use diskless and dataless configurations without the possibility of one client screwing it up for all of them. I want to be able to "test drive" the system from a CDROM or from a directory tree on an MS-DOS or Win95 or OS/2 file system without repartitioning my disk on speculation. I want to have a command line admin utility that can be popen'ed by a curses/GUI utility. I want to have a curses/GUI utility. I want to have multiple system administration vi popen of an rsh of the command line utility by the same curses/gui utility. What framework do you suggest for accomplishing these goals? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509261803.LAA07924>