Solaris Jumpstart AFS install
Nathan Neulinger
nneul@umr.edu
Mon, 16 Apr 2001 20:04:56 -0500
We do something very similar - our O/S installation philosophy is to use
the base O/S installer and facilities like 'jumpstart' or Ignite or
NetInstall or KickStart/etc. to get just enough functionality on the box
to support rdist.
Once that is done, we have a fully automated web interface for
completing the system installation with rdist packages.
Our rdist packages are each composed of common, os, os-version,
os-version-arch, host-specific components, which are each optional and
applied in that order.
-- Nathan
Russ Allbery wrote:
>
> Noel Hunt <nhunt@lehman.com> writes:
>
> > Our experience with Jumpstart has been that the more we can avoid
> > using the Solaris package format apart from the actual operating
> > system, the happier we are. We do all installation of this sort
> > of thing, including the AFS client, using postinstall scripts.
>
> > Before one is reduced to mumbling something about tradesmen blaming
> > their tools, some examples please?
>
> I'm not sure what you're looking for examples of. The reasons why we
> chose that approach are:
>
> * The postinstall scripts are then usable on other operating systems as
> well, at least in part (if well-divided between the OS-specific parts
> and the OS-independent parts). Solaris packages aren't. That makes
> the code more reusable and easier to deal with.
>
> * We can find a lot more sysadmins who can understand shell scripts (or
> in our case bundle scripts) than sysadmins who understand how to
> modify and regenerate a Solaris package.
>
> * I *do* know how to build Solaris packages and would prefer to never
> have to do so again, since the packaging format is, IMO, gross.
>
> * Despite the theoretical advantages of a packaging format, using the
> Solaris package format offered us no actual benefits in practice, since
> none of the theoretical advantages like versioning were actually
> interesting. (I can much more easily tell what version of AFS client a
> machine is running using rxdebug than by trying to query Solaris's
> package database, for example.)
>
> Not all of these points may apply to all installations.
>
> We used to use Solaris packages, and points two and three above bit us
> badly. The situation slowly degenerated to the point where the two people
> on our group who understood Solaris packages had to make *all* of the
> changes because no one else wanted to touch them. That was even with
> makefiles in place to do the work of building the package; the problem was
> that one still ended up with an undebuggable black box unless one
> understood the Solaris package format. I slowly replaced all of our
> Solaris packages with postinstall scripts that use a simple
> locally-written file installation tool called bundle, and I'm happy to
> report that quite a few people are now helping maintain our Jumpstart
> packages and all the work isn't on the shoulders of the people who know
> Solaris packages.
>
> If I thought that Solaris's packaging format had any real future, I might
> have a different opinion and encourage other sysadmins to learn it as a
> skill; however, given the existence of (IMO) massively superior package
> formats like RPM and Debian's dpkg, my *personal* opinion is that
> Solaris's packaging format, just like HP-UX's swinstall packages and
> IRIX's inst packages, is an evolutionary dead end, and would encourage new
> sysadmins to not waste a bunch of time learning its intricate details.
>
> --
> Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
--
------------------------------------------------------------
Nathan Neulinger EMail: nneul@umr.edu
University of Missouri - Rolla Phone: (573) 341-4841
CIS - Systems Programming Fax: (573) 341-4216