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