There are a number of steps required to prepare the toolkit for installation of a new target server:
- Ensure the JumpStart server has all the required media, packages and patches.
- Collate all information necessary to build the target server.
Target Server Preparation
Collate all information necessary to build the target server
This includes such things as hostnames, ip address (including subnet information) and mac address of the interface the client will be jumpstarting with.
Create a 'template' for the Target Server
All of the target server configuration is performed through the use of a single flat file template. To create a new template for the target server, use the '/opt/SUNWjet/bin/make_template' script with a single argument of the target server name.
# /opt/SUNWjet/bin/make_template <target server name>
This will then create a new template file /opt/jet/Templates/<target server name>
If the Toolkit has been supplemented with additional modules, this template will contain all configuration options for all modules. To limit the modules presented in the template, list the individual modules you require after the target server name.
# /opt/SUNWjet/bin/make_template <target server name> <module1> <module2>....
The standard module "base_config" will always be included. To create a template with ONLY the standard module, list the base_config module only.
# /opt/SUNWjet/bin/make_template <target server name> base_config
To overwrite an existing template, make_template can be called with the "-f" option.
Customise the New Template
The template should now be edited using your editor of choice; the minimum configuration should include the architecture type, ethernet address and Solaris version to be installed on the target server. The Solaris version is one of the tags defined earlier; these can be listed by using the '/opt/SUNWjet/bin/list_solaris_locations' command. The installation mechanism (bootp or dhcp) is set using the variable base_config_client_allocation. If installing x64 clients, you MUST use dhcp.
The template file itself is sourced by a bourne shell script, so must conform to standard bourne shell construct rules. For example, variables that have multiple values must be enclosed by either single or double quotes. In addition, special characters such as ';' and '*' must be protected by quotes to prevent shell expansion etc.
The template file contains many comments to assist with the definition of the target server. Further information on module specific configuration can be found in a file named 'ReleaseNotes' which should be present in all modules, under the module specific directory within /opt/SUNWjet/Products.
Set up the JumpStart
Once the template has been edited, the actual files required to enable a JumpStart install must be created, and specific scripts run. The toolkit provides a utility command called 'make_client' to perform this task. This utility will create and populate the /opt/SUNWjet/Clients/<target server> directory with all the required information to boot the target server according to the details in the template. It will also ensure that the JumpStart framework is primed to allow install requests from the target server.
# /opt/jet/bin/make_client <target server name>
The 'make_client' script configures the JumpStart server with the appropriate files for the target server and then calls the standard 'add_install_client' script, supplied within the particular operating system image. It also performs a number of checks on the information supplied in the template and may indicate possible problems with the configuration.
It should be noted that the template is purely a mechanism for collating all the configuration into one location. It serves no other purpose. If you subsequently need to change an option in the template, you must remember to re-run the 'make_client' command to propagate your changes into the '/opt/SUNWjet/Clients' area.
When re-running the 'make_client' command, you will need to supply the '-f' option to force the overwrite of the existing configuration information.
The target server specific directory will now contain all the information that will be required during the install, and in particular, the JumpStart specific files 'profile' and 'sysidcfg' will have been automatically created.
Files and scripts that are to be applied to the target server, as defined by the custom product in the template, should also be placed relative to this target specific directory.
Starting the Build (SPARC)
To start the build process on the target server, make sure the target server is at the Open Boot Prom 'ok' prompt, and use the command:
ok boot net - install - w
The above command will perform a bootp build. For a dhcp build, you must use the following:
ok boot net:dhcp - install - w
 | Note For a DHCP build of SPARC to work, you must add the machine type to the JS_DHCP_VENDOR line in /opt/SUNWjet/etc/jumpstart.conf. The value is the equivalnet of the output of "uname -i" on the machine being built. e.g. SUNW.SUNW-Fire-T200. |
Starting the Build (x64)
Solaris uses PXE/dhcp to install on x86/x64 platforms. This requires that you set up your JET server to use DHCP. To start the Solaris install on x64, simply PXE boot the client.
Build Sequence
Before covering some extended features of the toolkit, a brief walk through of the build sequence is required, so that behaviour can be fully understood.
The build sequence of the JumpStart Enterprise Toolkit is as follows:
- Standard Solaris installation phase
- Standard JumpStart finish script called
- Individual module 'install' scripts called
- Target server reboots
- <optional> Platform related installation tasks; reboot after each level
- <optional> Application related installation tasks; reboot after each level
- <optional> Final installation tasks (no reboot)
- login prompt appears on the console etc
The optional steps after the initial reboot are dependent on the individual modules configured within the target server template. Modules can be written in such a way that they request that the toolkit perform additional work after the first reboot. In this request they can identify whether the work should be in the 'Platform' related area, the 'Application' related area or whether the work needs to be done at the end, when there are no more planned reboots.
This distinction of Platform and Application is important, as it allows a module developer to disregard any other modules that have been or may be written. For example, the configuration of a volume management product would be done within the 'Platform' scope, while a database would be in the 'Application' scope. Neither need to know about the existence of the other, or need to consider possible interaction.
Reboot numbering
For the Platform and Application optional reboot sequences, the modules can request that a particular task be executed on reboot 'x' where 'x' is a numeric number greater than 0.
The toolkit will group all requests for that particular reboot level and at the appropriate time, execute the scripts and then reboot the machine. The module itself does not do a reboot.
As the machine reboots the toolkit advances an internal counter so the next set of tasks is performed. If there are no more tasks remaining in the Application set, the toolkit will advance on to the Platform set. Once those are completed, the toolkit finally looks for the set of tasks which do not require a reboot.
No more reboots
Certain operations require the machine to be in a stable condition, in the knowledge that it is not just about to reboot. A classic example is when you attach a mirror to a volume manager controlled device; some volume manager software requires the operation to complete the resync without interruption.
Once these set of tasks are reached, the toolkit will move the 'rc' script into the post_install subdirectory which is /var/opt/sun/jet. This prevents the rc script being invoked by accident at a later date.