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