Using the custom Module

Use the custom module to install arbitrary packages, patches, and files on the target server. You can also use this module to run arbitrary scripts. When being installed on the target server, the order of installation is always: packages, patches, files, then scripts. If this order does not work for you, you can also create your own JET module. For information, see Appendix C, Creating Custom JET Modules.

The custom module can be used to install packages and patches at different stages of the build. See Solaris Installation Process through JET.

When you edit the target server template, you can list the names of the additional packages in the configuration variables custom_packages_[1-n], depending on when in the boot sequence the packages need to be installed. Likewise, you can identify patches in the variables custom_patches_[1-n].

Packages and patches are installed in the order given, so you must order them appropriately to satisfy any dependencies between them. If you have many packages or patches, or if a common set is used frequently on several different target servers, consider creating your own module. For information, see Appendix C, Creating Custom JET Modules. You might also need to consider this approach if you need to intersperse the installation of packages with patches.

If the product installation includes packages to be installed, a package.matrix file is included which contains a list of supported operating systems and product version numbers with a list of the packages required to be installed. There is also a patch.matrix file which defines the required patches in a similar fashion.

Populating Custom Patch and Package Media

The custom module enables you to define a custom package and patch set on a per target server basis. This module also provides two scripts to enable the package and patch media to be placed in the correct place for the toolkit to find.

When copying patch and package media, the scripts will place the media according to the definitions of JS_PKG_MEDIA and JS_PATCH_MEDIA as found in the toolkit configuration file (/opt/SUNWjet/etc/jumpstart.conf). To use an alternative location to hold all the media, modify the configuration file before executing the scripts.

Custom patches can be placed using the /opt/SUNWjet/bin/copy_custom_patches script:

# copy_custom_patches src-dir patch [patch....] 

This script takes at least two arguments, the first one is the source directory which contains the patches. Any other arguments are then considered to be patch numbers, which are located within the directory and subsequently copied.

Custom packages can be transferred using the /opt/SUNWjet/bin/copy_custom_packages script:

# copy_custom_packages src-dir arch package [package....] 

The arguments are very similar to the arguments used for the custom scripts command, with the inclusion of the additional arch argument, which is used to define the target architecture for the packages. The target architecture will be defined by the output of uname -p on the target server. Currently, the values are either sparc or i386, for SPARC and IA86 architectures respectively.

Custom patches do not need the definition of an architecture, because distinctly numbered patches are released for each architecture for which the package is available.

The custom module cannot contain multiple different versions of the same package for the same architecture. If you need this functionality, consider a specific module to cover these requirements. See Appendix C, Creating Custom JET Modules.

Custom Files

The custom module enables files to be created, overwritten, or appended to on the target server. Files are referenced by a value that defines three items:

• The source file, relative to the target server directory within /opt/SUNWjet/Clients on the JumpStart server

• The mode of operation, which is either “a” (append) or “o” (overwrite)

• The destination file on the target server

For example, for a target server called banana the following line in the custom area of the template would append the contents of the file /opt/SUNWjet/Clients/banana/hosts on the JumpStart server to the file /etc/hosts on the machine banana while it was being built.

custom_files="hosts:a:/etc/hosts"

The source files must be placed correctly before the build of the target server. The files must be located within the /opt/SUNWjet directory tree.

Do not use absolute paths for the source file.

Do not refer to files that are outside of the tree, such as /etc/hosts or /etc/passwd.

The middle field of the triple specifies whether to append or overwrite the destination file on the target server. If a set of files are common to a number of target servers, consider creating a holding area within the /opt/SUNWjet/Clients directory. Place the common files within that directory. The templates for the target servers can then refer to the files as:

custom_files="../common/hosts:a:/etc/hosts ../common/ftpusers:o:/etc/ftpusers" 

Where the files are placed in /opt/SUNWjet/Clients/common rather than multiple copies in each target server specific directory. Because the template file is a Bourne shell script, you can use regular techniques to continue lines. Use the \ character, or append information to the variable custom_files="${custom_files} ......".

Custom Scripts

Custom scripts are defined by the source location of the script. The toolkit will copy the script to the scratch area on the target server during the build and execute it at the appropriate point.

As with the custom files described in the previous section, the source of the script must be within the /opt/SUNWjet directory. The source also can be a relative reference to a common holding area.

The custom module does not offer any provision for executing scripts before the first reboot, when the system is running on the NFS image from the JumpStart server and the real target server filesystem is mounted on $ROOTDIR (/a).

To execute a script prior to the first reboot, consider creating a module as described in Appendix C, Creating Custom JET Modules.