From owner-freebsd-hackers Fri Apr 17 14:53:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA08011 for freebsd-hackers-outgoing; Fri, 17 Apr 1998 14:53:24 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA07818 for ; Fri, 17 Apr 1998 21:52:37 GMT (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id RAA13756; Fri, 17 Apr 1998 17:51:52 -0400 (EDT) Date: Fri, 17 Apr 1998 17:51:51 -0400 (EDT) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: Mike Smith cc: Archie Cobbs , hackers@FreeBSD.ORG Subject: Re: Discussion : Using DHCP to obtain configuration. In-Reply-To: <199804170534.WAA00450@antipodes.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 16 Apr 1998, Mike Smith wrote: > > > > The way UNIX piles random configuration information all into /etc > > has always bugged the crap out of me. Ideally, /etc should go away > > because nothing should be "miscellaneous".. it should all be organized. > > ... in a database. Go visit Terry's cube tomorrow. Say "LDAP?" and > wait for the lecture. > > > Hmm.. what if we created the /var/conf hierarchy... > > Actually, what I want is a stub version of the LDAP client library that > can be linked into a few of the items that run early on (init, mount, > fsck, dhclient, etc), before the network is up. Once the net is up, > everything parametric ought to be indirected through a generic "get me > a parameter" API. See, so the reason I find this concerning is that it stores the configuration information (presumably) in a single repository, and the kernel enforcement of the security on this repository can't be made finer grained. See the current discussion on freebsd-stable/-security for details. If you have several securelevels, you will want several sources of configuration information -- wherein higher securelevels can change their own configuration, but not that of lower securelevels (i.e., a higher securelevel might allow changing the web server configuration, but not changing the file system mount information as root). Some information looks like it would fit nicely into a single directory service -- i.e., DNS configuration, account name information, mail delivery information, etc. Other stuff does not fit so well -- ipfw configuration, port mapping of key daemons, file systems to mount, library search path, and so on. If the two approaches can be made compatible, I am all for a more sane configuration system :). If not, then I see problems. Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message