From owner-freebsd-hackers Mon Feb 2 11:34:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA21786 for hackers-outgoing; Mon, 2 Feb 1998 11:34:48 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cam.grad.kiev.ua (grad-UTC-28k8.ukrtel.net [195.5.25.54]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA21762; Mon, 2 Feb 1998 11:34:38 -0800 (PST) (envelope-from Ruslan@Shevchenko.kiev.ua) Received: from Shevchenko.kiev.ua (localhost [127.0.0.1]) by cam.grad.kiev.ua (8.8.8/8.8.5) with ESMTP id XAA14431; Sun, 1 Feb 1998 23:32:24 +0200 (EET) Message-ID: <34D4E9DE.3F127D46@Shevchenko.kiev.ua> Date: Sun, 01 Feb 1998 23:32:18 +0200 From: Ruslan Shevchenko X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) MIME-Version: 1.0 To: Adam Turoff CC: "'hackers@freebsd.org'" , "'config@freebsd.org'" , "'mike@smith.net.au'" Subject: Re: Multi-faced admin References: <34D6422A@smginc.com> Content-Type: multipart/alternative; boundary="------------0D9DB95FA17AC9268C1299B7" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe hackers" --------------0D9DB95FA17AC9268C1299B7 Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit Adam Turoff wrote: > Looking at Mikael Karpberg page on his architecture for admin'ing a ------------------------------------------------------------------------------- URL ? > FreeBSD > box, I came across a link to Caldera's COAS project: http://www.coas.org > > I'm rather sorry to say that I haven't looked deeply into some of the > broad > scope ideas that people have been posting to -hackers recently. (I feel > rather guilty that I haven't committed my big picture to bits and bytes > yet > either.) We all know what it means to be spread thin, I guess. :-) > > Anyway, skimming over COAS, (Caldera Open Adminstration System), > it looks like either it's something worth porting, or it's something > worth > improving upon. All of the standard knobs are there, like curses/X/Java > interfaces, etc. (Sorry, I can't post a summary right now. The code is > at v0.09, appears to use lots of python and is GPL'd.) And it is very unclean, on first look. > --- > > Reading the post about UMich's LDAP engine, it sounds rather radical. > 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) (why httpd server ? first-step is cgi. > - standardized CGI interface subset for admin modules > - LDAP for config managment by admin modules > > Five layers (three for glue) to have any random client reconfigure > any part of the system. The top glue is pretty dumb; it just > standardizes the interface. The middle glue layer is where all > 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). > > Sound good? I'll start a prototype in my copious free time before > the end of the month. :-) > I now work on configuration system for FreeBSD, which have next layers: C++ API --------- Tcl binding ----------------- Tk Interface ------------------ CGI Interface (future) --------- CORBA (future) At now I implemented all READ-CONFIG methods in C++, and write a part of GUI stuff, which looks better, than Linux UserCfg in python. look at http://cam.grad.kiev.ua/~rssh/admin/admin.html for details About General interface with Set-Get/Add-Remove metods under abstract stuff: sounds very good, but, imho, we must have glue API interface on some "real" language (tcl or CORBA ), but not declarative "sheme". > -- Adam. > > PS: Mike, where can I find some docs, etc. on the UMich LDAP server? Altavista on Query +LDAP +UNIX work fine ;) -- @= //RSSH mailto://Ruslan@Shevchenko.Kiev.UA --------------0D9DB95FA17AC9268C1299B7 Content-Type: text/html; charset=x-user-defined Content-Transfer-Encoding: 7bit Adam Turoff wrote:
Looking at Mikael Karpberg page on his architecture for admin'ing a
  -------------------------------------------------------------------------------  URL ?

FreeBSD
box, I came across a link to Caldera's COAS project: http://www.coas.org

I'm rather sorry to say that I haven't looked deeply into some of the
broad
scope ideas that people have been posting to -hackers recently.  (I feel
rather guilty that I haven't committed my big picture to bits and bytes
yet
either.)  We all know what it means to be spread thin, I guess.  :-)

Anyway, skimming over COAS, (Caldera Open Adminstration System),
it looks like either it's something worth porting, or it's something
worth
improving upon.  All of the standard knobs are there, like curses/X/Java
interfaces, etc.  (Sorry, I can't post a summary right now.  The code is
at v0.09, appears to use lots of python and is GPL'd.)

 And it is very unclean, on first look.

 ---

Reading the post about UMich's LDAP engine, it sounds rather radical.
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)

   (why httpd server ?     first-step is cgi.
 - standardized CGI interface subset for admin modules
 - LDAP for config managment by admin modules

Five layers (three for glue) to have any random client reconfigure
any part of the system.  The top glue is pretty dumb; it just
standardizes the interface.  The middle glue layer is where all
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).

Sound good?  I'll start a prototype in my copious free time before
the end of the month.  :-)
 

I now work on configuration system for FreeBSD, which have next layers:

 C++ API
               --------- Tcl  binding
                              ----------------- Tk Interface
                              ------------------ CGI Interface  (future)
              ---------  CORBA  (future)

At now I implemented all READ-CONFIG methods in C++,
 and write a part of GUI stuff, which looks better, than Linux UserCfg in python.

look at http://cam.grad.kiev.ua/~rssh/admin/admin.html for details

About General interface with Set-Get/Add-Remove metods under abstract stuff:
 sounds very good, but, imho, we must have glue API interface on some
"real"  language (tcl or CORBA ), but  not declarative "sheme".
 

 -- Adam.

PS: Mike, where can I find some docs, etc. on the UMich LDAP server?

Altavista on Query +LDAP  +UNIX work fine ;) 
-- 

    @=                                   
     //RSSH                              mailto://Ruslan@Shevchenko.Kiev.UA
  --------------0D9DB95FA17AC9268C1299B7--