[prev] [thread] [next] [lurker] [Date index for 2003/08/19]
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