N1 Grid Service Provisioning System User's Guide and Release Notes for the OS Provisioning Plug-In 1.0

Module Interfaces

The toolkit calls particular interfaces within the module during the life cycle of the JumpStart process - both on the target server and the JumpStart server. Each interface is expected to be an executable shell script (or worst case, a binary), with the context of the target server supplied through environmental variables.

copy_media Interface

Called on

JumpStart server

Arguments
<patches|packages> version srcdir destdir arch
Required or optional?

Required

The copy_media script is called when the user calls the copy_product_media or copy_product_patches scripts to manage the media for this module. The script should understand what format the application is delivered in, and perform the copy from the passed source media location, to the appropriate media location on the server. This function allows the module to handle exotic forms of media (tar, gz, zip, bz2, and so on), without the main toolkit requiring to be updated for each media type. It also enables the module developer to place the media onto the server in a known state. For example, a product may require a whole directory tree to be visible, or just a bunch of Solaris packages.

make_template Interface

Called on

JumpStart server

Arguments

none

Required or optional?

Optional

When an administrator wants to create a new definition for a server build, they will execute the top level command make_template supplied in /opt/SUNWjet/bin. This top level make_template script will set up the basic target server configuration information and then call each module specific make_template script, if it is present. The module specific make_template script can perform additional work on the template; for example, populating per-client defaults for the user to edit.

make_client Interface

Called on

JumpStart server

Arguments

none

Required or optional?

Optional

When an administrator wants to set up a target server for installation, they will execute the top level command make_client supplied in the bin directory of the toolkit. This top level make_client script will set up the basic target server configuration information and then call each module specific make_client script if it is present. The module specific make_client script can perform additional work in the target server specific /opt/SUNWjet/Clients directory, it may configure module hints, modify the target server profile, sysidcfg or other files accordingly.

begin Interface

Called on

target server

Arguments

none

Required or optional?

Optional

During the “begin” phase of the JumpStart process, the toolkit will check to see if the module has a script called begin, and if it is present, the script will be executed. Any variables set in the module configuration section of the template will be present in the environment for the script to access.

install Interface

Called on

target server

Arguments

none

Required or optional?

Required

The install script is the main workhorse of the module. It is called on the target server after the main Solaris installation has completed, during the “finish” script phase. Its purpose is to instigate the installation or configuration of the particular application.

The script itself is called prior to the first reboot of the newly installed target server. At this point, the root directory (/) is actually an NFS mounted filesystem from the JumpStart server. The real disk based root directory is located through the use of the environment variable $ROOTDIR, traditionally set to /a.

If the application cannot be installed when root is located on $ROOTDIR, the install script should use the post-installation functionality provided by the toolkit, to schedule a subsequent installation after the first reboot. After the first reboot, the target server will actually boot of its own disk, and root will really be on /.

The install script is responsible for taking the user supplied configuration and driving the actual application installation and configuration appropriately. How this is achieved, is up to the ingenuity of the module developer, although a number of utility functions are available from the main toolkit, to assist with the common tasks; such as package or patch installation, file copies, message reporting etc.

Prior to the module install script being called, the module configuration as defined in the template and originally populated from the module.conf file is loaded into the shell environment. The install script should not expect to be called with arguments, but should instead take its configuration from the current environment. This technique avoids the problem of each module installation script requiring different numbers of arguments etc.

check_client Interface

Called on

target server

Arguments

none

Required or optional?

Optional

The check_client script can be employed by a module developer to perform basic checks about the configuration options specified in the template. When called, the environment will be configured with the variables set in the template, and the script can perform basic checking to try to reduce any installation errors.

The module may decide to check for valid options or that media exists for the selected version etc. The level of functionality provided is up to the implementor.