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

[Evan Simpson]

Yipe.  This is a great big pile of interesting ideas.  You may want to start
a Zope-sysadmin SIG :-)

Will Partain <partain@dcs.gla.ac.uk> wrote:
> Folks, I'm musing on an idea for "collaborative Unix system
> administration"
[snip]
> ... 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.
[snip]

Sounds like you're envisioning a site-wide linuxconf-like toolkit on the
scale of the Zope Portal Toolkit.  Take a pre-made set of ZClasses and use
them to simultaneously document and instrument your administrative
procedures and site assets.  What sort of relationship between sites do you
have in mind when you talk about inheritance, though?  Only sites within a
single division or organization, say?  I can only picture using part of
another site's administrative setup on my own if that site has somehow
defined generic Policies and Procedures which can act on/be assigned to
standard toolkit elements, similar to users/roles/permissions.  That sort of
design would of course be valuable in its own right.

> But I have Zope Doubts (sorry :-).  These include:
>
> * I definitely don't want through-Zope-only admin; I still
>   want a command-line interface (CLI)
[snip]

The Zope monitor and Client.py may help here.

> * There is so much Zope stuff I don't think I need; e.g.
>   the "connect to SQL (or any other) database" stuff.
[snip]

So leave it out :-)

> * I would rather do my own configuration management (version
>   control, etc.), with CVS/ClearCase/whatever.  Partly, it's
>   the politics in any CM-aware organization -- "sorry, I'm
>   not using the normal CM tools around here; I've got this
>   versions gizmo inside of Zope instead..." -- won't fly.

I'm sure that a contributed CVS storage product would be welcomed by
everybody.  If there's enough interest (or $$) in the community, it'll get
done.  Perhaps the Zope community should coopt CoSource or SourceXchange for
these sorts of wishlist items?

>   But mostly, what if I want to say "roll back the Solaris
>   boxes to the STABLE_1_3 release"? -- I feel confident
>   that kind of stuff can be built on CVS/CC/whatever; I'm
>   jumpy about Zope.

Zope could *really* benefit from some elaboration in its versioning
facility.  The ability to maintain a tree of labeled branches of development
the way CVS does, with checkouts and checkins and branch merging and 'patch
diff' exports and the ability to archive out old versions instead of just
packing them out of existence and then say "give me the Data.fs for
STABLE_1_3" and ... well, there's a lot of potential there.  I'm not
volunteering, though :-/

> * I'm not sure how/if Zope helps me w/ the "do across all
>   hosts" parts of the sysadmin problem; e.g. "change
>   /etc/exports on every NFS-serving host and run exportfs
>   -a, or equivalent"... Do I put a Zopey server on every
>   host and have them talk to each other?  Or what?

I picture an inetd-based daemon which talks XML-RPC (preferably written in
Python) installed on each host.  With something similiar to PythonMethods,
you might even be able to write methods in Zope and push them out to the
hosts.  Security issues here are critical.

Evan @ 4-am