how can i hate it? i can't even install it.

[prev] [thread] [next] [lurker] [Date index for 2003/08/19]

From: mjinks
Subject: how can i hate it? i can't even install it.
Date: 00:01 on 19 Aug 2003
So, I'm the JumpStart gimp in our shop.  For those who haven't had the
pleasure of hating JumpStart, it's Sun's software for automatically (HA!
Ha ha, ha!) setting up Solaris.  When it works (ha!), it saves loads and
loads of time and even more aggravation.  Having set up jumpstart over
the past months-and-months, I wonder how many machines we'll have to let
it install before we start to see a positive return on the time.

But I did not come here to hate JumpStart, nor Solaris, nor any specific
chunk of nasty nasty software; rather, I have come to hate an entire
class of software: interactive installers which don't offer an automated
option of the sort that would let them become part of our happy new
JumpStart regime.

Case in point: Sun's own "Forte" compiler package, formerly known as Sun
Workshop or something else, who knows.  Because it simply must have a
host-specific license key which is generated from an installation key
and some host-specific info, you can't just make a tarball and truck the
same installation out to all your machines at install time.  Oh, no.
You have to drop the distribution media into the box, answer all the
happy questions, drop in your installation key, and let it install all
the files itself, or it just won't work.

Even better: Veritas' NetBackup.  A hateful piece of software if ever
there was one, NBU had to have an installer of similar hatefulness.
Unlike Forte-or-whatever-they-think-sounds-cute-this-week, NBU doesn't
require a license key.  There's no reason why it couldn't be distributed
as netbackup.<platform+version>.<version>.tar.gz, or a SysV-style
package, or whateverthehell.  But because Veritas is staffed entirely by
slope-browed sadists, they made up for this oversight in inconvenience
by writing an installation script.  The script must be run interactively.
Because Bog knows you're not ever going to want to install NBU on every
last machine your operation runs, because after all who would ever want
to back up all their systems, so what's the harm in requiring hands-on
interaction for each and every blasted copy of NBU that your shop sets
up?  And in those few cases where NBU installation might be a good idea
to include in the initial setup of all a site's machines, well, people
will just write expect scripts or something, right?

I hate expect, so now I'm picking through Veritas' chain of scripts
(just one install script?  oh how droll!  we need a chain of them which
call each other!) looking for the point at which they stop collecting
silly environmental information (which will always be exactly the same on
every bogdamn box we run) and actually frickin' /do/ something.  (I
already know that, rather than running tar, or cpio, or pkgadd, or any
of the other perfectly-reasonable approaches to installing software
archives, they call "cp" many, many times on many, many files.)  Then
I'm going to slice off all the fat and include just that part of their
script in our JumpStart setup.

It won't work of course.  There will end up being some reason why every
box we set up must first be JumpStart'ed, then some human will have to
sit down, log in, cd to the NBU source directory, run ./install, hit
three keys, and go on to the next thing.  Meaning that some percentage
of our machines will fall victim to human error and won't get backup
software at first.  I wonder how long before such a machine has a
catastrophic data loss before the oversight is corrected.

Then there's ipf.  I hate ipf, and now that I'm trying to include it in
all our automatically-installed machines, I have new reason to hate it
even more.  Now, if you hate ipf as well, and particularly if you've
hated ipf on Solaris, you might wonder why I mention it here.  After
all, Mr. Reed makes ample provision for distributing ipf as a Solaris
package, so what's the problem?  "pkgadd -d <file> -a <admin_file> ipf
ipfx" and you're done, right?

Well you are if you run that command from an interactive shell, sure;
zips right on through, never bothers the user to answer any dumb prompt.
But run it as part of a script (as in, say, JumpStart) and it dies, with
some moron error like "no TTY set" or some shit like that.  Other SysV
packages don't do that, but who cares?  Why on earth would you want to
automate ipf installation anyhow?  Not like you'll actually want all
your computers to be able to filter unwanted network traffic, after all.

Maybe it's my fault.  Maybe I'm just a luddite who doesn't see the
advantage in having more and more Unix software act more and more like
Windows software, with individual quirks requiring knowledgeable humans
spending their time clicking "OK" over, and over, and over, and over,
and over, and over, and over again.  I'm learning though.  I typed "and
over" manually each time, rather than having vi repeat for me, because
I'm a get-along-with-others kind of guy, and if that's the trend, then
dammit I'm gonna fit in.

*fume*

-- 
Michael Jinks /// "Dumb is good." -- David Champion, Bastille Day, 2003
Enterprise Networks and Systems Administration // University of Chicago

Generated at 14:02 on 01 Jul 2004 by mariachi 0.52