Re: some try-ark suggestions

Jonathan:

   Date: Tue, 12 Jun 2001 18:57:43 +0100
   x-sender: [email protected]
   From: Jonathan Hogg <[email protected]>

   On 12/6/01 15:33, [email protected] wrote:

   >But this is screwy.  Success or failure appears to depend on getting just
   >the right mix of .tar, or .tar.gz.
   [...]
   >I think there is a very real problem here.  You can't depend on the user
   >having just the right mix of package file formats.  Either you must
   >strictly require the package-x.y.z.tar.gz format across the board, or
   >better you code for every reasonable possibility.

   I think this sort of makes sense with regards to how things are shipped. 
   The sidai team is setup to take the tarball *as it comes*. So for 

But as it comes from where?  It might come as .tar from one place, .tar.gz
from another, *.tgz from a third, and so on.

   Traditionally gzip shipped as 'gzip-n.m.tar' since they assumed you might 
   not already have gzip to uncompress a '.gz', but everyone with a UNIX 
   installation should have some kind of tar (on a bare Solaris box this is 
   a good assumption). I took a look on ftp.gnu.org and I see that they 
   offer both now.

And, unlucky me, I chose to download the .tar.gz version.

   >In other words, if the user has, say, the following
   >
   >-rw-r--r--    1 berto    berto     1064960 Jun  9 08:31 gzip-1.3.tar
   >-rw-r--r--    1 berto    berto      332269 Jun  9 08:34 rsync-2.4.6.tar.gz
   >-rw-r--r--    1 root     root      2170104 Jun 12 08:10 textutils-2.0.14.tgz
   >-rw-r--r--    1 berto    berto      287239 May 21 11:19 bison-1.25.tar.Z
   >-rw-r--r--    1 berto    berto      380995 May 21 11:19 flex-2.5.4a.tar.bz2
   >
   >the Arusha code should take this all in stride and just Do the Right Thing
   >in all cases.

   As you say, it would perhaps make sense for the assemble-source method to 
   try to Do The Right Thing if it can't find the source as it expected it, 
   but this isn't necessarily trivial because the default assemble-source 
   method is overidden in various places - gzip being a prime example, where 
   the gzip version doesn't try to uncompress it first.

At the least, you should mention this pitfall in the try-ark FAQ (not that
there is one yet, but we're moving toward having one, it seems  :-)).

In the long run, difficult though it might be, I think you need to devise
some sort of solution to this problem.  I mean to say, sidai develops the
perfect Linux setup, but half of it fails for the (stupid) reason that half
of my file formats don't match?  Or I mix and match sidai with setups from
a half dozen other teams around the globe (eventually).  Most of the builds
fail due to the file format problem?!  (Admittedly, "most" overstates the
case.)

   >Oh, I repeat my assertion that you need to embellish the "Test drive with
   >try-ark" section of the try-ark1.html page with additional commentary.
   >On the face of it, the demo is underwhelming.
   [...]
   >What is sidai's value-added?

   I see what you mean, but I'm not sure what we should say. See, really 
   we're not trying to sell sidai at all, but ARK on it's own doesn't do a 
   whole hell of a lot. So if you want to try it out you have to start with 
   something and sidai is the most developed policy we have.

For the benefit of persons who did a minimal install and don't already have,
say, textutils on their systems, you might then walk them through the
install, deploy, and reveal steps.  This is something real-world useful
that the user might attempt after try-ark.  The minimalist try-ark, sample1
configs are capable of doing this, right?

I'm just saying that after the user achieves a successful try-ark run,
you need to have a response to the question, "So what?"  (Which is different
from the question, "So what next?")

You say that "we're not trying to sell sidai at all".  But, arent't you
sort of?  Arusha is about "collaborative systems administration."  For lack
of an alternative team policy to try, what have I just gained by this sidai
collaboration, if anything?

   I have a question for you: what would you like to do with Arusha? If the 
   answer is you don't know what you could do with it, then I guess that's 
   where we need to start writing. If you have ideas, but you don't know how 
   Arusha might apply to them, then that'd be great too as we can start 
   taking them as case studies to flesh out.

For starters, it would be great if we could get a working Arusha setup this
summer to handle our long overdue sendmail upgrade.  sendmail just isn't my
"thing".  It would be great if the Sidai or Glasgow or some other team makes
available a trusted, well-done sendmail install and setup.

I could mention other open source software packages for which upgrades are
also long overdue.  The ideal of using Arusha to manage a gradual rollout
of the new software sounds appealing.

I would also apply Arusha to certain standard things we do to new machines,
e.g., do local installs of tcpd, the ssh suite, customize various system
config files.

I am also intrigued by the notion of having Arusha handle miscellaneous
administrative issues, like licenses, serial nos., purchase orders, other
vendor "things", things that Will hints at with:

    The point is: the ARK "language" gives you a *single*
    mechanism to manage all the "things" that comprise *your*
    sysadmin task.

As I gain experience with Arusha, I'm sure I could find other useful things
to do with it.

Berto

-------------------------------------------------------------------------------
Robert Osterlund, Unix Systems Manager                [email protected]
Grad School of Business, U of Chicago                       phone: 773/702-8898
1101 E. 58th Street, #309, Chicago, IL 60637, USA             fax: 773/702-0233