[Return to Library] [Contents] [Previous Chapter] [Next Chapter] [Index] [Help]


5    Cloned Installations

This chapter explains how to use RIS to set up and manage cloned installations. Topics include:


[Return to Library] [Contents] [Previous Chapter] [Next Section] [Next Chapter] [Index] [Help]


5.1    Installation Cloning Overview

A cloned installation provides the ability to duplicate the installation configuration from a system that has already been installed with Digital UNIX Version 4.0 or higher on to systems with similar hardware configurations.

Cloning is ideal for environments in which there are many of the same or similarly configured systems. The installation of a model system can be duplicated on other systems using this procedure. The benefits are that the resulting installations are identical and limited user input is required during a cloned installation.

Cloning also provides the ability to easily reinstall a system which is identical to the prior system installation.

When Digital UNIX Version 4.0 is installed on a system, the installation procedure creates a Configuration Description File (CDF). After the installation is complete, the CDF is located on the newly-installed system in /var/adm/smlogs/install.cdf. The CDF contains the following information about the installation:

If you copy the CDF that was created on an already-installed RIS client to the /var/adm/ris/clients/cdf area on the RIS server, you can register new RIS clients for cloned installations. You do this by registering new clients to a RIS environment as well as to a CDF. If a RIS client is registered to a CDF and boots across the network to start an installation, the CDF is retrieved and used by the installation procedure to provide the answers to all installation configuration questions.


[Return to Library] [Contents] [Previous Chapter] [Next Section] [Next Chapter] [Index] [Help]


5.2    Modifying the CDF

Digital does not recommend modifying the CDF in any way. Modifying a CDF may cause the installation to fail and may result in an unusable client system. Therefore, CDF modification is unsupported.


[Return to Library] [Contents] [Previous Chapter] [Previous Section] [Next Section] [Next Chapter] [Index] [Help]


5.3    Prerequisites

The only requirements for a system to use installation cloning are:


[Return to Library] [Contents] [Previous Chapter] [Previous Section] [Next Section] [Next Chapter] [Index] [Help]


5.4    Acceptable Differences Between the CDF and the System to Be Cloned

Differences in the disk configuration, graphics adapter, keyboard type, and fonts are acceptable as explained in the following sections.


[Return to Library] [Contents] [Previous Chapter] [Previous Section] [Next Section] [Next Chapter] [Index] [Help]


5.4.1    Acceptable Differences in Disks Configurations

The system to use installation cloning should have the same configuration as the system where the CDF was generated. However, it is possible to support differences in configuration.

The system to use installation cloning must have the same disk configuration for those disks on which /, usr, swap1, var (if not a directory within usr) and swap2 (if allocated) are to be installed as the system on which the CDF was generated. The same disk configuration means that the disk type (for example RZ26) and the device name (for example rz3) must match. If the partition tables on these disks are not the same, the software specified in the CDF may not fit on to the system.

It does not matter if disks other than those referenced previously are different or not on the system to use installation cloning. Consider this scenario: A CDF generated on system SYSA, which has an RZ26 at rz0 and an RZ25 at rz1 and /, usr, and swap1 are placed on rz0. SYSB has an RZ26 at rz0 and an RZ26 at rz1. SYSB can use the CDF from SYSA assuming there are no other differences. The difference in disk type at rz1 is acceptable. If the disks at rz0 were different, an installation cloning could not be performed.


[Return to Library] [Contents] [Previous Chapter] [Previous Section] [Next Section] [Next Chapter] [Index] [Help]


5.4.2    Acceptable Differences in Graphics Adapters

To reduce the disk space required when installing Digital UNIX, the software required to support the different graphics options has been packaged so that the subsets required to support options that are not on your system are not installed. This determination is done automatically by the installation process and guarantees that the appropriate subsets are loaded. However, when a system uses installation cloning, the subsets loaded onto the system are defined by the contents of the CDF. Therefore, if the system to be installed has a different graphics type than the system on which the CDF was created, the appropriate graphics support will not be installed.

When generating the CDF through the full installation of a system, you must consider the graphics options of the systems that will be cloned from the CDF. If any of the systems to be cloned have different graphics options, you must load the subsets required to support the graphics options needed by those systems.

When selecting subsets, look in the Windowing Environment category for subsets of the name X Servers for <xxx>. The <xxx> will be replaced with a name that describes which graphics options the subset supports. In Digital UNIX Version 4.0, the following graphics subsets are available:

X Servers Base - device independent X Server support (always loaded)
X Servers for Open3D - supports the ZLXp-L graphics adapter
X Servers for PCbus - support for EISA and PCI bus graphics adapters
X Servers for TurboChannel - support for TurboChannel bus graphics adapters

Note

X Servers for PCbus adapters supported by Digital UNIX are specified in the Software Product Description (SPD).

The following example explains an acceptable graphics cloning scenario.

SYSA and SYSB are determined to be similar enough to allow the CDF from SYSA to be used for installation cloning of SYSB. SYSA has an Open3D graphics option while SYSB has a QVision graphics option (a PCbus based adapter). When installing SYSA, the X Servers for Open3D subset will be mandatory while the X Servers for PCbus subset will be optional. Installing this optional subset ensures that the appropriate subset is installed when doing the installation cloning of SYSB. If you do not install the optional subset, the graphics capabilities of SYSB are likely to be disabled.

Digital does not recommend using the CDF from a system without graphics support to clone systems with graphics support. There are several subsets that will not be loaded on these systems that are mandatory for systems with graphics support.

If you are unsure of which graphics options are available on the systems you want to clone, install all of the graphics subsets that are available. However, installing all of the subsets requires more disk space than loading only selected graphics subsets.


[Return to Library] [Contents] [Previous Chapter] [Previous Section] [Next Section] [Next Chapter] [Index] [Help]


5.4.3    Acceptable Differences in Font Types

In order to reduce the disk space required when installing Digital UNIX, the software required to support the 75dpi and 100dpi DECwindows fonts are contained in individual subsets. By doing this, the installation will load only the fonts required for the system and leave the other as an optional subset. This determination is done automatically by the installation process. When installation cloning occurs, the fonts loaded are defined by the contents of the CDF. If the system to be cloned requires a different size font from those in the CDF, the system to be cloned will not have the appropriate fonts loaded.

When generating the CDF through the full installation of a system, you must consider the font sizes required by the systems that will be cloned from the CDF. If the systems to be cloned require other font sizes, load the appropriate font subset when installing the 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 running Digital UNIX, this value can be determined by invoking 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 subsets to ensure 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 subsets that contain fonts, only the DECwindows fonts are packaged separately by size.

The following scenario explains an acceptable font difference.

SYSA is being installed with the intention of using its CDF to perform installation cloning on other systems, including SYSB. The graphics adapter on SYSA provides a resolution of 1024x680 while the adapter on SYSB provides a resolution of 1280x1024. When installing SYSA, the DECwindows 75dpi Fonts is mandatory and DECwindows 100dpi Fonts is optional. Select the optional subset as well to provide the necessary fonts for the installation cloning on SYSB.

If you are unsure of the fonts available on the systems you want to clone, load all of the font subsets that are available. However, loading all of the font subsets requires more space than loading selected fonts.


[Return to Library] [Contents] [Previous Chapter] [Previous Section] [Next Section] [Next Chapter] [Index] [Help]


5.4.4    Acceptable Differences in Keyboard Type

In order to reduce the disk space required when installing Digital UNIX, the software required to support the different Digital keyboard types is contained in individual subsets. By doing this, the installation will load only the software required. This determination is done automatically by the installation process. However, when an installation cloning occurs, the keyboard support to be loaded is defined by the contents of the CDF. If the system to be installed has a different keyboard type than the system on which the CDF was created, that system will not load the appropriate keyboard support.

When generating the CDF through the installation of a 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 appropriate keyboard support subset when installing the system. The keyboard type can be determined from information available when the system is in console mode or by simply looking at the model number which can generally be found on the underside of the keyboard itself.

The following scenario explains an acceptable keyboard difference.

SYSA is being installed with the intention of using its CDF to perform installation cloning on other systems, including SYSB. SYSA has a PXCAL keyboard while SYSB has an LK444 keyboard. During the installation of SYSA, the subset PCXAL Keyboard Support is mandatory. However, the subset LK444 Keyboard Support is optional. Selecting this optional subset results in some unnecessary software being loaded on SYSA, but allows the CDF to be appropriate for use on SYSB.

If you are unsure of the keyboard types available on the systems you want to clone, load all of the keyboard subsets that are available. However, loading all of the keyboard subsets requires more disk space than loading selected keyboard subsets.


[Return to Library] [Contents] [Previous Chapter] [Previous Section] [Next Section] [Next Chapter] [Index] [Help]


5.5    RIS Administrator Tasks

The following steps must be performed prior to attempting to register a client for a cloned installation:

  1. Copy the CDF to the RIS server as described in the following section.

  2. Add the client on the RIS server as shown in Section 6.2.


[Return to Library] [Contents] [Previous Chapter] [Previous Section] [Next Section] [Next Chapter] [Index] [Help]


5.5.1    Copying the CDF to the RIS Server

Copy the CDF, /var/adm/smlogs/install.cdf, from the system where is was created into the following directory on the RIS server: /var/adm/ris/clients/cdf using the copy tool you usually use (for example ftp, dcp, or rcp ).

Since all CDFs created during an installation will have the file name install.cdf, you should establish a naming convention which lets you easily distinguish one CDF from another. For example, the CDF for an AlphaStation 400 system could be called alphastation400.cdf. There is no restriction on the file name you use for a CDF.


[Return to Library] [Contents] [Previous Chapter] [Previous Section] [Next Section] [Next Chapter] [Index] [Help]


5.5.2    Adding the Client System to Be Cloned on the RIS Server

Section 6.2 describes the RIS client registration process.


[Return to Library] [Contents] [Previous Chapter] [Previous Section] [Next Section] [Next Chapter] [Index] [Help]


5.6    Determining CDF Registration

To determine if a RIS client is registered to a CDF, examine the RIS database file, /var/adm/ris/clients/risdb, on the RIS server. The name of the CDF is specified in the fourth field: fields are separated by a colon. In the following sample entry in the risdb file, dec3000.cdf is the configuration description file to which the client is registered:

coral:08-00-2b-e6-76-77:ris2.alpha,product_1:dec3000.cdf


[Return to Library] [Contents] [Previous Chapter] [Previous Section] [Next Section] [Next Chapter] [Index] [Help]


5.7    Removing a Client from CDF Registration

You can remove a client from CDF registration by using the Modify option from the RIS Utility Main Menu. When you are prompted to specify a CDF for the client, enter n or press Return to register the client without specifying a CDF.


[Return to Library] [Contents] [Previous Chapter] [Previous Section] [Next Section] [Next Chapter] [Index] [Help]


5.8    Deleting CDFs from the RIS Server

If a CDF is no longer needed, you can delete the CDF by removing the appropriate file from the /var/adm/ris/clients/cdf directory.

Before deleting a CDF, you should ensure that no clients are registered for the CDF being deleted by examining the RIS database file, /var/adm/ris/clients/risdb, on the RIS server. The name of the CDF is specified in the fourth field: fields are separated by a colon. In the following sample entry in the risdb file, dec3000.cdf is the CDF to which the client is registered:

coral:08-00-2b-e6-76-77:ris2.alpha,product_1:dec3000.cdf


[Return to Library] [Contents] [Previous Chapter] [Previous Section] [Next Chapter] [Index] [Help]


5.9    Messages Displayed During a Cloned Installation

The messages displayed during a cloned installation are documented in the Installation Guide.