Arusha Project 20040529

The Arusha Project (ARK) seeks to provide a framework and/or tools for collaborative system administration of multi-platform Unix sites with many dozens of machines.

The core ARK developers are interested in using the Arusha Project as a comprehensive solution for system administration.

It is therefore easy to miss the point that the core ARK engine---which simply provides a ``configuration language to say sysadminish things---can be used in many less-than-comprehensive ways.

Here is a ``laundry list... There are undoubtedly hundreds of other weird-and-wonderful possibilities we havent thought of.

Also note that some of these uses are orthogonal to each other. You could pick one (or none) of the ways to tackle software packages and pick one (or none) of the ways to manage the config files in /etc and pick one (or none) of the ways to manage user accounts, etc. -- this gives you many ARK options, without even breaking a sweat.

1. As a multi-platform package manager for user applications, particularly standard freeware packages.

(We arent pleased to have written Yet Another package manager, but the others [RPM, BSD ports, etc.] just arent up to much when you have several diverse Unix platforms for which you want the ``same packages.)

(Other system administration would be done by other means.)

2. To provide an early-adopter `playpen: [a variant on #1] at a site of any size, you will have a small number of people keen to try out beta- and even alpha-quality software. (It is wise to let them do so---they accumulate much ``intelligence which is helpful when deciding about new software to roll out to the general user population.)

You could use ARK to set up a `playpen where early-adopters could do their trials in a controlled and non-problematic way. (The Sidai version wrapper stuff is one way to get a handle on the multiple-versions-live-at-the-same-time problem.)

3. As a `unifier for diverse package managers: Imagine you have a site of Solaris, Linux, and NetBSD boxes, .and you want to use the native package managers for each. But you want the ``same packages on all hosts, and want a site-at-a-time way to manage them; i.e. ark package install ALL should install all packages on all hosts, each in the appropriate way.

4. As a (binary) package producer: One can imagine having a small number of ARK hosts whose job is to produce (say) binary RPM packages of everything of interest to your site. Your (many?) client/production hosts would then simply use the RPMs.

5. As a front-end for Cfengine or PIKT, or similar: Express what there is to know about the hosts, etc., at your site in the ARK object way (including constraints between them), then push a button to generate a configuration for one of the established sysadmin tools, which will do the heavy lifting for you.

6. As a fancy `rdist: A Unix site has bunches of config files that need to be ``the same across many machines, e.g. /etc/hosts or /etc/resolv.conf. The distributed ARK code (notably from team Sidai) is a good way to do this stuff, and you might use ARK just for that.

7. As an `idea bank: Dont run ARK code at all; simply study others sysadmin solutions as a source of ideas. This is a pathetic choice in our view :-), but entirely legitimate!

8. Toss it for system administration and build chip designs with it, instead! (While this is a mostly-facetious suggestion, it reflects the fact that the earliest ARK ideas emerged alongside some chip-building ideas at Glasgow University in 1999.)