The Sun/Oracle JET makes the process of JumpStarting Solaris boxes much easier than traditional JumpStart, and still very flexible. However, trying to set up a Standard Build environment requires investment of time and effort to get to know the toolkit, and a degree of imagination to make it do what you want it to. The 'JET Manifest Install' module helps remove some of the requirement to really get to know the inner workings of the tool and put you on the path to defining and managing a standardised build environment.

When JET was first designed, flexibility was the primary driver. It was an internal tool to help field service engineers quickly deliver repeatable system builds on customer sites - normally from their laptops. As each customer had their own requirements, flexibility was key. The tool was designed to keep things simple, and it was alwasy envisaged that something else would come along to deal with large-scale deployments of very similar builds - after all, JET was just a bunch of scripts.

After being involved in a number of different projects with customers to produce the 'something else' that dealt with their specifics, a number of common themes emerged. Most customers want a 'core' software distribution that goes to every host - OS, additional software and then security settings. After that, it depends on what the host is being used for as to what else gets loaded.

Out of the box, JET is great for getting the OS and standard packages installed - even more so if the sys-admins create flars of this and then deploy those. To get to the next step, the recommendation was that customers then started to create their own JET modules to deliver the additional software components. In an ideal world, the individual product teams within a company would own and manage the JET modules to deploy the s/w. Ideal worlds never seem to exist though.

In a more realistic world, big customers got Sun involved and paid them to 'solve' these problems - so specific modules were written, and then probably never looked at again by the customers or their admin teams. For smaller customers who wanted to DIY, they looked at the 'custom' module and started to put all their configs into the system templates. Fine for a single system, but when you start to increase the volume of servers to manage, remembering to update all the templates each time there is a change is an administration nightmare.

Something was needed to fill the void.