Date: Thu, 29 Jan 1998 13:04:43 -0800 (PST) From: Alex Belits <abelits@phobos.illtel.denver.co.us> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: Karl Pielorz <kpielorz@tdx.co.uk>, Adam Turoff <AdamT@smginc.com>, hackers <hackers@FreeBSD.ORG> Subject: Re: WebAdmin (was: RE: /usr/src/release/sysinstall needs YOU. :-)) Message-ID: <Pine.LNX.3.96.980129122009.32218A-100000@phobos.illtel.denver.co.us> In-Reply-To: <14682.886103186@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 29 Jan 1998, Jordan K. Hubbard wrote:
> > 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.
HTTP over ssh tcp forwarding does that easily, and provides nice
"fallback" to plaintext passwords for configuration without ssh.
>
> 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".
IMHO HTML forms already provide necessary frontend for it.
POST /admin-html?newuser
and encoded form-submit containing
"uname=joe"
"fullname=Joe Blow"
"password=geheim"
"shell=/usr/local/bin/tcsh"
"include=default-user-profile
(separator characters and escape-encoding omitted for clarity).
BTW, the HTTP server, I wrote
(http://phobos.illtel.denver.co.us/pub/fhttpd/),
allows running separate process as the handler for all requests to some
set of URLs (with or without allowing to have simultaneously running
copies of such process, so locks can be easily avoided, and session state
can be preserved in the running process). I believe that reinventing the
wheel and creating yet another protocol to send hierarchically organized
key-value pairs data to some running program that edits files and runs
scripts based on that data, will be rather pointless now when HTTP exists,
and if one wants to write better-looking user interface for it at the
client side, he can use java, tcl or whatever else, but keep HTTP as the
protocol.
I have implemented the "administration interface" for two cameras
attached to my home box (http://phobos.illtel.denver.co.us/qcam-config)
and "administration" for X-10 appliances that I use in my apartment.
Both things require that a single process handles all operations on
device, is constantly running, receives various messages from device or
its driver and keeps its state -- soimething that can't be done with CGI
alone, and making CGI interface to some constantly-running server
IMHO defeats the idea of clean, secure and fast protocol. There shouldn't
be a big problem writing SMIT-like interface for system configuration and
packages installation based on the same model, however properly designed
system should have means of configuration replication (program creates the
form that when submitted to the same kind of server on another box copies
chosen parts of configuration), processes and logs monitoring, etc.
--
Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.96.980129122009.32218A-100000>