Re: System administration tool

[Dave Stagner <dave spnz org>]

On Fri, Apr 09, 1999 at 11:20:27PM -0400, Havoc Pennington wrote:
> 
> Sounds super-cool. I think the real key to something like this though,
> much more important than the implementation, is getting everyone on board.
> That is, we need a configuration engine used by all the Linux
> distributions, and ideally one that various pieces of software (such as
> Gnome) can use directly.

I'm glad you like it.  :}  And i agree, this is something that
(assuming it works out and isn't just vaporware) i would like to see
as a standard for Linux distributions, and useful for other unices as
well.  I think the real heart of my design is the XML configuration
files.  The client and server code can change to scratch various
itches, but the XML provides commonality and interoperability.  The
specifics of my own client and server (local only, GNOME) are for my
personal biases about how i'd like to see it used.  I don't want to
design the configuration files in a way that limits other
implementations.  
 
> Wichert Akkerman (Debian project leader) has a specification in mind for 
> a similar client-server setup:
> 
> http://www.debian.org/~wakkerma/config6/
> 
> I think there's also been some talk of using the same setup to replace
> gnome-config sooner or later. 

Interesting work, but i think he's working on a different aspect of
the problem than i am.  Not that there needs to be any conflict, of
course.:}  My interest is largely in a mechanism for non-root users
to securely execute a limited set of root commands via a single,
flexible gui, without needing either root password or suid.  
 
Here are a couple of other design bits i missed in my first
post... first, each "module" (interface?  Dang it, i need a good word
for this) will have its own unique directory within the configuration
directory.  Things like gifs and scripts can be put there directly.
Modules can be shipped as tarballs, rpms, etc, and installed through
the gui itself.  

Second, the client would use a url-like path for connecting to the
server and loading modules.  For example, mad:/user_manager could
point to a user manager module on the local server.  For network
clients, mad://foo.bar.org/user_manager could bring up user manager
module on another host (authenticating via NIS or LDAP?).  

Third, the XML data stream from server to client could either be a
flat file (like an html file) or program-generated (like cgi).  For
example, a simple password-changing program could send a flat file
asking for the old password and the new password (twice), and send
the three responses as parameters to a server-side Expect script that
runs 'passwd'.  The user manager module, on the other hand, would
start by running a script that returns a table of all the users on the
system.  Clicking on a user name could bring up another form to modify
user information.  Or, click on a "new user" button, and a different
form pops up, to get parameters for 'useradd'.  

So right now, i'm not thinking in terms of configuration management.
But a well-designed, consistent set of modules could (and probably
should) be tied to a configuration management system.

> Anyway it would be great to get everyone working together on this
> thing... I'll forward Wichert your email for you. :-)

Good thinking.  Thanks!

-dave

-- 
Practice beautiful randomness and act kind of senseless.