8 Configuration Cloning

This chapter provides the following information:

An overview of Configuration Cloning

How does a Configuration Cloning happen?

A description of the format and contents of the config.cdf file

A sample config.cdf file

Restrictions pertaining to the system where the config.cdf file was generated and the type of systems that are suitable to be cloned from it

Step by step procedures, which describe how to save configuration information to a CDF, edit the CDF, and start the cloning process

8.1 What is Configuration Cloning?

Network services, naming services, printers, internet services, and electronic mail delivery must be configured to make users of a newly installed system productive and able to communicate with other systems and users. On a newly-installed system, system configuration tasks are performed from the Quick Setup application, the Custom Setup checklist, or the SysMan Menu. Before Configuration Cloning was available, configuration tasks had to be performed at each system individually.

Configuration Cloning lets you duplicate the configuration from an already-configured system onto one or more target systems, eliminating the need to perform the configuration tasks as a separate operation.

It is recommended that you use Configuration Cloning to clone systems with similar hardware and functions. Configuration cloning is ideal for cloning the same class or type of machine (for instance, all workstations or all servers). The criteria for determining whether cloning is suitable for your situation is if the systems are of the same type and have the same number and type of network adapters. Instead of configuring each system individually, you configure a single system, then replicate that model configuration among other systems of the same class or type.

You can also use the Configuration Cloning process to restore the configuration of a system if the current configuration becomes corrupted or if you want to go back to a previous configuration.

To achieve a fully automated installation and configuration of another system, Configuration Cloning can be combined with Installation Cloning to completely eliminate the need to perform these tasks at the target system itself. Installation cloning requires a separate install.cdf file that is created automatically when a system is installed. Refer to Chapter 7 for more information about Installation Cloning.

8.2 How Does it Happen?

When a system you designate to be a model system has been fully configured the way you want it, you use the sysman -clone -save command to save a snapshot of the system configuration data into a configuration description file (CDF). This file is named config.cdf, and it is saved in the /var/adm/smlogs directory by default. The information saved in the config.cdf file is used to duplicate the same configuration on similar systems. You may edit the config.cdf file and change any value (except the checksum), but there are certain host-specific attributes (such as host name and IP address) that must be edited to retain a unique network identity for the cloned systems.

The config.cdf file can be applied automatically to another system during a Full Installation process or can be applied manually after the system to be cloned is installed but is not yet configured. The following list summarizes your options:

To manually clone one system at a time, edit the config.cdf file to set host- and site-specific attributes, copy the CDF to the target system, and manually apply the CDF to an installed target system using the sysman -clone -apply command.

To clone one system during a Full Installation, edit the config.cdf file to set host- and site-specific attributes, and position the config.cdf file in one of four acceptable locations.

When you begin a Full Installation on a system you want to clone, the installation process looks for the config.cdf file in the order shown in Table 8-1.

Table 8-1: Search Order for the config.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 that contains 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).

To clone multiple systems during a Full Installation, write a postload script to define each system to be cloned and sets values for host- and site-specific attributes in the config.cdf file. The config.cdf file and the postload script are executed automatically by a Full Installation when they are placed in the right locations.

Note

Configuration Cloning is not just available at installation time; Section 8.11.2 has instructions on how to apply a configuration to an already-running system.

If you want more information, Figure 6-2 in Chapter 6 contains a theory of operation, which describes the points at which user-supplied files and CDFs are invoked during a Full Installation.

8.3 Configuration CDF Format and Contents

The config.cdf is organized by configuration component. Each component contains several groups in which there are one or more attribute-value pairs to define the configuration data. An equal sign ( = ) separates each attribute and its associated value.

The config.cdf file contains the following components:

The bindconfig component contains Domain Name Service (DNS) configuration data. Only cloning of a DNS client is supported; DNS servers cannot be cloned.

The internetServices component starts and stops the process that manages participation on the Internet.

The mail component contains information about the mail server configuration. Only cloning of a mail client is supported.

The networkAdapters component defines the type of network adapter that is configured.

The networkServices component specifies whether the system is a member of a cluster.

The networkedSystems component defines, among other things, the hosts in the /etc/hosts database.

The networks component defines the data in the /etc/networks file, which contains information about known networks that comprise the DARPA.

The nfs_export component defines whether the system is configured to export local file systems across the network.

The nfsconfig component defines the Networked File Systems (NFS) client and server settings.

The nisconfig component contains information about the Network Information Services (NIS) configuration.

The ntpconfig component contains Network Time Protocol (NTP) server information.

The printcap component contains information about defined printers similar to the information found in the /etc/printcap file.

The remoteWhoServices component manages the rwhod daemon (server that maintains the databases used by the rwho and ruptime daemons).

The routing component defines the routing configuration.

8.3.1 Sample Configuration CDF

Example 8-1 shows the bindconfig component in a config.cdf file. Comment lines begin with a number sign ( # ). The last piece of information within a config.cdf file component is Group: componentid, which contains internal information required by the cloning process for validation purposes.

Note

For space considerations, only a small portion of a config.cdf file is shown in the example. If you want to see an entire config.cdf file, use the sysman -clone -save command on a configured system to save configuration information to the default location /var/adm/smlogs/config.cdf. Then, use a text editor or another method of your choice to view the file.

Example 8-1: Portion of a config.cdf File

CHECKSUM=56823 
 
#
# CDF Created: Fri Apr 28 11:34:30 EST 2000
#
#
# Component: bindconfig
#
#
# Group: bind
#
/bindconfig/bind:
        configured=YES
        bindtype=CLIENT
#
# Group: resolver
#
/bindconfig/resolver:
        change_hostname=NO
        domain=mydomain.com
        precedence=first
#
# Group: ns
#
/bindconfig/ns:
        cdf_record=00000001
        ipaddress=16.29.1.1
        hostname=libra.mydomain.com
#
# Group: search
#
/bindconfig/search:
#
# Group: componentid
#
/bindconfig/componentid:
        manufacturer=Compaq Computer Corporation
        product=Domain Name Service Configuration
        version=DNS-1.1.4.17
        serialnumber=1.1.4.17
        installation=19990203184929.000000-300
        verify=7
#
# CDF Created: Fri Apr 28 11:34:47 EST 2000
#

8.4 Configuration Cloning Restrictions

It is recommended to adhere to the following restrictions when selecting or generating a config.cdf file to clone other systems:

Configuration cloning is not supported between different releases of the operating system. If you want to clone a configuration onto a system running Version 5.0A, the config.cdf file you use must be created from a model system that is installed and configured with Version 5.0A.

Software licenses are not cloned. The product authorization codes (PAKs) that you installed and registered on the original system are not cloned on the target system. You must run the License Manager application or the lmfsetup script on the cloned system to install and register software licenses.

A config.cdf file that was created on a system with multiple network interfaces (adapters) should not be used to clone the configuration on a system with only one network adapter . If you decide to do this, be careful to remove the extra adapter information from the CDF or the CDF will fail validation.

Configuration cloning is best suited for cloning similar class machines. It is recommended to use a CDF created from a server class system to clone servers and to use a CDF from a workstation class system to clone other workstations.
You do not want to clone a workstation class system with a CDF that was taken from a machine that is configured to be any type of server because the CDF contains too much server setup information that is not necessary on a workstation. This unnecessary information can prove harmful to the network. For example, if a system is configured to be the primary IP router for your site, you do not want to clone another one.

Configuration Cloning is not supported in a cluster environment. Do not save the configuration of a cluster member because individual cluster members share disks, and the information saved in the CDF relates to the entire cluster, not to individual members.

8.5 Summary of Configuration Cloning Procedures

The following list summarizes the steps required to clone the configuration from a model system to one or more target systems.

Use the sysman -clone -save command to save system configuration information from a configured model system to a config.cdf file.

Modify the config.cdf file to set host-specific attributes, and optionally, site-specific attributes.

Validate the CDF before you use it to clone another system.

To set up Configuration Cloning of multiple systems during a Full Installation process, optionally create a postload script to dynamically set host-specific values.

Copy the config.cdf file to the right location depending upon how it will be applied to the target system or depending upon your distribution media requirements.

Use the Full Installation process or the sysman -clone -apply command to apply the config.cdf file to the target system.

8.6 Step 1: Saving Configuration Information to a Configuration CDF

Unlike Installation Cloning, where the install.cdf file is created automatically, you must intentionally save configuration data into a config.cdf file. The reason the process is not automated is because without human intervention there is no automated way to be certain when a system configuration is complete. You can save configuration data into a CDF at any time after a system is installed, as often as you like. When configuration data is saved, any attribute that has no associated value will not be defined in the config.cdf file.

If you intend to clone the configuration of many systems using one config.cdf file, you should consider installing and configuring one system to use as the model system. That way, except for host-specific attributes, there is very little CDF editing required.

On a system that is configured the way you want it, use the sysman command with the following flags to save configuration data into a CDF:

sysman -clone -save filename

This command saves the current system configuration to /var/adm/smlogs/config.cdf unless you specify a different path and file name. Be aware that if you intend to clone a system configuration during a Full Installation process, the installation process searches for a file called config.cdf. A configuration CDF with any other name is not recognized.

The sysman -clone -save command also validates the CDF which is evidenced by the checksum number at the top of the config.cdf file. When you apply the CDF to clone a target system, the checksum number determines the integrity of the config.cdf file to protect against it from being rendered unusable by incorrect modifications. It is very important that you do not modify this checksum.

To list the status of all configured components, use the sysman command as follows:

sysman -clone -list

8.7 Step 2: Modifying Host- and Site-Specific Attributes in the Configuration CDF

The config.cdf file contains host- and site-specific attributes that must be edited to ensure each cloned system is uniquely configured on the network. It is suggested that you do not modify the original config.cdf file located in the /var/adm/smlogs directory. Instead, make a copy of the file and modify the copy. The original CDF should be retained in the /var/adm/smlogs directory because it contains information about the model system configuration that could be valuable for future troubleshooting or restoring the original configuration. You should save a backup of the modified config.cdf file as a record of your modifications.

Note

The top of the file contains a checksum number, which is used for validation purposes. Do not change this number because the cloning process will not be able to validate the CDF after which it cannot be used to clone another system.

If you plan to edit this file in any way, it is recommended that you do not modify any attribute or value that you do not understand. If you see a host- or site-specific value that you know is incompatible with the target system, for instance, the host name of the model system, you should change it. It is recommended that you only modify the attributes and values that are specifically described in this chapter.

Table 8-2 lists the host-specific attributes that must be modified before the configuration is applied so that cloned systems maintain a unique identity on the network. The third attribute should be considered if the hardware or processor type on the system to be cloned does not exactly match the system where the config.cdf file was generated.

Table 8-2: Host-Specific Attributes in the config.cdf File

Host-Specific Attribute	Description
`systemName=`	Sets the name of the system as it is known on the network. This attribute must be modified because each system must have a unique name. This attribute is located in the `networkAdapters` component in the `interface` group, and depending upon which other components are configured, the name may be specified in other attributes. Make sure to search for and change all occurrences of the system name.
`networkAddress=`	Sets the unique internet protocol (IP) address of the client system as it is identified on a network. This attribute is located in the `networkAdapters` component in the `interface` and is located in the `networkedSystems` component in the `hostMappings` group.
`devName=` and `type=`	Defines the network adapter attached to the system. This value is modified only if the network adapter on the system to be cloned is different from the one defined in the `config.cdf` file. Valid values for this attribute include `tu0` for Tulip devices, `ln0` for Lance devices, and `fddi0` for FDDI devices. To determine the network adapters available on the system to be cloned, issue the `show dev` command at the console mode prompt (>>>).

Section 8.7.1 describes the site-specific attributes you may want to modify; Section 8.7.2 describes how to use the CDFMODE attribute to modify component groups with more than one record.

8.7.1 Optional Step: Modifying Site-Specific Attributes in the Configuration CDF

The config.cdf file contains many network related attributes that you may want to consider editing if the systems you are cloning have different requirements. For example, you may be cloning all systems in a particular department or site that require a special network configuration. Attributes to consider modifying are the values for DNS server, netmask, domain name, type of network routing, network time protocol (NTP) server name, default printer, and printer and mail client configuration.

8.7.2 Using the CDFMODE Attribute for Component Groups with Multiple Records

The CDFMODE attribute applies only to component groups containing multiple records. CDFMODE is a global attribute that applies to all cdf_record labels within a component group throughout the entire CDF. An example of a component group containing multiple records is the hostMappings group within the networkedSystems component. This group represents the data in the /etc/hosts file.

The configuration CDF begins each record within a multiple-record group with the label cdf_record= to show that there is more than one record within the group. Example 8-2 shows an example of a host group with multiple records.

Example 8-2: Example of a Component Group with Multiple Records

# Component: networkedSystems # # Group: hostEquivalencies # /networkedSystems/hostEquivalencies: # # Group: hostMappings # /networkedSystems/hostMappings: cdf_record=00000001 networkAddress=127.0.0.1 systemName=localhost cdf_record=00000002 aliases=aries networkAddress=16.29.1.1 systemName=aries.mydomain.com cdf_record=00000003 networkAddress=16.29.1.15 systemName=pluto cdf_record=00000004 aliases=pices networkAddress=16.29.1.27 systemName=pices.mydomain.com # #

Table 8-3 lists and describes valid values for the CDFMODE attribute.

Table 8-3: Values for the CDFMODE Attribute

Value	Description
`MERGE`	Merges the component/group data with existing data on the target system. Duplicate data is ignored. This is the default behavior for the entire configuration CDF if `CDFMODE` is not specified.
`APPEND`	Appends the component and group data to existing configuration data on the target system. Duplicate data is not ignored.
`REPLACE`	Replaces the component and group data on the target system with the data in the configuration CDF. Data existing on the target system, but not in the CDF will be removed. Data that exists in the configuration CDF, but not on the target system will be applied. Data existing in both the CDF and the target system will be modified accordingly.

The CDFMODE attribute can be placed outside of any component contained within a config.cdf file.

Note

As shown in Example 8-3, the CDFMODE= attribute must start in the first column of the line on which it is located; do not indent it by inserting spaces or tab characters.

The CDFMODE value is in effect until another CDFMODE= statement is reached. Example 8-3 shows the use of the CDFMODE attribute. In this example, the default mode MERGE is in effect until CDFMODE=REPLACE is encountered. This causes the entire /etc/hosts file to be replaced with the contents of the CDF. After that, CDFMODE=MERGE (which is the default mode) is encountered, and the remaining attributes are merged onto the system to be cloned.

Example 8-3: Inserting the CDFMODE Attribute into a CDF

CDFMODE=REPLACE # # Component: networkedSystems # # Group: hostEquivalencies # /networkedSystems/hostEquivalencies: # # Group: hostMappings # /networkedSystems/hostMappings: cdf_record=00000001 networkAddress=127.0.0.1 systemName=localhost cdf_record=00000002 aliases=host1 networkAddress=16.29.1.2 systemName=host1.mydomain.com cdf_record=00000003 networkAddress=16.29.1.16 systemName=host2 cdf_record=00000004 aliases=host3 networkAddress=16.29.1.28 systemName=host3.mydomain.com # CDFMODE=MERGE

8.8 Step 3: Validating the Modified CDF

After you have modified the config.cdf file, it is recommended that you validate its contents by entering the following command:


# sysman -clone -validate filename

If you do not supply a file name, the command assumes the file name is /var/adm/smlogs/config.cdf. This command uses the checksum at the top of the file to determine whether modifications you made have rendered the file unusable to clone other systems. The validation process attempts to isolate the component group in which the error occurred and a message is displayed. If validation errors occur, obtain an unmodified original copy of the config.cdf file and begin again.

8.9 Optional Step 4: Creating a Script to Clone Multiple Systems During a Full Installation

To use a config.cdf file during a Full Installation to clone many systems at once, it is suggested that you create a single, representative config.cdf file with the values of host-specific values set to dummy variables. Then, manually enter a value for the dummy variables before applying them to a system, or you can create a script to be invoked during a Full Installation process to dynamically modify the dummy variables in the config.cdf file before it is applied to the target system.

The Full Installation process is designed to look for specific scripts during a Full Installation in the same places where the config.cdf file is located. If the installation process finds a script named postload in the right location, the postload script is executed after software subsets are loaded but before kernel build takes place. This is also the phase where the config.cdf file is applied. Appendix B contains an example of just such a postload script, which shows how to create dummy variables for host-specific values. The postload file and the config.cdf file must reside in the same location.

Section 8.10.3 describes the four locations where the installation process looks for the postload and config.cdf files.

8.10 Step 5: Copying the Configuration CDF to the Right Location

The location of the config.cdf file depends on whether you are cloning the system configuration during a Full Installation or if you are cloning the configuration on a system that is already installed but not yet configured:

If you intend to apply the config.cdf file manually on a single system or to one system at a time, copy the config.cdf file to a diskette as shown in Section 8.10.1 or set up a temporary network to move the config.cdf file to the system to be cloned as shown in Section 8.10.2.

If you want to clone a system configuration during a Full Installation, refer to Section 8.10.3 for the list of supported locations that are searched. These locations are the same places where the installation process searches for user-supplied scripts and the install.cdf file.

8.10.1 Copying the Configuration CDF to a Diskette

Use the following procedure to copy the config.cdf file to a diskette:

Format, write a new disk label, and create a new file system on a diskette:

# fddisk -fmt /dev/rdisk/floppy0a
# disklabel -wr floppy0 rx23
# newfs /rdisk/floppy0c

Mount the diskette drive on the /mnt mount point:
```
# mount /dev/disk/floppya /mnt
```

Save the configuration data to the diskette using the file name config.cdf:
```
# sysman -clone -save /mnt/config.cdf
```

Once the config.cdf file is copied to the diskette, insert and mount the diskette into the diskette drive of the system to be cloned. Go to Section 8.11.2 for instructions about applying the config.cdf file manually to automatically configure the system.

8.10.2 Copying the Configuration CDF to a System That Is Not Connected to the Network

If the system you want to clone is installed, but is it not configured and does not have a diskette drive, there is no way to copy the config.cdf file there unless a temporary network connection is created. Use the following procedure to set up a temporary network and then use the file transfer protocol (FTP) to copy the config.cdf file to the system to be cloned. You will need to know the Internet Protocol (IP) address of the system from which you are copying the CDF.

The following steps are performed on the system that is already installed but is not yet configured and assume you have root privileges on both machines:

On the system to be cloned, issue the following command to determine the network adapter and IP address:
```
# ifconfig -a
```
Look for the line that contains the IP address of the machine to know which network interface is the one to configure.

Temporarily connect the network adapter to the network:
```
# ifconfig adapter_name IP_address
```

Check the network connection you just set up to make sure your system recognizes the model system where the CDF is located:
```
# /usr/sbin/ping -c2 model_system_name
```

Change to the following directory, which is the default location of the config.cdf file:
```
# cd /var/adm/smlogs
```

Use the file transfer protocol (FTP) to connect to the model system where the config.cdf file was generated. Because the domain name service (DNS) is not running, specify the IP address of the model system rather than the system name:
```
# ftp model_system_IP_address
```

Log in to FTP as the user root, and enter the root password.

Change to the directory where the config.cdf file is located. This example assumes the file is in the default location:
```
ftp> cd /var/adm/smlogs
```

Copy (get) the config.cdf file to move it to the system to be cloned:
```
ftp> get config.cdf
```

Close the connection and exit out of FTP:
```
ftp> bye
```

The config.cdf file is now located in the /var/adm/smlogs directory of the system to be cloned. Go to Section 8.11.2 for instructions about applying the config.cdf file manually to configure the system.

8.10.3 Copying the Configuration CDF to Distribution Media

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

Because the config.cdf file is located in and is searched for in the same locations as the user-supplied files and the install.cdf file for Installation Cloning, the actual steps in the copy process are not duplicated here. Based on your media requirements, decide where you want to move the config.cdf file and go to the referenced section in column 3 for step-by-step procedures for copying the file.

Table 8-4: Acceptable Locations of the config.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

When you have copied the config.cdf file to the right location, go to Section 8.11.1 to learn how to apply the CDF to a target system.

8.11 Step 6: Applying the Configuration CDF to a Target System

When applying a config.cdf file to a target system, any attribute not defined in the CDF will remain unchanged or unconfigured on the target system. Depending upon your needs, the config.cdf file clones a system in the following ways:

Section 8.11.1 confirms that the Full Installation will do the cloning if the CDF is in the right place.

Section 8.11.2 describes how to manually apply the CDF to the target system

Section 8.11.3 describes how to use the CDF to restore the configuration on a system with a corrupted configuration

8.11.1 Applying the Configuration CDF During a Full Installation

When the Full Installation process finds a config.cdf file in any one of the locations shown in Section 8.10.3, the CDF is applied to the system after file systems are created, software is loaded, and the system is rebooted off the newly installed system disk. The newly installed system will be configured exactly as defined in the CDF.

8.11.2 Applying the Configuration CDF Manually to a Running System

When a config.cdf file is copied to a diskette, which has been inserted into the diskette drive and mounted or has been copied to the /var/adm/smlogs directory on a system to be cloned, use the sysman command with the following syntax to apply the configuration to the system:

sysman -clone -apply filename

If you do not specify a full path and file name, the sysman command assumes the default location and file name /var/adm/smlogs/config.cdf. If you placed the config.cdf file in a location other than /var/adm/smlogs or called the file something other than config.cdf, you must specify the path and exact file name on the command line.

8.11.3 Restoring a System Configuration Using the Configuration CDF

To restore a corrupted system configuration or to simply go back to a previous configuration that is stored in a config.cdf file, make sure the right config.cdf file is in the /var/adm/smlogs directory, and issue the following command:

sysman -clone -apply

If the configuration CDF is stored at a location or is called something other than /var/adm/smlogs/config.cdf, you must specify the full path in the command line.