7. Advanced Installation Procedures: JumpStart, Flash Archive, and PXE
Objectives
The following test objectives for exam CX-310-202 are covered in this chapter:
Explain custom JumpStart configuration, including the boot, identification, configuration, and installation services.
• This chapter helps you understand the components of a JumpStart network installation. You’ll learn about setting up servers and clients to support a JumpStart installation, including JumpStart related commands, configuration files, and services.
Configure a JumpStart including implementing a JumpStart server; editing the sysidcfg, rules, and profile files; and establishing JumpStart software alternatives (setup, establishing alternatives, troubleshooting, and resolving problems).
• This chapter shows you how to implement a JumpStart installation, as well as the files and scripts that are modified and used.
Explain Flash, create and manipulate the Flash archive, and use it for installation.
• The Solaris Flash feature takes a snapshot of a Solaris operating environment, complete with patches and applications, if desired. It can be used only in initial installations, however, not upgrades.
Given a Preboot Execution Environment (PXE) installation scenario, identify requirements and install methods, configure both the install and DHCP server, and boot the x86 client.
• This chapter shows you how to use the PXE to boot and install an x86 client across the network.
Outline
Preparing for a Custom JumpStart Installation
What Happens During a Custom JumpStart Installation?
Differences Between SPARC and x86/x64-Based Systems
JumpStart Stages: SPARC System
JumpStart Stages: x86/x64 System
Name Service, Domain Name, and Name Server Keywords
Setting the System Locale, Terminal, Time Zone, and Time Server
Setting Up JumpStart in a Name Service Environment
A Sample JumpStart Installation
Creating the JumpStart Directory
Setting Up a Configuration Server
Using the Solaris Installation Program to Install a Flash Archive
Creating a Differential Flash Archive
Preboot Execution Environment (PXE)
Preparing for a PXE Boot Client
Adding an x86 Client to Use DHCP
Suggested Reading and Resources
Study Strategies
The following strategies will help you prepare for the test:
• Practice the Step By Step examples provided in this chapter on a Solaris system. Be sure that you understand each step and can describe the process of setting up a boot server, an install server, and a configuration server. You should also be able to identify the events that occur during the JumpStart client boot sequence.
• Understand each of the commands described in this chapter. Get familiar with all the options, especially the ones used in the examples. You’ll see questions on the exam related to the add_install_client and add_to_install_server scripts.
• State the purpose of the sysidcfg file, the class file, and the rules file. Given the appropriate software source, be prepared to explain how to create a configuration server with a customized rules file and class files.
• State the purpose of the JumpStart server and identify the main components of each type of server. Learn the terms listed in the “Key Terms” section near the end of this chapter. Be prepared to define each term.
• State the features and limitations of Solaris Flash and be able to implement a Flash Archive. Practice the Flash Archive example in this chapter using two Solaris systems. Make sure you are comfortable with the concepts being introduced, as well as the procedures to successfully use this powerful feature.
• Become familiar with the Preboot Execution Environment (PXE) features, the requirements, and the procedures to follow in order to get an x86 client to successfully boot across the network. Also, make sure you understand what the DHCP symbols represent, and be prepared for a question in the exam that asks you to match a symbol with its corresponding description.
Introduction
There are six ways to install the Solaris software on a system. The first two interactive methods of installation, GUI and command-line, are described in Solaris 10 System Administration Exam Prep (Exam CX-310-200), Part I. The more advanced installation methods—custom JumpStart, WAN boot, Solaris Flash, and Live Upgrade—are described in this book. The topics are quite lengthy, so I divided them into two chapters.
In this chapter, I describe how to use custom JumpStart to install the operating system onto SPARC-based clients across the network. Custom JumpStart is used to install groups of similar systems automatically and identically.
Also in this chapter, I describe the Solaris Flash Archive method of installation. With a Flash Archive, you can take a complete snapshot of the Solaris operating environment on a running system, including patches and applications, and create an archive that can be used to install other systems. This method effectively creates a clone.
Finally, I describe the Preboot Execution Environment (PXE). PXE is a direct form of network boot that can be used to install the Solaris Operating Environment onto x86/x64-based systems across the network using DHCP. It does not require the client to have any form of local boot media.
Custom JumpStart
Objectives
• Explain custom JumpStart configuration, including the boot, identification, configuration, and installation services.
• Configure a JumpStart including implementing a JumpStart server; editing the sysidcfg, rules, and profile files; and establishing JumpStart software alternatives (setup, establishing alternatives, troubleshooting, and resolving problems).
The custom JumpStart method of installing the operating system provides a way to install groups of similar systems automatically and identically. If you use the interactive method to install the operating system, you must interact with the installation program by answering various questions. At a large site with several systems that are to be configured exactly the same, this task can be monotonous and time-consuming. In addition, there is no guarantee that each system is set up the same. Custom JumpStart solves this problem by providing a method to create sets of configuration files beforehand so that the installation process can use them to configure each system automatically.
Custom JumpStart requires up-front work, creating custom configuration files before the systems can be installed, but it’s the most efficient way to centralize and automate the operating system installation at large enterprise sites. Custom JumpStart can be set up to be completely hands-off.
The custom configuration files that need to be created for JumpStart are the rules and class files. Both of these files consist of several keywords and values and are described in this chapter.
Another file that is introduced in this chapter is the sysidcfg file, which can be used to pre-configure the system identification information and achieve a fully hands-off installation.
Table 7.1 lists the various commands that are introduced in this chapter.
Table 7.1 JumpStart Commands
JumpStart has three main components:
• Boot and Client Identification Services: These services typically are provided by a networked boot server and provide the information that a JumpStart client needs to boot using the network. Alternatively, the identification service can be provided by any network server configured to provide this service.
• Installation Services: These are provided by a networked install server, which provides an image of the Solaris operating environment the JumpStart client uses as its source of data to install.
• Configuration Services: These are provided by a networked configuration server and provide information that a JumpStart client uses to partition disks and create file systems, add or remove Solaris packages, and perform other configuration tasks.
NOTE
Server configurations At times we describe the boot server, the install server, and the configuration server as though they are three separate systems. The reality, however, is that most sites have one system that performs all three functions. This topic is discussed in more detail in the section “The Install Server.”
Each of these components is described in this chapter. If any of these three components is improperly configured, the JumpStart clients can
• Fail to boot.
• Fail to find a Solaris Operating Environment to load.
• Ask questions interactively for configuration.
• Fail to partition disks, create file systems, and load the operating environment.
Preparing for a Custom JumpStart Installation
The first step in preparing a custom JumpStart installation is to decide how you want the systems at your site to be installed. Here are some questions you should answer before you begin:
• Will the installation be an initial installation or an upgrade?
• What applications will the system support?
• Who will use the system?
• How much swap space is required?
These questions will help you group the systems when you create the class and rules files later in this chapter.
Additional concerns to be addressed include what software packages need to be installed and what size the disk partitions need to be in order to accommodate the software. After you answer these questions, group systems according to their configuration (as shown in the example of a custom JumpStart near the end of this chapter).
The next step in preparing a custom JumpStart installation is to create the configuration files that will be used during the installation: the rules.ok file (a validated rules file) and a class file for each group of systems. The rules.ok file is a file that should contain a rule for each group of systems you want to install. Each rule distinguishes a group of systems based on one or more system attributes. The rule links each group to a class file, which is a text file that defines how the Solaris software is to be installed on each system in the group. Both the rules.ok file and the class files must be located in a JumpStart directory you define.
The custom JumpStart configuration files that you need to set up can be located on either a diskette (called a configuration diskette) or a server (called a configuration server). Use a configuration diskette when you want to perform custom JumpStart installations on nonnetworked standalone systems. Use a configuration server when you want to perform custom JumpStart installations on networked systems that have access to the server. This chapter covers both procedures.
What Happens During a Custom JumpStart Installation?
This section provides a quick overview of what takes place during a custom JumpStart installation. Each step is described in detail in this chapter.
To prepare for the installation, you create a set of JumpStart configuration files, the rules and class files, on a server that is located on the same network as the client you are installing. Next, you set up the server to provide a startup kernel that is passed to the client across the network. This is called the boot server (or sometimes it is called the startup server).
After the client starts up, the boot server directs the client to the JumpStart directory, which is usually located on the boot server. The configuration files in the JumpStart directory direct and automate the entire Solaris installation on the client.
To be able to start up and install the operating system on a client, you need to set up three servers: a boot server, an install server, and a configuration server. These can be three separate servers; however, in most cases, one server provides all these services.
Differences Between SPARC and x86/x64-Based Systems
SPARC and x86/x64-based systems differ in how they perform a network boot. SPARC systems initiate a network boot by executing the boot net command from the OpenBoot prompt. On the other hand, most x86/x64-based systems can boot directly from a network interface card using the Preboot Execution Environment (PXE). These differences affect the JumpStart process and are worth noting.
JumpStart Stages: SPARC System
The JumpStart stages for a SPARC-based system are as follows:
1. Boot the client from the OpenBoot PROM:
ok> boot net - install<cr>
2. The client broadcasts a reverse address resolution protocol (RARP) request over the network requesting an IP address.
3. A rarpd daemon, running on a boot server, responds to the RARP request with an IP address for the boot client.
4. The client issues a TFTP request to the boot server to send over the bootstrap loader.
5. At the boot server, the inetd daemon receives the TFTP request and starts the in.tftpd daemon. The in.tftpd daemon locates an IP address along with the boot client’s architecture in the /tftpboot directory. The boot server sends a JumpStart mini-root kernel to the client via TFTP.
6. The boot client boots to the mini-root kernel that was sent from the boot server.
7. The boot client broadcasts another RARP request, asking for an IP address.
8. The boot server searches the ethers and hosts databases to map the client’s Ethernet MAC address to an IP address. The boot server responds to the RARP request with an IP address.
9. The client sends a BOOTPARAMS request to the boot server to get its hostname.
10. The boot server returns a hostname obtained from its bootparams table.
11. The client sends a BOOTPARAMS request to the boot server to get a root (/) file system.
12. The boot server locates the information in the bootparams table and sends the root file system information to the client.
13. Using the bootparams information just received, the client uses NFS to mount the root (/) file system from the boot server and starts the init program.
14. After the boot server is finished bootstrapping the client, it locates the client’s configuration server in the bootparams table. It sends this information to the client.
15. The client uses the BOOTPARAMS information to search for the configuration server.
16. The client mounts the OS image from the install server and executes sysidtool to obtain system identification information.
17. The client mounts the OS image on the install server.
18. The client runs install-solaris and installs the OS.
NOTE
Configuring a DHCP server For SPARC-based clients, you have the option of using RARP or DHCP to supply the identity information they require to boot and begin the system identification and installation process. But x86/x64 clients that use the PXE use only DHCP for their configuration. Therefore, you must configure a DHCP server to support the boot and identification operations of x86/x64-based JumpStart clients. The same boot server may provide ARP/RARP services for SPARC clients and DHCP services for x86/x64 clients, or both SPARC and x86/x64 clients could use DHCP.
Setting up a DHCP server to support PXE clients is described later in this chapter.
JumpStart Stages: x86/x64 System
The JumpStart Stages for an x86/x64-based system are as follows:
1. A network boot is configured in the system’s BIOS (or in the network interface utility), or the user can press the appropriate key at boot time to display a menu of boot options. Typically, this key is F12.
2. During the network boot, the PXE client broadcasts a DHCPDISCOVER message containing an extension that identifies the request as coming from a client that implements the PXE protocol.
3. The boot server sends the PXE client a list of appropriate boot servers.
4. The client then discovers the boot server and receives the name of an executable file on the chosen boot server. The client issues a TFTP request based on the BootSrvA and BootFile parameters it received from the DHCP server and requests a download of the executable from the boot server.
The BootFile parameter specifies the file that the PXE client will use to boot through the network.
The BootsrvA parameter specifies the IP address of the boot server.
5. At the boot server, the inetd daemon receives the TFTP request and starts the in.tftpd daemon. The in.tftpd daemon locates an IP address along with the boot client’s architecture in the /tftpboot directory. The boot server sends a JumpStart mini-root kernel to the client via TFTP.
6. The PXE client downloads the executable file using either standard TFTP or MTFTP (Multisource File Transfer Protocol).
7. The PXE client initiates execution of the downloaded image.
8. After obtaining the boot image, the PXE client issues another DHCPDISCOVER request message, requesting a new IP address. The boot server responds with a network bootstrap program filename.
9. The DHCP server responds with a DHCPACK, also called DHCPOFFERACK, which includes the following:
• SrootNM and SrootIP4: Hostname and IP address of the boot server
• SrootPTH: Path to the exported mini-root file system on the boot server
• SinstNM and SinstIP4: Hostname and IP address of the install server
• SrootPTH: Path to the exported Solaris distribution on the install server
• SjumpsCF: Path to the Jumpstart configuration
• SsysidCF: Path to the sysidcfg
10. Using this DHCP information received from the DHCP server, the PXE client uses NFS to mount the root (/) file system from the boot server and to locate the configuration server.
11. The client mounts the configuration server and executes sysidtool to obtain system identification information.
12. The client mounts the OS image on the install server.
13. The client runs install-solaris and installs the OS.
The Boot Server
The boot server, also called the startup server, is where the client systems access the startup files. This server must be on the local subnet (not across routers). Although it is possible to install systems over the network that are not on the same subnet as the install server, there must be a boot server that resides on the same subnet as the client.
When a client is first turned on, it does not have an operating system installed or an IP address assigned; therefore, when the client is first started, the boot server provides this information. The boot server running the RARP (Reverse Address Resolution Protocol) daemon, in.rarpd, looks up the Ethernet address in the /etc/ethers file, checks for a corresponding name in its /etc/hosts file, and passes the Internet address back to the client.
NOTE
Check the rarpd daemon rarpd is a daemon that is not always running. The in.rarpd service is managed by the service management facility under the FMRI svc:/network/rarp. Make sure that this service is enabled by issuing the following command:
svcadm enable svc:/network/rarp
RARP is a method by which a client is assigned an IP address based on a lookup of its Ethernet address. After supplying an IP address, the server searches the /tftpboot directory for a symbolic link named for the client’s IP address expressed in hexadecimal format. This link points to a boot program for a particular Solaris release and client architecture. For SPARC systems, the filename is <hex-IP address.architecture>. For example:
C009C864 . SUN4U -> inetboot . sun4u . Solaris_10-1
The boot server uses the in.tftpd daemon to transmit the boot program to the client via Trivial File Transfer Protocol (TFTP). The client runs this boot program to start up.
Make sure that the in.tftpd daemon is enabled on your boot server by typing:
# svcs -a|grep tftp<cr>
If nothing is displayed, the in.tftpd daemon is not enabled. Although the service is managed by SMF under the FMRI svcs:/network/tftp/udp6:default, you enable it by uncommenting the following line in the /etc/inetd.conf file:
tftp dgram udp6 wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot
After uncommenting the line, run the following command:
# /usr/sbin/inetconv<cr>
Check that the service is running by typing:
# svcs -a|grep tftp<cr>
The system displays this:
online 10:02:35 svc:/network/tftp/udp6:default
The boot program tries to mount the root file system. To do so, it issues the whoami request to discover the client’s hostname. The boot server running the boot parameter daemon, rpc.bootparamd, looks up the hostname and responds to the client. The boot program then issues a getfile request to obtain the location of the client’s root and swap space. The boot server responds with the information obtained from the /etc/bootparams file.
As soon as the client has its boot parameters, the boot program on the client mounts the / (root) file system from the boot server. The client loads its kernel and starts the init program. When the boot server is finished bootstrapping the client, it redirects the client to the configuration server.
The client searches for the configuration server using the bootparams information. The client mounts the configuration directory and runs sysidtool, which is a suite of tools used to configure the system identification information. Typically, all the system identification information is stored in the sysidcfg file, described later in this chapter. The client then uses the bootparams information to locate and mount the installation directory where the Solaris image resides. The client then runs the install-solaris program and installs the operating system.
For boot operations to proceed, the following files, directories, and services must be properly configured on the boot server:
• /etc/ethers
• /etc/hosts
• /etc/dfs/dfstab
• /etc/bootparams
• /tftpboot
• The TFTP service in SMF
• The rarpd service in SMF
The following sections describe each file.
/etc/ethers
This file is required on the boot server. It supports RARP requests sent from the SPARC-based JumpStart client. When the JumpStart client boots, it has no IP address, so it broadcasts its Ethernet address to the network using RARP. The boot server receives this request and attempts to match the client’s Ethernet address with an entry in the local /etc/ethers file.
If a match is found, the client name is matched to an entry in the /etc/hosts file. In response to the RARP request from the client, the boot server sends the IP address from the /etc/hosts file back to the client. The client continues the boot process using the assigned IP address.
An entry for the JumpStart client must be created by editing the /etc/ethers file or using the add_install_client script described later in this chapter in the section “Setting Up Clients.”
/etc/hosts
The /etc/hosts file was described in Chapter 1, “The Solaris Network Environment.” The /etc/hosts file is the local file that associates the names of hosts with their IP addresses. The boot server references this file when trying to match an entry from the local /etc/ethers file in response to a RARP request from a client. In a name service environment, this file would be controlled by NIS. See Chapter 5, “Naming Services,” for more information on how this file can be managed by NIS.
NOTE
DHCP services on the boot server can be used as an alternate method of providing boot and identification information to the JumpStart client. In fact, DHCP is used to support x86/x64-based JumpStart clients. It is described later in this chapter.
/etc/dfs/dfstab
The /etc/dfs/dfstab file lists local file systems to be shared to the network. This file is described in detail in Chapter 2, “Virtual File Systems, Swap Space, and Core Dumps.”
/etc/bootparams
The /etc/bootparams file contains entries that network clients use for booting. JumpStart clients retrieve the information from this file by issuing requests to a server running the rpc.bootparamd program. See the section “Setting Up Clients” later in this chapter for more information on how this file is configured.
/tftpboot
/tftpboot is a directory that contains the inetboot.SUN4x.Solaris_10-1 file that is created for each JumpStart client when the add_install_client script is run.
The client’s IP address is expressed in hexadecimal format. This link points to a boot program for a particular Solaris release and client architecture.
When booting over the network, the JumpStart client’s boot PROM makes a RARP request, and when it receives a reply, the PROM broadcasts a TFTP request to fetch the inetboot file from any server that responds and executes it. See how this directory is configured in the section “Setting Up Clients.”
Setting Up the Boot Server
The boot server is set up to answer RARP, TFTP, and BOOTPARAMS requests from clients using the add_install_client command. Before a client can start up from a boot server, the setup_install_server command is used to set up the boot server. If the same server will be used as a boot server and an install server, proceed to the next section, “The Install Server.”
To set up the boot server, follow the steps in Step By Step 8.1.
NOTE
Booting on a separate subnet Normally, the install server also provides the boot program for booting clients. However, the Solaris network booting architecture requires you to set up a separate boot server when the install client is on a different subnet than the install server. Here’s the reason: SPARC install clients require a boot server when they exist on different subnets because the network booting architecture uses Reverse Address Resolution Protocol (RARP). When a client boots, it issues a RARP request to obtain its IP address. RARP, however, does not acquire the netmask number, which is required to communicate across a router on a network. If the boot server exists across a router, the boot fails, because the network traffic cannot be routed correctly without a netmask.
STEP BY STEP
8.1 Setting Up the Boot Server
1. On the system that is the boot server, log in as root. Ensure the system has an empty directory with approximately 350MB of available disk space.
2. Insert the Solaris 10 DVD or Software CD 1 into the DVD/CD-ROM drive, allowing vold to automatically mount the media. Change the directory to the mounted media. Here is an example:
# cd /cdrom/cdrom0/s0/Solaris_10/Tools<cr>
3. Use the setup_install_server command to set up the boot server. The -b option copies just the startup software from the Solaris media to the local disk. Enter this command:
# ./setup_install_server -b <boot_dir_path><cr>
where -b specifies that the system is set up as a boot server and <boot_dir_path> specifies the directory where the Solaris image is to be copied. You can substitute any directory path, as long as that path is shared across the network.
For example, the following command copies the kernel architecture information into the /export/jumpstart directory:
# ./setup_install_server -b /export/jumpstart<cr>
The system responds with this:
Verifying target directory...
Calculating space required for the installation boot image
Copying Solaris_10 Tools hierarchy...
Copying Install Boot Image hierarchy...
Install Server setup complete
NOTE
Insufficient disk space The following error indicates that there is not enough room in the directory to install the necessary files. You need to either clean up files in that file system to make more room or choose a different file system:
ERROR: Insufficient space to copy Install Boot image
362978 necessary -69372 available.
NOTE
Destination must be empty The location in which you are trying to create the boot server must be empty. You see the following error if the target directory is not empty:
The target directory /export/jumpstart is not empty. Please
choose an empty directory or remove all files from the
specified directory and run this program again.
If no errors are displayed, the boot server is now set up. This boot server will handle all boot requests on this subnet. A client can only boot to a boot server located on its subnet. If you have JumpStart clients on other subnets, you need to create a boot server for each of those subnets. The installation program creates a subdirectory named Solaris_10 in the <boot_dir_path> directory.
The Install Server
As explained in the previous section, the boot server and the install server are typically the same system. The exception is when the client on which Solaris 10 is to be installed is located on a different subnet than the install server. Then a boot server is required on that subnet.
The install server is a networked system that provides the Solaris 10 operating system image. This can be any of the following:
• A shared CD-ROM or DVD-ROM drive with the Solaris OE media inserted
• A spooled image from either CD or DVD media
• A Flash installation image
Typically, we create an install server by copying the images from the Solaris installation media onto the server’s hard disk. This chapter focuses on using CD images, but you should be aware that Solaris 10 is also available on a single DVD.
By copying these CD images (or single DVD image) to the server’s hard disk, you enable a single install server to provide Solaris 10 CD images for multiple releases, including Solaris 10 CD images for different platforms. For example, a SPARC install server could provide the following:
• Solaris 10 Software CD 1 CD image
• Solaris 10 Software CD 2 CD image
• Solaris 10 Software CD 3 CD image
• Solaris 10 Software CD 4 CD image
• Solaris 10 Languages CD image (this CD is optional)
To set up a server as a boot and installer server, complete Step By Step 8.2. This Step by Step assumes that all systems are on the same subnet, and the boot and install server are to be on the same system.
STEP BY STEP
8.2 Setting Up a Server as a Boot and Install Server
1. The first step is to copy the Solaris 10 Software CD images to the server:
Insert the CD labeled “Solaris 10 Software CD 1” into the CD-ROM, and allow vold to automatically mount the CD. Change to the Tools directory on the CD:
# cd /cdrom/cdrom0/s0/Solaris_10/Tools<cr>
2. Use the setup_install_server command to install the software onto the hard drive:
# ./setup_install_server <install_dir_path><cr>
<install_dir_path> is the path to which the CD images will be copied. This directory must be empty, and it must be shared so that the JumpStart client can access it across the network during the JumpStart installation. Many system administrators like to put the CD images for the boot server and install server into /export/install and create a directory for each architecture being installed, such as sparc_10, or x86_10. This is because the install server could be used to hold multiple versions and multiple architectures. It’s a personal preference; just be sure that the target directory is empty, shared, and has approximately 3GB of space available, if all four CD images and the Language CD image are to be copied.
To install the operating environment software into the /export/install/sparc_10 directory, issue the following command:
# . /setup_install_server /export/install/sparc_10<cr>
The system responds with this:
Verifying target directory...
Calculating the required disk space for the Solaris_10
Product Calculating space required for the installation boot image
Copying the CD image to disk...
Copying Install boot image hierarchy...
Install Server setup complete
3. Eject the CD, and insert the CD labeled “Solaris 10 Software CD 2” into the CD-ROM, allowing vold to automatically mount the CD.
Change to the Tools directory on the mounted CD:
# cd /cdrom/cdrom0/Solaris_10/Tools<cr>
4. Run the add_to_install_server script to install the additional software into the <install_dir_path> directory:
# . /add_to_install_server <install_dir_path><cr>
For example, to copy the software into the /export/install/sparc_10 directory, issue the following command:
# . /add_to_install_server /export/install/sparc_10<cr>
The system responds with the following messages:
The following Products will be copied to /export/install/sparc_10/
Solaris_10/Product:
Solaris_2
If only a subset of products is needed enter Control-C
and invoke . /add_to_install_server with the -s option.
Checking required disk space...
Copying Top Level Installer...
131008 blocks
Copying Tools Directory...
4256 blocks
Processing completed successfully.
After checking for the required disk space, the image is copied from CD to disk. When it’s finished installing, repeat the process with the remaining CDs and then with the Solaris 10 Languages CD if you are planning to support multiple languages. When using a DVD, these additional steps are not required.
After copying the Solaris CDs, you can use the patchadd -C command to patch the Solaris miniroot image on the install server’s hard disk. This option patches only the miniroot. Systems that are installed still have to apply recommended patches if they are required.
The Configuration Server
If you are setting up custom JumpStart installations for systems on the network, you have to create a directory on a server called a configuration directory. This directory contains all the essential custom JumpStart configuration files, such as the rules file, the rules.ok file, the class file, the check script, and the optional begin and finish scripts.
The server that contains a JumpStart configuration directory is called a configuration server. It is usually the same system as the install and boot server, although it can be a completely different server. The configuration directory on the configuration server should be owned by root and should have permissions set to 755.
To set up the configuration server, follow Step By Step 8.3.
STEP BY STEP
8.3 Setting Up a Configuration Server
1. Choose the system that acts as the server, and log in as root.
2. Create the configuration directory anywhere on the server (such as /export/jumpstart).
3. To be certain that this directory is shared across the network, edit the /etc/dfs/dfstab file and add the following entry:
share -F nfs -o ro, anon=0 /export/jumpstart
4. Execute the svcadm enable network/nfs/server command. If the system is already an NFS server, you only need to type shareall and press Enter.
5. Place the JumpStart files (that is, rules, rules.ok, and class files) in the /export/jumpstart directory. The rules, rules.ok, and class files are covered later in this section. Sample copies of these files can be found in the Misc/jumpstart_sample subdirectory of the location where you installed the JumpStart install server.
You can also use the add_install_client script, which makes an entry into the /etc/dfs/dfstab file as part of the script. The add_install_client script is described in the section “Setting Up Clients.”
Setting Up a Profile Diskette
An alternative to setting up a configuration server is to create a profile diskette, also called a configuration diskette (provided that the systems that are to be installed have diskette drives). If you use a diskette for custom JumpStart installations, the essential custom JumpStart files (the rules file, the rules.ok file, and the class files) must reside in the root directory on the diskette. The diskette that contains JumpStart files is called a profile diskette. The custom JumpStart files on the diskette should be owned by root and should have permissions set to 755. See Step By Step 8.4 to set up a profile diskette.
STEP BY STEP
8.4 Setting Up a Profile Disk
1. Format the disk by typing the following:
# fdformat -U<cr>
2. If your system uses Volume Manager, insert the disk. It will be mounted automatically.
3. Create a file system on the disk by issuing the newfs command:
# newfs /vol/dev/aliases/floppy0<cr>
4. Eject the disk by typing the following:
# eject floppy<cr>
5. Insert the formatted disk into the disk drive.
You have completed the creation of a diskette that can be used as a profile diskette. Now you can create the rules file and create class files on the configuration diskette to perform custom JumpStart installations.
The Rules File
The rules file is a text file that should contain a rule for each group of systems you want to install automatically. Each rule distinguishes a group of systems based on one or more system attributes and links each group to a class file, which is a text file that defines how the Solaris software is installed on each system in the group.
After deciding how you want each group of systems at your site to be installed, you need to create a rules file for each specific group of systems to be installed. The rules.ok file is a validated version of the rules file that the Solaris installation program uses to perform a custom JumpStart installation.
After you create the rules file, validate it with the check script by changing to the /export/jumpstart directory and issuing the check command. If the check script runs successfully, it creates the rules.ok file. During a custom JumpStart installation, the Solaris installation program reads the rules.ok file and tries to find the first rule that has a system attribute matching the system being installed. If a match occurs, the installation program uses the class file specified in the rule to install the system.
A sample rules file for a Sun Ultra is shown next. You’ll find a sample rules file on the install server located in the <install_dir_path>/Solaris_10/Misc/jumpstart_sample directory, where <install_dir_path> is the directory that was specified using the setup_install_server script when the install server was set up. For the examples in this chapter, the install directory is /export/install/sparc_10.
Notice that almost all the lines in the sample rules file are commented out. These are simply instructions and sample entries to help the system administrator make the correct entry. The last, uncommented line is the rule we added for the example. The syntax is discussed later in this chapter. Each line in the code table has a rule keyword and a valid value for that keyword. The Solaris installation program scans the rules.ok file from top to bottom. If the program matches a rule keyword and value with a known system, it installs the Solaris software specified by the class file listed in the class file field.
Table 7.2 describes the syntax that the rules file must follow.
Table 7.2 Rule Syntax
Rules File Requirements
The rules file must have the following:
• At least one rule
• The name “rules”
• At least a rule keyword, a rule value, and a corresponding profile
• A minus sign (-) in the begin and finish fields if there is no entry
The rules file should be saved in the JumpStart directory, should be owned by root, and should have permissions set to 644.
The rules file can contain any of 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.
• Rules that span multiple lines. You can let a rule wrap to a new line, or you can continue a rule on a new line by using a backslash () before pressing Enter.
Table 7.3 describes the rule_keywords and rule_values that were mentioned in Table 7.2.
Table 7.3 rule_keyword and rule_value Descriptions
During a custom JumpStart installation, the Solaris installation program attempts to match the system being installed to the rules in the rules.ok file in order—the first rule through the last rule.
Rules File Matches
A rule match occurs when the system being installed matches all the system attributes defined in the rule. As soon as a system matches a rule, the Solaris installation program stops reading the rules.ok file and begins installing the software based on the matched rule’s class file.
Here are a few sample rules:
karch sun4u - basic_prof -
The preceding example specifies that the Solaris installation program should automatically install any system with the sun4u platform group based on the information in the basic_prof class file. There is no begin or finish script.
hostname pyramid2 - ultra_class -
The rule matches a system on the network called pyramid2. The class file to be used is named ultra_class. No begin or finish script is specified:
network 192.168.0.0 && !model 'SUNW,Ultra-5_10' - net_class set_root_passwd
The third rule matches any system on the network that is not an Ultra 5 or Ultra 10. The class file to be used is named net_class, and the finish script to be run is named set_root_passwd.
any - - generic_class -
The last example matches any system. The class file to be used is named generic_class, located in the /export/jumpstart directory. There is no begin or finish script.
Validating the Rules File
Before the rules file can be used, you must run the check script to validate that this file is set up correctly. If all the rules are valid, the rules.ok file is created.
To validate the rules file, use the check script provided in the <install_dir_path>/ Solaris_10/Misc/jumpstart_sample directory on the install server.
Copy the check script to the directory containing your rules file and run the check script to validate the rules file:
# cd /export/jumpstart<cr>
. /check [-p <path>] [-r <file_name>]
<install_dir_path> is the directory that was specified using the setup_install_server script when the install server was set up.
The check script options are described in Table 7.4.
Table 7.4 Check Script Options
When you use check to validate a rules file, the following things happen:
1. The rules file is checked for syntax. check makes sure that the rule keywords are legitimate, and the <begin>, <class>, and <finish> fields are specified for each rule.
2. If no errors are found in the rules file, each class file specified in the rules file is checked for syntax. The class file must exist in the JumpStart installation directory and is covered in the next section.
3. If no errors are found, check creates the rules.ok file from the rules file, removing all comments and blank lines, retaining all the rules, and adding the following comment line to the end:
version=2 checksum=<num>
As the check script runs, it reports that it is checking the validity of the rules file and the validity of each class file. If no errors are encountered, it reports the following:
The custom JumpStart configuration is ok.
The following is a sample session that uses check to validate a rules and class file. I named the rules file “rulestest” temporarily, the class file is named “basic_prof” and I am using the -r option. With -r, the rules.ok file is not created, and only the rulestest file is checked.
# /export/install/Solaris_10/Misc/jumpstart_sample/check -r/tmp/rulestest<cr>
Validating /tmp/rulestest...
Validating profile basic_prof...
Error in file "/tmp/rulestest", line 113
any - - any_maine -
ERROR: Profile missing: any_maine
In this example, the check script found a bad option. any_machine was incorrectly entered as any_maine. The check script reported this error.
In the next example, the error has been fixed, we copied the file from rulestest to /export/jumpstart/rules, and reran the check script:
# cp rulestest /export/jumpstart/rules<cr>
# cd /export/jumpstart<cr>
# /export/install/Solaris_10/Misc/jumpstart_sample/check<cr>
Validating rules...
Validating profile basic_prof...
Validating profile any_machine...
The custom JumpStart configuration is ok.
As the check script runs, it reports that it is checking the validity of the rules file and the validity of each class file. If no errors are encountered, it reports The custom JumpStart configuration is ok. The rules file is now validated.
After the rules.ok file is created, verify that it is owned by root and that it has permissions set to 644.
begin and finish Scripts
A begin script is a user-defined Bourne shell script, located in the JumpStart configuration directory on the configuration server, specified within the rules file, that performs tasks before the Solaris software is installed on the system. You can set up begin scripts to perform the following tasks:
• Backing up a file system before upgrading
• Saving files to a safe location
• Loading other applications
Output from the begin script goes to /var/sadm/system/logs/begin.log.
CAUTION
Beware of /a Be careful not to specify something in the script that would prevent the mounting of file systems to the /a directory during an initial or upgrade installation. If the Solaris installation program cannot mount the file systems to /a, an error occurs, and the installation fails.
begin scripts should be owned by root and should have permissions set to 744.
In addition to begin scripts, you can also have finish scripts. A finish script is a user-defined Bourne shell script, specified within the rules file, that performs tasks after the Solaris software is installed on the system but before the system restarts. finish scripts can be used only with custom JumpStart installations. You can set up finish scripts to perform the following tasks:
• Move saved files back into place.
• Add packages or patches.
• Set the system’s root password.
Output from the finish script goes to /var/sadm/system/logs/finish.log.
When used to add patches and software packages, begin and finish scripts can ensure that the installation is consistent between all systems.
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.
EXAM ALERT
Terminology warning You’ll see the class file referred to as the profile in many Sun documents, scripts, and programs that relate to JumpStart. In Sun System Administration training classes, however, it is sometimes called a class file. That’s how we refer to it throughout this chapter. On the exams, it is also called both a profile and a class file. The same is true of the configuration server. Sometimes Sun calls this server a profile server.
A class file consists of one or more class file keywords (they 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_10/Misc/jumpstart_sample on the Solaris 10 Software CD 1. 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 can contain either of 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. The class file keywords and their respective values are described in the following sections.
archive_location
This keyword is used when installing a Solaris Flash Archive and specifies the source of the Flash Archive. The syntax for this option is shown here:
archive_location retrieval type location
The retrieval_type parameter can be one of the following:
• NFS
• HTTP or HTTPS
• FTP
• Local tape
• Local device
• Local file
The syntax for a Flash Archive located on an NFS server is as follows:
archive_location nfs server_name:/path/filename <retry n>
where <retry n> specifies the maximum number of attempts to mount the archive.
The syntax for a Flash Archive located on an HTTP or HTTPS server is as follows:
archive_location http://server_name:port/path/filename <optional keywords>
archive_location https://server_name:port/path/filename <optional keywords>
Table 7.5 lists the optional keywords that can be used with this option.
Table 7.5 HTTP Server Optional Keywords
The syntax for a Flash Archive located on an FTP server is as follows:
archive_location ftp://username:password@server_name:port/path/
filename <optional keywords>
Table 7.6 lists the optional keywords that can be used with this option.
Table 7.6 FTP Server Optional Keywords
The syntax for a Flash Archive located on local tape is as follows:
archive_location local_tape <device> <position>
where <device> specifies the device path of the tape drive and <position> specifies the file number on the tape where the archive is located. The <position> parameter is useful because you can store a begin script or a sysidcfg file on the tape prior to the actual archive.
The syntax for a Flash Archive located on a local device is as follows:
archive_location local_device device path/filename file_system_type
The syntax for a Flash Archive located in a local file is as follows:
archive_location local_file path/filename
All that is needed for this option is to specify the full pathname to the Flash Archive file.
backup_media
backup_media defines the medium that is 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.
Table 7.7 backup_media Keywords
Here are some examples of class file keywords being used:
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 boot_device keyword can be used when you install either a UFS file system or ZFS root pool. 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>
Table 7.8 describes the <device> and <eeprom> values.
Table 7.8 boot_device Keywords
NOTE
x86 preserve only For x86 systems, the <eeprom> parameter must be preserve.
The installation program installs the root file system on c0t1d0s0 and updates the EEPROM to start up automatically from the new startup device. For more information on the boot device, see Chapter 3, “Perform System Boot and Shutdown Procedures,” in Solaris 10 System Administration Exam Prep (Exam CX-310-200), Part I.
bootenv_createbe
bootenv_createbe enables an empty, inactive boot environment to be created at the same time the Solaris OS is installed. The bootenv keyword can be used when you install either a UFS file system or ZFS root pool. You only need to create a / file system; other file system slices are reserved, but not populated. This kind of boot environment is installed with a Solaris Flash Archive, at which time the other reserved file system slices are created.
Here’s the bootenv createbe syntax:
bootenv createbe bename <new_BE_name> filesystem <mountpoint:device:fs_options>
The bename and filesystem values are described in Table 7.9.
Table 7.9 bootenv createbe Keywords
For a ZFS root pool, the bootenv keyword changes the characteristics of the default boot environment that is created at install time. This boot new boot environment is a copy of the root file system you are installing. The following options can be used when creating a ZFS root pool:
• installbe: Used to change the characteristics of the default boot environment that gets created during the installation.
• bename <name>: Specifies the name of the new boot environment.
• dataset <mountpoint>: Identifies a /var dataset that is separate from the ROOT dataset. The <mountpoint> value is limited to /var.
For example, to create a ZFS root pool with a boot environment named “zfsroot” and a separate /var dataset, use the following syntax:
bootenv installbe bename zfsroot dataset /var
client_arch
client_arch indicates that the operating system server supports a platform group other than its own. If you do not specify client_arch, any diskless client that uses the operating system server must have the same platform group as the server. client_arch can be used only when system_type is specified as server. You must specify each platform group that you want the operating system server to support.
Here’s the client_arch syntax:
client_arch karch_value [karch_value...]
Valid values for <karch_value> are sun4u and i86pc.
Here’s an example:
client_arch sun4u
client_root
client_root defines the amount of root space, in MB, to allocate for each diskless 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. You can use the client_root keyword only when system_type is specified as server.
Here’s the syntax:
client_root <root_size>
where <root_size> is specified in MB. Here’s an example:
client_root 20
NOTE
Don’t waste space 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 MB, 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% of the disk where it resides, unless free space is left on the disk after the other file systems are laid out.
Here’s the syntax:
client_swap <swap_size>
where <swap_size> is specified in MB.
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. Table 7.10 lists the software groups.
Table 7.10 Software Groups
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.
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
NOTE
dontuse and usedisk You cannot specify the usedisk keyword and the dontuse keyword in the same class file, because they are mutually exclusive.
filesys
The values listed in Table 7.11 can be used for <slice>.
Table 7.11 <slice> Values
The values listed in Table 7.12 can be used for <size>.
Table 7.12 <size> Values
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.
Table 7.13 file_system Values
In the following example, the size of swap is set to 512MB, and it is installed on c0t0d0s1:
filesys c0t0d0s1 512 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.
Table 7.14 optional_parameters Options
A new option to the filesys keyword in Solaris 10 is mirror, which facilitates the creation of RAID-1 volumes as part of the custom JumpStart installation. This facility allows the creation of mirrored file systems. You can issue this keyword more than once to create mirrors for different file systems.
NOTE
Only on initial install The filesys mirror keyword is supported for only initial installations.
The syntax for the filesys mirror keyword is as follows:
Filesys mirror [:<name>]slice [<slice>] <size> <file_system> <optional_parameters>
Table 7.15 details the available options for the filesys mirror keyword.
Table 7.15 filesys mirror Options
filesys can also be used to set 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.16.
Table 7.16 filesys Remote Mount Keywords
Here’s an example:
filesys zeus:/export/home/user1 192.9.200.1 /home ro,bg,intr
forced_deployment
This keyword forces a Solaris Flash differential archive to be installed on a clone system even though the clone system is different from what the software expects. This option deletes files to bring the clone system to an expected state, so it should be used with caution.
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 is the syntax:
install_type [initial_install | upgrade]
Select one of initial_install, upgrade, flash_install, or flash_update.
For a ZFS installation, only the initial_install keyword can be used.
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
geo <locale>
Values you can specify for <locale> are listed in Table 7.17.
Table 7.17 <locale> Values
Refer to the “International Language Environments Guide” in the “Solaris 10 International Language Support Collection” for a complete listing of <locale> values. This guide is available on the Solaris 10 documentation CD, or online at http://docs.sun.com.
Here’s an example where the locale specified is S_America:
geo S_America
layout_constraint
layout_constraint designates the constraint that auto-layout has on a file system if it needs to be reallocated during an upgrade because of space problems. layout_constraint can be used for the upgrade option only 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.18 describes the options for layout_constraint.
Table 7.18 layout_constraint Options
The following are some examples:
layout_constraint c0t0d0s3 changeable 1200
The file system c0t0d0s3 can be moved to another location, and its size can be changed to more than 1200MB but no less than 1200MB.
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.
local_customization
This keyword is used when installing Solaris Flash Archives and can be used to create custom scripts to preserve local configurations on a clone system before installing a Solaris Flash Archive. The syntax for this option is
local_customization local_directory
The local_directory parameter specifies the directory on the clone system where any scripts are held.
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 (.
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.
Following is the locale syntax:
locale <locale_name>
Here’s an example:
locale es
This example specifies Spanish as the language package you want installed.
metadb
The metadb keyword allows you to create Solaris Volume Manager state database replicas as part of the custom JumpStart installation. You can use this keyword more than once to create state database replicas on several disk slices.
The syntax for this keyword is shown here:
metadb slice [size <size-in-blocks>] [count <number-of-replicas>]
Table 7.19 describes the options for metadb.
no_content_check
This keyword is used when installing Solaris Flash Archives. When specified, it ignores file-by-file validation, which is used to ensure that a clone system is a duplicate of the master system. Use this option only if you are sure the clone is a duplicate of the master system, because files are deleted to bring the clone to an expected state if discrepancies are found.
no_master_check
This keyword is used when installing Solaris Flash Archives. When specified, it ignores the check to verify that a clone system was built from the original master system. Use this option only if you are sure the clone is a duplicate of the original master system.
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. You can use this option only when system_type is set to server.
Following is 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 that is installed on the system. add or delete indicates the action required. If you do not specify add or delete, add is set by default.
Following is the syntax:
package <package_name> [add [<retrieval_type> location] | delete]
The <package_name> must be in the form SUNWname.
The <retrieval_type> parameter can be one of the following:
• NFS
• HTTP or HTTPS
• Local device
• Local file
The syntax for a package located on an NFS server is as follows:
package <package_name> add nfs server_name:/path <retry n>
where <retry n> specifies the maximum number of attempts to mount the directory.
The syntax for a package located on an HTTP or HTTPS server is as follows:
package <package_name> add http://server_name:port/path <optional keywords>
package <package_name> add https://server_name:port/path <optional keywords>
Table 7.20 lists the optional keywords that can be used with this option.
Table 7.20 HTTP package Optional Keywords
The syntax for a package located on a local device is as follows:
package <package_name> add <local_device> <device> <path> <file_system_type>
The syntax for a package located in a local file is as follows:
package <package_name> add <local_file> <path>
All that is needed for this option is to specify the full pathname to the directory containing the package.
Here’s an example:
package SUNWxwman add nfs server1:/var/spool/packages retry 5
In this example, SUNWxwman (X Window online man pages) is being installed on the system from a location on a remote NFS server.
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.
Following is the syntax:
partitioning default|existing|explicit
The partitioning options are described in Table 7.21.
Table 7.21 partitioning Options
pool
The pool keyword is used for ZFS only and defines the new root pool to be created. The syntax for this keyword is as follows:
pool <poolname> <poolsize> <swapsize> <dumpsize> <vdevlist>
where <poolname> is the name of the new ZFS pool to be created.
The <poolsize>, <swapsize>, <dumpsize>, and <vdevlist> options, described in the following list, are required:
• <poolsize>: A value specifying the size of the new pool to be created. The size is assumed to be in megabytes unless g or auto is specified. auto allocates the largest possible pool size on the device.
• <swapsize>: A value specifying the size of the swap volume (zvol). The options are auto and size. When using auto, the swap area is automatically sized. The default size is one half the size of physical memory, but no less than 512MB and no greater than 2GB. You can set the size outside this range by using the size option. size is assumed to be in megabytes, unless specified by g (gigabytes).
• <dumpsize>: Specifies the size of the dump volume that will be created within the new root pool. Use the auto option to use the default swap size, or specify a custom size using the size option.
• <vdevlist>: Specifies the devices used to create the pool. Devices in the vdevlist must be slices for the root pool. vdevlist can be either a <single-device-name> in the form c#t#d#s#, or mirror or any option:
• <single-device-name>: A disk slice in the form or c#t#d#s#, such as c0t0d0s0.
• mirror <device-names>: Specifies the mirroring of the disk. The device names are in the form of c#t#d#s#.
• mirror any: Enables the installer to select a suitable device.
The following example creates a new 20GB root pool on device c0t0d0s0, the swap and dump volumes are 4GB each:
pool rpool 20G 4G 4G c0t0d0s0
The following example installs a mirrored ZFS root pool. The root pool is named “rootpool,” the disk slice is 80GB, and the swap and dump volumes are 2GB each. The root pool will be mirrored and will use any two available devices that are large enough to create an 80GB pool:
pool rootpool 80g 2g 2g mirror any any
This example is the same as the previous one, except that the disk devices are specified:
pool rootpool 80g 2g 2g mirror c0t0d0s0 c1t0d0s0
This example creates a new root pool named “rootpool.” The size of the pool is determined automatically by the size of the disks, the swap is sized automatically (half of physical memory), the dump device is sized automatically, and the mirror is set up on devices c0t0d0s0 and c1t0d0s0:
pool rootpool auto auto auto mirror c0t0d0s0 c0t1d0s0
patch
patch specifies the patch ID numbers that are to be installed. The list should be a list of comma-separated Solaris patch IDs (no spaces). The patches are installed in the order specified in the list. The syntax for this keyword is as follows:
patch <patchid_list>
patch <patch_file> <patch_location> <optional_keywords>
where:
• <patchid_list>: Specifies the patch ID numbers that are to be installed.
• <patch_file>: A file that contains a list of patches that are found in the <patch_location>.
• <patch_location>: Specifies the location where the patches are found. This location can be an NFS server, HTTP server, local device, or local file.
• <optional_keywords>: Optional keywords that depend on where the patches are stored. Refer to “Solaris 10 Installation Guide: JumpStart and Advanced Installations” for a list of keywords.
root_device
root_device designates the system’s root disk.
Following is the syntax:
root_device <slice>
Here’s an example:
root_device c0t0d0s0
NOTE
Specifying mirrors If you are upgrading a RAID-1 (mirror) volume, the slice you specify should be one side of the mirror. The other side will be upgraded automatically.
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.
Following is the syntax:
system_type [standalone | server]
Here’s an example:
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.
Following is the syntax:
usedisk <disk_name> [<disk_name>]
Here’s an example:
usedisk c0t0d0 c0t1d0
NOTE
dontuse and usedisk You cannot specify the usedisk keyword and the dontuse keyword in the same class file, because they are mutually exclusive.
Testing Class Files
After you create a class file, you can use the pfinstall command to test it. Testing a class file is sometimes called a dry run installation. By looking at the installation output generated by pfinstall, you can quickly determine whether a class file will do what you expect. For example, you can determine whether a system has enough disk space to upgrade to a new release of Solaris before you actually perform the upgrade.
To test a class file for a particular Solaris release, you must test it within the Solaris environment of the same release. For example, if you want to test a class file for Solaris 10, you have to run the pfinstall command on a system running Solaris 10.
To test the class file, change to the JumpStart directory that contains the class file, and type the following:
# /usr/sbin/install.d/pfinstall -d<disk_config><cr>
or type the following:
# /usr/sbin/install.d/pfinstall -D<cr>
NOTE
Install or test? Without the -d or -D option, pfinstall actually installs the Solaris software on the system by using the specified class file, and the data on the system is overwritten.
Following is the syntax for pfinstall:
/usr/sbin/install.d/pfinstall [-D|-d] <disk_config> [-c <path>] <profile>
The pfinstall options are described in Table 7.22.
Table 7.22 pfinstall Options
You can create a <disk_config> file by issuing the following command:
prtvtoc /dev/rdsk/<device_name> > <disk_config>
where /dev/rdsk/<device_name> is the device name of the system’s disk. <device_name> must be in the form c?t?d?s2 or c?d?s2. <disk_config> is the name of the disk configuration file to contain the redirected output.
NOTE
Identifying disks c?t?d?s2 designates a specific target for a SCSI disk, and c?d?s2 designates a non-SCSI disk.
Here’s an example:
# prtvtoc /dev/rdsk/c0t0d0s2 > test<cr>
The file named “test” created by this example would be your <disk_config> file, and it would look like this:
NOTE
Multiple disks If you want to test installing Solaris software on multiple disks, concatenate single disk configuration files and save the output to a new file.
The following example tests the ultra_class class file against the disk configuration on a Solaris 10 system on which pfinstall is being run. The ultra_class class file is located in the /export/jumpstart directory, and the path to the Solaris CD image is specified because Volume Management is being used.
In addition, if you want to test the class file for a system with a specific system memory size, set SYS_MEMSIZE to the specific memory size in MB. For this example, I’ll set SYS_MEMSIZE to 512MB:
# SYS_MEMSIZE=512<cr>
# export SYS_MEMSIZE<cr>
# cd /export/jumpstart<cr>
# /usr/sbin/install.d/pfinstall -D -c /cdrom/cdrom0/s0 ultra_class<cr>
The system tests the class file and displays several pages of results. Look for the following message, which indicates that the test was successful:
Installation complete
Test run complete. Exit status 0.
sysidcfg File
When a SPARC-based JumpStart client boots for the first time, the booting software first tries to obtain the system identification information from either the sysidcfg file or a name service. The identification information and the configurable sources are described in Table 7.23.
Table 7.23 JumpStart Client Identification Information
The JumpStart client determines the location of the sysidcfg file from the BOOTPARAMS information provided by the boot server. The location of the sysidcfg file was specified when you set up the JumpStart client on the boot server using the add_install_client script. If you’re not using a name service, you’ll use the sysidcfg file to answer system identification questions during the initial part of the installation. If you’re using a name service, you’ll want to look over the section “Setting Up JumpStart in a Name Service Environment.”
You’ll use the sysidcfg file to answer system identification questions during the initial part of the installation. If the JumpStart server provides this information, the client bypasses the initial system identification portion of the Solaris 10 installation process. Without the sysidcfg file, the client displays the appropriate interactive dialog to request system identification information. You must create a unique sysidcfg file for every system that requires different configuration information.
The sysidcfg file can reside on a shared NFS directory or the root (/) directory on a UFS file system. It can also reside on a PCFS file system located on a diskette. Only one sysidcfg file can reside in a directory or on a diskette. The location of the sysidcfg file is specified by the -p argument to the add_install_client script used to create a JumpStart client information file.
Creating a sysidcfg file requires the system administrator to specify a set of keywords in the sysidcfg file to preconfigure a system. You use two types of keywords in the sysidcfg file: independent and dependent. Here’s an example illustrating independent and dependent keywords:
name_service=NIS {domain_name=pyramid.com name_server=server(192.168.0.1)}
In this example, name_service is the independent keyword, and domain_name and name_server are the dependent keywords.
NOTE
Dependent keywords Enclose all dependent keywords in curly braces ({ }) to tie them to their associated independent keyword. Values can optionally be enclosed in single quotes (‘) or double quotes (“).
To help explain sysidcfg keywords, we’ll group them in categories and describe each of them in detail.
Name Service, Domain Name, and Name Server Keywords
The following keywords are related to the name service you will be using.
The name_service=<value> keyword is assigned one of five values that specify the name service to be used: NIS, NIS+, LDAP, DNS, and NONE:
• NIS or NIS+: If you are using NIS as your name service, for example, specify the following:
name_service=NIS
For the NIS and NIS+ values, additional keywords are specified:
domain_name=<value>
The domain <value> in the previous line is the domain name, such as pyramid.com.
name_server=<value>
The name_server <value> is the hostname or IP address for the name server. For the name_server <value>, you can specify up to three IP addresses for the name_server. For example:
name_server=192.168.0.1,192.168.0.2,192.168.0.3
• DNS: If you are using DNS for the name_service <value>, specify the following:
name_service=DNS
Then you need to specify the following additional dependent keywords:
domain_name=<value>
Enter the domain name for the domain_name <value>. For example, if the domain name is pyramid.com, specify it as follows:
domain_name=pyramid.com
For the name_server <value>, you can specify up to three IP addresses for the name_server. For example:
name_server=192.168.0.1,192.168.0.2,192.168.0.3
The search option adds the values to the search path to use for DNS queries. Specify the following:
search=<value>
where <value> is the search entry, which cannot exceed 250 characters. Here’s a sample DNS search entry:
search=pyramid.com,east.pyramid.com,west.pyramid.com
• LDAP: If you are using LDAP for the name_service <value>, specify the following:
name_service=LDAP
Then you need to specify the following additional dependent keywords:
domain_name=<value>
Enter the domain name for the domain_name <value>. For example, if the domain name is pyramid.com, specify it as follows:
domain_name=pyramid.com
The profile parameter can also be specified to identify an LDAP profile to use. Specify this as follows:
profile=<value>
where <value> is the profile name.
The profile server identifies the IP address of the profile server from which the LDAP profile can be obtained. Specify this as follows:
profile_server=<value>
where <value> is the IP address of the profile server.
Here’s an example LDAP entry with its dependent keywords:
name_service=LDAP
{domain_name=west.pyramid.com
profile=default
profile_server=192.168.0.100}
Network-Related Keywords
Network-related keywords relate to the network interface to be used. Specify this item as follows:
network_interface=<value>
Specify a <value> for the interface to be configured. You can enter a specific interface, such as eri0, or you can enter NONE (if there are no interfaces to configure) or PRIMARY (to select the primary interface):
network_interface=eri0
If you are not using DHCP, the dependent keywords for a PRIMARY interface are as follows:
hostname=<hostname>
ip_address=<ip_address>
netmask=<netmask value>
default_route=<ip_address>
protocol_ipv6=<yes or no>
For example, if your primary network interface is named eri0, here’s a sample sysidcfg file:
network_interface=eri0
{primary hostname=client1
ip_address=192.168.0.10
netmask=255.255.255.0
default_route=192.168.0.1
protocol_ipv6=no}
If you are using DHCP, the only keywords available are the following:
dhcp protocol_ipv6=<yes or no>
For example, here’s a sample entry:
network_interface=eri0 {primary dhcp protocol_ipv6=no}
Whether using DHCP or not, the protocol_ipv6 keyword is optional.
NOTE
Multiple interfaces allowed You can now enter multiple network interfaces into the sysidcfg file; just specify a separate network_interface entry for each one to be included.
Setting the Root Password
The root password keyword is
root_password=<encrypted passwd>
The value for <encrypted passwd> is taken from the /etc/shadow file. For example, an entry might look like this:
root_password=XbcjeAgl8jLeI
The following is the security related keyword:
security_policy=<value>
where <value> is either KERBEROS or NONE.
When specifying the KERBEROS value, you also need to specify the following dependent keywords:
default_realm=<fully qualified domain name>
admin_server=<fully qualified domain name>
kdc=<value>
where <value> can list a maximum of three key distribution centers (KDCs) for a security_policy keyword. At least one is required. Here’s an example using the security_policy keyword:
security_policy=kerberos
{default_realm=pyramid.com
admin_server=krbadmin.pyramid.com
kdc=kdc1.pyramid.com,kdc2.pyramid.com}
Setting the System Locale, Terminal, Time Zone, and Time Server
The keyword used to set the system locale is
system_locale=<value>
where <value> is an entry from the /usr/lib/locale directory. The following example sets the value to English:
system_locale=en_US
The keyword to set the terminal type is as follows:
terminal=<terminal_type>
where <terminal_type> is an entry from the /usr/share/lib/terminfo database. The following example sets the terminal type to vt100:
terminal=vt100
The keyword to set the time zone is as follows:
timezone=<timezone>
where <timezone> is an entry from the /usr/share/lib/zoneinfo directory. The following entry sets the time zone to Eastern Standard Time:
timezone=EST
The keyword to set the time server is as follows:
timeserver=<value>
where <value> can be LOCALHOST, HOSTNAME, or IP_ADDRESS. The following example sets the time server to be the localhost:
timeserver=localhost
The following rules apply to keywords in the sysidcfg file:
• Keywords can be in any order.
• Keywords are not case-sensitive.
• Keyword values can be optionally enclosed in single quotes (‘).
• Only the first instance of a keyword is valid; if you specify the same keyword more than once, the first keyword specified is used.
The following is a sample sysidcfg file, located in the configuration directory named /export/jumpstart:
system_locale=en_US
timezone=EST
timeserver=localhost
terminal=vt100
name_service=NONE
security_policy=none
root_password=XbcjeAgl8jLeI
nfs4_domain=dynamic
network_interface=eri0 {primary hostname=sunfire ip_address=192.168.1.10
protocol_ipv6=no netmask=255.255.255.0}
Setting Up JumpStart in a Name Service Environment
As stated in the previous section, you can use the sysidcfg file to answer system identification questions during the initial part of installation regardless of whether a name service is used. When the sysidcfg file is used with the NIS naming service, identification parameters such as locale and time zone can be provided from the name service. The sysidcfg file necessary for installing a JumpStart client on a network running the NIS name service is typically much shorter, and a separate sysidcfg file for each client is unnecessary.
You’ll use the /etc/locale, /etc/timezone, /etc/hosts, /etc/ethers, and /etc/netmasks files as the source for creating NIS databases to support JumpStart client installations. See Chapter 5 for more information on NIS and how to create NIS maps.
Setting Up Clients
Now you need to set up the clients to install over the network. After setting up the /export/jumpstart directory and the appropriate files, use the add_install_client command on the install server to set up remote workstations to install Solaris from the install server. The command syntax for the add_install_client command is as follows:
add_install_client [-e <ethernet_addr>] [-i <ip_addr>]
[-s <install_svr:/dist>] [-c <config_svr:/config_dir>]
[-p <sysidcfg_svr/sysid_config_dir>] <host_name> <platform group>
add_install_client -d [-s <install_svr:/dist>] [-c
<config_svr:/config_dir>] [-p <sysidcfg_svr/sysid_config_dir>]
[-t install_boot_image_path] <platform_name> <platform group>
The add_install_client options are described in Table 7.24.
Table 7.24 add_install_client Options
For additional options to the add_install_client command, see the Solaris online manual pages.
In Step By Step 8.5, you’ll create a JumpStart client that will boot from a system that is configured as both the boot and install server. In addition, the entire Solaris 10 media is copied to the local disk.
STEP BY STEP
8.5 Creating a JumpStart Client
NOTE
Sample setup In the following steps, the following associations have been made in the examples: Install server name: sunserver
Distribution directory: /export/jumpstart/install
Configuration server name: sunserver
Configuration directory: /export/jumpstart/config
Boot server name: sunserver
Install client: client1
Install client’s MAC address: 8:0:20:21:49:25
Client architecture: sun4u
1. On the install server, change to the directory that contains the installed Solaris 10 Operating Environment image:
# cd /export/jumpstart/install/Solaris_10/Tools<cr>
2. Create the JumpStart client using the add_install_client script found in the local directory:
# . /add_install_client -s sunfire:/export/jumpstart/install -c
sunfire: /export/jumpstart/config -p sunfire:/export/jumpstart -e
8:0:20:21:49:25 -i 192.168.1.106 client1 sun4u<cr>
The system responds with this:
Adding Ethernet number for client1 to /etc/ethers
Adding “share -F nfs -o ro,anon=0 /export/jumpstart/install” to
/etc/dfs/dfstab
making /tftpboot
enabling tftp in /etc/inetd.conf
updating /etc/bootparams
copying inetboot to /tftpboot
The add_install_client script automatically made entries into the following files and directory:
3. Use the rm_install_client command to remove a JumpStart client’s entries and configuration information from the boot server:
#. /rm_install_client client1<cr>
The system responds with this:
removing client1 from bootparams
removing /etc/bootparams, since it is empty
removing /tftpboot/inetboot.SUN4U.Solaris_10-1
removing /tftpboot
disabling tftp in /etc/inetd.conf
TIP
Know your config files Make sure you are familiar with the differences between the rules file, a class file, and the sysidcfg file. It is quite common to get an exam question that displays the contents of one of them and asks you to identify which one it is.
Troubleshooting JumpStart
The most common problems encountered with custom JumpStart involve the setting up of the network installation, or booting the client. This section describes briefly some of the more popular errors and what to do if you are faced with them.
Installation Setup
When running the add_install_client command to set up a new JumpStart client, you might get the following message:
Unknown client “hostname”
The probable cause of this error message is that the client does not have an entry in the hosts file (or table if using a name service).
Make sure the client has an entry in the hosts file, or table, and rerun the add_install_client command.
When you have set up the JumpStart Install server, make sure the relevant directories are shared correctly. It is a common problem to share the file systems at the wrong level so that the table of contents file cannot be found when the client tries to mount the remote file system.
Client Boot Problems
The following error message can appear if the Ethernet address of the JumpStart client has been specified incorrectly:
Timeout waiting for ARP/RARP packet...
Check the /etc/ethers file on the JumpStart server, and verify that the client’s Ethernet address has been specified correctly.
When booting the client from the network, to initiate a custom JumpStart installation, you might get the following error message if more than one server attempts to respond to the boot request:
WARNING: getfile: RPC failed: error 5 (RPC Timed out).
This error indicates that more than one server has an entry for the client in its /etc/boot-params file. To rectify this problem, you need to check the servers on the subnet to find any duplicate entries and remove them, leaving only the entry required on the JumpStart server.
When booting the client from the network, you could get the following error message if the system cannot find the correct media required for booting:
The file just loaded does not appear to be executable
You need to verify that the custom JumpStart server has been correctly set up as a boot and install server. Additionally, make sure you specified the correct platform group for the client when you ran add_install_client to set up the client to be able to use JumpStart.
A Sample JumpStart Installation
The following example shows how you would set up a custom JumpStart installation for a fictitious site. The network consists of an Enterprise 3000 server and five Ultra workstations. The next section details how to start the JumpStart installation process by creating the install server.
Setting Up the Install Server
The first step is to set up the install server (see Step By Step 8.6). You’ll choose the Enterprise server. This is where the contents of the Solaris CD are located. The contents of the CD can be made available by either loading the CD in the CD-ROM drive or copying the CD to the server’s local hard drive. For this example, you will copy the files to the local hard drive. Use the setup_install_server command to copy the contents of the Solaris CD to the server’s local disk. Files are copied to the /export/install directory.
STEP BY STEP
8.6 Setting Up the Install Server
1. Insert the Solaris Software CD 1 into the server’s CD-ROM drive.
2. Type the following:
# cd /cdrom/cdrom0/s0/Solaris_10/Tools<cr>
# . /setup_install_server /export/install<cr>
The system responds with this:
Verifying target directory...
Calculating the required disk space for the Solaris_10 Product
Calculating space required for the installation boot image
Copying the CD image to disk...
Copying Install boot image hierarchy...
Install Server setup complete
3. Eject the Solaris 10 Software CD 1, and put in the Solaris 10 Software CD 2. Let vold automatically mount the CD.
4. Change to the Tools directory on the CD:
# cd /cdrom/cdrom0/Solaris_10/Tools<cr>
5. Execute the add_to_install_server script as follows to copy the images from the CD to the /export/install directory:
# . /add_to_install_server /export/install<cr>
6. Repeat steps 3, 4, and 5 for the remaining CDs.
Creating the JumpStart Directory
After you install the install server, you need to set up a JumpStart configuration directory on the server. This directory holds the files necessary for a custom JumpStart installation of the Solaris software. You set up this directory by copying the sample directory from one of the Solaris CD images that has been put in /export/install. Do this by typing the following:
# mkdir /export/jumpstart<cr>
# cp -r /export/install/Solaris_10/Misc/jumpstart_sample/* /export/jumpstart<cr>
Any directory name can be used. You’ll use /export/jumpstart for this example.
Setting Up a Configuration Server
Follow the procedure in Step By Step 8.7 to set up a configuration server.
STEP BY STEP
8.7 Setting Up a Configuration Server
1. Log in as root on the server where you want the JumpStart configuration directory to reside.
2. Edit the /etc/dfs/dfstab file. Add the following entry:
# share -F nfs -o ro,anon=0 /export/jumpstart<cr>
3. Type shareall and press Enter. This makes the contents of the /export/jumpstart directory accessible to systems on the network.
4. Working with the sample class file and rules files that were copied into the JumpStart directory earlier, use them to create configuration files that represent your network. For this example, I create a class file named engrg_prof. It looks like this:
#Specifies that the installation will be treated as an initial
#installation, as opposed to an upgrade.
install_type initial_install
#Specifies that the engineering systems are standalone systems.
system_type standalone
#Specifies that the JumpStart software uses default disk
#partitioning for installing Solaris software on the engineering
#systems.
partitioning default
#Specifies that the developer’s software group will be installed.
Cluster SUNWCprog
#Specifies that each system in the engineering group will have 2048
#Mbytes of swap space.
filesys any 2048 swap
The rules file contains the following rule:
network 192.9.200.0 - engrg_prof -
This rules file states that systems on the 192.9.200.0 network are installed using the engrg_prof class file.
5. Validate the rules and class files:
# cd /export/jumpstart<cr>
# ./check<cr>
Validating rules...
Validating profile eng_prof...
The custom JumpStart configuration is ok.
# /usr/sbin/install.d/pfinstall -D -c /export/install engrg_prof<cr>
If check doesn’t find any errors, it creates the rules.ok file. Look for the following message, which indicates that the pfinstall test was successful:
Installation complete
Test run complete. Exit status 0.
You are finished creating the configuration server.
Setting Up Clients
Now, on the install server, set up each client:
# cd /export/install/Solaris_10/Tools<cr>
# ./add_install_client -s sparcserver:/export/install -c sparcserver:
/export/jumpstart -p sparcserver:/export/jumpstart -e 8:0:20:21:49:25
-i 192.9.200.106 sun1 sun4u<cr>
# ./add_install_client -s sparcserver:/export/install -c sparcserver:
/export/jumpstart -p sparcserver:/export/jumpstart -e 8:0:20:21:49:24
-i 192.9.200.107 sun2 sun4u<cr>
This example sets up two engineering workstations, sun1 and sun2, so that they can be installed over the network from the install server named sparcserver. It is assumed that a sysidcfg file is located in the /export/jumpstart directory on “sparcserver” and that both clients will use the same sysidcfg file.
Starting Up the Clients
After the setup is complete, you can start up the engineering systems by using the following startup command at the OK (PROM) prompt of each system:
# boot net - install<cr>
You see the following:
Rebooting with command: net - install
Boot device: /pci@1f,0/pci@1,1/network@1,1 File and args: - install
20800
SunOS Release 5.10 Version Generic_127127-11_64-bit
Copyright 1983-2008 Sun Microsystems, Inc. All rights reserved.
whoami: no domain name
Configuring /dev and /devices
Using RPC Bootparams for network configuration information.
Configured interface eri0
Using sysid configuration file 192.9.200.101:/export/jumpstart/sysidcfg
The system is coming up. Please wait.
Starting remote procedure call (RP services: sysidns done.
Starting Solaris installation program...
Searching for JumpStart directory...
Using rules.ok from 192.9.200.101:/export/jumpstart.
Checking rules.ok file...
Using profile: engrg_prof Executing JumpStart preinstall phase...
Searching for SolStart directory...
Checking rules.ok file...
Using begin script: install_begin
Using finish script: patch_finish
Executing SolStart preinstall phase...
Executing begin script "install_begin"...
Begin script install_begin execution completed.
Processing default locales
- Specifying default locale (en_US)
Processing profile
- Selecting cluster (SUNWCprog)
WARNING: Unknown cluster ignored (SUNWCxgl)
- Selecting package (SUNWaudmo)
- Selecting locale (en_US)
Installing 64 Bit Solaris Packages
- Selecting all disks
- Configuring boot device
- Configuring swap (any)
- Configuring /opt (any)
- Automatically configuring disks for Solaris operating environment
Verifying disk configuration
Verifying space allocation
- Total software size: 3771.46 Mbytes
Preparing system for Solaris install
Configuring disk (c0t0d0)
- Creating Solaris disk label (VTO
Creating and checking UFS file systems
- Creating / (c0t0d0s0)
- Creating /opt (c0t0d0s5)
Beginning Solaris software installation
Starting software installation
SUNWxwrtl...done. 3756.31 Mbytes remaining.
<output truncated>
Completed software installation
Solaris 10 software installation succeeded
Customizing system files
- Mount points table (/etc/vfstab)
- Network host addresses (/etc/hosts)
Customizing system devices
- Physical devices (/devices)
- Logical devices (/dev)
Installing boot information
- Installing boot blocks (c0t0d0s0)
Installation log location
- /a/var/sadm/system/logs/install_log (before reboot)
- /var/sadm/system/logs/install_log (after reboot)
Installation complete
Executing SolStart postinstall phase...
Executing finish script "patch_finish"...
Finish script patch_finish execution completed.
Executing JumpStart postinstall phase...
The begin script log 'begin.log'
is located in /var/sadm/system/logs after reboot.
The finish script log 'finish.log'
is located in /var/sadm/system/logs after reboot.
syncing file systems... done
rebooting...
The client reads the sysidcfg file, and then the class file, and then the rules.ok file on the server. If any system identification information is missing in the sysidcfg file, the client displays the appropriate dialog requesting identification information. The system then automatically installs the Solaris operating environment.
This completes the JumpStart configuration.
Solaris Flash
Objective
• Explain Flash, create and manipulate the Flash Archive, and use it for installation.
The main feature of Solaris Flash is to provide a method to store a snapshot of the Solaris operating environment, complete with all installed patches and applications. This snapshot is called the Flash Archive, and the system that the archive is taken from is called the master machine. This archive can be stored on disk, CD-ROM, or tape media. You can use this archive for disaster recovery purposes or to replicate (clone) an environment on one or more other systems. When using a Flash Archive to install the Solaris environment onto a system, the target system we are installing the environment on is called the installation client.
When you’re ready to install the Solaris environment using the Flash Archive, you can access the archive on either local media or across the network. The Flash Archive is made available across the network by using FTP, NFS, HTTP, or HTTPS. Furthermore, when installing from a Flash Archive onto the installation client, the install can be modified from the original archive to accommodate things such as kernel architecture, device differences, and partitioning schemes between the master machine and the installation client.
A few limitations of the Flash Archive are worth noting:
• Flash does not support metadevices or non-UFS file systems.
• The archive can only be generated using packages that are currently installed and available on the master server.
You can also initiate pre- and post-installation scripts to further customize the system before or after the installation of the Flash Archive. These standard shell scripts can be run during creation, installation, post-installation, and the first reboot. Specifically, you could use these scripts to perform the following tasks:
• Configure applications on the clone.
• Validate the installation on the clone.
• Protect local customizations from being overwritten by the Solaris Flash software.
This section describes how to create the Flash Archive using the flarcreate command, how to obtain information from an existing Flash Archive using the flar command, and how to install the operating system on an installation client from a Flash Archive.
NOTE
Flash install enhancement A Flash installation can now be used to update a system, using a differential Flash Archive. Previously, a Flash Install could only be used to perform an initial installation. A new <install_type> of flash_update is available with Solaris 10.
Creating a Flash Archive
The first step is to identify the master machine. This system will serve as the template for the archive. All software and data on the master machine, unless specifically excluded, will become part of the Flash Archive that will be installed on the installation client.
Next, make sure that the master machine is completely installed, patched, and has all its applications installed. Depending on the application, you may want to create the archive before the application is configured, however. This will allow you to configure the application specifically for each system it is running on. To ensure that the archive is clean, it’s recommended that the archive be created before the master machine has ever gone into production and while the system is in a quiescent state.
Finally, determine where the archive will be stored. You can store the archive onto a disk, a CD-ROM, or a tape. After the archive has been stored, you can even compress it so that it takes up less space. Because these archives can be used for disaster recovery, store the archive somewhere offsite.
You’ll use the flarcreate command to create the archive. The syntax for the command is as follows:
The options to the flarcreate command are described in Table 7.25. In this command syntax, <archive> is the name of the archive file to be created. If you do not specify a path, flar-create saves the archive file in the current directory.
Table 7.25 Command-Line Options for flarcreate
Additional options are available, such as for creating the archive on tape and adding some user-defined options. Information on these options is found in the online manual pages and in the Solaris 10 Installation Guide in the Solaris 10 Release and Installation Collection.
The following example shows how to use the flarcreate command to create the Flash Archive:
# flarcreate -n “Solaris 10 Ultra Archive” -a “WS Calkins” -R / /u01/ultra.lfar<cr>
In the previous example, we are creating a Flash Archive named “Solaris 10 Ultra Archive.” We are specifying the author (creator) to be labeled as “WS Calkins.” The -R option specifies to recursively descend from the specified directory. The last part of the command specifies which directory to store the archive in and what to name the archive.
After you enter the command and press Enter, the flarcreate command displays the status of the operation:
Full Flash Checking integrity...
Integrity OK.
Running precreation scripts...
Precreation scripts done.
Determining the size of the archive...
8172587 blocks
The archive will be approximately 3.89GB.
Creating the archive...
8172587 blocks
Archive creation complete.
Running postcreation scripts ...
Postcreation scripts done.
Running pre-exit scripts ...
Pre-exit scripts done.
When the operation is complete, you can see the archive file by issuing the ls command:
# ls -l /u01/ultra.flar<cr>
-rw-r—r— 1 root other 3820943938 Sep 3 11:12 ultra.flar
The flar command is used to administer Flash Archives. With the flar command, you can
• Extract information from an archive
• Split archives
• Combine archives
To use the flar command to extract information from an archive, use the following command:
# flar -i /u01/ultra.flar<cr>
The system displays the following information about the Flash Archive:
archive_id=fb2cfa3c51d3af4a10ce6e804243fe19
files_archived_method=cpio
creation_date=20090217003131
creation_master=ultra
content_name=Solaris 10 Ultra Archive
creation_node=ultra10
creation_hardware_class=sun4u
creation_platform=SUNW, UltraAX-i2
creation_processor=sparc
creation_release=5.10
creation_os_name=SunOS
creation_os_version=Generic_137137-09
files_compressed_method=none
files_archived_size=4184375301
files_unarchived_size=4184375301
content_author=WS Calkins
content_architectures=sun4u
type=FULL
For additional information on the flarcreate or flar commands, refer to the online manual pages or the Solaris 10 Installation Guide: Solaris Flash Archive (Creation and Installation)” in the Solaris 10 Release and Installation Collection.
Using the Solaris Installation Program to Install a Flash Archive
In the previous section we described how to create a Flash Archive. In this section, you learn how to install this archive on an installation client using the GUI-based Solaris installation program.
The Flash Archive was created on a system named ultra10 with the IP address of 192.168.0.110 and placed into a file system named /u01. On ultra10 we need to share the /u01 file system so that the archive is available to other systems on the network via NFS. You use the share command to do this. NFS and the share command are described in Chapter 2.
Initiate a Solaris installation from CD-ROM. When prompted to select the Installation Media, as shown in Figure 7.1, select Network File System.
FIGURE 7.1 Specify Media window.
Click the Next button. You’re prompted to enter the path to the network file system that contains the Flash Archive, as shown in Figure 7.2.
FIGURE 7.2 Specify Network file system path window.
After entering the path, click the Next button. The Flash Archive Summary window appears, as shown in Figure 7.3.
FIGURE 7.3 Flash Archive Summary window.
The selected archive is listed. Verify that it is correct, and then click the Next button. You’re prompted to enter any additional archives you want to install, as shown in Figure 7.4.
FIGURE 7.4 Additional Flash Archives window.
You have no additional archives to install, so click the Next button. The system is initialized, as shown in Figure 7.5.
FIGURE 7.5 Initialization window.
After the system initialization is finished, you see the Disk Selection window displayed as with a normal GUI-based installation. From this point forward, the installation continues as a normal GUI-based installation. The difference is that you are not asked to select the software you want to install. Instead, the entire Flash Archive is installed. When the installation is complete, the system reboots (if you selected this option during the earlier dialog), and the login message appears. The final step is to log in as root, configure your applications, and make system-specific customizations. The system is now ready for production use.
Creating a Differential Flash Archive
If you created a clone system using a Flash Archive, you can update that clone using a differential archive. For example, let’s say you have already created a Flash Archive on a master server using the flarcreate command, and you used that archive to install a clone system. Later, on the master server, you install updates and make other changes to the OS, and you want to apply these changes to the clone system. You’ll use a differential archive to accomplish the task. When installing the differential archive on the clone, using custom JumpStart or Live Upgrade, only the files that are in the differential archive are changed.
NOTE
Differential update failure If the clone has been manually updated after it was originally created from the master server’s archive, the differential update fails.
When creating a differential archive on the master server, the original master Flash Archive must still be present and untouched. After updating or making changes to the master server’s OS, you’ll create a differential archive by comparing the current OS to the original master Flash Archive. The differential archive is created and contains the differences between the two archives.
Step By Step 7.8 describes the process of creating a differential archive.
STEP BY STEP
7.8 Creating a Differential Archive
1. Create your original Flash Archive on the master server:
# flarcreate -n “Archive” /u01/original.flar<cr>
This is the archive that was initially used to create the clone.
2. After modifying the master server (adding/removing packages, patches, and so on), create a differential archive by comparing the original Flash Archive with the current OS image that is installed in (/):
# flarcreate -n “differential archive” -A /u01/original.flar /u01/diff_archive<cr>
where -A specifies the location of the original, unchanged master Flash Archive.
The name of the new differential archive is /u01/diff_archive.
Now you can install the differential archive on the clone system with custom JumpStart. Or you can use Solaris Live Upgrade to install the differential archive on an inactive boot environment.
Solaris Flash and JumpStart
Earlier in this chapter, I described how to set up a JumpStart installation. If you recall, we set up a boot server, which provided the information that a JumpStart client needed to boot across the network. We also set up an install server, which supplied the Solaris image, and we created the profile and rules configuration files which provided additional setup information such as disk partitions and software packages.
You can utilize a Solaris Flash Archive in a JumpStart installation, but first you need to add the installation client to the JumpStart boot server as described earlier in this chapter.
The next step is to create a profile for the installation client. This was also described earlier in this chapter. However, when using JumpStart to install from a Flash Archive, only the following keywords can be used in the profile:
• archive_location
• install_type: For a full flash archive install, specify this option as flash_install. For a differential flash archive, specify flash_update.
• partitioning: Only the keyword values of explicit or existing must be used.
• filesys: The keyword value auto must not be used.
• forced_deployment
• local_customization
• no_content_check: Used only for a differential flash archive.
• no_master_check: Used only for a differential flash archive.
• package: Used only for a full flash installation; cannot be used with a differential flash archive.
• root_device
Here’s a sample profile for an installation client using a Flash Archive:
The rules and sysidcfg files for the Flash installation client would be the same as described earlier in this chapter.
When finished configuring the profile, rules, and sysidcfg files, and assuming the Flash Archive is available on the install server in a shared file system, you can boot the installation client using this:
ok boot net - install<cr>
The automated installation proceeds without further intervention, and the system will be installed using the Flash Archive.
Preboot Execution Environment (PXE)
The Preboot Execution Environment (PXE) is a direct form of network boot that can be used to install the Solaris Operating Environment over the network using DHCP. It does not require the client to have any form of local boot media. With PXE, x86/x64-based clients can boot consistently and in an interoperable manner, regardless of the sources or vendors of the software and the hardware of both client and server machines. This is accomplished via a uniform and consistent set of preboot protocol services within the client. They ensure that network-based booting is accomplished through industry-standard protocols used to communicate with the server. In addition, to ensure interoperability, the downloaded Network Bootstrap Program (NBP) is presented with a uniform and consistent preboot operating environment within the booting client, so it can accomplish its task independent of the type of network adapter implemented in the system.
PXE is available only to x86/x64-based systems that implement the Intel Preboot Execution Environment specification. Depending on your system, PXE may be implemented in the system’s BIOS or might be configurable via the network adapter’s configuration utility. You need to consult the hardware documentation for your system to determine whether it supports the PXE network boot.
To use PXE, you need three systems:
• A configured install server containing the Solaris boot image and images of the Solaris CDs
• A configured DHCP server from which to boot successfully
• An x86 client that supports the PXE network boot
NOTE
Only one DHCP server You must make sure that only one DHCP server is on the same subnet as the PXE client, because the PXE network boot does not work properly on a subnet containing multiple DHCP servers.
Preparing for a PXE Boot Client
As you saw in the previous section, three systems are required in order to be able to make use of the PXE network boot. The first of these is the install server. Setting up the install server was described earlier in this chapter, in the section “The Install Server.” The procedure for an x86 install server is the same, but you store x86 CD images instead of SPARC.
NOTE
You can still use SPARC Even though you are setting up an x86 installation, you can still use a SPARC system as your install server if you want to. All it does is share the CD images over the network, and a single install server can serve both SPARC and x86 clients. Remember that you cannot run setup install server on a SPARC system using an x86 CD, or vice versa, but you can from a DVD.
The third system is also very straightforward, because you have to consult your hardware documentation to verify whether PXE network boot is supported by the BIOS. It is worth investigating whether an upgrade to the BIOS firmware is necessary as well.
It is the second of these systems that requires the most work. Configuring a DHCP server is beyond the scope of this exam and is covered completely in the Solaris 10 Network Administrator Exam (Exam 310-302). It is necessary, however, to create some vendor class macros so that the correct configuration information is passed to the client when booting across the network.
NOTE
DHCP already configured You should note that a working DHCP server should already be configured. The details described in this section merely configure some parameters within the DHCP server.
Configuring the DHCP Server
A few parameters need to be configured to ensure that the client, when booted, has all the information it requires in order to boot successfully and then access the install server containing the correct CD images, required for the installation of the Solaris Operating Environment. Table 7.26 lists some of the most common parameters.
Table 7.26 Vendor Client Class Options
The fields are described here:
• Symbol Name: The name of the symbol.
• Code: A unique code number.
• Type: The data type of the entry.
• Granularity: The number of instances. For example, a symbol with a data type of IP Address and a Granularity of 2 means that the entry must contain two IP addresses.
• Max: The maximum number of values. For example, a symbol with a data type of IP Address, a Granularity of 2, and a Max of 2 means that the symbol can contain a maximum of two pairs of IP addresses.
• Description: A textual description of the symbol.
You can add these symbols to the DHCP server by using the dhtadm command:
dhtadm -A -s <macro> -d <definition>
or by using the GUI-based dhcpmgr command. The following example shows how to add a symbol (SrootIP4) and Vendor Client Class (SUNW.i86pc) to the achilles macro using the GUI-based dhcpmgr:
1. Start dhcpmgr by entering /usr/sadm/admin/bin/dhcpmgr & from any CDE window. The DHCP manager window appears, as shown in Figure 7.6.
FIGURE 7.6 DHCP Manager window.
Note that the DHCP server is already configured to support 10 IP addresses and that the DHCP server name is achilles.
2. Select the Options tab; the Options window appears. Select Edit, Create, as shown in Figure 7.7.
FIGURE 7.7 DHCP Options window.
3. A subwindow appears to create the option. Enter the name SrootIP4 in the Name field. The next field is a pull-down menu; select Vendor from this menu, as shown in Figure 7.8.
FIGURE 7.8 DHCP Create Options window.
4. Refer to Table 7.26, which lists the valid values for the symbols to be added. In this case, the code value for the symbol SrootIP4 is 2. The type is currently set to IP Address, which is correct. Table 7.26 also states the values for Granularity and Maximum; enter these accordingly into their correct locations.
5. On the right side of the window is the Vendor Client Classes box. This is where you specify which class of systems the option applies to. For example, if an x86 client is being used, the client class is SUNW.i86pc. Enter this in the box provided and click Add. The class now appears in the list, as shown in Figure 7.9.
FIGURE 7.9 DHCP completed Create Options window.
6. Make sure the box titled Notify DHCP server of change is checked, and click OK to complete the operation.
7. You are returned to the Options window, which now includes the symbol just created, as shown in Figure 7.10.
FIGURE 7.10 DHCP Options window with a symbol defined.
8. The remaining symbols can be added by repeating the previous steps.
9. To add the symbol SrootIP4 to the achilles macro, select the Macro tab and the achilles macro from the list on the left. Figure 7.11 shows the current contents of this macro.
FIGURE 7.11 The achilles macro.
10. Select Edit, Properties. Figure 7.12 shows the Properties window.
FIGURE 7.12 The Properties window.
11. You need to locate the symbol that you want to add, so click Select to the right of the Option Name field. The Select Option window appears, as shown in Figure 7.13.
FIGURE 7.13 The Select Option (Standard) window.
12. The symbol just created is a Vendor class symbol, and the options being displayed are standard symbols. The selector field is a pull-down menu, so click the menu and choose Vendor. The symbol SrootIP4 appears, as shown in Figure 7.14.
FIGURE 7.14 The Select Option (Vendor) window.
13. Click the symbol SrootIP4, and then click OK to display the Macro Properties window. This symbol identifies the IP Address of the JumpStart root server, which is 192.168.0.110 for this example. Enter this in the Option Value field, as shown in Figure 7.15.
FIGURE 7.15 The Macro Properties window.
14. Click Add to insert the symbol and value into the macro properties. Figure 7.16 shows that the symbol SrootIP4 has been added to the macro.
FIGURE 7.16 The Macro Properties window with symbol added.
15. When you click OK to complete the operation, you are returned to the macro window, showing the contents of the achilles macro. Figure 7.17 shows the completed operation.
FIGURE 7.17 The achilles macro with symbol added.
16. Repeat this operation for the other symbols that the DHCP server requires to properly support the PXE network boot.
When the macro and symbols have been configured, the DHCP server is ready to handle the client correctly when it boots across the network.
Adding an x86 Client to Use DHCP
Having configured the DHCP server, the next task is to add the client to the install server. This is carried out using the add_install_client command, virtually the same as for a custom JumpStart, but this time the majority of the configuration information is supplied by the DHCP server. The following command adds support for the SUNW.i86pc class of system:
# cd /export/install/x86pc/Tools<cr>
# ./add_install_client -d SUNW.i86pc i86pc<cr>
This add_install_client example configures DHCP to PXE boot a class of machines. The next example configures DHCP to PXE boot one specific machine based on its MAC address of 00:21:9b:33:c0:d7:
# . /add_install_client -d -e 00:21:9b:33:c0:d7<cr>
Booting the x86 Client
When the install server and the DHCP server have been configured correctly and the x86 client has been added, the only remaining thing to do is to boot the x86 client to install over the network. The way in which this is done depends on the hardware that you have, but usually one of the following will have the desired effect:
• Enter the system BIOS using the appropriate keystrokes.
• Configure the BIOS to boot from the network.
• Adjust the boot device priority list, if present, so that a network boot is attempted first.
• Exit the system BIOS.
The system should start booting from the network and should prompt you for the type of installation you want to run. The remainder of the installation process depends on which installation type you choose.
NOTE
Set back boot options Remember when the installation finishes and the system reboots to re-enter the system BIOS and restore the original boot configuration.
Summary
It’s been my experience that JumpStart is not widely used, mainly because of its complexity. Many system administrators would rather go through an interactive installation for each system than automate the process. Many of the popular UNIX systems have installation programs similar to JumpStart, and most are underutilized. System administrators could save a great deal of time if they would only learn more about this type of installation.
The key to using JumpStart is whether it will benefit you to spend the time learning and understanding what is required; and then creating the necessary class files, an install server, and a configuration server; and editing a rules file to ensure that all systems are accommodated. For system administrators managing large numbers of systems—say, more than 100—it is probably worth the effort, especially if the JumpStart installation is to be used more than once. A good example of this is in a test environment, where systems might have to be regularly rein-stalled to a particular specification. On the other hand, if the system administrator manages only three or four systems, and they need to be installed only once, it is questionable as to whether the time is worth investing. It might be more efficient to carry out interactive installations.
I described the entire process of installing a networked system via JumpStart, including how to set up the boot server, the install server, and the configuration files located on the configuration server. I also described the necessary procedures that need to be performed for each client that you plan to install.
You also learned how to use the Solaris Flash Archive feature to create an exact image of a particular Solaris environment and replicate this environment across many systems, or simply store it away in case you need to rebuild the system as a result of a system failure. You also learned how to create a differential Flash Archive by comparing a new root (/) image to an existing Flash Archive. You learned how the Flash Archive can be used in a JumpStart session for a completely automated installation.
Finally, you learned about a new facility, the Preboot Execution Environment (PXE), which facilitates the installing of x86 clients across the network using a DHCP server to provide the boot configuration information. You also learned how to configure a DHCP server to add the required symbols to properly support a booting x86 client.
Key Terms
• Boot server
• Class file
• Clone system
• Custom JumpStart
• DHCP server
• Differential archive
• Flash Archive
• Flash installation
• Install server
• JumpStart client
• JumpStart directory
• JumpStart server
• MTFTP
• NBP
• Preboot Execution Environment (PXE)
• Profile
• RARP
• Rules file
• Solaris Flash
• TFTP
Apply Your Knowledge
Exercise
8.1 Creating JumpStart Servers
In this exercise, you’ll create a JumpStart boot server, install server, configuration server, configuration files, and configure a JumpStart client to automatically install the Solaris 10 operating environment across the network.
For this exercise, you’ll need two systems connected on a network. One system will serve as the boot/install/configuration server, so it needs about 5GB of free disk space. The second system will be the client and will have the entire disk destroyed and the operating system reloaded.
CAUTION
Destructive process This procedure destroys data on the disk. Be sure you have proper backups if you want to save any data on these systems.
Estimated time: 1 hour
1. On the system that will be used as the boot and install server, log in as root.
2. Edit the /etc/hosts file, and make an entry for the JumpStart client.
3. Create the boot server:
a. Insert the Solaris DVD (or CD labeled Solaris 10 CD 1), and let vold automatically mount the DVD/CD.
b. Change to the Tools directory on the CD:
# cd /cdrom/cdrom0/s0/Solaris_10/Tools<cr>
c. Run the setup_install_server script, and specify the location for the Solaris image. Be sure you have about 5GB of free space and that the target directory is empty. In the following example, I use /export/install as the install directory:
# ./setup_install_server /export/install<cr>
4. Add the additional software:
a. Eject the Solaris 10 CD 1, and put in the Solaris 10 CD 2. Let vold automatically mount the CD.
b. Change to the Tools directory on the CD:
# cd /cdrom/cdrom0/Solaris_10/Tools<cr>
c. Execute the add_to_install_server script as follows to copy the images from the CD to the /export/install directory:
# ./add_to_install_server /export/install<cr>
d. Repeat the procedure with the remaining CDs.
5. Create the JumpStart configuration directory:
# mkdir /export/jumpstart<cr>
6. Add the following entry in the /etc/dfs/dfstab file for this directory to share it across the network:
share -F nfs -o ro,anon=0 /export/jumpstart<cr>
7. Start the NFS server as follows if the nfsd daemon is not already running:
# svcadm enable nfs/server<cr>
8. In the /export/jumpstart directory, use the vi editor to create a class file named basic_class with the following entries:
#Specifies that the installation will be treated as an initial
#installation, as opposed to an upgrade.
install_type initial_install
#Specifies that the engineering systems are standalone
#systems.
system_type standalone
#Specifies that the JumpStart software uses default disk
#partitioning for installing Solaris software on the
#engineering systems.
partitioning default
#Specifies that the developer’s software group will be installed
cluster SUNWCprog
#Specifies that each system in the engineering group will have
#2048 Mbytes of swap space.
filesys any 2048 swap
9. In the /export/jumpstart directory, use the vi editor to create a rules file named rules with the following entry:
hostname sun1 - basic_class -
10. Validate the class and rules files with the check and pfinstall commands:
# cd /export/jumpstart<cr>
# /export/install/Solaris_10/Misc/export/jumpstart_sample/check<cr>
# /usr/sbin/install.d/pfinstall -D -c /export/install basic_class<cr>
11. Set up the JumpStart client:
# cd /export/install/Solaris_10/Tools<cr>
# ./add_install_client -s <SERVERNAME>:/export/install
-c <SERVERNAME>:/export/jumpstart -p <SERVERNAME>:/export/jumpstart
-e <MAC ADDRESS> <CLIENTNAME> <PLATFORM><cr>
where SERVERNAME is the hostname of your boot/install server, MAC ADDRESS is your client’s Ethernet address, CLIENTNAME is your client’s hostname, and PLATFORM is your client’s architecture (such as sun4u).
For example:
# ./add_install_client -s sparcserver:/export/install
-c sparcserver:/export/jumpstart -p sparcserver:/export/jumpstart
-e 8:0:20:21:49:24 sun1 sun4u<cr>
12. Go to the client and turn on the power. At the boot PROM, issue the following command:
ok boot net - install<cr>
The JumpStart installation executes.
Exam Questions
1. Which of the following is a method to automatically install Solaris on a new SPARC system by inserting the Solaris Operating System DVD in the drive and powering on the system?
• A. JumpStart
• B. WAN boot installation
• C. Interactive installation
• D. Custom JumpStart
2. Which of the following is a method to automatically install groups of identical systems?
• A. Custom JumpStart
• B. JumpStart
• C. Network Installation
• D. Interactive installation
3. Which of the following sets up an install server to provide the operating system to the client during a JumpStart installation?
• A. add_install_client
• B. add_install_server
• C. pfinstall
• D. setup_install_server
4. For a JumpStart installation, which of the following files should contain a rule for each group of systems that you want to install?
• A. sysidcfg
• B. rules.ok
• C. profile
• D. check
5. For a JumpStart installation, which of the following servers is set up to answer RARP requests from clients?
• A. Boot server
• B. Install server
• C. Configuration server
• D. JumpStart server
6. Which of the following is used as an alternative to setting up a configuration directory?
• A. Boot server
• B. Install server
• C. Configuration diskette
• D. rules.ok file
7. For a JumpStart installation, which of the following files contains the name of a finish script?
• A. check
• B. profile
• C. rules.ok
• D. profile diskette
8. Which of the following is a user-defined Bourne shell script, specified within the rules file?
• A. add_install_client script
• B. class file
• C. check script
• D. begin script
9. In JumpStart, which of the following files defines how to install the Solaris software on a system?
• A. class file
• B. rules
• C. rules.ok
• D. install.log
10. Which of the following is used to test a JumpStart class file?
• A. check
• B. pfinstall
• C. rules
• D. add_install_client
11. When working with JumpStart, which of the following files is not used to provide information about clients?
• A. rules
• B. sysidcfg
• C. check
• D. class
12. Which of the following is not a valid entry in the first field in the rules file?
• A. karch
• B. any
• C. hostname
• D. ip_address
13. Which of the following files is the JumpStart file that can use any name and still work properly?
• A. class
• B. rules
• C. sysidcfg
• D. pfinstall
14. Which of the following scripts updates or creates the rules.ok file?
• A. pfinstall
• B. check
• C. setup_install_server
• D. install_type
15. Which of the following supplies the operating system during a JumpStart installation?
• A. Setup server
• B. Install server
• C. Profile server
• D. /jumpstart directory
16. Which of the following contains the JumpStart directory and configuration files such as the class file and the rules file?
• A. Profile diskette
• B. Setup server
• C. Install server
• D. Configuration server
17. Which of the following commands is issued on the install server to set up remote workstations to install Solaris from the install server?
• A. add_install_client
• B. add_install_server
• C. setup_install_client
• D. setup_client
18. Which of the following commands sets up a system as a boot server only?
• A. setup_install_server
• B. add_install_server -b
• C. setup_install_server -b
• D. setup_boot_server
19. Which of the following commands is used on a JumpStart client to start the installation?
• A. boot net - install
• B. boot net
• C. boot - jumpstart
• D. boot net - jumpstart
20. Which script copies additional packages within a product tree to the local disk on an existing install server?
• A. add_install_server -a
• B. add_to_install_server
• C. setup_install_server
• D. _server -a
21. Which of the following class file keywords is valid only for a Solaris Flash Install using JumpStart?
• A. archive_location
• B. install_type
• C. locale
• D. system_type
22. Which of the following are required to be able to boot an x86 client using the PXE network boot and install method? (Choose three.)
• A. A system with more than 1 GB of physical memory
• B. An x86 client with a system BIOS that supports the Intel Preboot Execution Environment specification
• C. A configured DHCP server
• D. A server running either NIS or NIS+ naming service
• E. An install server
23. Which of the following symbols would you configure in a DHCP server to correctly specify the Hostname of the JumpStart Install server so that a PXE network client would be passed the correct configuration information at boot time?
• A. SinstIP4
• B. SinstNM
• C. SrootNM
• D . SrootIP4
24. Which option is used to create a differential Flash Archive?
• A. -D
• B. -A
• C. -C
• D. -M
Answers to Exam Questions
1. A . JumpStart lets you automatically install the Solaris software on a SPARC-based system just by inserting the Solaris CD and powering on the system. You do not need to specify the boot command at the ok prompt. For more information, see the section “JumpStart.”
2. A. The custom JumpStart method of installing the operating system provides a way to install groups of similar systems automatically and identically. For more information, see the section “JumpStart.”
3. D. The setup_install_server script sets up an install server to provide the operating system to the client during a JumpStart installation. For more information, see the section “The Install Server.”
4. B. The rules.ok file is a file that should contain a rule for each group of systems you want to install. For more information, see the section “The Rules File.”
5. A. The boot server is set up to answer RARP requests from a JumpStart client. For more information, see the section “Setting Up the Boot Server.”
6. C. A configuration disk is used as an alternate to setting up a configuration directory. For more information, see the section “Setting Up a Configuration Diskette.”
7. C. The rules.ok file contains the name of a finish script. For more information, see the section “The Rules File.”
8. D. A begin script is a user-defined Bourne shell script, located in the JumpStart configuration directory on the configuration server, specified within the rules file, that performs tasks before the Solaris software is installed on the system. For more information, see the section “begin and finish Scripts.”
9. A. A class file is a text file that defines how to install the Solaris software on a system. For more information, see the section “Creating Class Files.”
10. B. After you create a class file, you can use the pfinstall command to test it. For more information, see the section “Testing Class Files.”
11. C. The sysidcfg, rules, and class files all provide information about the JumpStart client. The check script is used to validate the rules file. For more information, see the section “JumpStart.”
12. D. any, hostname, and karch are all valid keywords that can be used in the rules file. For more information, see the section “The Rules File.”
13. A. The class file can be named anything, but it should reflect the way in which it installs the Solaris software on a system. For more information, see the section “Creating Class Files.”
14. B. The check script updates or creates the rules.ok file. For more information, see the section “Validating the Rules File.”
15. B. The install server supplies the operating system during a JumpStart installation. For more information, see the section “The Install Server.”
16. D. The configuration server contains all the essential custom JumpStart configuration files, such as the rules file, the rules.ok file, the class file, the check script, and the optional begin and finish scripts. For more information, see the section “Configuration Server.”
17. A. Use the add_install_client command on the install server to set up remote workstations to install Solaris from the install server. For more information, see the section “Setting Up Clients.”
18. C. setup_install_server -b sets up a system as a boot server only. For more information, see the section “Setting Up the Boot Server.”
19. A. boot net - install is used on a JumpStart client to start the installation. For more information, see the section “Starting Up the Clients.”
20. B. The add_to_install_server script copies additional packages within a product tree to the local disk on an existing install server. For more information, see the section “The Install Server.”
21. A. The archive_location option is a valid class file keyword that is used only when installing a Flash Archive using JumpStart. For more information, see the section “Creating Class Files.”
22. B, C, E. The requirements for a PXE network boot are an install server, a configure DHCP server, and an x86 client that supports the Intel Preboot Execution Environment specification. For more information, see the section “Preboot Execution Environment.”
23. B. The DHCP symbol SinstNM specifies the hostname of the JumpStart Install server. For more information, see the section “Configuring the DHCP Server .”
24. B. The -A option is used to create a differential Flash Archive by comparing a new system image to the original Flash Archive image. For more information, see the section “Creating a Flash Archive.”
Suggested Reading and Resources
Solaris 10 Documentation CD. “Solaris 10 Installation Guide: Custom JumpStart and Advanced Installations” manual.
http://docs.sun.com. Solaris 10 documentation set. “Solaris 10 Installation Guide: Custom JumpStart and Advanced Installations” book in the Solaris 10 Release and Installation collection.
Solaris 10 Documentation CD. “Solaris 10 Installation Guide: Solaris Flash Archives (Creation and Installation)” manual.
http://docs.sun.com. Solaris 10 documentation set. “Solaris 10 Installation Guide: Solaris Flash Archives (Creation and Installation)” book in the Solaris 10 Release and Installation collection.
Solaris 10 Documentation CD. “Solaris 10 Installation Guide: Network Based Installations” manual.
http://docs.sun.com. Solaris 10 documentation set. “Solaris 10 Installation Guide: Network Based Installations” book in the Solaris 10 Release and Installation collection.