"collaborative Unix sysadmin" -- is Zope the right tool?
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! "Collaborative Unix sysadmin": better explain what I'm on about. Think about Unix sites with, say, 100 hosts, of more than one flavor (e.g. Linux+Solaris). A good sysadmin "adds value" to the site in all sorts of ways: configuring printers, installing packages other than the vendor-supplied ones, designing/implementing a backups strategy, writing Web pages to explain "where things are", etc. Problem #1 is that a huge fraction of this "added value" may reside only in the sysadmin's head, and, if the proverbial bus runs over him/her, then ... So, solution(s) #1 is to have *systematic* ways to record/implement the value added. 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... 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. 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? So this is where Zope might come in. It's object-, Python-, and XML-friendly. By always presenting "added value" via a (search-friendly, index-friendly, ...) Zope-generated page, it becomes more accessible than just a big pile of *.xml and *.py files! From there, it is but a short step to *doing* sysadmin over the Web, perhaps remotely (scary, but...). And the "added value" you want to "inherit" from your friendly neighbor is now just a URL away... sounds good, no? 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), and to be able to concoct ad-hoc scripts out of my .xml/.py pile. (Perhaps xml-rpc rides to the rescue? -- with it, we can suck on any Zopery from a CLI; but isn't that pretty heavy-handed for a simple task like "list-site-hosts"?) So, though I like the look of Zope transaction- and security-ish stuff, I'm not sure how I could make use of it in CLI land... * I would like what comes *out* of my .xml/.py pile to be XML also (as well as making the .py *do* stuff). To a big extent, my Zope stuff would be mere presentation of that XML. Reasonable? * There is so much Zope stuff I don't think I need; e.g. the "connect to SQL (or any other) database" stuff. * 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. 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. * 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? Recap: I need a tool to help (at least) with *presentation* of Unix sysadmin "added value", across collaborating mid-size installations. I like objects/Python/XML. How should Zope fit in the picture, if at all? Thanks, Will PS: Thanks to Jim Rowan and Jonathan Hogg for helping me organize these thoughts; sillinesses/brain-fades/etc mine.
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
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
participants (3)
-
Evan Simpson -
Pavlos Christoforou -
Will Partain