Module Overview
The basic toolkit provides common configuration options for the Solaris Operating Environment, but very little else. The design intention was to make a modular toolkit, so that changes can be made to small parts of the toolkit, without affecting the remaining code or configurations. The toolkit comes with one default module 'base_config' and an optional 'custom' module.
Modules may be made available by Sun or any third party. Details on how to write modules are covered later in this document.
Adding custom Packages, Patches, Files etc
The custom module can be used to install arbitrary packages, patches, files and run arbitrary scripts on the target server.
If the custom module options are not already present in the target server template, the following command can be run to add them:
# /opt/SUNWjet/bin/make_template -f -T <target server> <target server> custom
This command is effectively deriving a new template for the target server, based on its original configuration, but with the addition of the custom module.
When being installed on the target server, the order of installation is always:
packages, patches, files, scripts
If this order is not what you require, consider creating your own module, as described later in this document.
Custom Packages and Patches
The module can be used to install packages and patches at different stages of the build - see section 5.6 for information about the build sequence.
When editing the target server template, the names of the additional packages can be listed in the configuration variables 'custom_packages_[1-n]' depending on when in the boot sequence the packages need to be installed. Likewise, patches can be defined in the variables 'custom_patches_[1-n]'.
Packages and patches are installed in the order given, so must be arranged appropriately to satisfy any dependencies between them.
If you have many packages or patches, or there are a common set frequently used on a number of different target servers, you should consider creating your own module, as described later. You may also need to consider this approach if you need to intersperse the installation of packages with patches etc.
Populating custom patch and package media
The custom module allows the definition of a custom package and patch set on a per target server basis and 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 following 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). Should you wish to use an alternative location to hold all the media, please remember to modify the configuration file prior to 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 that of those 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. This will be defined by the output of 'uname -p' on the target server. Currently, the values will be one of 'sparc' or 'i386' for SPARC and IA86 architectures respectively.
Custom patches do not need the definition of an architecture, since distinctly numbered patches are released for each architecture the package is available for.
The custom module does not offer any provision for holding multiple different versions of the same package for the same architecture. Should this feature be required, consider writing a specific module to cover these requirements.
Custom Files
The module allows files to be created, overwritten or appended to on the target server. Files are referenced by a triple that defines the source file, relative to the target server directory within '/opt/SUNWjet/Clients' on the JumpStart server, the mode of operation and 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 file(s) must be placed accordingly prior to the build of the target server, and must be located within the '/opt/SUNWjet' directory tree - you can not use absolute paths for the source file, or refer to files outside of the tree i.e. /etc/hosts, /etc/passwd etc. The middle field of the triple, specifies whether to 'a' - append, 'o' - overwrite the destination file on the target server or 'b' - backup, then 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/common.files' directory, and placing the common files within that directory. The templates for the target servers can then refer to the files as:
custom_search_path="../common.files"
where the files are placed in '/opt/SUNWjet/Clients/common.files' rather than multiple copies in each target server specific directory.
Since the template file is just a bourne shell script, you can continue lines using regular techniques, such as the use of the '\' character, or by appending to the variable 'custom_files="${custom_files} ......"'.
Custom Scripts
Custom scripts are defined just 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.
In the same fashion as the custom files described in the previous section, the source of the script must be within the '/opt/SUNWjet' directory but can be a relative reference to a common holding area.
The custom module provides the facility to run scripts before the O/S is installed, and at the end of the O/S install before it is booted the first time. During these phases, the client will be running the net booted O/S, and the script writer needs to understand these differences.
Replicating an Existing Target Server Configuration
If the toolkit is being used to rollout a number of identically configured servers, it may be beneficial to simply copy and modify a known good template for a target server instead of creating a new one from scratch each time.
The toolkit provides a mechanism for creating a new template based on an existing one, through the use of the 'make_template' script.
For example, to create a new template for the target server 'apple' based on the existing server 'banana', you can do the following:
# make_template -T banana apple
This will copy almost all the settings from 'banana' in to the new 'apple' template, with the exception of ethernet (MAC) address, IP address and netmask. These values will be obtained from the name service switch as would have occurred during a standard make_template invocation.
Creating a Generic Template
If a number of target servers require a very similar base configuration, consider creating a 'generic' template containing all the common configuration information and then derive the individual target server templates from the generic one using the process described in the previous section.
If individual target servers require additional modules over and above the generic template, you can use the 'make_template' command shown below:
# make_template -T generic orange module2
This command is deriving a new template for the target server 'orange', based on the existing template 'generic' and adding the module 'module2' to the newly created template.
Using Alternative Patch Definition files.
In many installations it may be beneficial to standardise on a known fixed set of patches, which may be different from that defined by the individual module patch.matrix files.
Target Server Specific Definitions
These can be achieved by creating a set of subdirectories within the target server specific '/opt/jet/Clients' area, with a similar structure to that of the Product directory. These subdirectories can then be populated with patch.matrix files for each module. For example:
# mkdir /opt/SUNWjet/Clients/orange/vts # cp /opt/SUNWjet/Products/vts/patch.matrix /opt/SUNWjet/Clients/orange/vts # vi /opt/SUNWjet/Clients/orange/vts/patch.matrix
In the above example, we have taken the patch matrix file for the Sun Validation Test Suite and made a target server specific version. During the installation, the toolkit will now use this patch matrix over the one supplied by the module itself.
To do something similar for the standard Solaris Recommended patches, the process is slightly different. Within the target specific area under '/opt/SUNWjet/Clients' create a subdirectory 'base_config' and then a further subdirectory of 'base_config' named after the operating system release you wish to define a patch order file for; for example:
# mkdir /opt/jet/Clients/orange/base_config # mkdir /opt/SUNWjet/Clients/orange/base_config/5.8 # cp /export/install/patches/10_Recommended/patch_order \ /opt/SUNWjet/Clients/orange/base_config/10 # vi /opt/SUNWjet/Clients/orange/base_config/10/patch_order
This allows the recommended patches for this target server to differ from the regular recommended set that would normally be applied.
Generic Definitions
If a number of servers need to share the same set of patches at specific levels, the previous method of creating target server specific patch files is rather cumbersome.
The toolkit also provides a mechanism for referencing a similar structure to that described in the previous section, but held outside of the target server specific area under '/opt/SUNWjet/Clients'.
The area must be created somewhere under '/opt/SUNWjet' but placement is up to the implementor. In this example, the directory '/opt/SUNWjet/PatchDefs' has been chosen.
# mkdir -p /opt/jet/PatchDefs/1.0 # mkdir -p /opt/SUNWjet/PatchDefs/1.0/base_config/10 # cp /export/install/patches/10_Recommended/patch_order \ /opt/SUNWjet/PatchDefs/1.0/base_config/10 # vi /opt/SUNWjet/PatchDefs/1.0/base_config/10/patch_order # mkdir -p /opt/SUNWjet/PatchDefs/1.0/vts # cp /opt/SUNWjet/Products/vts/patch.matrix /opt/SUNWjet/PatchDefs/1.0/vts
In the above example, we have created an area under '/opt/jet/PatchDefs' called '1.0' to represent the 1.0 release of our configuration. Within this configuration, a given number of patches at specific levels have been agreed upon. It is the intention that all future builds of target servers at level '1.0' use these patches at the defined levels. Should we need to change the patches, a new release level '1.1' or '2.0' would be created in a similar fashion.
When we wish to build a target server using the configuration '1.0' of the patches, we create the template in the usual manner, and then use 'make_client' using the -p argument:
# make_client -p /opt/SUNWjet/PatchDefs/1.0 orange
This will populate the target server specific '/opt/SUNWjet/Clients' directory with the patch_order and patch.matrix files as in the previous section.
Comments (2)
Apr 30, 2009
mmore says:
How can the custom_files variable be made to work with filenames that contain a ...How can the custom_files variable be made to work with filenames that contain a colon, such as hostname.ce0:1?
May 01, 2009
mramchand says:
I've never thought about it before, but since the destination filename is the la...I've never thought about it before, but since the destination filename is the last in the field, we can change the code in the custom module to simply take EVERYTHING after the 2nd colon to be the destination filename. This means you'd need to call it something without a colon on the JET server, but give it it's real name in the 3rd field.
I'll update JET to do this, but it won't appear till at least JET 4.7.1.
In the meantime you can edit the following yourself:
/opt/SUNWjet/Products/custom/install, lines 74 and 178
/opt/SUNWjet/Products/custom/postinstall line 77
change
fn2="`echo ${filetriple} | cut -d: -f3 -s`"
to
fn2="`echo ${filetriple} | cut -d: -f3- -s`"
(I've not actually tested this, pls let me know if this works.)