Creating class Files
A class file is a text file that defines how to install the Solaris software on a system. Every rule in the rules file specifies a class file that defines how a system is installed when the rule is matched. You usually create a different class file for every rule; however, the same class file can be used in more than one rule. Please note that Sun will sometimes refer to this file as a profile.
A class file consists of one or more class file keywords (which are described in the following sections). Each class file keyword is a command that controls one aspect of how the Solaris installation program installs the Solaris software on a system. Use the vi editor (or any other text editor) to create a class file in the JumpStart configuration directory on the configuration server. You can create a new class file or edit one of the sample profiles located in /cdrom/cdrom0/s0/Solaris_9/Misc/jumpstart_sample on the Solaris CD-ROM. The class file can be named anything, but it should reflect the way in which it installs the Solaris software on a system. Sample names are basic_install, eng_profile, and accntg_profile.
A class file must have the following:
The install_type keyword as the first entry
Only one keyword on a line
The root_device keyword if the systems being upgraded by the class file have more than one root file system that can be upgraded
A class file allows the following:
A comment after the pound sign (#) anywhere on a line. If a line begins with a #, the entire line is a comment. If a # is specified in the middle of a line, everything after the # is considered a comment.
Blank lines.
The class file is made up of keywords and their values. They are described in the following sections.
archive location
The archive_location keyword defines where a Web Start Flash archive is stored. As stated in Chapter 8, “Web Start,” this Flash archive can be stored in any one of the following locations for later retrieval:
NFS server
HTTP server
FTP server
Local tape
Local device
Local file
The syntax for the archive_location keyword is as follows:
archive_location <retrieval_type> <location>
How you specify values for <retrieval_type> and <location> depends on where the Web Start Flash archive is stored. I’ve defined the syntax for each in the following sections.
NFS Server
When the archive is stored on an NFS server, the syntax is as follows:
archive_location <nfs server_name>:</path/filename> retry <n>
server_name is the name of the server where the archive is stored. The /path/filename is broken down as follows:
path is the path to the location on the server where the archive is stored. filename is the name of the Web Start Flash archive. retry is an option keyword followed by a value <n> that specifies the maximum number of times the Web Start Flash utilities will attempt to mount the archive if the first attempt fails.
Here are a couple of examples of how to use the archive_location keyword to specify an archive located on an NFS server:
archive_location nfs zeus:/webarchives/usrarchive archive_location nfs://zeus/webarchives/usrarchive
HTTP Server
When the archive is stored on an HTTP server, the syntax is as follows:
archive_location http://<server_name>:<port> <path/filename> [optional keywords]
Where:
server_name is the name of the server where the archive is being stored. server_name can be a port number or the name of a TCP service that has a port number that is determined at runtime.
port is where you can specify an optional port in addition to the server_name. If you do not specify a port, the Web Start Flash installation utilities use the default HTTP port number, 80.
The /path/filename is broken down as follows: path is the path to the location on the server where the archive is stored. filename is the name of the Web Start Flash archive.
optional_keywords are the optional keywords listed in Table 7.5 that you can specify when you retrieve a Web Start Flash archive from an HTTP server.
Here are a couple examples of how to use the archive_location keyword to specify an archive located on an HTTP server:
archive_location http://pyramid/webarchives/usrarchive.flar timeout 5
Here’s an example of the auth_basic keyword:
archive_location http://pyramid/webarchives/usrarchive.flar timeout 5 auth_basic bcalkins mypasswd
FTP Server
When the archive is stored on an FTP server, the syntax is as follows:
archive_location ftp://<username>:<password>@<servername>:<port> <path/filename> [optional_keywords]
Where:
username:password is the username and password required to access the FTP server.
servername is the name of the server where the archive is stored. servername can be a port number or the name of a TCP service that has a port number that is determined at runtime.
port enables you to specify an optional port. If you do not specify a port, the Web Start Flash installation utilities use the default FTP port number, 21. The /path/filename is broken down as follows:
path is the path to the location on the server where the archive is stored. filename is the name of the Web Start Flash archive.
optional_keywords are the optional keywords listed in Table 7.6 that you can specify when you retrieve a Web Start Flash archive from an FTP server.
Here is an for example of how to use the archive_location keyword to specify an archive located on an FTP server:
archive_location ftp://bcalkins:mypasswd@pyramid/webarchives/usrarchive.flar timeout 5
Local Tape
When the archive for is stored on tape and is accessible via the local tape drive, the syntax is as follows:
archive_location local_tape <device> <position>
Where:
device is the name of the local tape drive.
position is where you specify the position of the archive on the tape. If you do not supply a position, the Web Start Flash installation utilities retrieve the archive from the current position on the tape drive. The begin script or a sysidcfg file can be located on other positions on the tape before the archive.
Here is an example of how to use the archive_location keyword to specify an archive located on a local tape. We’ll be specifying the local tape named /dev/rmt/0n (no rewind device), tape position 5:
archive_location local_tape /dev/rmt/0n 5
Local Device
When the archive is stored on a local disk (hard drive or CD-ROM), the syntax is as follows:
archive_location local_device <device> <path/filename> <filesystem_type>
device is the name of the disk drive where you stored the archive. The /path/filename is broken down as follows:
path is the path to where the archive is stored.
filename is the name of the Web Start Flash archive.
file_system_type specifies the type of file system that the archive is stored on. If you do not supply a file system type, the Web Start Flash installation utilities will try to mount a UFS file system by default. If the UFS mount fails, the Web Start Flash installation utilities attempt to mount an HSFS file system.
Here is an example of how to specify an archive located on a local disk (UFS file system):
archive_location local_device c0t0d0s0 /webarchives/usrarchive
Local File
You can retrieve an archive that you stored in the miniroot from which you booted. When you perform a custom JumpStart installation, you boot the system from a CD-ROM or an NFS-based miniroot. The installation software is loaded and run from this miniroot. Therefore, a Web Start Flash archive that you stored in the CD-ROM or NFS-based miniroot is accessible as a local file. Use the following syntax for the archive_location keyword:
archive_location local_file <path/filename> The /path/filename is broken down as follows:
path is the path to the location of the archive.
filename is the name of the Web Start Flash archive.
To use an archive that is located in the local directory named /webarchives /usrarchive, use the following syntax:
archive_location local_file /webarchives/usrarchive
backup_media
backup_media defines the medium used to back up file systems if they need to be reallocated during an upgrade because of space problems. If multiple tapes or disks are required for the backup, you are prompted to insert these during the upgrade. Here is the backup_media syntax:
backup_media <type> <path>
type can be one of the keywords listed in Table 7.7.
backup_media local_tape /dev/rmt/0
backup_media local_diskette /dev/rdiskette0
backup_media local_filesystem /dev/dsk/c0t3d0s7
backup_media local_filesystem /export
backup_media remote_filesystem sparc1:/export/temp
backup_media remote_system bcalkins@sparc1:/export/temp
backup_media must be used with the upgrade option only when disk space reallocation is necessary.
boot_device
boot_device designates the device where the installation program installs the root file system and consequently what the system’s startup device is. The EEPROM value also lets you update the system’s EEPROM if you change its current startup device so that the system can automatically start up from the new startup device. Here’s the boot_device syntax:
boot_device <device> <eeprom>
The device and eeprom values are described in Table 7.8.
The installation program installs the root file system on c0t1d0s0 and updates the EEPROM to start up automatically from the new startup device.
client_arch
client_arch indicates that the OS server supports a platform group other than its own. If you do not specify client_arch, any diskless client or Solstice AutoClient system that uses the OS server must have the same platform group as the server. client_arch can be used only when system_type is specified as the server. You must specify each platform group that you want the OS server to support. Here’s the client_arch syntax:
client_arch karch_value [karch_value...]
Values for karch_value include sun4m, sun4u, and i86pc. Here’s an example:
client_arch sun4m
client_root
client_root defines the amount of root space, in megabytes, to allocate for each client. If you do not specify client_root in a server’s profile, the installation software automatically allocates 15MB of root space per client. The size of the client root area is used in combination with the num_clients keyword to determine how much space to reserve for the /export/root file system. Here’s the syntax:
client_root <root_size> root_size is specified in megabytes. Here’s an example:
client_root 20
Note
When allocating root space, 20MB is an adequate size. 15MB is the minimum size required. Any more than 20MB is just wasting disk space.
client_swap
client_swap defines the amount of swap space, in megabytes, to allocate for each diskless client. If you do not specify client_swap, 32MB of swap space is allocated. Physical memory plus swap space must be a minimum of 32MB. If a class file does not explicitly specify the size of swap, the Solaris installation program determines the maximum size that the swap file can be based on the system’s physical memory. The Solaris installation program makes the size of swap no more than 20 percent of the disk where it resides, unless there is free space left on the disk after the other file systems are laid out.
Here’s the syntax:
client_swap <swap_size> swap_size is specified in megabytes. Here’s an example:
client_swap 64
This example specifies that each diskless client has a swap space of 64MB.
cluster
cluster designates which software group to add to the system. The software groups are listed in Table 7.9.
You can specify only one software group in a profile, and it must be specified before other cluster and package entries. If you do not specify a software group with cluster, the end-user software group, SUNWCuser, is installed on the system by default. Here is cluster’s syntax:
cluster <group_name> Here’s an example:
cluster SUNWCall
This example specifies that the entire distribution group should be installed.
The cluster keyword can also be used to designate whether a cluster should be added to or deleted from the software group that was installed on the system. add and delete indicate whether the cluster should be added or deleted. If you do not specify add or delete, add is set by default. Here’s the syntax:
cluster <cluster_name> [add | delete] <cluster_name> must be in the form SUNWCname. To view detailed information about clusters and their names, start AdminTool on an installed system and choose Browse, Software.
dontuse
dontuse designates one or more disks that you don’t want the Solaris installation program to use. By default, the installation program uses all the operational disks on the system. disk_name must be specified in the form c?t?d? or c?d?, such as c0t0d0. Here’s the syntax:
dontuse disk_name [disk_name...]
Here’s an example:
dontuse c0t0d0 c0t1d0
filesys
filesys sets up the installed system to mount remote file systems automatically when it starts up. You can specify filesys more than once. The following syntax describes using filesys to set up mounts to remote systems:
filesys <server>:<path> <server_address> <mount_pt_name> [mount_options]
The filesys keywords are described in Table 7.10.
filesys zeus:/export/home/user1 192.9.200.1 /home ro,bg,intr
filesys can also be used to create local file systems during the installation by using this syntax:
filesys <slice> <size> [file_system] [optional_parameters]
The values listed in Table 7.12 can be used for <slice>.
The values listed in Table 7.12 can be used for <size>.
file_system is an optional field when slice is specified as any or c?t?d?s?. If file_system is not specified, unnamed is set by default, but you can’t specify the optional_parameters value.
The values listed in Table 7.13 can be used for file_system.
In the following example, the size of swap is set to 64MB, and it is installed on c0t3d0s1:
filesys c0t3d0s1 64 swap
In the next example, /usr is based on the selected software, and the installation program determines what disk to put it on when you specify the any value:
filesys any auto /usr
The optional_parameters field can be one of the options listed in Table 7.14.
install_type
install_type specifies whether to perform the initial installation option or the upgrade option on the system. install_type must be the first class file keyword in every profile. Here’s the syntax:
install_type [initial_install | upgrade]
Select either initial_install or upgrade. Here’s an example:
install_type initial_install
geo
The geo keyword followed by a locale designates the regional locale or locales you want to install on a system (or to add when upgrading a system). The syntax is as follows:
geo <locale> Values you can specify for locale are listed in Table 7.15.
Refer to the Solaris 9 Advanced Installation Guide for a complete listing of locale values.
Here’s an example in which the locale specified is S_America:
geo S_America
isa_bits
The isa_bits keyword specifies whether 64-bit or 32-bit Solaris 9 packages are to be installed. The syntax is as follows:
isa_bits <bit_switch> <bit_switch> represents the option 64 or 32, which you use to indicate whether 64-bit or 32-bit Solaris 9 packages are to be installed. If you do not set this keyword in the class file, JumpStart installs:
64-bit packages on UltraSPARC(TM) systems 32-bit packages on all other systems
For example, to specify that only 32-bit Solaris 9 packages are to be loaded, use the following entry in the class file:
isa_bits 32
layout_constraint
layout_constraint designates the constraint that autolayout has on a file system if it needs to be reallocated during an upgrade because of space problems. layout_constraint can be used only for the upgrade option when disk space reallocation is required.
With layout_constraint, you specify the file system and the constraint you want to put on it. Here’s the syntax:
layout_constraint <slice> <constraint> [minimum_size]
The <slice> field specifies the file system disk slice on which to specify the constraint. It must be specified in the form c?t?d?s? or c?d?s?. Table 7.16 describes the options for layout_constraint.
The following are some examples:
layout_constraint c0t3d0s1 changeable 200
The file system c0t3d0s1 can be moved to another location, and its size can be changed to more than 200MB but no less than 200MB.
layout_constraint c0t0d0s4 movable
The file system on slice c0t0d0s4 can move to another disk slice, but its size stays the same.
layout_constraint c0t2d0s1 collapse
c0t2d0s1 is moved into its parent directory to reduce the number of file systems.
locale
locale designates which language or locale packages should be installed for the specified locale_name.A locale determines how online information is displayed for a specific language or region, such as date, time, spelling, and monetary value. Therefore, if you want English as your language but you also want to use the monetary values for Australia, you would choose the Australia locale value (en_AU) instead of the English language value (C).
The English language packages are installed by default. You can specify a locale keyword for each language or locale you need to add to a system. Here’s the locale syntax:
locale locale_name
Here’s an example:
locale es
This example specifies Spanish as the language package you want installed.
num_clients
When a server is installed, space is allocated for each diskless client’s root (/) and swap file systems. num_clients defines the number of diskless clients that a server supports. If you do not specify num_clients, five diskless clients are allocated. Here’s the syntax:
num_clients client_num
Here’s an example:
num_clients 10
In this example, space is allocated for 10 diskless clients.
package
package designates whether a package should be added to or deleted from the software group installed on the system. add or delete indicates the action required. If you do not specify add or delete, add is set by default. Here’s the syntax:
package package_name [add | delete] package_name must be in the form SUNWname . Here’s an example:
package SUNWxwman delete
In this example, SUNWxwman (X Window online man pages) is not installed on the system.
partitioning
partitioning defines how the disks are divided into slices for file systems during the installation. If you do not specify partitioning, the default is set. Here’s the syntax:
partitioning default|existing|explicit
The partitioning options are described in Table 7.17.
root_device
root_device designates the system’s root disk. Here’s the syntax:
root_device <slice> root_device c0t3d0s2
system_type
system_type defines the type of system being installed. If you do not specify system_type in a class file, standalone is set by default. Here’s the syntax:
system_type [standalone | server]
system_type server
usedisk
usedisk designates one or more disks that you want the Solaris installation program to use when the partitioning default is specified. By default, the installation program uses all the operational disks on the system. disk_name must be specified in the form c?t?d? or c?d?, such as c0t0d0. If you specify the usedisk class file keyword in a class file, the Solaris installation program uses only the disks that you specify. Here’s the syntax:
usedisk disk_name [disk_name]
usedisk c0t0d0 c0t1d0