• Overview of the installation cloning process and support of user-supplied files

• Role of the administrator

• Theory of operation for invoking user-supplied files and CDFs

• Description of the CDF

• Relationship between the user-supplied files and the CDF

• Acceptable differences between the CDF and the systems to be cloned

• Modifying the CDF to achieve unattended installation cloning of client systems

• Creating files for execution during a Digital UNIX full installation or installation cloning

• Moving the CDF and files to the appropriate distribution media (diskette, RIS server, or CD-ROM)

When a system is installed with Digital UNIX Version 4.0B, a configuration description file (CDF) is generated that contains the results of the questions answered during the installation. This file is located on the installed system in the /var/adm/smlogs directory under the file name install.cdf. The CDF contains all the configuration information required to perform an initial system installation on a client system.

CDFs and user-supplied files can be used independently or in any combination. The CDFs and user-supplied files can be located on different sources. For example, the install.cdf file may be on a diskette, the preinstall file might come from the RIS server, and the postload file might come from the /isl directory of the distribution media.

The installation process searches for the install.cdf, preinstall, and postload files in the following order of priority:

1. The / (root) directory of diskette drive fd0 or fd1. If a diskette is used, it requires a standard UNIX File System (UFS).

2. The /var/adm/ris/clients/sets/profile_set directory on a RIS server where profile_set is a user-created directory name

3. The /var/tmp directory on the system to be installed. Keep in mind that CDFs or user-supplied files cannot be delivered in the /var/tmp directory. They can, however, be copied into this directory by executing the preinstall file, which has been previously customized to manipulate a CDF or other user-supplied file.

4. In the /isl directory of the distribution media (for CD-ROM or RIS installations) or the /isl directory of an extracted RIS area (for RIS installations only).

The CDF contains the following information about an installation:

• File systems that were created: / (root), /usr, and var

• Swap space that was created

• 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 or Advanced File System)

• System-specific information such as host name and root password and site-specific information such as geographic location, time zone, and date and time

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

• Software subsets that were installed

The CDF, install.cdf, is located on a newly installed system in the /var/adm/smlogs directory.

NOTE

CDFs used in previous versions of the operating system may not be compatible with Digital UNIX Version 4.0B.

Four items are defined in the installation CDF:

• Inst_islinfo contains initial system load information that conveys the state of the system before the start of the installation process

• Inst_filesystem contains file system information such as the number and type of file systems that were created on the installed 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 contains a list of the installed Digital UNIX base software subsets

• Inst_cinstall conveys client system configuration information 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 installation configuration phase.

install:
      _item=Inst_islinfo
      prompt=no			*
      media_type=REMOTE
      server_timezone=Eastern
      timeset=1
      server_locality=US
      server=daria
      risdir=/
      _action=create
      srcloc=daria:
      client=kramer

install:
      _item=Inst_filesystem
      maj_min_num=8388608
      disk_number=0
      disk_name=rz0
      controller_type=SCSI
      name=root
      partition=a
      controller_number=0
      disk_type=RZ26L
      _action=create
      file_system_type=UFS

install:
      _item=Inst_filesystem
      maj_min_num=8388608
      disk_number=0
      disk_name=rz0
      controller_type=SCSI
      name=usr
      partition=g
      controller_number=0
      disk_type=RZ26L
      _action=create
      file_system_type=UFS

install:
      _item=Inst_filesystem
      maj_min_num=8388608
      disk_number=0
      disk_name="in /usr"
      controller_type=SCSI
      name=var
      partition=g
      controller_number=0
      disk_type=RZ26L
      _action=create
      file_system_type=UFS

install:
	     _item=Inst_filesystem
	     maj_min_num=8388608
	     disk_number=0
	     disk_name=rz0
	     controller_type=SCSI
	     name=swap1
	     partition=b
	     controller_number=0
	     disk_type=RZ26L
	     _action=create
	     file_system_type=swap

install:
	     _item=Inst_subsets
	     names=OSFBASE410,OSFBIN410,OSFBINCOM410,OSFCDEDT410,OSFCDEMAIL410,
OSF CDEMIN410,OSFCLINET410,OSFCMPLRS410,OSFDPSFONT410,OSFFONT15410,OSFHWB
ASE410,OSFHWBIN410,OSFHWBINCOM410,OSFKBDLK401410,OSFMITFONT410,OSFNETCON
F410,OSFNETSCAPE410,OSFNFS410,OSFNFSCONF410,OSFOLDX11410,OSFPRINT410,OSF
SER410,OSFSERTC410,OSFSYSMAN410,OSFTCLBASE410,OSFTKBASE410,OSFX11410,OSF
XADMIN410,OSFXPRINT410,OSFXSYSMAN410
	     _action=create
	     advflag=1

install:
	     _item=Inst_cinstall
	     kernel_option=all			*
	     password=C36V.nMSW0j/o
	     timeset=yes
	     timezone=Eastern
	     locality=US
	     _action=create
	     hostname=kramer

The attribute-value pairs within individual items differ as a result of the distribution method (CD-ROM or RIS) that was used to perform the initial installation of the model system.

To use a single CDF to clone many systems, consider leaving the system-specific attributes such as host name and password null, but provide attributes for site-specific attributes such as kernel option, time zone, geographic location, and date and time.

To reduce the disk space required when Digital UNIX is installed, the software required to support the different graphics adapters, font sizes, and keyboard types has been packaged so that only the software subsets required to support options present on the system are mandatory and installed automatically. All other software subsets are considered optional and are not installed unless you specifically select them. Determining the mandatory software subsets for a system is done automatically by the installation process and guarantees that only appropriate software subsets are installed.

However, when a system is installed using installation cloning, the software subsets installed on to the system are defined in the CDF. Therefore, if the system to be cloned has a different graphics adapter, font size, or keyboard type than the system on which the CDF was created, the appropriate software subsets will not be installed and the cloned system may not be usable.

The system to be cloned must have the same disk configuration for the disks on which root, usr, swap1, var (if it is not a directory under /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 rz0) must match. If the partition tables for these disks are not identical on both systems, the software defined in the CDF may not fit on to the system to be cloned or would overlap the disk partitions.

When selecting software subsets, 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. In Digital UNIX Version 4.0B, the following graphics software subsets are available:

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

• X Servers for Open3D -- Supports the ZLXp-L graphics adapter

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

• X Servers for TurboChannel -- Supports TurboChannel bus graphics adapters

Note

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

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. If you use a CDF from a system without graphics capabilities to clone a system with graphics capabilities, the desktop environment on the cloned system will be corrupted.

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

During an installation cloning, the font software subsets to be installed are defined in the CDF. If the system to be cloned requires a different size font than those defined by the software subsets 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 model system, you must consider the font sizes required by the systems to be cloned from the CDF. If the systems to be cloned require different size fonts, load the appropriate 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 Digital UNIX, this value can be determined by entering the following command:

# sizer -gr

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.

If you are unsure of the fonts available on the systems you want to clone, you can ensure that you provide the appropriate fonts by installing all of the font software subsets on to the model system. Installing all of the font software subsets will require more space than loading selected fonts.

During an installation cloning, the keyboard support software subset to be installed is defined in the CDF. If the system to be cloned has a different keyboard type than the model system, the cloned system will not have the appropriate keyboard software installed.

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 appropriate keyboard support software subset when installing the model system. The keyboard type can be determined from information available when the system is in console mode or by looking at the model number on the underside of the keyboard.

If you are unsure of the keyboard types available on the systems you want to clone, you can ensure that you provide the appropriate keyboard type by installing all of the keyboard software subsets. However, loading all keyboard software subsets will require more disk space than loading selected keyboard software subsets.

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

The CDF confirmation question is now configurable through the prompt= attribute-value pair in the Inst_islinfo item in the CDF. The value of the prompt= attribute determines whether confirmation is required before the CDF is used to start an installation cloning process. Valid values are:

• prompt=yes -- means that the user will be asked to confirm that the CDF should drive the installation cloning process.

• prompt=no -- means that the installation cloning process will bypass the CDF use confirmation question and begin an installation cloning process automatically.

A portion of a CDF in the following example shows you where to include the prompt= attribute-value pair in the Inst_islinfo item:

install:

_item=Inst_islinfo
prompt=no
media_type=CDROM
server=cosmo
_action=create
srcloc=/ALPHA/BASE

The kernel_option attribute in the Inst_cinstall item allows a noninteractive tailored kernel build with all kernel options (mandatory and optional) or mandatory kernel options only. In addition, the interactive value can be specified to allow you to tailor the kernel. The values for the kernel_option attribute are defined as follows:

• kernel_option=interactive -- Provides an interactive kernel build. This is the default setting for this attribute.

• kernel_option=mandatory -- Provides a noninteractive kernel build that selects mandatory kernel options only.

• kernel_option=all -- Provides a noninteractive kernel build that selects all (mandatory and optional) kernel options.

A portion of a CDF in the following example shows you where to include the attribute-value pair into the Inst_cinstall item:

install:

_item=Inst_cinstall
kernel_option=all
password=SdDt78fuPrMkE
timeset=yes
timezone=Eastern
locality=US
_action=create
hostname=kramer

Kernel build failures that occur during a noninteractive kernel build cause the kernel build process to become interactive and provides the user with options for proceeding.

Setting site- and system-specific information such as host name, geographic location, time zone, date, and time are trivial in the case of a RIS installation because these values are obtained from the RIS server automatically during the installation. This statement is true for full installations from RIS or from a RIS installation cloning process.

In the case of a standalone system installed by a CD-ROM installation cloning process, 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 configuration phase of the installation cloning process that occurs after software has been loaded.

The system-specific attributes to be considered are:

Actions to be carried out before file systems are created and software subsets are loaded might include writing a customized disk label to one or more disks.

You would not want the preinstall file to execute any function that requires the installed file systems and software to be available because these phases of the installation have not yet been completed.

The user-supplied file must be named preinstall, and the preinstall file and any files that it calls require execute permission.

It is not necessary that this file be contained in the same location in which the CDF and postload files are found.

If execution of the preinstall file fails, the preinstall file is responsible for supplying its own status or error messages. Digital does not guarantee the results of executing the script or program but does guarantee that upon successful completion, the installation process proceeds.

The installation process queries the return status from the execution of the preinstall file and terminates the installation process if a non-zero return status is received.

The installation process searches for the preinstall file in the following order of priority:

# /dev/rrz8a:
type: SCSI
disk: rz26
label:
flags:
bytes/sector: 512
sectors/track: 57
tracks/cylinder: 14
sectors/cylinder: 798
cylinders: 2570
sectors/unit: 2050860
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0		# milliseconds
track-to-track seek: 0	# milliseconds
drivedata: 0

8 partitions:
#      size  offset  fstype [fsize bsize  cpg]
 a:  131072       0  4.2BSD   1024  8192   16  # (Cyl.    0 - 164*)
 b:  262144  131072  unused   1024  8192       # (Cyl.  164*- 492*)
 c: 2050860       0  unused   1024  8192       # (Cyl.    0 - 2569)
 d:  552548  393216  unused   1024  8192       # (Cyl.  492*- 1185*)
 e:  552548  945764  unused   1024  8192       # (Cyl. 1185*- 1877*)
 f:  552548 1498312  unused   1024  8192       # (Cyl. 1877*- 2569*)
 g: 1210000  393216  4.2BSD   1024  8192   16  # (Cyl.  492*- 2009*)
 h:  447644 1603216  4.2BSD   1024  8192   16  # (Cyl. 2009*- 2569*)

Actions to be carried out after software subsets are loaded might include creating additional file systems or installing additional software that was not installed as part of the Digital UNIX base operating system.

The postload file and any files that postload calls require execute permission. The installation process searches for the postload file in the following order of priority:

#!/sbin/sh
#
# postload - script which is invoked after the subset load of a full
#	installation.  The script creates a new file system and
#	adds an entry in the fstab file.  Doing this will make the
#	file system available as soon as the installation completes.

#
# Create a new file system on rz2c which is to be mounted at /usr/users
#

echo "postload:  creating new file system on rz2c\n"

# First, make sure that all device special files exist

(cd /dev; ./MAKEDEV rz2)

# Next, create the UFS file system on rz2c, an RZ26L disk.

/usr/sbin/newfs -F /dev/rrz2c RZ26L ||
{
	   echo "postload:  failed to create a new file system on rz2c\n"

	   # We consider this a nonfatal error and allow the install to
	   # continue.  This is done by returning 0.  Otherwise, exit with a
	   # non-zero value.

	   exit 0
}

# Next, add an entry to fstab so that this new file system is
# automatically mounted when the system boots.

# NOTE:  the actual installed file systems are mounted at /mnt.
# Therefore, we want to add the entry to /mnt/etc/fstab and
# not /etc/fstab.

echo "/dev/rz2c	/usr/users	ufs rw 1 2" >> /mnt/etc/fstab

# Finally, make sure the mount point is created.  Once again, create it
# relative to /mnt.

/bin/mkdir /mnt/usr/users

# Process complete!

exit 0

fddisk-fmt raw_diskette_device

disklabel-wr diskette_drive disk_type

newfsraw_diskette_device_partition

Use commands similar to the following to format the diskette in diskette drive fd0, write a new disk label specifying the rx23 type of diskette, and creating a new file system on the entire diskette (partition c):

1. Enter commands similar to the following to format a diskette drive fd0:

   # fddisk -fmt /dev/rfd0

2. Enter commands similar to the following to write a new disk label to an rx23 type of diskette. The diskette type is printed on the diskette.

   # disklabel -wr fd0 rx23

3. Use commands similar to the following to create a new file system on the entire diskette, the c partition:

   # newfs /dev/rfd0c

If either the preinstall or postload files are located on the diskette, all files called by the preinstall or postload files must be located on the diskette.

Use commands similar to the following to mount the diskette drive and copy the CDF and all related files to the diskette:

1. Mount the diskette drive on the /mnt mount point:

   # mount /dev/fd0c /mnt

2. Enter the chmod command to ensure all files have execute permissions:

   # chmod 777 *

   The asterisk (*) is a wildcard character that represents all files in the directory.

3. Assuming that you are in the directory in which the files are located, enter the following copy commands to copy the files to the diskette:

   # cp ./install.cdf /mnt/install.cdf 
   
   # cp ./preinstall /mnt/preinstall 
   
   # cp ./postload /mnt/postload 
   
   # cp ./file_name /mnt/file_name

4. Unmount the diskette drive:

   # umount /mnt 

If this action is not appropriate, the administrator should create profile set directories to supply these files on a client-by-client basis.

• When RIS is invoked for the first time on a system that has been updated to Digital UNIX Version 4.0B that previously supported Digital UNIX Version 4.0 installation cloning, the existing RIS area is converted. In previous versions of Digital UNIX, CDFs were located in the /var/adm/ris/clients/cdf directory and could have any file name.

  The conversion process converts all existing CDFs into profile set directories. The new profile set directory has the same name as the original CDF and the original CDF is renamed to install.cdf. If the original CDF name could not be used to name the new profile set directory, a unique profile set name is created by appending a digit (starting with the number one) to the original CDF name.

  The first time RIS is invoked after Digital UNIX Version 4.0B has been installed, messages similar to the following are displayed:

  Converting old cdf directory to new sets directory format...
  CDF File acctng moved to set acctng and renamed install.cdf
  CDF File acctng.cdf moved to set acctng1 and renamed install.cdf
  CDF File acctng1.cdf moved to set acctng11 and renamed install.cdf
  CDF File acctng.cdf2 moved to set acctng12 and renamed install.cdf
  done

  After the conversion is done, these messages will not be displayed again.

• A question similar to the following is displayed during RIS client registration if at least one profile set directory exists. If no profile set directories exist, the question will not be displayed.

  Do you want to specify an Installation Profile Set
  for Installation Cloning on this client? [y/n]

  If you enter y, a list of available profile sets is displayed for selection.

  This RIS server has the following Installation Profile Sets available:
  
  acctng acctng1 acctng11 acctng12
  
  Enter a set name or press <Return> to exit set selection: acctng
  
  You have selected the acctng installation profile set.
  This set contains the following files:
  install.cdf preinstall postload DLSAVE

  Once a profile set is selected, RIS validates the CDF to ensure that the software subsets specified in the CDF match the software subset names and software subset version numbers present in the RIS environment to which the client system is registered. No validation of the user supplied files is performed.

kramer:08-00-2b-58-89-1c:ris2.alpha,product_1:engineering

Examine the RIS database file on the RIS server, /var/adm/ris/clients/risdb, before deleting a profile set to ensure that no clients are registered to it. The name of the profile set is specified in the fourth field; fields are separated by a colon (:). In the following sample entry in the risdb file, the client newman is registered to the accounting profile set:

newman:08-00-2b-58-89-1c:ris2.alpha,product_1:accounting

Note

Copying software may be done only for the purpose of licensed use of Digital UNIX. A valid license agreement must be present for all instances of use of the copied Digital UNIX operating system.

Use the method you usually use to burn a CD-ROM (i.e., write to a CD-ROM) if you plan to provide the install.cdf, preinstall, and postload files on a CD-ROM. The method you use depends upon the type of CD-ROM burner you have.

The basic steps to create an image and burn a CD-ROM are:

1. Mount the Digital UNIX Version 4.0B CD-ROM to determine how much disk space is required on the magnetic disk to which you will be copying the contents of the CD-ROM. For example, to mount the CD-ROM in drive /dev/rz4c on the directory /mnt, enter commands similar to the following:

   # mkdir /mnt
   
   # mount -r /dev/rz4c /mnt
   
   # cd /mnt

2. Enter the following command to determine disk space in kilobytes:

   # df -k

   Remember this figure and make sure you have a disk large enough to meet the space requirement.

3. Unmount the CD-ROM using commands similar to the following:

   # umount /mnt

4. Create an image of the operating system by copying the contents of a Digital UNIX Version 4.0B CD-ROM on to a disk that is at least as large as the figure obtained in Step 2. Use commands similar to the following to copy the contents of the CD-ROM to disk. In the example, the input file is the CD-ROM device, (/dev/rz4c), the output file is the magnetic disk (/dev/rz2c), and the input and output block size is 32 kilobytes (32k).

   # dd if=/dev/rz4c of=/dev/rz2c bs=32k

   ---

   Caution

   The output file (of=) must specify a disk partition that starts at block zero (usually a or c). Specifying a partition that does not start at zero (0) results in an operating system image that is not bootable.

   ---

5. Mount the disk to which you just copied the contents of the Digital UNIX Version 4.0B CD-ROM, and use the cp command to copy the install.cdf, preinstall, postload files and any files called by the files into the /isl directory of the image:

   # mount /dev/rz2c /mnt
   
   # cp ./preinstall /mnt/isl/preinstall
   
   # cp ./install.cdf /mnt/isl/install.cdf
   
   # cp ./postload /mnt/isl/postload
   
   # cp ./file_name /mnt/isl/file_name

6. Depending upon the type of CD-ROM burner you have, use the recommended method to burn a CD-ROM from the modified image on the disk.

   ---

   Note

   To ensure that you have a valid, bootable Digital UNIX Version 4.0B image, Digital recommends that you verify the ability to boot from the image on the disk before burning the CD-ROM.

   ---