From owner-freebsd-hackers Sun Apr 19 03:23:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA00168 for freebsd-hackers-outgoing; Sun, 19 Apr 1998 03:23:38 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from const. (willow20.verinet.com [199.45.181.52]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA00162 for ; Sun, 19 Apr 1998 10:23:34 GMT (envelope-from allenc@verinet.com) Received: (from allenc@localhost) by const. (8.8.8/8.8.8) id EAA10069 for hackers@FreeBSD.ORG; Sun, 19 Apr 1998 04:24:29 -0600 (MDT) (envelope-from allenc) Date: Sun, 19 Apr 1998 04:24:29 -0600 (MDT) From: allen campbell Message-Id: <199804191024.EAA10069@const.> To: hackers@FreeBSD.ORG Subject: Re: Discussion : Using DHCP to obtain configuration. In-Reply-To: <199804182328.QAA25724@hub.freebsd.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Oh.. and while I'm dreaming, how about using portalfs or similar as > > such: mount /etc with portalfs and have a translator present all of > > the data from the database in traditional format. > > This is a *terrifically* cool idea! This simply obsoletes any idea to-date that I know of for supporting the legacy system. Terry, I have followed your advocacy of LDAP (or a similar alternative) for some time now and I have some questions. How do you address an assertion which says dependency on a database reduces robustness because of, for instance, database corruption? Do you disregard the assertion based on evolutionary necessity ('bite the bullet') or do you dispute that there is any significant compromise at all? Does a configuration database imply a client/server design and, therefore, a daemon to implement the server, or do you expect that a static/shared library would allow the client direct access? The former provides for a very thin client and powerful concurrency control (such as signaling registered clients when the hostname changes.) The latter has the appeal of not requiring an daemon which would be tough to support in minimalist applications. Both perhaps? Different parts of the configuration hierarchy have different security requirements and this will ultimately require close integration with the kernel for enforcement, authentication, etc. How does that square with a user mode subsystem such as LDAP? (A disclaimer on this one; I am not proficient enough with LDAP to assert that this isn't already provided for, I merely suspect not. As a database applications developer, I have learned that there is little integration between host system security and database security in contemporary SQL database systems.) Allen Campbell allenc@verinet.com ps. This thread should be migrated to the config list. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message