7 Installation Cloning

This chapter contains the following topics:

An overview of the Installation Cloning process

How an Installation Cloning happens

An overview of the installation configuration description file (CDF), install.cdf

The format and contents of the install.cdf file

A sample install.cdf file

Step by step procedures that describe how to generate a suitable CDF, edit the CDF, and start the Installation Cloning process

See Chapter 6 for information about the other customizations that can be made to a Full Installation process.

7.1 What is Installation Cloning?

Installation Cloning lets you duplicate the installation characteristics (that is, the file systems and installed software) from a running system onto one or more systems with the same or similar hardware configuration.

When you install the current version of the operating system on a machine, the installation process automatically generates a configuration description file (CDF) that contains a record of the installation setup data you specified. This file is created in the /var/adm/smlogs directory under the file name install.cdf. The install.cdf file contains all the installation information required to perform the same installation on a target system.

Note

If you want to clone Version 5.0A of the operating system onto a target system, the CDF must be created by a Version 5.0A Full Installation. Installation cloning is not supported between different releases of the operating system because CDFs created by other versions of the operating system are not compatible with the current version.

Systems that are installed by the cloning process must have the same disk configuration as the system where the CDF was generated. This means that the disks used for the / ( root ), /usr, /var, /usr/i18n file systems and swap areas on both systems must have the same disk type and the same device name. It is possible, however, to accommodate slight differences in configuration. Section 7.5.1 describes these acceptable differences.

Attributes in the install.cdf file can be modified so that there is no user intervention required at the target system. The install.cdf file also contains host- and site-specific attributes that you should modify in order to give the cloned system a unique identity. You most likely will have to change the host name entry for any system you want to clone.

Installation Cloning can be combined with Configuration Cloning, which is described in Chapter 8, and user-supplied scripts, which are described in Chapter 6, to totally clone and customize one or more target systems from a single installed and configured system.

Using Installation Cloning to mass-install systems has the following benefits:

You can produce identical installations with less effort.

You can set up the Installation Cloning process to run with minimal user intervention.

You can save time and reduce the chance of error in environments because Installation Cloning eliminates the need to manually perform duplicate installations on all systems.

You can administer software centrally, instead of attempting concurrent installations with locally-mounted removable media such as CD-ROMs.

7.2 How Does It Happen?

To clone a system, you copy the install.cdf file from the original model system to one of the four locations shown in Table 7-1. When you begin a Full Installation on a system you want to clone, the installation process looks for the install.cdf file in the order shown.

Table 7-1: Search Order for the install.cdf File

Search Order	Location
1	On a diskette in diskette drive `floppy0` or `floppy1`.
2	In the `/var/adm/ris/clients/sets/profile_set` subdirectory on the RIS server. During the RIS client registration process, the target system must be registered to the `profile_set` directory with the `install.cdf` file you want to use.
3	In the `/var/tmp` memory file system (MFS) on the system to be cloned.
4	In the `/isl` directory on the distribution media (local CD-ROM or extracted RIS area).

If the installation process finds an install.cdf file in any of the locations shown in Table 7-1, an Installation Cloning begins on the target system. As soon as the file is found, the installation process stops looking in the remaining locations. For example, if the installation process finds the install.cdf file on diskette, it does not look on the RIS server. If an install.cdf file is not found in any of the four locations, a regular Full Installation begins on the target system.

A majority of the remainder of this chapter is provided to assist you in editing the install.cdf file. If you are performing the Full Installation from CD-ROM (regardless of where the CDF is located), read Section 7.6.3, which describes the importance of modifying host- and site-specific attributes.

If you want to learn more about the format and contents of the CDF, refer to Section 7.3, Section 7.3.1, and Section 7.3.2. If you want to begin the tasks associated with Installation Cloning, go directly to Section 7.4.

7.3 Installation CDF Overview

An install.cdf file contains the following information about an installation:

Where file systems were created: / (root), /usr, /var, and /usr/i18n

Where swap space was created

The disklabel definition for each device

Disk types and disk names where file systems reside

File system layout (the specific partitions where file systems reside)

File system types: UNIX File System (UFS) or Advanced File System (AdvFS)

Logical Storage Manager (LSM) configuration

Host-specific information such as host name and encrypted root password and site-specific information such as location and area (also known as time zones)

Type of distribution media (CD-ROM or RIS) from which the installation took place

Software subsets that were installed

Section 7.3.1 describes the format and contents of the installation CDF, and Section 7.3.2 shows a sample installation CDF.

7.3.1 CDF Format and Contents

The install.cdf file is organized as groupings of attribute-value pairs. An equal sign ( = ) separates each attribute-value pair. An _item= defines each logical grouping of attribute-value pairs. Refer to the stanza(4) reference page for more information about stanza file format.

Table 7-2 describes each _item= in the install.cdf file. Appendix A provides detailed descriptions of the attribute-value pairs in each item.

Table 7-2: Items in the install.cdf File

_item=	Contains
`Inst_islinfo`	Information about the media used for the installation (CD-ROM, RIS, or clone) and other system information that conveys the state of the system before the start of the installation process.
`Inst_disklabel`	Disk configuration information such as partition sizes and offsets.
`Inst_filesystem`	File system information such as the number and type of file systems that were created on the system. There is one `Inst_filesystem` item for every file system and swap area that was created. At a minimum, there are four `Inst_filesystem` items in the CDF to describe the `/` ( `root` ), `/usr`, and `/var` file systems and the swap device.
`Inst_subsets`	A list of the installed base software subsets. If you installed Worldwide Language Support (WLS) subsets, up to two additional `Inst_subsets` item were created. If you are cloning a system that was installed with a hardware release, another `Inst_subsets` item contains a list of hardware-specific base subsets.
`Inst_cinstall`	Target system configuration information, which is conveyed to the installation process. All of the attributes specified in the `Inst_cinstall` item are optional. If values are not provided for these attributes, the installation process becomes interactive to request this information during the system configuration phase.
`Inst_lsm_disks`	Logical Storage Manager (LSM) private region partition information.
`Inst_lsm_global`	Global LSM information including the size of the private region and the LSM host name.

7.3.2 Sample Installation CDF

Example 7-1 shows the contents of an install.cdf file. Appendix A provides descriptions of each attribute and its valid values. The order of the attributes within each _item does not matter.

Example 7-1: Sample Installation CDF

install:
	_item=Inst_islinfo
	_action=create
	media_type=CDROM
	srcloc=/ALPHA/BASE
 
install:
	_item=Inst_disklabel
	g_size=1433600
	c_offset=0
	e_offset=1812528
	b_size=401408
	g_offset=663552
	d_size=1148976
	b_offset=262144
	f_size=1148976
	name=dsk1
	h_size=2013328
	d_offset=663552
	a_size=262144
	f_offset=2961504
	c_size=4110480
	_action=create
	h_offset=2097152
	e_size=1148976
	a_offset=0
 
install:
	_item=Inst_filesystem
	disk_number=1
	disk_name=dsk1
	controller_type=SCSI
	name=root
	partition=a
	controller_number=0
	disk_type=RZ28M
	file_system_type=AdvFS
	_action=create
 
install:
	_item=Inst_filesystem
	disk_number=1
	disk_name=dsk1
	controller_type=SCSI
	name=usr
	partition=g
	controller_number=0
	disk_type=RZ28M
	file_system_type=AdvFS
	_action=create
 
install:
	_item=Inst_filesystem
	disk_number=1
	disk_name="in usr_domain"
	controller_type=SCSI
	name=var
	partition=g
	controller_number=0
	disk_type=RZ28M
	file_system_type=AdvFS
	_action=create
 
install:
	_item=Inst_filesystem
	disk_number=1
	disk_name=dsk1
	controller_type=SCSI
	name=swap1
	partition=b
	controller_number=0
	disk_type=RZ28M
	file_system_type=swap
	_action=create
 
install:
	_item=Inst_filesystem
	disk_number=1
	disk_name="in usr_domain"
	controller_type=SCSI
	name=i18n
	partition=g
	controller_number=0
	disk_type=RZ28M
	file_system_type=AdvFS
	_action=create
 
install:
	_item=Inst_subsets
	volume_name=DISC1
	name=BASE
	ss_names=OSFADVFS505,OSFADVFSBIN505,OSFBASE505,OSFBIN505,
   OSFBINCOM505,OSFCDEDT505,OSFCDEMAIL505,OSFCDEMIN505,
   OSFCLINET505,OSFCMPLRS505,OSFFONT15505,OSFHWBASE505,
   OSFHWBIN505,OSFHWBINCOM505,OSFJAVA505,OSFKBDPCXAL505,
   OSFMITFONT505,OSFNETCONF505,OSFNETSCAPE505,OSFNFS505,
   OSFNFSCONF505,OSFOLDX11505,OSFPRINT505,OSFSER505,
   OSFSERPC505,OSFSYSMAN505,OSFTCLBASE505,OSFTKBASE505,
   OSFX11505,OSFXADMIN505,OSFXPRINT505,OSFXSYSMAN505
	advflag=1
	_action=create
 
install:
	_item=Inst_subsets
	volume_name=DISC2
	name=Worldwide_Language_Support
	ss_names=IOSPLCDEDT505,IOSPLCDEMAIL505,IOSPLCDEMIN505,
   IOSPLOLDX11505,IOSPLUCSBASE505,IOSPLX11505,IOSWWBASE505,
   IOSWWLAT2FONT100M505,IOSWWLAT9FONT100M505,IOSWWPRINT505,
   IOSWWSYSMAN505,IOSWWUCSBASE505,IOSWWX11505
	advflag=1
	_action=create
 
install:
	_item=Inst_cinstall
	kernel_option=interactive
	timeset=yes
  lang_env=C
	password=Bp2xAe46zVpUo
	timezone=New_York
	locality=America
	_action=create
	hostname=taurus

7.4 Summary of Installation Cloning Procedures

This section summarizes the tasks to set up and perform an Installation Cloning on a target system:

Create or select a suitable installation CDF.

Modify the installation CDF to set host- and site-specific attributes and include certain attributes to eliminate the need for user intervention at the cloned system.

Optionally create user-supplied scripts or a config.cdf file to execute during the Full Installation as well.

Copy the installation CDF to the right location depending upon your distribution needs.

Start a Full Installation on the target system.

The following sections provide more detail about each step in the Installation Cloning process.

7.5 Step 1: Creating or Selecting a Suitable CDF

Whether you are intentionally installing a model system to generate a CDF or you are selecting an existing CDF to use to clone target systems, you must consider the disk configuration, graphics adapter, font sizes and keyboard types of the systems to be cloned. Ideally, you should clone systems with identical hardware configurations.

During a regular Full Installation of a model system (not during cloning), the installation process automatically determines the mandatory software subsets required to support the graphics adapters, font sizes, and keyboard types resident on the system. All other software subsets are considered optional and are not installed unless you specifically select them.

When cloning a system, the CDF defines the software subsets to be installed on the target system. Therefore, if the target system has a different graphics adapter, font size, or keyboard type from the model system on which the CDF was created, the right software subsets will not be installed, and the cloned system may not be usable.

To generate an installation CDF that is versatile enough for use across differing systems, you may want to consider performing a Full Installation on a model system so that the CDF generated from that installation is usable by systems with different graphics adapters, font sizes, and keyboards. You do this by installing the software subsets to support all graphics adapters, font sizes, and keyboard types required by the systems to be cloned even though they are not required by the model system. Installing these optional software subsets will result in additional software being loaded on each system, but it will create a generic CDF that can be used to clone target systems with different configurations.

The following sections describe acceptable differences between the model system and target systems with respect to disk configuration, graphics adapters, font sizes, and keyboard types.

7.5.1 Acceptable Differences in Disks

Target systems should have the same hardware configuration as the model system where the CDF was generated. However, it is possible to support slight differences.

The disks on which /, /usr, swap1, /var, /usr/i18n (if it is not a directory under /usr) and swap2 (if allocated) must have the same configuration on both the target system and the model system from which the CDF was generated. The same disk configuration means that the disk type (for example RZ26) and the device name (for example dsk0) must match. If the partition tables for these disks are not identical on both systems, the cloning process will reconfigure the target system's disks as described in the CDF. It does not matter if disks not touched during the cloning process are different on the target system.

Note

If the cloning process reconfigures a disk or disks on the target system, be aware that this action may destroy user data on the reconfigured disk or disks.

Table 7-3 illustrates one example of acceptable differences in disk configuration between a CDF generated from a model system and a target system. Both systems have two disks, but the second disk on the target system is an RZ26 disk instead of an RZ25 disk. This difference does not matter because the cloning is taking place on the first RZ26 with device name dsk0, which both systems have in common.

Table 7-3: Acceptable Differences in Disks Between a Model System and a Target System

System	Disk Type	Device Name
model system	`RZ26RZ25`	`dsk0` ^{[Footnote 5]} `dsk1`
target system	`RZ26RZ26`	`dsk0dsk1`

Assuming there are no other differences in disk configuration, the target system can use the CDF generated from the model system. As long as the /, /usr, and /var file systems and swap space are not on dsk1, the disk type at device name dsk1 can be different. If the disk device at dsk0 were different, however, the cloned installation would fail.

7.5.2 Differences in Graphics Adapters

If any of the target systems have different graphics adapters from the model system, the software subsets required to support the graphics options needed by those systems must be installed on the model system or must be added manually to the install.cdf file before starting the cloning process on the target system.

When selecting software subsets during the installation of the model system, look in the Windowing Environment category for software subsets starting with the words X Servers for <name>. Replace <name> with the name that describes the graphics options supported by the software subset. The following graphics software subsets are available:

X Servers Base - Device independent X Server support (always installed)

X Servers for PCbus - Supports EISA bus and PCI bus graphics adapters

X Servers for TurboChannel - Supports TurboChannel bus graphics adapters

Note

All graphic adapters supported by this release of the operating system are listed in the Software Product Description (SPD).

Table 7-4 shows the graphics adapters on a model system and a target system.

Table 7-4: Graphics Adapters on a Model System and a Target System

System	Graphics Adapter
model system	`TurboChannel`
target system	`QVision (PCbus)`

Based on the model system's configuration, the installation process automatically installs the software subset X Servers for TurboChannel as a mandatory subset for the model system. Therefore, the X Servers for PCbus software subset is optional for the model system. To ensure the availability of the right software for the cloned system, you must install the X Servers for PCbus software subset onto the model system; otherwise, the target system will not have graphics capability.

Caution

Do not use the CDF from a system that does not have graphics capabilities to clone systems that have the hardware to support graphics. There are several software subsets, most notably those associated with the common desktop environment (CDE), that will not be loaded on systems without graphics capabilities that are mandatory for systems with graphics capabilities.

You can ensure that you provide the right graphics by installing all of the graphics software subsets on the model system. Be aware that installing all of the software subsets requires more disk space than loading only selected graphics software subsets.

7.5.3 Differences in Font Size

When generating the CDF through the Full Installation of a model system, you must consider the font sizes required by the target systems. If the target systems require different size fonts from those defined in the CDF, load the right font software subset when installing the model system.

The need for DECwindows 75dpi Fonts or DECwindows 100dpi Fonts depends on the resolution of the graphics adapter being used. On a system already installed with the operating system, this value can be determined by entering the following command:


# sizer -gr

When the resolution is 1024x768 or less, the DECwindows 75dpi Fonts are required. When the resolution is greater, the DECwindows 100dpi Fonts are required. If you are unsure of the resolution available on the systems to be cloned, select both font software subsets to ensure that the correct font is available.

Systems with multiple graphics adapters may require both the DECwindows 75dpi Fonts and DECwindows 100dpi Fonts if the adapters include those with 1024x768 or less resolution and those with greater resolution.

While there are other software subsets that contain fonts, only the DECwindows fonts are packaged separately by size.

Table 7-5 shows the different font sizes required on a model system and a target system.

Table 7-5: Font Sizes on a Model System and a Target System

System	Graphics Resolution	Required Font Size
model system	`1024x768`	`DECwindows 75dpi Fonts`
target system	`1280x1024`	`DECwindows 100dpi Fonts`

During the installation of the model system, the DECwindows 75dpi Fonts software subset is mandatory and is installed automatically; the DECwindows 100dpi Fonts software subset is optional. You should install the optional software subset to provide the necessary fonts for the Installation Cloning of the target system.

You can ensure that you provide the right fonts by installing all of the font software subsets on the model system. Installing all of the font software subsets will require more disk space than loading selected fonts.

7.5.4 Differences in Keyboard Type

When generating the CDF through the installation of a model system, you must consider the keyboard type of the systems that will be cloned using the CDF. If the systems that will be cloned have different keyboard types, load the right keyboard support software subset when installing the model system.

To determine the keyboard type on a system already installed with the current release of the operating system, use the following command:

# sizer -wk

Table 7-6 shows an example of the keyboard types on a model system and a target system.

Table 7-6: Keyboard Types on a Model System and a Target System

System	Keyboard Type
model system	`PXCAL`
target system	`LK444`

Based on the model system's configuration, the installation process automatically installs the software subset PCXAL Keyboard Support as a mandatory subset for the model system. Therefore, the software subset for LK444 Keyboard Support is optional. Installing this optional software subset results in some unnecessary software being loaded on the model system but allows the CDF to be suitable to clone the target system.

You can ensure that you provide the right keyboard type by installing all of the keyboard software subsets on the model system. Be aware that loading all keyboard software subsets requires more disk space on the model system than loading selected keyboard software subsets.

7.6 Step 2: Modifying the CDF

You have the option to modify the install.cdf file so that the Full Installation bypasses all user responses usually required during a Full Installation process. It is also recommended to modify host- and site-specific attributes so that the target system has a unique identify when the cloning process is complete.

Caution

Typographical errors and inserting attribute-value pairs into the wrong item may result in a failure during the Installation Cloning process and may render the cloned system unusable.
Attribute-value pairs cannot contain blank spaces because blank spaces cause data validation errors. Be very careful to remove all blank spaces, especially at the end of a line. When you want to give an attribute a null value, make sure there is nothing (null) after the equal sign ( = ).
Do not modify or remove attributes that are prefixed with an underscore ( _ ). These attributes, for example _action=create, are internal variables required by the Full Installation and Installation Cloning processes.

It is recommended that you do not modify the original install.cdf file located in the /var/adm/smlogs directory of an installed system. Instead, make a copy of install.cdf and modify the copy. The original CDF should be retained in the /var/adm/smlogs directory because it contains information about the initial system installation that could be valuable for future troubleshooting.

The next three sections describe how to set the confirmation and kernel option attributes to run the cloning in an unattended fashion, and how to modify host- and site-specific attributes to achieve uniqueness of the cloned system. Section 7.6.4 describes a common error to avoid when modifying the CDF.

7.6.1 Setting the CDF Confirmation Attribute to Eliminate User Intervention

By default, the installation process prompts the user to confirm whether or not the install.cdf file should be applied. To turn off this confirmation and eliminate the need for user intervention, the CDF confirmation attribute determines whether user confirmation is required before the CDF is used to start an Installation Cloning process. This feature is set with the prompt= attribute-value pair in the Inst_islinfo item in the CDF. You must always manually add this attribute to the CDF because the installation interfaces do not provide the ability to set this value. Valid values are:

prompt=yes -- means that the user will be asked to confirm the use of the install.cdf file to drive the installation process. If this attribute-value pair is not defined or is null, the Installation Cloning process defaults to prompt=yes.

prompt=no -- bypasses the CDF confirmation question and begins an Installation Cloning process automatically. This eliminates any user intervention at the system to be cloned.

A portion of an install.cdf file in Example 7-2 shows you where to include the prompt= attribute-value pair in the Inst_islinfo item:

Example 7-2: Adding the CDF Confirmation Attribute to the install.cdf File

install:
 
_item=Inst_islinfo
prompt=no
media_type=CDROM
server=cosmos
_action=create
srcloc=/ALPHA/BASE

7.6.2 Setting the Kernel Option Attribute to Eliminate User Intervention

The kernel_option attribute in the Inst_cinstall item controls the type of kernel components that are built into the tailored kernel and controls whether or not user intervention is required.

Note

The tailored kernel build on the target system does not automatically include the optional kernel components that were in the model system unless the kernel build type is set to interactive and the user intentionally selects them.

The values for the kernel_option attribute are:

kernel_option=interactive - Provides an interactive kernel build, which stops the cloning process to let the user select optional kernel components from a menu. You should set this value to interactive in order to select the same optional kernel components that are on the model system.

kernel_option=mandatory - Builds a kernel with all mandatory kernel components; no user intervention is required.

kernel_option=all - Builds a kernel with all mandatory and all optional kernel components; no user intervention is required.

A portion of the install.cdf file in Example 7-3 shows you where to include the kernel_option= attribute-value pair in the Inst_cinstall item. This example sets the value to mandatory, which automatically builds a kernel with mandatory components, which will not require any user intervention.

Example 7-3: Setting the Type of Kernel Build in the install.cdf File

install:
	_item=Inst_cinstall
	kernel_option=mandatory
	timeset=yes
  lang_env=C
	password=Bp2xAe46zVpUo
	timezone=New_York
	locality=America
	_action=create
	hostname=taurus

7.6.3 Setting Host- and Site-Specific Attributes

You must read this section if you are performing the Full Installation from CD-ROM; it is recommended to read this section if you are performing the Full Installation from a RIS server.

Setting host- and site-specific information such as host name, geographic location and area, date, and time are not necessary in the case of a RIS installation because these values are obtained from the RIS server automatically during the installation even if they are defined in the CDF. This statement is true for Full Installations from RIS and for Installation Cloning from RIS.

In the case of a stand-alone system installed from a CD-ROM, however, setting these values must be determined from the CDF that drives the Installation Cloning. If the CDF does not define these attributes, the values must be entered interactively during the software configuration phase of the Installation Cloning process that occurs after software has been loaded. If you want to eliminate the need for user intervention during the cloning process, you should define values for these attributes.

The host-specific attributes to be considered are:

Host Name
A system's host name is contained in the hostname= attribute-value pair in the Inst_cinstall item. Host names for model and target systems that exist on the same network must be unique, so you should change this value. If the hostname= attribute does not exist in the CDF, or if the value associated with this attribute is null, the installation process becomes interactive during the software configuration phase of the Installation Cloning process to request this information. If LSM configuration data is contained in the CDF, it is recommended that you set the lsm_hostname= attribute in the Inst_lsm_global item to the same host name specified by the hostname= attribute. Refer to the Installation Guide if you need guidelines for choosing a proper host name.

Password
Be aware that an encrypted value in the password= attribute means that all systems to be cloned share the same root password with the model system. You may want to consider leaving this value null so that the installation process becomes interactive to request a root password. For security reasons, sharing passwords among systems is not recommended. If you choose to retain the encrypted password in the CDF, remember that the password came from the model system and you should change the password on that model system to protect it from unauthorized users. Because the value of the password= attribute must be encrypted, this value cannot be set manually. If you need to change the password on the model system, the Installation Guide contains guidelines for choosing correct passwords.

The site-specific attributes to be considered are:

Geographic Location and Area
A system's geographic location and time zone are contained in the locality= and timezone= attribute-value pairs in the Inst_cinstall item. On a system already installed with the current version of the operating system, valid values for these attributes are located in the /etc/zoneinfo directory, the contents of which are shown in Example 7-4. Geographic locations that are divided into time zones are directories in /etc/zoneinfo. In Example 7-4, directories are followed by a slash ( / ).
Example 7-4: Contents of the /etc/zoneinfo Directory
```
 Africa/      EET          GMT+2     GMT-4     GMT5         London       SystemV/
America/     EST          GMT+3     GMT-5     GMT6         MET          Turkey
Antarctica/  EST5EDT      GMT+4     GMT-6     GMT7         MST          UCT
Arctic/      Egypt        GMT+5     GMT-7     GMT8         MST7MDT      US/
Asia/        Etc/         GMT+6     GMT-8     GMT9         Mexico/      UTC
Atlantic/    Europe/      GMT+7     GMT-9     Greenwich    NZ           Universal
Australia/   Factory      GMT+8     GMT0      HST          NZ-CHAT      W-SU
Belfast      GB-Eire      GMT+9     GMT1      Hongkong     Navajo       WET
Brazil/      GMT          GMT-0     GMT10     Iceland      PRC          Zulu
CET          GMT+0        GMT-1     GMT11     Indian/      PST8PDT      localtime@
CST6CDT      GMT+1        GMT-10    GMT12     Iran         Pacific/     posixrules
Canada/      GMT+10       GMT-11    GMT13     Israel       Poland       sources/
Chile/       GMT+11       GMT-12    GMT2      Jamaica      ROC          time
Cuba         GMT+12       GMT-2     GMT3      Japan        ROK          timezones
Dublin       GMT+13       GMT-3     GMT4      Libya        Singapore
```
Recent changes to locations and time zones to make them comply to industry standards have resulted in changes to this file. For example, locality=US/timezone=Eastern is now represented as locality=America/timezone=New_York. You can use either representation, but the new style is recommended. When you specify a value for a locality that is divided into time zones, you must choose a valid time zone for that location. The Installation Guide contains more information about locations and areas.
If the locality= and timezone= attributes do not exist in the CDF, or if the value associated with these attributes is null, the installation process becomes interactive during the software configuration phase to request this information. A locality= attribute can be present without a timezone= attribute because not all geographic locations are divided into time zones. For example, the geographic location Japan does not have time zones. In that situation, the installation process recognizes the fact that Japan does not have time zones and bypasses the request for a time zone.

Date and Time
It is not possible to specify dynamic values such as date and time in an install.cdf file and still retain accuracy at the cloned system. The ability does exist, however, for the install.cdf file to indicate that the date and time have been set previously either by one of the installation interfaces or through a RIS installation cloning process. The method used is the timeset= attribute-value pair in the Inst_cinstall item:
- timeset=no - Means that the system date and time have not been set previously. The Installation Cloning process becomes interactive to request this information.
- timeset=yes - Means that the system date and time have been set previously. Therefore, it is possible by using the timeset= attribute set to yes to continue the installation in an unattended fashion, even if the system time had not been set. The value of date and time on the target system is undetermined until the first user logs in and sets the date and time to the proper values using the date command.

7.6.4 Common Error: Trailing Blank Space

While modifying a CDF, a common error is to include a trailing blank space after an attribute-value pair. If the validation process detects a trailing blank space in the CDF, a message similar to the following is displayed:

-----------------------------------------Some errors occurred:
SetItmAttr: invalid attribute value kernel_option=all
-----------------------------------------

This error causes the installation process to stop. In the previous example, the validation process found a trailing blank space after the word all in the kernel_option=all attribute-value pair. The corrective action is to edit the CDF and remove the blank space. Then, restart the installation process on the target system.

7.7 Optional Step 3: Creating and Positioning Other User-Supplied Files

If you want to go a step further and recreate customized features of the model system on the cloned system, create preinstall, postload, and postreboot files. The Full Installation has the ability to invoke user-supplied files to perform customizations during a Full Installation. To learn more about invoking these files during a Full Installation, refer to Chapter 6.

You can also clone the configuration from a model system onto a target system. If you want to fully configure as well as install a target system, refer to Chapter 8 for information about how to create and apply a config.cdf file during a Full Installation.

The user-supplied files and config.cdf file are searched for in the same locations and order as the install.cdf file, which makes combining these features easy to do. If you want to take advantage of configuration cloning and invoke user supplied scripts to further customize the cloned system, refer to Chapter 6 and Chapter 8, respectively.

To continue with the Installation Cloning procedure, go to Section 7.8.

7.8 Step 4: Copying the CDF to the Right Location

The next step in the process is to copy the modified CDF to the right location. Because the install.cdf file must be located in and is searched for in the same locations as the user-supplied files and the config.cdf file for configuration cloning, the actual steps in the copy process are not duplicated here.

Based on your media requirements, decide where you want to move the install.cdf file and go to the referenced section shown in Table 7-7 for step-by-step procedures for copying the file.

Table 7-7: Acceptable Locations of the install.cdf File

Search Order	Location	Copy Instructions Located In
1	On a diskette in diskette drive `floppy0` or `floppy1`.	Section 6.8.1
2	In the `profile_set` subdirectory of the `/var/adm/ris/clients/sets` directory on the RIS server.	Section 6.8.2
3	In the `/var/tmp` memory file system (MFS) on the system to be cloned.	Section 6.8.3
4	In the `/isl` directory on the distribution media (local CD-ROM or extracted RIS area).	Section 6.8.4

7.9 Step 5: Beginning a Full Installation on the Target System

Once you have verified the contents of the install.cdf file and copied it to the right location based on your media requirements, begin a Full Installation on the target system as described in the Installation Guide. When the installation process finds the install.cdf file, an Installation Cloning process begins on the target system. If the Full installation process finds correctly named and placed user-supplied files or a config.cdf file, those files are executed as well.

If you start a Full Installation on the target system and the Full Installation graphical or text-based interface is displayed instead, the install.cdf file was not located in one of the four supported locations. In that case, copy the install.cdf file to one of the locations shown in Table 7-1, and restart the Full Installation on the target system.