From owner-freebsd-config Thu Feb 5 15:10:05 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA19801 for config-outgoing; Thu, 5 Feb 1998 15:10:05 -0800 (PST) (envelope-from owner-config) Received: from dingo.cdrom.com (lapdog.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA19794; Thu, 5 Feb 1998 15:10:04 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id WAA00515; Thu, 5 Feb 1998 22:28:18 +1030 (CST) Message-Id: <199802051158.WAA00515@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Adam Turoff cc: "'hackers@freebsd.org'" , "'config@freebsd.org'" , "'mike@smith.net.au'" Subject: Re: Multi-faced admin In-reply-to: Your message of "Mon, 02 Feb 1998 14:03:00 PST." <34D6422A@smginc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Feb 1998 22:28:18 +1030 From: Mike Smith Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Looking at Mikael Karpberg page on his architecture for admin'ing a > FreeBSD > box, I came across a link to Caldera's COAS project: http://www.coas.org COAS is vapourware at this point in time. I wasn't impressed last time I looked; it's a GUI frontend to a pile of specific configuration file editors and completely fails to address the issues of multisystem management. ie. idea for a standalone desktop, but a complete dud for anything that aspires to being a server operating system. > Reading the post about UMich's LDAP engine, it sounds rather radical. I don't know if "radical" is right; all I'm saying is that we need to provide a uniform interface to *all* the parametric information that controls the system, if we want to be able to abstract the "configuration" process from the "interpretation" process. This is where COAS (and others) fall down. > So, as of the moment, here's a concise view of what I'm seeing/hearing > for a FreeBSD framework: > > - httpd type server (easy to plug any client into/write new clients) > - standardized CGI interface subset for admin modules This is only *one* interface stack, but likely to be the most commonly used. > - LDAP for config managment by admin modules Terry's picture describes it much better than I can in words. You are describing the path from "Browser" to "LDAP Server", leaving out a few components, but pointing out that there has to be a shim between "HTTPD" and "LDAP Client API", ie. your CGI interface subset above. > the work is done. The bottom glue layer appears rather dumb, > but it should hide the complexity of a bazillion different config file > formats > (if I'm reading what Mike is saying about LDAP correctly). This is one of the key items; it means that there is no change in the parametric interface if/when we shift from separate configuration files to trusting the LDAP database for everything. > PS: Mike, where can I find some docs, etc. on the UMich LDAP server? Go to /usr/ports/net/ldap, and try "make install". The manpages it splats in are a good starting point, and it has some xrefs as well. There's also a mob called Critical Path (IIRC) that have some UMich LDAP resources (FAQ, etc.) online. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\