5 Producing Kernel Product Kits

This chapter tells you how to produce a kernel product kit, what additional files are required, and how to test the kit installation.

Note

The information in this chapter describes how to produce kernel product kits.

If you want to create a user product kit, go to Chapter 4.

If you want to create a hardware product kit, go to Chapter 6.

Follow these steps to create and test a kernel product kit:

Read Chapter 1 for an overview of product kits.

Design the kit directory structure as described in Chapter 2.

Create subsets as described in Chapter 3. Kernel product kits require a subset control program (Section 3.4).

Create additional installation files as described in Section 5.2.

Rerun the newinv utility as described in Section 3.7 to update the master inventory file with the additional installation files.

Rerun the kits utility as described in Section 3.5 to produce updated subsets and control files.

Create the kit distribution media as described in Section 5.3.

Test the distribution media as described in Section 5.4.

5.1 Overview

A kernel product is a layered product that contains kernel support. Users do not run kernel products directly; the operating system and utilities access kernel products to perform their work. For example, a device driver is one common type of kernel product. A user runs an application or utility, which generates system requests to perform operations such as opening a file or writing data to a disk. The system determines which device driver should service this request and then calls the required driver interface.

The kernel modules and the kit support files are distributed as part of the kernel product kit, and can be installed either directly from the distribution media or loaded onto a Remote Installation Services (RIS) area for installation by RIS clients over a local area network (LAN).

5.2 Creating Additional Installation Files

The files needed to build a kernel product kit depend on whether the kit will be configured statically or dynamically on the customer's system. For example:

A statically configured product is linked statically into the kernel at build (or bootlink) time and configured at boot time. A static product can be built from source files, binary objects, modules, or all three.

A dynamically configured product is loaded into a running kernel after it has been booted. It is not part of the permanent kernel and is configured when it is loaded. It must be reloaded after each boot of the system. A dynamic product can be built from source files, binary objects, modules, or all three.

Note:

A module that can be loaded dynamically also can be linked statically. The only difference is the call to configure the product. For more information on static and dynamic drivers, refer to Writing Device Drivers.

Figure 5-1 shows the files that make up the ODB product kit source directory. Additional kernel product files are highlighted.

Figure 5-1: Kernel Product Source Directory

/README.odb -- a text file containing general product information
This file is installed in the root ( / ) file system and is placed in the opt/OAT100 source directory.

/sbin/odb_recover -- a utility to recover corrupt ODB documents when the system boots. The odb_recover script executes when the system boots and the /usr file system may not be mounted.
This file is installed in the root ( / ) file system and is placed in the opt/OAT100/sbin source directory.

/usr/bin/odb_start -- the ODB tool startup script. The odb_start script is a user command.
This file is installed in the /usr file system and is placed in the usr/opt/OAT100/bin source directory.

/usr/var/templates/odb_template -- a document template that can be modified by a user.
This file is installed in the /var file system and is placed in the usr/var/opt/OAT100/templates source directory.

/usr/var/log_files/odb_log -- the context-dependent symbolic link (CDSL) for the odb_log file.
This symbolic link is installed in the /usr/var file system and is placed in the usr/var/opt/OAT100/log_files source directory.

/usr/var/cluster/members/member0/log_files/odb_log -- the file listing all of the ODB documents created by a user. The odb_log file can be modified by users.
This file is installed in the /usr/var file system and is placed in the usr/var/cluster/members/member0/opt/OAT100/log_files source directory.

files -- the files file fragment contains information about the location of the source code and modules associated with the driver, tags indicating when the driver is loaded into the kernel, and whether the source or binary form of the driver is supplied to the customer.

sysconfigtab -- the sysconfigtab file fragment contains device special file information, bus option data, and information on contiguous memory usage for statically and dynamically configured drivers. The sysconfigtab file fragment gets appended to the /etc/sysconfigtab database when the kernel product kit is installed. For more information, refer to the sysconfigtab(4) reference page.

odb_printer.mod -- the object module file containing the single binary module for the ODB kernel product.

A kernel product kit requires you to include the following files on the distribution media to make the kernel product accessible during installation:

The files file fragment (Section 5.2.1)

The sysconfigtab file fragment (Section 5.2.2)

The driver.mod object module file (Section 5.2.3)

The *.c (source) and *.h (header) files (Section 5.2.4)

The device.mth method files (Section 5.2.5)

5.2.1 The files File Fragment

The files file fragment contains information about the location of the source code and modules associated with the driver, tags indicating when the driver is loaded into the kernel, and whether the source or binary form of the driver is supplied to the customer. You need to edit this file if the kit development directory structure differs from the driver development directory structure or if you must change the driver name for any reason.

Caution

The files file fragment must be in the same directory as the kernel modules or the kreg and doconfig utilities will not work properly.

Figure 5-2 shows which fields within the files file fragment need to change.

Figure 5-2: Editing the files File Fragment

5.2.2 The sysconfigtab File Fragment

The sysconfigtab file fragment contains device special file information, bus option data information, and information on contiguous memory usage for statically and dynamically configured drivers. When the user installs a kernel product kit, the driver's sysconfigtab file fragment gets appended to the /etc/sysconfigtab database. You should place this file fragment in a product directory, such as /opt/OAT100/etc.

You do not need to change the sysconfigtab file fragment unless you change the driver (subsystem) name. The driver name appears in three places within the file, as shown in Figure 5-3. In the example, the driver runs on a TURBOchannel bus (indicated by the TC_Option entry), but a similar set of bus options would be specified for other bus types.

Figure 5-3: Editing the sysconfigtab File Fragment

This file is described in the sysconfigtab(4) reference page.

5.2.3 The Object Module File

The driver.mod object module file contains the single binary module for both statically and dynamically configured drivers. Include this file in a product directory, such as /opt/OAT100/sys/BINARY, in the root ( / ) file system.

Caution

You cannot use RIS to link compressed modules. Use the file command to determine if a file is compressed. You see output similar to the following:
# file odb_graphics.mod
odb_graphics.mod:
    alpha compressed COFF executable or object module not stripped

5.2.4 The Source and Header Files

The *.c (source) and *.h (header) files contain the source code for the device driver. Include these files in a product directory, such as /usr/opt/OAT100/src, when the driver is statically configured and distributed in source form.

5.2.5 The Method Files

The device.mth method files contain driver methods that are called during automatic configuration to create device special files for dynamically configured drivers. The subset control program creates links to these device special files in the customer's subsys directory when the driver is installed. The driver method files are on the distribution media and are not installed onto the customer's system. The device driver developer can tell you which method files the subset control program should link to, typically /subsys/device.mth. Link the method in a device driver kernel kit only if the driver needs to have device special files created for its devices.

5.3 Producing Distribution Media

After you have tested the subsets, you can produce the distribution media. Distribution media production consists of the following tasks:

Rerunning the newinv utility to update the master inventory file with the additional installation files (Section 3.7)

Rerunning the kits utility to produce updated subsets and control files (Section 3.5)

Editing the /etc/kitcap file. (Section 5.3.1)

Building the kernel product kit on the distribution media.
- Use the gendisk utility to build a kit on disk media (Section 5.3.2)
- Use the gentapes utility to build a tar format kit on magnetic tape (Section 5.3.3)

You can produce the kernel product kit in either tar format or direct CD-ROM (DCD) format.

If your product kit does not access kernel modules during boot, use the tar format to compress your kit and save space on the media.

If your product kit accesses kernel modules during the boot process, you must use the DCD format and cannot produce the kit on magnetic tape media.

Installation time for DCD format kits is slower than for tar format kits.

tar format
In tar format, the product files in each subset are written to the distribution media as a single file. During installation, the setld utility uncompresses the files and moves them onto the target system, preserving the files' original directory structure. Kits distributed in tar format install more quickly and consume less space on the distribution media.

direct CD-ROM (DCD) format
In DCD format, the files are written to the distribution media as a UNIX file system where the product files are organized into a directory structure that mirrors the target system. Subsets distributed in DCD format cannot be compressed. During installation, the setld utility does the following:
1. Creates a single file in tar format for the product files in each subset.
2. Compresses each tar-format subset file.
3. Uncompresses each tar-format subset file.
4. Writes each tar-format subset file onto the target system.

You can distribute user product kits on diskette, CD-ROM, or magnetic tape, as follows:

Diskette
Diskettes are a good media for testing purposes or for small products. The product must fit on a single diskette; it cannot span multiple diskettes. Use the gendisk utility to produce kits for diskette media.

CD-ROM
CD-ROM media can support large kits or multiple kits on a single media. The kit is first produced on the hard disk, then written onto the CD-ROM. Use the gendisk utility to produce the master kit on hard disk. Follow the CD-ROM manufacturer's instructions for writing the kit onto the CD-ROM media.

Magnetic tape
You can distribute kits for kernel products on magnetic tape. Magnetic tape does not support DCD format. Use the gentapes utility to produce kits for magnetic tape media.

Figure 5-4 shows the types of file formats and distribution media that are available for kernel product kits.

Figure 5-4: Kernel Product Kit File Formats

5.3.1 Editing the /etc/kitcap File

The gendisk and gentapes utilities refer to the /etc/kitcap file, a database containing information about the kits to be built on the system. Each record contains a product code and the names of the directories, files, and subsets that make up the product kit. Before you can build your kit, you must add a media descriptor record to the /etc/kitcap database.

Note

If you use the gendisk utility to produce your kit on disk distribution media, you can specify an alternate kit descriptor database. Refer to the gendisk(1) reference page for additional information.

Use the following conventions when you add a record to the /etc/kitcap file:

Separate the first field from the rest of the record by a colon ( : ) for disk media descriptors and by a pipe character ( | for tape media descriptors.

Separate all other fields with colons ( : ).

Indicate continuation with a backslash ( \ ) at the end of the line.

Lines starting with a pound sign ( # ) are comments and are ignored.

Comments within the record start with pound sign ( # ) and end with a colon ( : ). Use this feature sparingly.

The contents of a kitcap record differ depending on whether you are producing disk or tape media. You must add one record for each media type on which you plan to distribute your kit.

The contents of the record also depend on the product type you are delivering. For example, the kitcap record for a kernel product may require the kk=true parameter and the rootdd= option. Refer to the kitcap(4) reference page for more information about the contents of the /etc/kitcap file.

5.3.1.1 Disk Media Descriptor

Create a disk media kitcap record when you produce kits for distribution on diskette or CD-ROM. The kitcap record for disk media contains the following elements:

The kit name, consisting of two parts:
- The product code, consisting of the product code and version number specified in the CODE and VERS fields of the kit's key file (prodcode.k).
- The media code HD to indicate disk media. This element is followed by a colon ( : ).

The partition on the disk media where the product should be placed. The partition is a letter between a and h. Partition c is used most often, as it spans the entire disk.

The destination directory for the subsets on the disk media. This allows a hierarchical structure so you can put multiple products on one disk, or put parts of one product on different areas of the same disk. You can use multiple destination directories in a kitcap record.
The destination directory field may also include these parameters:
- kk=true
  Indicates that the kit is needed during the boot process. When the gendisk utility finds this option, it automatically generates a kitname.kk file.
- rootdd=dirname
  Specifies kit file placement on the distribution media, relative to the kit-specific directory such as /OAT100/kit. For example, rootdd=.. would place the kit's root under the /OAT100 directory.

The product description. This entry is taken from key file NAME field. Replace any spaces with an underscore ( _ ) character, for example: Product Description becomes Product_Description.

The name of the output directory where you created the kit, where the gendisk utility can find the product subsets.

The instctrl directory, relative to the output directory specification.

The names of the subsets that make up the kit.

Refer to the kitcap(4) reference page for more information about the disk media record format.

Refer to Section 3.3 for information about the key file.

Example 5-1 shows the record to be added to the /etc/kitcap file to produce the ODB kit on disk media:

Example 5-1: Sample Disk Media Descriptor for Kernel Product

OAT100HD:c:\
  dd=/OAT100:Orpheus_Document_Builder:/mykit/output:\
  OATODB100:OATODBTEMPS100:OATODBKERNEL100

Based on the information shown in Example 5-1, the gendisk utility places the kit on the c partition in the / (root) directory of the disk media. The product description is Orpheus_Document_Builder and the kit output directory is named /mykit/output. The kit consists of three subsets: OATODB100, OATODBTEMPS100, and OATODBKERNEL100.

5.3.1.2 Tape Media Descriptor

The kitcap record for tape media contains the following elements:

The kit name, consisting of two parts:
- Product code, consisting of the product code and version number specified in the CODE and VERS fields of the kit's key file (prodcode.k).
- The media code, either TK for TK50 tapes or MT for 9-track magnetic tape. This element is followed by a pipe character ( | ).

Product description. This entry is taken from the NAME field of the key file.

Name of the output directory where you created the kit, where the gentapes utility can find the subsets.
Since the gentapes utility can take subsets from multiple products and merge them on tape as a combined product, you can specify multiple directories where the gentapes utility can find the subsets. There must be one directory entry for each kitcap descriptor.

Three empty SPACE files to ensure compatibility with operating system kits. To create the SPACE file in the output area of the kit directory structure, issue the following commands:
```
# cd /mykit/output
# touch space
# tar -cf SPACE space
```

The INSTCTRL image in the output directory containing setld control information.

The names of the subsets that make up the kit. Each subset listed must be stored in one of the specified directories.

Optional volume identifiers %%N, followed by the names of the subsets to be placed on that volume. You can use multiple tapes.

Refer to the kitcap(4) reference page for more detailed information about the tape media record format.

Example 5-2 shows the record to be added to the /etc/kitcap file to produce the ODB kit on TK50 tapes:

Example 5-2: Sample Tape Media Descriptor

OAT100TK|Orpheus Document Builder:\
  /mykit/output:SPACE:SPACE:SPACE:\
  INSTCTRL:OATODB100:OATODBTEMPS100:OATODBKERNEL100

The product name, OAT100, is the same name that appears in the key file. The product description, Orpheus Document Builder also appears in the key file. The name of the output directory is specified as /mykit/output, and three SPACE files are included for compatibility with operating system kits. The last line of the record contains the INSTCTRL directory and the names of the subsets that make up the kit: OATODB100, OATODBTEMPS100, and OATODBKERNEL100.

5.3.2 Building a Kernel Product Kit on Disk Media

When the product subsets are located in the output area of the kit directory structure, use the gendisk utility to create the kit on a disk.

Note

The gendisk utility supports diskettes but does not allow you to create a chained diskette kit. A kit written to diskette must fit on a single diskette or be packaged as a set of kits on separate diskettes.

Use the following syntax for the gendisk command:

gendisk [-d] [-i] [-k filename] [-w] [-v] [hostname:] prodID devname

-d: Creates a distribution disk in direct CD (DCD) format. This means that the distribution disk contains uncompressed file systems that are arranged in the same way as the software will be installed on the system.
-i: Creates a distribution disk in ISO 9660 format. This means that the distribution disk contains an ISO 9660-compliant CD-ROM file system (CDFS).
-k filename: Uses an alternate kit descriptor database, filename, on the local system. You may use either a full absolute pathname or a relative pathname from the directory where you run the gendisk utility. You do not have to name the file kitcap.
-w: If used without the -v option, writes the product media without verification. If used with the -w option, the gendisk utility writes and then verifies the product media.
-v: If used without the -w option, verifies the product media without writing it first. This assumes that you already have written kit files to the distribution media. If used with the -w option, the gendisk utility writes and then verifies the product media.
hostname:: The optional hostname: operand is the name of a remote machine that contains the kitcap file. The utility searches the /etc/kitcap file on the remote machine for the prodID and uses it for creating the media. The colon (:) is a required delimiter for TCP/IP networks, and space is permitted between the colon and the prodID. For example, if the product code is OAT100 and you are using the kit descriptor database on node mynode, use mynode:OAT100 for this option.
prodID: The mandatory prodID operand is a kit identifier consisting of the product code and version number specified in the CODE and VERS fields of the kit's key file. Refer to Section 3.3 for information about the key file.
devname: The mandatory devname operand specifies the device special file name for a raw or character disk device such as /dev/rdisk/dsk1. The gendisk utility uses the disk partition specified in the kit descriptor and ignores any partition specified on the command line.

Note

If you do not use either the -w or -v options, the gendisk utility writes and then verifies the product media.

The command illustrated in Example 5-3 creates a tar format kernel product kit for OAT100 on the c partition of dsk0:

Example 5-3: Sample gendisk Command

# gendisk OAT100 /dev/rdisk/dsk0c

Refer to the gendisk(1) reference page for more information about this utility.

5.3.3 Building a Kernel Product Kit on Magnetic Tape

When the product subsets are located in the output area of the kit directory structure, use the gentapes utility to create the kit on magnetic tape. Use the following syntax for the gentapes command:

gentapes [ -w | -v ] [hostname:] prodID devname

-w: Writes the product media without verification. Do not use the -w option with the -v option.
-v: Verifies the product media without writing it first. Do not use the -v option with the -w option.
hostname:: The optional hostname: argument is the name of a remote network machine that contains the kit descriptor database. The gentapes utility searches the kit descriptor database on the remote machine for the kit identifier (prodID[TK|MT]) and uses it to create the media. The colon (:) is a required delimiter for TCP/IP networks, and space is permitted between the colon and the prodID. For example, if the product code is OAT100 and you are using the kit descriptor database on node mynode, use mynode:OAT100 for this option.
prodID: The mandatory prodID operand is a kit identifier consisting of the product code and version number specified in the CODE and VERS fields of the kit's key file. Refer to Section 3.3 for information about the key file.
devname: The mandatory devname operand specifies the device special file name for a no-rewind tape device such as /dev/ntape/tape0l. The gentapes utility uses the default tape density for the device and ignores any suffix specified on the command line.

Note

If you do not use either the -w or -v option, the gentapes utility writes the tape, rewinds it, and then verifies the files in the kit descriptor.

The command illustrated in Example 5-4 creates a tar format user product kit for OAT100 on the magnetic tape in /dev/ntape/dat:

Example 5-4: Sample gentapes Command

# gentapes OAT100 /dev/ntape/dat

Refer to the gentapes(1) reference page for more information about this utility.

5.4 Testing the Distribution Media

Before shipping a kernel product kit to customers, you should test the kit with the same procedures that your customers will use on configurations that resemble your customers' systems.

Run the following tests to test a kernel product kit:

Use the setld utility to verify that the subsets have been built correctly and that the files get installed into the correct locations on the target system. (Section 5.4.1)

Use the ris utility to add a kernel product kit into a RIS area and verify that the correct files are present on the kit. Then, register the client system to the RIS area and start a Full Installation on the client system. (Section 5.4.2)

The following sections describe how to set up and perform these tests.

5.4.1 Testing a Kernel Product Kit with the setld Utility

Use the setld utility to test a kernel product kit as described in the following procedure for the OAT100 kit:

Log in to the system as root or use the su command to gain superuser privileges.

Place the CD-ROM in the drive.

Create a directory to be the media mount point, such as /cdrom:
```
# mkdir /cdrom
```

Mount the CD-ROM on /cdrom. For example, if the CD-ROM device is located on the c partition of cdrom0, enter the following command:
```
# mount -r /dev/disk/cdrom0c /cdrom
```

Use the setld utility to install the kernel product subsets:

# setld -l /cdrom/OAT100/kit

*** Enter subset selections ***
 
The following subsets are mandatory and will be installed automatically
unless you choose to exit without installing any subsets:
 
      * Document Builder Kernel Support
      * Document Builder Tools
 
The subsets listed below are optional:
 
 - Other:
     1) Document Builder Templates
 
Or you may choose one of the following options:
 
     2) ALL mandatory and all optional subsets
     3) MANDATORY subsets only
     4) CANCEL selections and redisplay menus
     5) EXIT without installing any subsets
 
Estimated free diskspace(MB) in root:54.5 usr:347.0
 
Enter your choices or press RETURN to redisplay menus.
 
Choices (for example, 1 2 4-6): 2
 
You are installing the following mandatory subsets:
 
        Document Builder Kernel Support
        Document Builder Tools
 
You are installing the following optional subsets:
 
 - Other:
        Document Builder Templates
 
Estimated free diskspace(MB) in root:54.5 usr:347.0
 
Is this correct? (y/n): y
 
Checking file system space required to install selected subsets:
 
File system space checked OK.
 
3 subset(s) will be installed.
 
Loading subset 1 of 3 ...
 
Document Builder Tools
   Copying from /cdrom/OAT100/kit (disk)
   Verifying
 
Loading subset 2 of 3 ...
 
Document Builder Templates
   Copying from /cdrom/OAT100/kit (disk)
   Verifying
 
Loading subset 3 of 3 ...
 
Document Builder Kernel Support
   Copying from /cdrom/OAT100/kit (disk)
   Verifying
 
3 of 3 subset(s) installed successfully.
 
Configuring "Document Builder Tools" (OATODB100)
 
The installation of the Document Builder Tools (OATODB100)
software subset is complete.
 
Please read the /opt/OAT100/README.odb file before
using the Document Builder Tools product.
 
Configuring "Document Builder Templates" (OATODBTEMPS100)
 
Configuring "Document Builder Kernel Support" (OATODBKERNEL100)
 
*** Document Builder Kernel Support Product Installation Menu ***
 
1. Statically configure the graphics support
2. Dynamically configure the graphics support
 
Type the number of your choice []: 1
 
*** KERNEL CONFIGURATION AND BUILD PROCEDURE ***
 
Saving /sys/conf/TEST01 as /sys/conf/TEST01.bck
 
Do you want to edit the configuration file? (y/n) [n]: n
 
*** PERFORMING KERNEL BUILD ***
        Working....Fri May 19 14:49:25 EDT 2000
 
The new kernel is /sys/TEST01/vmunix
 
The /sys/TEST01/vmunix kernel has been
moved to /vmunix and the changes will take effect
the next time the system is rebooted.
#

The setld utility displays prompts and messages to guide you through the process of selecting the subsets you want to install. As each subset is loaded, the setld utility calls the subset control program as needed, including static or dynamic driver configuration. Figure 5-5 shows the steps the subset control program takes to statically configure the driver.

Figure 5-5: Static Configuration of a Driver

When the installation is complete, unmount the CD-ROM:
```
# umount /cdrom
```

If the product was configured statically, restart the system with the new kernel:
```
# /usr/sbin/shutdown -r now
```
When the system restarts, the device driver is available on the system.

Verify that the installed product functions correctly.

Delete the ODB subsets with the setld -d command. You see output similar to the following:


# setld -d OATODB100 OATODBTEMPS100 OATODBKERNEL100

Deleting "Document Builder Templates" (OATODBTEMPS100).
 
*** KERNEL CONFIGURATION AND BUILD PROCEDURE ***
 
Saving /sys/conf/TEST01 as /sys/conf/TEST01.bck
 
Do you want to edit the configuration file? (y/n) [n]: n
 
*** PERFORMING KERNEL BUILD ***
        Working....Fri May 19 14:55:31 EDT 2000
 
The new kernel is /sys/TEST01/vmunix
 
The /sys/TEST01/vmunix kernel has been
moved to /vmunix and the changes will take effect
the next time the system is rebooted.
 
Deleting "Document Builder Kernel Support" (OATODBKERNEL100).
 
Deleting "Document Builder Tools" (OATODB100).
#

Restart the system to ensure that it reboots with the new kernel after the product is removed:
```
# /usr/sbin/shutdown -r now
```
When the system restarts, the product should not be available on the system.

Refer to the Installation Guide and the setld(8) reference page for more information about using the setld utility to install layered products.

5.4.2 Testing a Kernel Product Kit in a RIS Area

Use the ris utility to test a kernel product kit on a RIS server as described in the following procedure for the OAT100 kit. Refer to the Sharing Software on a Local Area Network manual for additional information about Remote Installation Services (RIS).

Log in to the RIS server as root or use the su command to gain superuser privileges.

Place the CD-ROM in the drive.

Create a directory to be the media mount point, such as /cdrom:
```
# mkdir /cdrom
```

Mount the CD-ROM on /cdrom. For example, if the CD-ROM device were located on the c partition of cdrom0, enter the following command:
```
# mount -r /dev/disk/cdrom0c /cdrom
```

Enter /usr/sbin/ris to start the ris utility. You see the RIS Utility Main Menu:

Checking accessibility of RIS areas.... done
 
*** RIS Utility Main Menu ***
 
Choices without key letters are not available.
 
  ) ADD a client
  ) DELETE software products
 i) INSTALL software products
  ) LIST registered clients
  ) MODIFY a client
  ) REMOVE a client
  ) SHOW software products in remote installation environments
 x) EXIT
 
Enter your choice:

Enter i to select Install software products. You see the RIS Software Installation Menu:

RIS Software Installation Menu:
    1)  Install software into a new area
    2)  Add software into an existing area
    3)  Return to previous menu
 
Enter your choice:

Depending on your test environment, enter 1 to select Install software into a new area or 2 to Add software into an existing area.

Install the software as described in Sharing Software on a Local Area Network.

To install the product kit from the RIS server onto the client system, first register the client system with the RIS server and then use the setld utility as described in the following procedure:

Log in to the RIS server as root or use the su command to gain superuser privileges.

Enter /usr/sbin/ris to start the ris utility. You see the RIS Utility Main Menu:

Checking accessibility of RIS areas.... done
 
*** RIS Utility Main Menu ***
 
Choices without key letters are not available.
 
  ) ADD a client
  ) DELETE software products
 i) INSTALL software products
  ) LIST registered clients
  ) MODIFY a client
  ) REMOVE a client
  ) SHOW software products in remote installation environments
 x) EXIT
 
Enter your choice:

Enter a to select ADD a client.

Enter the client information as described in Sharing Software on a Local Area Network.

Log in to the RIS client as root or use the su command to gain superuser privileges.

Use the setld -l command to load the product subsets from the RIS area. For example, if the RIS server is named test01, enter the following command:
```
# setld -l test01:
```
The setld utility displays prompts and messages to guide you through the installation process as described in Sharing Software on a Local Area Network.
Refer to the Installation Guide and the setld(8) reference page for more information on using the setld utility to install layered products.