Re: SA-ML anyone? (oh so very long)

Roger S writes:

> ... I thought I'd throw my $0.02 in, as well
> as about 19 years of Unix (TM) experience :-).

Hey, Roger, thanks for the post; as a comparative newbie
(I'm at 18 years :-), I'll chip in a few remarks.

> I don't intend this rather long diatribe to be taken as a
> flame or an "Anti-ARK" thing.  Just one old man's opinion:
> 
> ARK really needs to be simplier for a real world Sysadmin to use it.  
> Most sys-admins write their stuff in good ol' Bourne Shell. Why?  It's
> simple.  For me, if I do more than 5 lines of Bourne, I want to haul out
> Perl.

Yep.  That's why the method to create a directory to build a
package in looks like...

   <mkdir-build>
     <param name="MKDIR_P">@proxy-host:MKDIR-P@</param>

     <code once-per="site"><![CDATA[
   # create the directory in which to build the package
   [ -d $PKG_BUILD_DIR ] || $MKDIR_P $PKG_BUILD_DIR
   ]]></code></mkdir-build>

Ignore the hair -- the business end is a one-line /bin/sh script.

Now, you may rightly say, "Well, lose the hair then."  But
you can't, to do what ARK is trying to do, namely *tie
together* in some coherent way how all those little scripts
fit together!  It also says that the script only needs to be
run once (once-per="site"), and it provides for "mkdir -p"
being different on different platforms.  If you're really
trying to do what ARK is, that stuff can't be wished away.

> I looked at ARK, and decided it was too complex to understand in
> under an hour.  ...

I simply don't believe such a thing is possible for this
class of thing/tool, namely the "automate things for a whole
site".  As an absolute utter bare minimum, you've got to
enumerate the hosts in play (or describe how to start up the
"host discoverer").

Then, depending how far you move up the paranoia scale (and
I'm only about half-way :-), you may want to say "use *this*
compiler", "use *that* version of OpenSSL", and so on.  (The
"use any old thing, and hope for the best out of what's in
/usr/local" doesn't cut it for me; but there's nothing in
core ARK that forces you to agree with me!)  Since you will
inevitably have to thing about some of these questions -- in
particular when some of your choices bump into each other in
unexpected ways -- it isn't going to take an hour.  Not with
ARK, not with cfengine, not with anything.

> But I still want to have an object model that takes things
> into account, like:
> 
>    OS dependancies (the difference between Solaris 7 and Solaris 8)
>    Machine dependanices (I'm running on X86 or Sparc)
>    Normal site configuration (yeah, put it in /usr/local...)
>    For this group of users/hosts (maybe hardware dependant)
>    Options I generally want for this package.
> 
> I, as a sysadmin want NOT to have to think about:
> 
>     Does this type of machine use gcc, or cc, or ????
>     What libraries does this package need?
>     Is it Solaris or AIX?
>     Where are they on this class of box, or this particular box?
>     I have this special group of boxes, what are the exceptions?
>       (I only want to define that once).

I think we can cover all of this kind of stuff.

> For example, I want to really say to something:
> 
> 	"Hey.  Take this Gnugrep package and install it on all machines"

% vi $ARK/myteam/package/grep--2.5.1 # mine is six boilerplate lines...
% ark package reveal grep--2.5.1

> or maybe:
> 
> 	Install this Foobar patch for me (obviously you need Foobar
>         on the box in question, but I don't want to think about it).

% vi $ARK/myteam/package/sun-patch-Foobar.xml # slightly more boilerplate...
% ark package install --dangerous sun-patch-Foobar

(uh, that does the patch on all hosts that require it)

> I don't want to write translations.
> I don't want to write code unless I have to.
> I want to understand the model quickly:
> 
>     A simple object base
>     Look at Java/C# as a "pattern" for OO languages.
>     With polymorphism, inhertiance, etc.

We would like to think that our "prototype-based" object model
is about as simple as you can get.  (I daresay *way* simpler
than what you suggest.)

As you have seen in recent discussion on this list, we're
musing very casually about how to move forward, perhaps to a
different/better model.  I have been surprised, frankly, at
how well the existing model works.  I am still trying to
discover the idioms that it supports.

> I want class libraries, I can just install without thinking (e.g.
> Solaris 7 vs 8).

Well, we call them "prototypes from a bigger team"
(e.g. Sidai), but it serves the same purpose.  We could do
better.  Note that all the things you *don't* want to
specify (what compiler, use /usr/local, dependencies, etc.)
are Very Fine items to put in prototype objects.

It is Very Important not to confuse "what ARK can do" with
"what the Sidai lads have as their way of doing things".

> It has to be ROBUST!  And not screw up my boxes... a bad tool is
> worse than no tool.  Think transactions like a database.

Agreed; I am also interested in whether simple-tool (as now)
plus certain-work-practices can get you there, or close.
So, for instance, instead of having some mondo-ultra-hairy
"transaction" support in ARK, try to make all package
installs have a <verify-install> method, so that if you get
past the install step, you at least know your package isn't
entirely brain-dead.  It might be enough.

> Doesn't need to be in XML.  It's OK, but concentrate on the WHAT you
> want ARK to become before you figure out HOW it's to do it.

Agreed completely; I am slowly accumulating a list of use
cases that aren't really as I would wish.

Have I mentioned here that there will be a "configuration
workshop" on the Sunday before LISA proper (notices below),
and there will be some Arusha presence?  Should be interesting.

Keep the good thoughts coming!

Will

=== workshop ===========================================

Configuration Workshop
Sunday 3rd November
Paul Anderson, University of Edinburgh
Alva Couch, Tufts University

Specifying the required configurations for large numbers of
interconnected machines, and automatically installing those
configurations to produce reliable clusters, has been been a important
topic since the very early LISA conferences. Automatic tools are now
essential to anyone who wants to manage more than a few machines
efficiently, and to have confidence in their correctness and security.

A number of tools such as cfengine and LCFG have become well
established and we now have a better understanding of the
problems. There is also a growing demand to manage bigger and more
complex clusters for applications such as Grid computing. This
workshop is intended to look at some of the difficulties in using
existing tools, and to examine requirements and ideas for the next
generation of configuration systems.  The workshop will build on
experience of previous workshops such as the cfengine workshop at LISA
2001, and the Large Scale System Configuration Workshop
(http://www.dcs.ed.ac.uk/home/paul/wshop/).

The workshop will be a mixture of short presentations and informal
discussions, and active participation will be encouraged.  For an
invitation, send a short email to [email protected].  Please
include a brief description of your areas of interest/experience, and
indicate whether you would be prepared to make a short presentation.

=== LISA ===============================================

Date: Wed, 14 Aug 2002 19:34:23 -0700 (PDT)
Subject: Invitation to LISA: 16th Systems Administration Conference (73794)
From: [email protected]

Dear Colleague,

I'd like to invite you to attend the 16th Systems Administration
Conference and Tutorial Program (LISA) taking place November 3-8 in
Philadelphia, PA.  http://www.usenix.org/lisa02/

To keep pace in this rapidly evolving Internet culture, the informed 
professional must commit to continually learning new skills.  LISA 
offers over 35 tutorials, taught by expert practitioners and noted 
authors, that help you stay ahead of the latest techniques and 
technologies, including:

* UNIX, Solaris, and Linux system administration
* Performance tuning, disaster recovery planning, SANs, massive
upgrades, user request management, and other service challenges
* Monitoring, intrusion detection, firewalls, and Web security
* DNS administration and practical wireless networking

LISA's technical program also offers innovative solutions to current
challenges.  Learn from expert speakers, including:

- Keynote: Jim Reese, Chief Operations Engineer of Google, on
Google's architecture and the challenges of running an Internet
search service
- Paul Vixie on Internet governance, peering, and legislation
- Curtis Preston, backup guru, on streamlining backup and recovery
- Len Sassaman on "the promise of privacy"
- Tim Nagle of TRW on his years with the NSA Red Team
- Daniel V. Klein on the constitutional and legal arguments against spam

LISA continues to provide an integrated experience for all attendees. In
one place, you can:

- Evaluate new approaches to automation, monitoring, security, and
the evolving theory of system administration (among other topics) in
the Refereed Paper sessions
- Find people with similar interests or administrative problems at
Birds-of-a-Feather sessions
- Bring your perplexing technical questions to experts at LISA's
unique "The Guru Is In" sessions
- Explore the latest commercial innovations at the Vendor Exhibition

Please join us in Philadelphia and lend your skills, experience, and
opinions toward forging an exciting future for the profession.

For complete program information, and to register visit:
http://www.usenix.org/lisa02/

For the LISA 2002 Program Committee,

Alva Couch, Tufts University
Program Chair

================================================================
If you do NOT want to receive email announcements about USENIX
and SAGE activities, please reply to this message, and you will
not receive future email notices.
================================================================


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390