[Zope] "collaborative Unix sysadmin" -- is Zope the right tool?

[Pavlos Christoforou]

On Wed, 3 Nov 1999, Will Partain wrote:

> Folks, I'm musing on an idea for "collaborative Unix system
> administration", and can't quite decide if Zope is the right
> tool for (part of) the job, or not...  I throw myself on
> your collective wisdom!

Long time ago I began a 'ditributed monitor' unix adm tool, and after
thinking long about it I decided to skip Zope and build it around
ZPublisher and medusa. I did have a very basic zopish infrastructure,
but everything was based on the unix filesystem. Adding functionality was
very easy, you just had to define a few variables in your __init__ method
and everything was published automatically. It was impressively fast but I
gave up on it because of time constrains. Lately I was given the job of
administering my departments unix servers so I might be interested in
helping but unfortunately after november.

> 
> Problem #2 is that the "added value" of a good sysadmin at
> Site A probably has many *similarities* to that at Site B.
> Without help, you have wheel reinvention on a grand scale.
> (NB: it won't be the *same* because, at the heart of
> sysadmin, you have Immovable Local Realities -- e.g. a
> different printer, different "security guidelines",
> different critical apps, etc.)
> 
> So wouldn't it be great if the sysadmin at Site B could say,
> "I want to do my backups the same way as at Site A, except
> for <detail-1> and <detail-2>?"  Essentially, I'm thinking
> of some kind of "inheritance" of Site A's "added value" by
> Site B's...


They way I had designed it, was to have a set of configuration parameters
defined in XML. Each node registered itself with a main server where they
received the default configuration parameters and you could add/modify per
node. Changes to the main server were propagated automatically to every
registered node. I have the implementation of the XMLConfig file where it
maps the XML configuration doc to a python dict but not the client/server
update part.

> Onwards... Building blocks I already envisage: (a) Encode
> basic *data* about a site -- hosts, users, support
> contracts, packages, how to power-down the mail server,
> checklist for setting up a new account, etc. -- as XML
> documents; and (b) encode basic site *behavior* for all
> these things as Python classes.  I already know this kind of
> thing can be Very Useful.

Yes I agree.


> 
> Where would that leave us?  We now have tools for systematic
> recording (Problem 1) and, if thought through and written
> correctly, we could have some kind of "inheritance" (Problem
> 2).  But we will soon have Problem #3: a site's pile of
> sysadmin "added value" will quickly become big/complex
> enough that it will be impenetrable to all but the original
> author -- and you're back to the run-over-by-a-bus problem.
> And we might want to think about Problem #4: how can
> collaborating sysadmins make available some of their "added
> value" so that others can "inherit" from it?

Here Zope might be a better fit.

<snip- excellent ideas from an obviously experienced unix sys-adm>


Well maybe you should head the zope-sysadmin effort!


Pavlos