Date: Thu, 29 Jan 1998 20:39:21 +0000 From: Karl Pielorz <kpielorz@tdx.co.uk> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: hackers@FreeBSD.ORG Subject: Re: /usr/src/release/sysinstall needs US. :-)) Message-ID: <34D0E8F9.CCE51F59@tdx.co.uk> References: <14682.886103186@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
That was one of my thoughts, about having the client so dumb, it almost gets
told everything to do (This is getting to sound like Web based again isn't
it?)
Right - A lot of people have ideas, some free time (hmmm... ;-) - and
suggestions etc. - I'm pretty new around here, so erm, what do we do next? -
some sort of show of hands, who's prepaired to work on it? - then we can hive
off to some other list or something and get cracking on more brainstorming,
planning, more planning, even more planning - then implmenting...
Just to add fuel to the fire - I like my 'admind' idea (then again I would) -
I did like the idea of a Win32 (i.e. 95 / NT ) front end, but I'm starting to
go off it a bit in favour of 'Java' (OK, I know, don't hit me too hard) - as
it will look 'similar', but be runnable on Unix itself (which is probably a
big plus ;-) and hopefully someday we'll have a nice FreeBSD setup that boots
off a CD straight into a VGA x-server with Netscape running, and off you go (I
wouldn't like to see the text install disapear however)...
Of course admind could just end up being a rather glorified rexec with better
security, and the ability to inform the client about how to gather and present
information, as well as execute the commands?
So, what next?
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.
>
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34D0E8F9.CCE51F59>