Re: configuring...

Harlan writes:

> I'd like to find a way to massively simplify ARK configuration.

Harlan, good subject :-( Not that I have any great ideas, or
we woulda tried 'em already.  Jonathan's your man, I'm
guessing...

My biggest difficulty is philosophical: ARK is supposed to
be policy-free.  You are talking about full-bore
manage-the-whole-site Sidai-style ARKing (which is what I
do, too), but that's *entirely optional* in ARK land.

For example, I think one of the sanest uses someone could
make of ARK would be simply to build /usr/local/gnu for a
multi-platform site.  No fancy install->deploy->reveal;
basically just 'make install' into a NFSified /usr/local.
Not all packages on the planet, just the standard freeware
stuff. Now, that's pretty far from Sidai land...

I could easily list another 10 Very Good ARK Setups, some of
which might not have anything to do with "packages" as we
normally understand them.  Again: nothing Sidai-ish.

So when we want to be better at "configuring", the question
is: Configuring *what* and for *whom*?

If we do lots and lots to help people do full-bore
Sidai-style ARK-for-everything (and I am not sure there are
*that* many people who want to do this...), what about
people who choose otherwise?

> I'd like to be able to configure my team(s) by providing:
> 
> - a way to specify the "covered" hosts
> - - /etc/hosts?
> - - DNS?
> - - something else?

In the contexts I can imagine, I'd probably do it with
'perl-script < /etc/hosts', populating my host/ dir with
.xml files.  I still think you'd need to edit them
afterwards, to fill in the prototype relationships.  (Unless
your /etc/hosts happens to encode things like "a lab
machine".)  Have been there before: the scripts
sidai/dchunk-utils/*.sample do comparable things to populate
a dchunk/ dir from /etc/fstab and /etc/auto_* maps.

> - a way to specify the ARK-specific directories
> I'm thinking about using autogen to do this, at least at first.
> Any ideas?

No ideas; but a question - is there any freeware thing
around to build "wizards"?  Would something like that help?

> While we're on the subject, I'm wondering how the
> ark-built software for a particular architecture gets
> deployed(?) on each machine.  Is it:
> 
> - built on each machine?
> - installed from a shared build tree?

Confession time: What I tend to do... Assuming 'oldbox' is
fully ARKified, and 'newbox' has just had a fresh OS install
on it, and they are the same "kind" of host.  I then do
[ignoring symlinks]

   oldbox% cd /
   oldbox% sudo tar cf - .-ark-deploy our \
	   | ersh newbox 'cd / && /usr/local/bin/sudo /our/bin/tar xf -'

This is what is commonly known as "cheating" :-)  Then, for
'newbox':

   % ark package reveal --hosts=newbox ALL

That's called "making an honest computer out of `newbox'".

> If the latter, I'm thinking that it might make sense in
> some environments to do the "official" building of
> software to an NFS-shared area (for example), and then
> hosts can deploy from that area if they want local copies
> of the packages, or NFS (for example) mount the packages
> if they are relatively diskless machines.

This is exactly how Sidai stuff works (normally).  For
example, my revealed 'groff':

  /our/bin/groff -> /.-ark-deploy/groff--1.16.1/bin/groff

And that 'deployment'...

  /.-ark-deploy/groff--1.16.1 -> /d/.-ark-install-sparc-solaris2.6/groff--1.16.1

And what is that partition?

  Filesystem            kbytes    used   avail capacity  Mounted on
  slimy:/._disc2/d/.-ark-install-sparc-solaris2.6
                     16949176 13358648 3421032    80%    /d/.-ark-install-sparc-solaris2.6

Am I reading you right?

> Going further, I'm thinking that perhaps the sidai style
> of teams need not be the 1 way to do everything, but could
> handle "choices" when appropriate.

Absolutely.  I *desperately* don't want Sidai to be the only
way.  I would love to have an ARK team that *hated*
everything Sidai (!) and built up a set of .xml files that
express what *they* think is Good System Administration.

Within Sidai, we can use the <param> stuff to allow for a
few choices, where we think reasonable minds might differ.
But I don't planned to get carried away.  Sidai is supposed
to represent *a* (not *the*) coherent way to do sysadmin.
Don't like it? -- join/start another team.

Let's keep ye olde brains working...

Will