I thought Bill Walker made a good start but here are some examples from an
in-progress effort at a major customer:
A) install a reduced subset of Solaris
B) install Solaris patches
C) install various third party software packages that come in Solaris packages,
tar files or a script that installs the product (and may contain the
product itself).
D) Patch installed products where patches are Solaris style patches or simply
new
executables replacing old executables.
E) Harden the system to meet customer security requirements where hardening is,
at a minimum, turning off services and modifying system files and
directories.
F) Add system tuning
G) Configure Solstice Disk Suite
H) Configure zones and resource pools and install the zones.
Customer likes the idea of flars in that they save time during the installation.
The reduced subset of Solaris reduces patching time and zone installation time.
Jim Litchfield
----- Original Message -----
From: Glenn Lagasse <[email protected]>
Date: Wednesday, March 25, 2009 11:11 am
Subject: Re: Does the AI opensolaris autoinstallation have the post script
just like the postscripts in the jumpstart
To: Lubomir Sedlacik <Lubomir.Sedlacik at Sun.COM>
Cc: Casper.Dik at Sun.COM, "Eric J. Ray" <Eric.Ray at Sun.COM>, Jon.Aimone at
Sun.COM, luke woo <Shenglong.Wu at Sun.COM>, desktop-discuss at
opensolaris.org, nv-users at sun.com, nv_re at sun.com
> * Lubomir Sedlacik (Lubomir.Sedlacik at Sun.COM) wrote:
> > Casper.Dik at Sun.COM wrote:
> >>> No, at this time those do not exist. That's deliberate. In many
> >>> (most) cases, Jumpstart finish scripts exist to work around gaps in
> >>> the feature set or implementation. We want to understand what the
> >>> real requirements are and build those into the product.
> >>
> >> Don't try that; after reading a large part of the AI opensolaris
> >> autoinstallation documentation I can only conclude that people have
> >> read the jumpstart installation but they have no idea how jumpstart
> >> is used in practice.
> >>
> >> First of all, everyone who uses jumpstart in a large environment
> >> doesn't actually need to do anything when a new client is installed.
> >>
> >> Secondly, in a past live, I used the begin/finish script to customize
> >> *everything* in a system.
> >
> > Seconded.
> >
> > E.g., at Solaris System Test we perform several hundreds of
> different
> > JumpStart installations (and upgrades) every week on a lab of ~400
>
> > machines. Install begin/finish scripts give us the flexibility to
>
> > implement any customization we need, often being creative to work
> around
> > bugs in various development builds which actually allows us to
> install
> > the system and don't just pronounce the build dead in the water and
> drop
> > testing. This functionality is absolutely essential for us.
> >
> > Lack of begin/finish script functionality would have a huge impact
> on
> > productivity of many teams in the company, forcing them to implement
>
> > various home brew workarounds since their requirements are unlikely
> to
> > change.
>
> So, what exactly are people not understanding when we (the install team
> working on this stuff) say 'provide us with concrete *requirements* of
> what you *need* and not what you want'? And saying 'we want jumpstart'
> doesn't count. Technology changes and moves on (and hopefully evolves
> and gets better).
>
> The lack of begin/finish script functionality *may* have an impact on
> teams if we don't actually provide some other mechanism that
> accomplishes the same tasks that people have been using the begin/finish
> script functionality in jumpstart for. But until we get people to 'look
> at the problem objectively' and provide us with useful data (real
> requirements) instead of just saying 'we want begin/finish scripts'
> we're not going to get anywhere.
>
> AI is different, intentionally so. Among other things, we're actually
> trying to improve automated installation of OpenSolaris. Begin/finish
> scripts was one possible solution to a myriad of problems. Surely since
> we're dealing with computers (that do what we program them to do) we can
> define the problems that the begin/finish script solution solved and
> implement better solutions for each problem rather than having the hodge
> podge solution of people writing their own scripts that Sun then can't
> easily support? Maybe we can't come up with solutions, but until people
> work with us by providing concrete requirements (other than just 'we
> want begin/finish scripts') so that we can actually engineer something
> we'll never know.
>
> My .02.
>
> --
> Glenn
