Our overhaul of Solaris installation in the Caiman project is a large undertaking with many facets.  As we’ve just published a design draft on derived manifests, this seems to be a good opportunity to discuss scripting in the Automated Installer (AI).  Before proceeding further, I recommend reviewing  Stephen‘s old post on scripting in the packaging system, pkg(5): a no scripting zone.

When Jumpstart was designed back in the early 90’s, its philosophy was largely an extension of that embodied in the SVR4 packaging system: provide a set of relatively simple core functions and rely on a deep set of scripting hooks to allow extension to more complex tasks.  In the case of packaging, the core functions essentially covered copying basic file system objects, and everything else was implemented by some type of script.  In the case of Jumpstart, the core functions boiled down to a few pre-defined configuration tasks (embodied in sysidtool’s implementation), partitioning disks, creating file systems, and installing SVR4 packages from Solaris media (extended later to include Flash archives).    Additional functionality, including installing non-Solaris packages, required the use of begin and finish scripts, which were executed before and after the installer, respectively.

This use of scripting to extend a product’s functionality is undeniably attractive, not least because it allows the most adept users of the product to attain the greatest benefit from it, extending it in unanticipated directions or providing conveniences that are not of broad enough applicability for the product team to bother implementing.  However, it can also have negative effects, such as:
  • reducing customer feedback to the product team on needed enhancements to the core functionality, due to customers or third parties just rolling their own; the Jumpstart Enterprise Toolkit (JET) is an example of this.  However useful JET may be to its users, there is no denying the fact that more users would benefit were its functions included in the product.
  • reducing the product team’s ability to evolve the product, due to the interface surface that the scripting environment exposes.  For example, the perl 5.8.4 scripting language is automatically embedded in the Automated Installer environment at this writing; this is not intentional, but merely a side-effect of today’s package boundaries and the resulting dependencies.  It will almost certainly not be included once we refactor the core packages.  One might argue that we can mitigate this via documentation, but documenting every last detail of that environment is an ineffective use of resources.
  • luring customers into creating extensive installation-specific functionality that is not reusable in other contexts.  An example of this case is zones; we don’t presently use AI to install non-global zones, but a frequent request in Solaris 10 was to use Jumpstart to provision non-global zones so that customers’ existing infrastructure around Jumpstart could be leveraged.  On the surface this isn’t a bad idea, except that non-global zones behave just enough differently that it’s fairly likely that most of customers’ existing Jumpstart infrastructure wouldn’t have worked, anyway.  We’re looking at how to combine AI and zones for Solaris, as we do recognize the leverage of provisioning both in the same way, but this becomes most powerful if we provide customers with a design that isolates them from the differences.
Our challenge in AI is that we’d like to provide the benefits of scripting, but reduce its costs, both to customers and ourselves.  One way to reduce costs for customers is to reduce the need for scripting.  We’ve looked at the things that customers commonly do in the begin and finish scripts and worked out ways to To that end, AI will provide more functionality built in, including items such as:
  • Installation of packages from multiple pkg(5) repositories
  • More extensible configuration capabilities based on SMF profiles
  • More complete capabilities to configure ZFS pools and datasets
Of course, providing all the functionality anyone could ever want is an impossibility, and as I’ve acknowledged above some amount of scripting can be positive.