SA Provisioning basics

SA provisioning has three essential parts:

• Build Plan framework
• The Service OS
• Bring a server into Maintenance when working in third-party certificate mode
• Out-of-the-box content

Build Plan framework

A Build Plan consists primarily of a list of steps that can be executed against a target server (the server to be provisioned). These steps specify the various tasks that ultimately provision a server. The framework includes an execution engine that runs the steps sequentially. This makes understanding Build Plans and their actions easy and intuitive.

Build Plans are SA objects, and as such, they can be viewed and manipulated in the SA Client Library. A number of baseline Build Plans are included when an SA Core is installed. These Build Plans can, by default, perform many common provisioning tasks.

Multiple Build Plan steps types are supported such as running a script, deploying a zip package or deploying a configuration file with parameter substitution. Other step types integrate with various SA features and provide the ability to attach software policies, start remediation, join a device group and more.

The Service OS

SA ships with several minimal RAM-based operating systems that can be started over a network, from physical or from virtual media (CD, DVD or ISO images), on a physical server or virtual machine. These are called Service OSes. Because of the limited functionality within a service OS, only a subset of SA operations can be run against a server that has been booted into a service OS. The primary purpose of a service OS is to enable installation of a full operating system, also known as a Production OS as well as other maintenance tasks that cannot be performed from a production OS.

The service OS is the means by which the Build Plan framework gathers information and executes tasks on a target server. These service OSes make use of a special instance of the SA Agent configured to run in this limited environment.

Starting a server in the service OS is also known as bringing the server into Maintenance mode. Servers in Maintenance mode are recognizable by the icon that is displayed in the SA Client and by their Maintenance status.

Minimum requirements to run a service OS is an x86 CPU (recommended x86-64) and 2 GB of RAM.

Maintenance Mode Icon

Service OSes can be booted on any server, whether or not it has an installed OS. A server can safely be booted from a production OS into Maintenance mode and back.

Bring a server into Maintenance when working in third-party certificate mode

When the SA Core is set to third-party certificate mode, SA does not allow the Agent used by the service OS to register with the SA Core automatically. For security reasons, SA requires you to manually approve their registration request from the SA Client. For information on SA Certificate modes, see Cryptographic material options.
Phase 1: Use the SA Bootstrap certificate to register the server to Core

1. Boot the server into service OS.

2. Check that the SA Client has discovered the device under Devices > Servers > Unprovisioned servers. All registration requests show up in the server's Lifecycle column as Pending.

3. Right-click on the server and either:

• click Approve to accept the registration request and provide the SA Agent certificate.
• click Reject to deny the server's request. This removes the server from SA and cancels the process of bringing the server into Maintenance mode.

To skip this approval step and allow all service OS Agents to register with the bootstrap certificate, go to SA  Client > Administration > Data Access Engine (spin) > System Configuration and change the value of the spin.agent.bootstrap_enabled parameter to 1.

For more information see OS Provisioning approval.

Phase 2: Update your SA Agent certificate to use third-party certificate mode

After installing the SA Agent with the SA self-signed bootstrap certificate, generate a CSR for your CA and import the third-party certificate using SA Agent scripts. This enables you to switch from SA Agent bootstrap certification to third-party certificate mode.

1. Log into the managed server using a remote shell. On UNIX, log in as root. On Windows, log in as administrator.
2. Remove any existing *.csr or .*crt files from your temporary PKI directory:
• Linux: /var/tmp/pki
• Windows: C:\Windows\Temp\PKI

3. Launch the following script to generate the Agent's CSR (agent.csr file) and the certificate's private key (agent.key file):

   • Linux script: /opt/opsware/agent/pylibs/cog/generate_csr
   • Windows script: C:\Program Files\Opsware\agent\pylibs\cog\generate_csr.bat
   Optionally, you can add the --crypto_dir <your crypto folder>  parameter to generate the CSR  in a custom crypto folder. Otherwise, the script creates the CSR in the temporary PKI folder.
4. Collect the CSR file from your custom crypto folder created in step 3 or from the default PKI folder:
5. Submit the CSR to your CA and import the resulting third-party certificate using the following script:/opt/opsware/agent/pylibs/cog/import_cert.
   This generates a .pkcs12 password-protected file under:
   • Linux: /var/opt/opsware/crypto/agent/agent.p12
   • Windows: C:\Program Files\Common Files\Opsware\crypto\agent\agent.p12
6. Restart the SA Agent to finalize updating the SA Agent certificate to third-party certificate mode.

Out-of-the-box content

The out-of-the-box content is a collection of Build Plans populated with Build Plan steps that deliver functionality for common use-cases and are the basic building blocks for user-created Build Plans. This includes provisioning of operating systems, network configuration and end-to-end provisioning of HPE ProLiant servers (including firmware and hardware configuration management). Using this functionality is as simple as running the Build Plans.

The out-of-the-box content is installed as part of SA Core installation or upgrade.

Installation-specific parameters can be customized either by editing the command-line arguments of script steps in the Build Plans or by specifying Custom Attributes. These are a generic parameter passing mechanism in SA. The custom attributes that influence the behavior of an out of the box Build Plan are set with blank values on the Build Plan object.

Custom attributes can be specified using a Build Plan or can be specified at the server, device group or facility level.

SA Provisioning uses a Media Server to serve large objects like OS installation media, system images (for example, Windows WIM images) and collections of drivers and firmware to the server being provisioned. Multiple transfer protocols are supported: HTTP, HTTPS, NFS and SMB (Windows shares). See the SA Provisioning Matrix to determine which protocols are supported with the operating system(s) you want to provision. SA includes a media server that can serve media through SMB and NFS. The Media Server is installed when you choose to install the SA Provisioning Components.