From owner-freebsd-hackers Thu Jan 29 12:41:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA14891 for hackers-outgoing; Thu, 29 Jan 1998 12:41:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA14773 for ; Thu, 29 Jan 1998 12:40:06 -0800 (PST) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.8.7/8.8.7) with ESMTP id UAA06998; Thu, 29 Jan 1998 20:39:19 GMT (envelope-from kpielorz@tdx.co.uk) Message-ID: <34D0E8F9.CCE51F59@tdx.co.uk> Date: Thu, 29 Jan 1998 20:39:21 +0000 From: Karl Pielorz Organization: TDX X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: "Jordan K. Hubbard" CC: hackers@FreeBSD.ORG Subject: Re: /usr/src/release/sysinstall needs US. :-)) References: <14682.886103186@time.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe hackers" 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