Re: configuring...

> > I'd like to find a way to massively simplify ARK configuration.
> 
> 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.

Yes, please forgive me.  I meant ARK-sidai configuration.

> 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...

Perhaps - I look at "sidai" as a collection of "best practices" that will
support multiple choices where appropriate.  I'm perfectly happy to have
sidai support things I don't use, or only use for certain smaller teams.

For example, I'd be happy to see a GNU team that has as close to all of the
GNU utilities listed in it.  At some point, some other policy team decides
whether or not the 'g' prefix needs to be added, or if all of the gnu
utilities will be installed (deployed?) under /usr/local/gnu/ .

I would expect Some Other Team Mechanism to let me specify that I don't want
*all* of the GNU utilities installed and let me select what I want.  I would
expect that the GNU team would have specifications for several/many
different versions of *each* GNU utility.

Think of the FreeBSD (and probably *BSD) ports collection.

> 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.

Examples, please?  And I'm wondering if things you think are not Sidai-ish
are still generally useful and could be distributed and easily incorporated
by folks who may want that framework.

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

I want a framework that supports as much of the heterogeneous SysAdmin
"tasks" as I can throw at it:

- package deployment customized for each user population (admin, DBA,
  developer, Q/C user, email server, virtual websites, ...)
- package testing and updating
- user account maintenance/access control
- machine configuration/setup and software upgrades
- DNS configuration and maintenance
- printer config maintenance
- ...

> 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?

They should be able to create a "subteam" (like the GNU subteam) and use
it.  If they choose, they can share it with others.

> > 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.

I want ARK/sidai/whatever to replace the SAT stuff, which has a "database"
of hosts (machine, OS type, disks and layout) and users and ...  There are
two ways to use this - "bootstrap" mode, and "ongoing maintenance" mode.
The SAT "hosts" database/relation will spit out /etc/hosts, the DNS config
files, the disk mount and export tables, etc.

> > - 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?

I think autogen is close, that and maybe automake/autoconf.  I'm also
perfectly happy with small text files that are EASY to edit (the .xml files
I've see ARK use are too complicated IMHO).  For example, a script could be
written that, given a list of hostnames and the "teams" that will use that
host, the bootstrap script could query each machine for the OS type and then
generate the ARK/sidai/localteam databases and then the various .xml files.
After the bootstrap, ARK would be able to keep these things up-to-date.

> > 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 -'
> 

"rsync" could also do this, right?  And if /{.-ark-deploy,our} was "built"
to a shared directory, all installation could be done using rsync and ::
rules, right?

> 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.1
> 6.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-spa
> rc-solaris2.6
> 
> Am I reading you right?

Yes, thanks, and I gather that for folks who don't mind NFS sharing, either
or both of /.-ark-deploy and /.-ark-install-sparc-solaris2 could be
automounted via multiple paths for failover/redundancy.

> > 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.

Agreed...

H