From owner-freebsd-hackers  Thu Jan 29 11:46:59 1998
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id LAA05780
          for hackers-outgoing; Thu, 29 Jan 1998 11:46:59 -0800 (PST)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA05756
          for <hackers@FreeBSD.ORG>; Thu, 29 Jan 1998 11:46:55 -0800 (PST)
          (envelope-from jkh@time.cdrom.com)
Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.6.9) with ESMTP id LAA14686; Thu, 29 Jan 1998 11:46:26 -0800 (PST)
To: Karl Pielorz <kpielorz@tdx.co.uk>
cc: Adam Turoff <AdamT@smginc.com>, hackers <hackers@FreeBSD.ORG>
Subject: Re: WebAdmin (was: RE: /usr/src/release/sysinstall needs YOU. :-)) 
In-reply-to: Your message of "Thu, 29 Jan 1998 16:38:40 GMT."
             <34D0B090.5061FE9C@tdx.co.uk> 
Date: Thu, 29 Jan 1998 11:46:26 -0800
Message-ID: <14682.886103186@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe hackers"

> On each machine we run an 'admind' process (admin. daemon). Now all our
> machines are firewalled correctly, so only internal machines on our Company
> LAN can connect on the AdminD port - but even so, I still intend to use
> passwords / encryption etc.

This approach sounds familiar. :-)

It's also not one without merit, though I also wonder how you're
handling the _export_ of information in this scenario.  If you want to
create a rich administrative interface which provides good overview
information as well as letting you create new system entitites (users,
filesystems, etc) then you've got to have nice flexible way of getting
system information back to the "browser" which hopefully doesn't
require that you modify the browser every time you add access to a new
system data type.

That abstraction was sort of the goal of Mike Smith's "juliette"
package in TCL which gives an arbitrary browser access to the data in
/etc/rc.conf, /etc/host.conf, /etc/master.passwd, etc. by exporting it
into a MIB-like space and abstracting away the underlying storage
details - the user neither knows nor cares which file a given system
administration variable comes out of.  I can't remember where he last
stashed a copy of it for ftp access, but I do recall him bringing it
up several times in this mailing list and it should be in the mailing
list archives.

Using TCL as the ascii data interchange format also means that you can
use it for simple data specification, e.g.:

newuser {
   uname	"joe"
   fullname	"Joe Blow"
   password	"geheim"
   shell	"/usr/local/bin/tcsh"
   include	default-user-profile
}

and you get parsing for free since your "newuser" command can just
register temporary commands like uname, fullname, etc. during the
scope of its argument's evaluation.  You also, obviously, leave the
door open for passing more "intelligent" data where the handlers for
the new data are passed along with the data itself.  The browser can
thus "learn" dynamically to deal with new data types and you don't
need to hack on it every time you add a significantly new feature to
your "admind".

					Jordan