This chapter provides an overview of the WAN boot installation method. This chapter describes the following topics.
The WAN boot installation method enables you to boot and install software over a wide area network (WAN) by using HTTP. By using WAN boot, you can install the Solaris OS on SPARC based systems over a large public network where the network infrastructure might be untrustworthy. You can use WAN boot with security features to protect data confidentiality and installation image integrity.
The WAN boot installation method enables you to transmit an encrypted Solaris Flash archive over a public network to a remote SPARC based client. The WAN boot programs then install the client system by performing a custom JumpStart installation. To protect the integrity of the installation, you can use private keys to authenticate and encrypt data. You can also transmit your installation data and files over a secure HTTP connection by configuring your systems to use digital certificates.
To perform a WAN boot installation, you install a SPARC based system by downloading the following information from a web server over a HTTP or secure HTTP connection.
wanboot program – The wanboot program is the second level boot program that loads the WAN boot miniroot, client configuration files, and installation files. The wanboot program performs tasks similar to those that are performed by the ufsboot or inetboot second level boot programs.
WAN boot file system – WAN boot uses several different files to configure the client and retrieve data to install the client system. These files are located in the /etc/netboot directory of the web server. The wanboot-cgi program transmits these files to the client as a file system, called the WAN boot file system.
WAN boot miniroot – The WAN boot miniroot is a version of the Solaris miniroot that has been modified to perform a WAN boot installation. The WAN boot miniroot, like the Solaris miniroot, contains a kernel and just enough software to install the Solaris environment. The WAN boot miniroot contains a subset of the software in the Solaris miniroot.
Custom JumpStart configuration files – To install the system, WAN boot transmits sysidcfg, rules.ok, and profile files to the client. WAN boot then uses these files to perform a custom JumpStart installation on the client system.
Solaris Flash archive – A Solaris Flash archive is a collection of files that you copy from a master system. You can then use this archive to install a client system. WAN boot uses the custom JumpStart installation method to install a Solaris Flash archive on the client system. After you install an archive on a client system, the system contains the exact configuration of the master system.
The flarcreate command no longer has size limitations on individual files. You can create a Solaris Flash archive that contains individual files over 4 Gbytes.
For more information, see Creating an Archive That Contains Large Files in Solaris 10 5/09 Installation Guide: Solaris Flash Archives (Creation and Installation).
You then install the archive on the client by using the custom JumpStart installation method.
You can protect the transfer of the previously listed information by using keys and digital certificates.
For a more detailed description of the sequence of events in a WAN boot installation, see How WAN Boot Works (Overview).
The WAN boot installation method enables you to install SPARC based systems that are located in geographically remote areas. You might want to use WAN boot to install remote servers or clients that are accessible only over a public network.
If you want to install systems that are located on your local area network (LAN), the WAN boot installation method might require more configuration and administration than necessary. For information about how to install systems over a LAN, see Chapter 4, Installing From the Network (Overview).
WAN boot uses a combination of servers, configuration files, Common Gateway Interface (CGI) programs, and installation files to install a remote SPARC based client. This section describes the general sequence of events in a WAN boot installation.
Figure 10–1 shows the basic sequence of events in a WAN boot installation. In this figure, a SPARC based client retrieves configuration data and installation files from a web server and an install server over a WAN.
You boot the client in one of the following ways.
Boot from the network by setting network interface variables in the Open Boot PROM (OBP).
Boot from the network with the DHCP option.
Boot from a local CD-ROM.
The client OBP obtains configuration information from one of the following sources.
From boot argument values that are typed at the command line by the user
From the DHCP server, if the network uses DHCP
The client OBP requests the WAN boot second level boot program (wanboot).
The client OBP downloads the wanboot program from the following sources.
From a special web server, called the WAN boot server, by using the Hyper Text Transfer Protocol (HTTP)
From a local CD-ROM (not shown in the figure)
The wanboot program requests the client configuration information from the WAN boot server.
The wanboot program downloads configuration files that are transmitted by the wanboot-cgi program from the WAN boot server. The configuration files are transmitted to the client as the WAN boot file system.
The wanboot program requests the download of the WAN boot miniroot from the WAN boot server.
The wanboot program downloads the WAN boot miniroot from the WAN boot server by using HTTP or secure HTTP.
The wanboot program loads and executes the UNIX kernel from the WAN boot miniroot.
The UNIX kernel locates and mounts the WAN boot file system for use by the Solaris installation program.
The installation program requests the download of a Solaris Flash archive and custom JumpStart files from an install server.
The installation program downloads the archive and custom JumpStart files over an HTTP or HTTPS connection.
The installation program performs a custom JumpStart installation to install the Solaris Flash archive on the client.
The WAN boot installation method enables you to use hashing keys, encryption keys, and digital certificates to protect your system data during the installation. This section briefly describes the different data protection methods that are supported by the WAN boot installation method.
To protect the data you transmit from the WAN boot server to the client, you can generate a Hashed Message Authentication Code (HMAC) key. You install this hashing key on both the WAN boot server and the client. The WAN boot server uses this key to sign the data to be transmitted to the client. The client then uses this key to verify the integrity of the data that is transmitted by the WAN boot server. After you install a hashing key on a client, the client uses this key for future WAN boot installations.
For instructions about how to use a hashing key, see (Optional) To Create a Hashing Key and an Encryption Key.
The WAN boot installation method enables you to encrypt the data you transmit from the WAN boot server to the client. You can use WAN boot utilities to create a Triple Data Encryption Standard (3DES) or Advanced Encryption Standard (AES) encryption key. You can then provide this key to both the WAN boot server and the client. WAN boot uses this encryption key to encrypt the data sent from the WAN boot server to the client. The client can then use this key to decrypt the encrypted configuration files and security files that are transmitted during the installation.
Once you install an encryption key on a client, the client uses this key for future WAN boot installations.
Your site might not permit the use of encryption keys. To determine if your site permits encryption, ask your site's security administrator. If your site permits encryption, ask your security administrator which type of encryption key, either 3DES or AES, you should use.
For instructions on how to use encryption keys, see (Optional) To Create a Hashing Key and an Encryption Key.
WAN boot supports the use of HTTP over Secure Sockets Layer (HTTPS) to transfer data between the WAN boot server and the client. By using HTTPS, you can require the server, or both the server and the client, to authenticate themselves during the installation. HTTPS also encrypts the data that is transferred from the server to the client during the installation.
HTTPS uses digital certificates to authenticate systems that exchange data over the network. A digital certificate is a file that identifies a system, either a server or client, as a system to trust during online communication. You can request a digital certificate from an external certificate authority, or create your own certificate and certificate authority.
To enable the client to trust the server and accept data from the server, you must install a digital certificate on the server. You then instruct the client to trust this certificate. You can also require the client to authenticate itself to the servers by providing a digital certificate to the client. You can then instruct the server to accept the certificate's signer when the client presents the certificate during the installation.
To use digital certificates during the installation, you must configure your web server to use HTTPS. See your web server documentation for information about how to use HTTPS.
For information about the requirements to use digital certificates during your WAN boot installation, see Digital Certificate Requirements. For instructions about how to use digital certificates in your WAN boot installation, see (Optional) To Use Digital Certificates for Server and Client Authentication.
WAN boot supports varying levels of security. You can use a combination of the security features that are supported in WAN boot to meet the needs of your network. A more secure configuration requires more administration, but also protects your system data to a greater extent. For more critical systems, or those systems you want to install over a public network, you might choose the configuration in Secure WAN Boot Installation Configuration. For less critical systems, or systems on semi-private networks, consider the configuration that is described in Insecure WAN Boot Installation Configuration.
This section briefly describes the different configurations you can use to set the level of security for your WAN boot installation. The section also describes the security mechanisms that are required by these configurations.
This configuration protects the integrity of the data exchanged between the server and client, and helps keep the contents of the exchange confidential. This configuration uses an HTTPS connection, and uses either the 3DES or AES algorithm to encrypt the client configuration files. This configuration also requires the server to authenticate itself to the client during the installation. A secure WAN boot installation requires the following security features.
HTTPS enabled on the WAN boot server and the install server
HMAC SHA1 hashing key on the WAN boot server and the client
3DES or AES encryption key for the WAN boot server and the client
Digital certificate of a certificate authority for the WAN boot server
If you want to also require client authentication during the installation, you must also use the following security features.
Private key for the WAN boot server
Digital certificate for the client
For a list of the tasks that are required to install with this configuration, see Table 12–1.
This security configuration requires the least administration effort, but provides the least secure transfer of data from the web server to the client. You do not need to create a hashing key, encryption key, or digital certificates. You do not need to configure your web server to use HTTPS. However, this configuration transfers the installation data and files over an HTTP connection, which leaves your installation vulnerable to interception over the network.
If you want the client to check the integrity of the data that is transmitted, you can use a HMAC SHA1 hashing key with this configuration. However, the Solaris Flash archive is not protected by the hashing key. The archive is transferred insecurely between the server and the client during the installation.
For a list of the tasks that are required to install with this configuration, see Table 12–2.