Re: Choosing an infrastructure tool

[added ark-dev list, as I hope to cyrogenically freeze
ark-users for a while, soon...]

Joel writes:

> Stepping back, I want the site-wide ordered installations of isconf 
> combined with the collected application-specific wisdom captured in Arusha 
> and SEPP.

(Incidentally, well-described and nicely put.)

If you look at the itches being scratched when these tools
were developed, I suspect it will be clear why they do what
they do :-)  Certainly on the Arusha side...

I'm on the "technical computing" side of the world.  I had
about twenty Unix boxen of four platforms (don't ask...),
with a rich and constantly changing tool mix (at least "many
dozens" of tools).  I wanted an engineer to be able to sit
down in front of any box, and it would look like any other
(tool-wise) and everything would Just Work (TM).  Of course,
I also wanted to manage the
what-sysadmins-mean-by-configuration stuff
(e.g. /etc/resolv.conf, automount maps, etc.) in some
unified way (i.e. not using a different tool for each
platform).

Note that a lot of the "configuration" stuff is expressed as
"packages".  While 'bison--1.34' is a package in the obvious
tool sorta way, 'sudo-config' is the package that gets a
correct /etc/sudoers onto every box, 'findutils-config' has
the smarts to generate indices for 'locate' every night,
'net-config' generates /etc/hosts and a bunch of other stuff
for every host, and so on.

The business of taking a machine from cold metal to
integrated into the network came up maybe twice a year.  So
I did it by hand.  Couldn't justify the effort to do it
otherwise (even if I would love to have a few weeks to play
with JumpStart, Kickstart, Ignite/UX, Debian FAI ... :-)

If I *were* to do something like JumpStart, I'd [beware
hand-waving ahead...]:

* Have a package (jumpstart--N.M) that simply puts the
  JumpStart software in place.

* Have another package (jumpstart-bits--N.M ?) that snaffles
  all the Solaris and other bits off of Sun CDs and puts
  them where they need to be.

* Have yet another package (jumpstart-local ?) that defines
  my local scripts and Stuff (TM) used in my own JumpStart
  world.

* A final package (jumpstart-config) of bits and pieces that
  tie things together; possibly e.g. inetd settings for a
  tftp server, a script for /etc/init.d, ... whatever.

* The above split into packages is arbitrary, and needn't be
  exactly that way.  The idea is simply to be able to change
  one piece of the puzzle (e.g. the precise release of Solaris
  being JumpStarted) without doing the whole thing over.

* Then, over on the ARK hosts side, you would give enough
  information so that a particular host could be
  jumpstarted.  So, the needful IP address for host 'foo'
  might come from an <ip-addresses> field in foo.xml;
  whereas the needful DHCP server, being the same for all
  hosts in a lab, would come from 'labhost.xml', where 'foo'
  has 'labhost' as one of its prototypes.  (There are a few
  common Arusha idioms for this kind of "commoning up".)

* All the info needed should now have been specified.

  As you would probably have <constraints> from
  jumpstart-config back to the other packages, you'd then
  type

  $ ark package reveal --interactive=yes jumpstart-config

  and it would sail through the work :-)  (The
  --interactive=yes is a *guess*; I suspect the method that
  asks you to change the CD would need to be marked
  'interactive'...) 

* Walk to a machine, jumpstart it; get a cup of coffee.
  Depending on what you specified in the mess above, you
  might subsequently do an 'ark package reveal ALL',
  or something else of your choice.

If I were going to use isconf to do the
cold-metal-to-vaguely-sane step, I would (similarly) have an
isconf--3.x package just to put the bits in place, and
isconf-config to capture my local settings/hacks/etc.

[Incidentally, the 'install' method in doing Sidai-style
package corresponds to "create a gold-server copy".  I
personally would *love* to see the subsequent per-host steps
('deploy' - get the bits onto each machine, and 'reveal' -
make it "live") be handled by something like cfengine.]

Good question; hope this helps.

Will

PS: If you are going to be at LISA (and I hope you are :-),
and interested in this kind of thing, I hope to talk to you.
I will even humiliate myself again and wear a Jimmy Wig, for
Obvious Identification purposes.

PPS: I will re-iterate my non-proudness :-) for writing Yet
Another Multi-Platform package manager; the choices weren't
good when I was looking four years ago.  RPM -- fine, but
ever tried to get a set of multi-platform friendly .spec
files?  Zoularis - if it worked, it would be just *too* cool
to have access to the NetBSD ports tree; but it was brittle
at best.

There are other choices now (e.g. OpenPKG,
http://www.openpkg.org/), but I haven't played with them.
I am near-certain any package manager could drop in to
replace our homebrew one.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf