How WAN Boot Works (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.

Sequence of Events in a WAN Boot Installation

Figure 9-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.

Figure 9-1 Sequence of Events in a WAN Boot Installation

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.

Protecting Data During a WAN Boot Installation

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.

Checking the Integrity of Data With a Hashing Key

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.

Encrypting Data With Encryption Keys

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.

Protecting Data by Using HTTPS

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.