by Isaac Rozenfeld
Published October 2012
The Automated Installer is part of the new software deployment architecture introduced in Oracle Solaris 11. It simplifies installation, provides greater provisioning flexibility, and automatically ensures package dependencies. For more information about the features and benefits of this software deployment architecture, see Simplified Installation and Cloud Provisioning with Oracle Solaris 11.
Note: This article applies to Oracle Solaris 11.1. A previous article, "How to Set Up Automated Installation Services for Oracle Solaris 11," describes how to perform similar tasks on Oracle Solaris 11.
This article illustrates how to create an initial system to host installation services (known as an Automated Installer server), how to create and configure installation services, and how to provision client systems using installation services. It focuses on the basics of automated installation capabilities in Oracle Solaris 11.1 with the goal of giving you a general understanding upon which to build.
Using the AI, you can create and manage services to install the Oracle Solaris 11.1 operating system over the network in a hands-off manner.
Three significant steps are performed by various services during the installation process:
Each of the steps can be provided by various services residing on the same physical or virtual system, or the services can be on separate systems. In this article, the following services reside on the same system:
Note: In environments where DHCP is not permitted, there are alternative methods for getting the network identity to the system manually, for example, through the use of network configuration arguments at the OpenBoot PROM (OBP) prompt on SPARC systems. It is possible to accomplish the installation by replacing the DHCP server with a step that otherwise provides a network identity to the client system. If your software is spread over multiple IPS repositories, it is also possible to install a system with software that is spread across multiple IPS repositories.
In this article, we will set up two Oracle Solaris 11.1 systems:
Installation of the first system will be performed interactively, while the subsequent installation of the second system will be automated.
Figure 1. Client System Installed by the Automated Install Server
Our first system, as depicted on the left in Figure 1, will be used to install our installation environment, that is, the one where we run the Automated Installer, IPS, and DHCP services. The second system, shown on the right in Figure 1, will be created and installed for the purpose of demonstrating automated installation.
After following the procedures in this article, you will have two systems configured as shown in Figure 1. The client system will be provisioned with a chosen installation profile, including the selected software and the system configuration.
When you begin evaluating Oracle Solaris 11.1, you will probably start by installing a small number of systems interactively in order to familiarize yourself with new features and begin testing applications and administrative procedures on the operating system.
Oracle Solaris 11.1 offers two interactive installation options to choose from:
Note: After the initial installation, you can add additional software components from network package repositories by using the Package Manager GUI or the
In this article, we'll use a text-based installer to install the server system. The text-based installer already contains the Automated Installer package, so no additional steps for downloading and installing the Automated Installer package are necessary.
Perform the following prerequisite steps:
In the remainder of this article, we will perform the following tasks:
Note: This article concentrates on a subset of the tasks required to get the installation services up and running quickly. For a full discussion on all the steps involved in creating an Oracle Solaris Automated Install server and how you can configure all the attributes, see Part III, "Installing Using an Install Server," in Installing Oracle Solaris 11 Systems in the Oracle Solaris documentation library.
Now that we understand what we are trying to do, in this section we will go through the steps shown in Figure 2, including command-line examples, to achieve our goal. While performing the procedures, refer to Figure 2 for a reminder of the "big picture" we are after. The client depicted in the middle uses all of the services shown.
The IPS repository and the DHCP server could be, and in our case are, on the install server. This simplifies things and requires us to configure less infrastructure.
Figure 2. Automated Installation Services
We begin by installing the server using the text-based installation method.
During the installation process, you will answer basic questions pertaining to language preference, time zone, and disk partition information (we will opt to use the whole disk for our example). Then you will specify a root password, your name, a username, and a user password, and you will choose to use automatic network discovery.
Perform the following steps to start the installation process:
Note: If you want to simply boot into the default menu selection (the first entry), pressing Esc is not necessary.
Figure 3. Choosing Which OS Image to Boot
Figure 4. Choosing a Keyboard Layout
Figure 5. Choosing to Install Oracle Solaris
Figure 6. Welcome Screen
Figure 7. Selecting a Discovery Method for Disks
Figure 8. Selecting a Disk
Because no pre-provisioned system configuration files are available when we use the text-based installer, the System Configuration Tool starts up and prompts us for information.
Perform the following steps:
aiserveras the computer name and highlight Manually to manually configure the network. Then press F2 to continue.
Note: We do not select it in this example, but if you were to select Automatically, you would not have to enter any network information. The configuration would be done for you.
Figure 9. Choosing to Configure the Network Manually
Figure 10. Specifying Network Settings
Figure 11. Choosing Not to Configure DNS
Figure 12. Choosing Not to Set Up a Name Service
Figure 13. Choosing a Time Zone Region
Figure 14. Specifying the Date and Time
Figure 15. Completing the Configuration
Figure 16. Providing Registration Information
On the next screen, you'll see a progress bar indicating that the installation is proceeding. When the installation is complete, you will see the screen summarizing the activity, and you will be prompted to press F8 to reboot.
Figure 17. Booting from the Hard Disk
Before we proceed, verify the network has a static IP address, as shown in Listing 1. We will need to use this address later when we'll have a system that acts as a client. It is that system that will be trying to connect to the IPS repository, and we'll be setting up a local IPS repository in the next step.
root@aiserver:~# dladm show-link LINK CLASS MTU STATE OVER net0 phys 1500 up -- root@aiserver:~# ipadm show-addr ADDROBJ TYPE STATE ADDR lo0/v4 static ok 127.0.0.1/8 net0/v4 static ok 192.168.1.222/24 lo0/v6 static ok ::1/128 net0/v6 addrconf ok fe80::a00:27ff:fec0:3399/10
Listing 1. Verifying the Network Has a Static IP Address
ipadm are new commands available in Oracle Solaris 11 for managing network configuration.
By default, all Oracle Solaris 11 installations are configured to use a software package repository hosted at
pkg.oracle.com. Administrators often choose to copy this repository locally due to network restrictions in their data centers, or to improve the speed of client installs, or simply to give them better control over what software client systems have access to. In this article, we will construct a local IPS repository using the IPS repository image that you downloaded earlier.
IPSto host the repository.
Note the path under which the ISO is mounted, as shown in the
rsync command below. The
rsync command will take time to complete, because over 6 GB of data comprise the IPS repository image.
root@aiserver:~# zfs create rpool/IPS root@aiserver:~# zfs set mountpoint=/IPS rpool/IPS root@aiserver:~# mkdir /IPS/Solaris11.1 root@aiserver:~# rsync -a /media/SOL_11_1_REPO_24b_FULL/ /IPS/Solaris11.1/
root@aiserver:~# svccfg -s application/pkg/server setprop \ pkg/inst_root=/IPS/Solaris11.1/repo root@aiserver:~# svccfg -s application/pkg/server setprop pkg/readonly=true root@aiserver:~# svcadm refresh application/pkg/server root@aiserver:~# svcadm enable application/pkg/server
pkgcommand to point the IPS client's
solarispublisher to the same host (that is, itself, in our case).
root@aiserver:~# pkg set-publisher –G '*' -g http://192.168.1.222 solaris
Now that you have a system that has an IPS package repository, let's create an instance of the Automated Installer services.
To complete this task, since we already created the Oracle Solaris 11 repository image locally and set it as the publisher to the Automated Install server itself, we can create this install service from the
pkg://install-image/solaris-auto-install package, instead of us having to download the
.iso file separately. To do this, perform the following steps.
root@aiserver:~# installadm create-service -n s11x86service -i 192.168.1.210 -c 1
Note: If you wanted to create a SPARC service, you would add the
-a sparc argument to the previous command. Additionally, using the
-n switch is optional, because the Automated Installer is intelligent enough to figure out the architecture of the service being created and to give it a name (if none is specified).
This command will create a service named
s11x86service and serve up DHCP clients starting with 192.168.1.210. The
-c argument specifies that only one IP address should be allocated, and that's fine for our case, since we are interested in provisioning only one client system in this example.
Creating the installation service causes the following to occur:
default-i386) is created.
Note: In our example, we are working with the very first instance of a service, so we have to use the default service name when referencing modifications to the service later on. Keep this in mind, because there will always be a default installation service that is architecture-specific. When executing commands on services that were created first, the commands must reflect the name
default-i386 instead of
root@aiserver:~# installadm list
The next step is to boot the client system off the network and provision it using the Automated Install service that we just set up.
Figure 18. Network Boot
Then you will be prompted by a GRUB menu, with a timer, as shown in Figure 19. The default selection (the "Text Installer and command line" option) is highlighted.
The reason we need to do this is because we want to prevent a system from being automatically re-installed if it were to be booted from the network accidentally.
Figure 19. GRUB Menu
What follows is the continuation of a networked boot from the Automated Install server, as shown in Figure 20. The client downloads a mini-root (a small set of files in which to successfully run the installer), identifies the location of the Automated Install manifest on the network, retrieves that manifest, and then processes it to identify the address of the IPS repository from which to obtain the desired software payload.
Figure 20. Continuation of the Network Boot
As you watch the screen, you'll see that
pkg.oracle.com is the default address of the IPS repository. In our case, however, we previously created a local IPS repository, so our local IPS repository should be used to install the client system, as shown in Figure 21.
Figure 21. Local Repository Is Used Instead of the Default
Some of the valuable information on the screen includes the location of log files and the XML manifest being used for this installation.
The default IPS repository that is hard-configured in the default Automated Install manifest is hosted by Oracle and the XML code
<origin name=> points to
pkg.oracle.com. If your system is able to reach the internet, your screen will indicate a successful installation.
However, if your system is not be able to reach the internet, the DNS resolution being done in the mini-root will fail and the system will be unable to contact the default IPS repository located at
pkg.oracle.com, causing a failure message, as shown in Figure 22:
Figure 22. Failure Message
In reality, this is not a big deal because internal IPS repositories will be built for most enterprise installations (as we did above), and most install clients point to those instead of stepping out to the internet and getting packages from
pkg.oracle.com for every system that is installed. This brings us to the next section, which shows how to alter the default manifest to point to the internal IPS repository.
In order to modify the default manifest used by installation clients, we leverage the
installadm command. Since we already have a service called
s11x86service, what we need to do is reflected in the following three tasks:
Accomplish these tasks using the following procedure.
root@aiserver:~# installadm list -m Service Name Manifest Status ------------ -------- ------ default-i386 orig_default Default s11x86service orig_default Default
s11x86serviceand the default manifest associated with it. The
-mswitch reflects the name of the manifest associated with a service. Since we want to capture that output into a file, we redirect the output of the command as follows:
root@aiserver:~# installadm export -n s11x86service -m orig_default > /var/tmp/orig_default.xml
Since we want to modify the location of the IPS repository, we can edit the file and input our changes.
orig-default2.xml, and edit the copy.
Typically (but not in this case), when we begin working with many services concurrently, the command to do that would be as follows:
root@aiserver:~# installadm update-manifest -n s11x86service -m orig_default -f /var/tmp/orig_default2.xml
However, in our example, we are working with the very first instance of a service, so we have to use the default service name when referencing modifications to the service. Therefore, the only thing that would change in the command above is the name of the service would need to be
default-i386 instead of
So execute the following command instead:
root@aiserver:~# installadm update-manifest -n default-i386 -m orig_default -f /var/tmp/orig_default2.xml
Prior to rebooting, you might want to log in and explore the system, looking at log files, such as the installation log file (
/system/volatile/install_log) or the Automated Install manifest that was used to install the system (
If you plan to log in before rebooting the system, the default Automated Install image username is
root and the password is
When you are ready, reboot the client. As it boots, you'll see a process similar to what you've previously seen, but now it will not stop with a DNS error. Instead, it will proceed to contact the local IPS repository for packages that the manifest lists.
As the process begins to look like Figure 23, notice the address in the
Figure 23. Booting the Client Using the Customized Manifest
There are many more additional types of customizations that can be done to the Automated Install manifest. The guiding principle in instituting these changes is to follow the process outlined in the "Customizing the Default Manifest" section and remember to reflect the appropriate installation service names.
Once the installation is underway, it progresses with the output shown in Figure 24.
Figure 24. Output
The installation subsequently completes with output similar to Figure 25:
Figure 25. Final Output
When the system is rebooted, it looks for pre-provisioned configuration files. If it finds none, it invokes the System Configuration Tool. Earlier in this article, we saw how the System Configuration Tool works.
In order to fully automate the installation process, we can provision a configuration file, that will be made available as part of the installation service. To do that, we first need to create a system configuration profile that contains all the minimum configuration data. Then we add this profile to the installation service that will be used by clients of the service.
sysconfig(1M) tool. The syntax could look like the following:
root@aiserver:~# sysconfig create-profile -o sc.xml
This command runs the System Configuration Tool and guides you through the process of populating the relevant entries by answering questions. Once done, you can validate the resulting output profile by running it against the install service and specifying the profile file name, for example:
root@aiserver:~# installadm validate -n default-i386 -P sc.xml
Note: For more examples, see "How to Configure Oracle Solaris 11 Using the
/export/auto_install/s11x86service/auto_install/sc_profilesdirectory, there is a file named
sc_sample.xml. By inspecting this text file, you can see that it defines a number of parameters, such as the username and a password, a password for the root role, keyboard mappings, the time zone, the DNS configuration, and the network configuration. If you want to make changes to this file, you could copy it to a different location and then associate it with an installation service. In our case, we do not need to make any changes, so you can accept the default system configuration parameters and skip to the next step.
/var/tmp, and work with the resulting copy—do this:
root@aiserver:~# cp /export/auto_install/s11x86service/auto_install/sc_profiles/sc_sample.xml /var/tmp/sc_client.xml
root@aiserver:~# installadm create-profile -n default-i386 -f /var/tmp/sc_client.xml -p sc_client
root@aiserver:~# installadm list -p
When you reboot the client from the network, you will witness the complete hands-off process of installing and configuring the system. You can then log in with the credentials configured in the system configuration profile, such as username
jack), and you can elevate privileges by assuming the
root role (password
solaris) as necessary.
In this article, you learned how to create, install, boot and configure a system using the Automated Installer. You learned how an Automated Install manifest can be modified and how modifications be put into effect automatically for you. You also learned how to add a local IPS repository and host it for all internally built systems in your environment without needing externally routable connectivity to systems that must be protected.
One of the greatest benefits of the Automated Installer is its level of integration with the rest of the infrastructure in Oracle Solaris, such as the Image Packaging System, the System Configuration Tool, and the ZFS file system. This integration provides the ability to automate most of the provisioning so that the installation service ultimately is capable of doing more to get the system closer to an "application-ready" state. This is done by installing the system with a specific system configuration profile and a well-defined set of software packages and services, which provides a very fast, consistent, and scalable provisioning experience.
Additionally, when it comes to deploying a system with Oracle Solaris Zones, the Automated Installer is capable of creating multiple zones that can be automatically installed using the same mechanisms used to install Oracle Solaris. (For more information on the subject of provisioning zones through the Automated Installer, see the Oracle Solaris 11 Technology Spotlights Web page.)
A follow-on article is planned that will explain how to extend this capability to provision Oracle Solaris Zones via the Automated Installation process.
For more information and next steps, please consult these resources:
And here are some additional resources:
Isaac Rozenfeld is a Principal Product Manager for Oracle Solaris and focuses on adoption, installation, and lifecycle management technologies. Isaac joined Oracle in 2010 as part of the Sun Microsystems acquisition.
|Revision 1.2, 01/09/2013|