Hands-on Lab: Large-Scale Installation and Deployment of Oracle Solaris 11 Isaac Rozenfeld Oracle Solaris Product Manager Acknowledgements to Glynn Foster, Martin Widjaja, Joost Pronk, Ethan Quach, Dave Miner, Sanjay Nadkarni, Duncan Hardie, Virginia Wray, Karen Tung, entire Oracle Solaris 11 Deployment team
Hands-on Lab: Large-Scale Installation and Deployment of Oracle Solaris 11 Isaac Rozenfeld Oracle Solaris Product Manager Acknowledgements to Glynn Foster, Martin Widjaja, Joost Pronk, Ethan Quach, Dave Miner, Sanjay Nadkarni, Duncan Hardie, Virginia Wray, Karen Tung, entire Oracle Solaris 11 Deployment team
Hands-on Lab: Large-Scale Installation and Deployment of Oracle Solaris 11 Isaac Rozenfeld Oracle Solaris Product Manager Acknowledgements to Scott Dickson, Shawn Walker, Bill Rushmore, Glynn Foster, Martin Widjaja, Joost Pronk, Ethan Quach, Dave Miner, Pavel Anni, Sanjay Nadkarni, Duncan Hardie, Virginia Wray, Karen Tung, Dan Kingsley, Art Beckman, Jeff McMeekin, Zones + Deployment + SMF + IPS + ZFS + Network + Security teams
1 Summary
This lab builds awareness and instills confidence surrounding the topic of deploying Oracle Solaris 11 in large installations. We address challenges associated with rolling out, and subsequently maintaining traditional Solaris installations across the enterprise. We subsequently provide an overview of installation and package management innovations that had been under development to address these specific challenges. Further, we review the built-‐in tools provided for transitioning to Oracle Solaris 11, as well as specific technical projects in Oracle Solaris development that have become the foundation for solidifying Oracle Solaris 11 installation and lifecycle management capabilities. Participants will gain example-‐led awareness and understanding of the following technical facilities: -‐ Automated Installation -‐ Image Packaging System -‐ System Configuration Profiles and Service Management Facility -‐ Boot environments -‐ Integration with Solaris Zones Because of the scope and available time for going through the steps in this lab, exercises with the following technologies are not included in this Hands-‐On Lab; they are however an important part of the overall deployment portfolio and we encourage attendees to read about ways these technologies provide value in JumpStart migration and custom image creation. -‐ Jumpstart to Automated Installation conversion -‐ Distribution constructor We examine each of the enhancements and demonstrate how, jointly, they make it easier to deploy Oracle Solaris 11 technology in the enterprise. Upon completion of this session, participants will have learned how to begin addressing business requirements with Oracle Solaris 11 provisioning and packaging technology, and get comfortable with methodologies that are available to aid in the process.
2 Overview
There are three significant steps involved in the installation process:
1) Assignment of a network identity for the system being installed 2) Contacting the automated installation service to download a small boot
image over the network and description of how to provision a system 3) Provisioning the system over the network, including software and system
configuration
Each of the above can be provided by various services residing on the same physical or virtual system, or they could also be on separate systems. Here these services will reside on the same system, provided by the following components:
1) DHCP service, 2) Automated Install service 3) Image Packaging System (IPS) Repository service
NOTE: In environments where DHCP is not permitted, there are alternative methods to getting the network identity to the system manually, such as through the use of network configuration arguments at OBP 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. In case 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 lab we will set up two Oracle Solaris 11 systems, one to host an Automated Installer environment for the purposes of installing other systems automatically, and one to host a system being installed. Installation of the first system will be performed interactively, whilst the installation of the second system, subsequently, will be automated.
Figure 1: Client system installed by the Automated Install Server
Our first system, as depicted on the left, will be used to install our installation environment, the one where we run our Automated Installer, IPS and DHCP
services. The second of our systems, as shown on the right, will be created and installed for the purposes of demonstrating automated installation.
After following this document you will find yourself with two systems configured as shown in Figure 1. The client system will be provisioned with a chosen installation profile including software selection and system configuration.
3 Outline
3.1 Pre-‐requisites
This lab includes the use of the following elements:
Functional requirement
Provided by the following technology
Where can you get it
Covered in Exercise:
Virtual Machine Manager (to simulate independent hardware
server systems)
Oracle VirtualBox Hypervisor Software
Provided in the lab, also on oracle.com
5.1
DHCP Service ISC DHCP Server Provided in Solaris 11
5.8
Automated Installation Service
Automated Install server
Provided in Solaris 11
5.8
Network-‐based software repository
Image Packaging System (IPS) repo
Provided in Solaris 11
5.7
Oracle Solaris 11 base OS image
Text Installer Provided in the lab, also on oracle.com
5.2, 5.3
Additional Oracle Solaris 11 software
IPS Repository Provided in the lab, also on oracle.com
5.4
Provisioning a Zone Automated Install server
Provided in Solaris 11
5.13,5.15
The following assumptions have been made regarding the environment where this lab is being performed:
1. Network connectivity to the Internet is not available. 2. Of the 2 systems being built, one (i.e. “Server”) will have to be configured
with a static IP address that will act as a DHCP server. 3. The second of the 2 systems buing built, (i.e. “Client”) will have to be
configured as a DHCP client because that is how it will receive its network identity information during the Installation sequence.
4. Mac OS X running VirtualBox 4.0.16 with Extensions Pack installed
In other scenarios, there may be network connectivity to the Internet and so various elements of this lab would have to be carried out slightly differently.
3.2 Exercise Outline
Below is the outline of exercises we go through, as we build-‐up on each of the exercises and learn to about Oracle Solaris 11 deployment tools. Because some of the decisions behinds these tasks would typically be more involved outside of a lab setting, certain exercises (while provided here) are marked in red in order to help stay within the time allotted to us for this lab today. If you’re skipping an exercise, you are encouraged to come back to it upon completion of the lab.
READ & SKIP 5.1 Using Oracle VirtualBox Hypervisor Software to Get Going
5.2 Install and Configure your Server
5.3 Using your Server for the first time
SKIP 5.4 Configure the IPS Repository for local use by the “Server”
SKIP 5.5 Perform an Installation of additional Software
SKIP 5.6 Boot Environments
5.7 Configure the IPS Repository as a network service
5.8 Using Automated Installer to create the first install service
SKIP 5.9 Installing the client with default values
5.10 Customizing the default Automated Install (AI) manifest
SKIP 5.11 Booting the Client with the modified Automated Install (AI) manifest
5.12 Providing a System Configuration profile for the Client System
5.13 Preparing for Installing a Client With an Automatically Deployed Zone
SKIP 5.14 Booting the Automatically Deployed (but not yet configured) Zone
5.15 Preparing for the Automatically Deployed and Configured Zone
4 Implementing the Automated Install Server Environment
Now that we understand what we are trying to do, in the following sections we will go through the steps, as shown in Figure 2, including command line examples of exactly how to achieve our goal.
While going through this document refer to Figure 2 below for a quick reminder of the “big picture” we are after. The IPS repository and the DHCP server could be, and in our case are, on the Install server. This simplifies the endeavor and requires much less infrastructure for us to configure.
Figure 2: Automated Installation services
5 Exercises
5.1 Using Oracle VirtualBox Hypervisor Software to Get Going
Oracle VirtualBox is already installed in the lab. It is installed with 2 Virtual machines.
Some basics things to remember about VirtualBox:
1. It has a notion of an escape key, which allows you to break-‐out of a virtual machine image and navigate back in your native OS environment. This key sequence is configurable in “Preferences -‐> Input”. While adjustable, it is currently configured to be Left WinKey
The VirtualBox instances that you see are named: “Server” and “Client”.
Ultimately, it is our “Client” machine that will act as a system onto which software gets installed in a fully automated fashion. In order to make that happen, we first need to work on preparing the “Server” machine.
1. Select the “Server” machine and click “Settings” 2. Click on “Storage” and associate the Text-‐install .iso with a CD/DVD drive 3. Click on “System” and make sure to check “CD/DVD-‐ROM” and click up
arrows to move it on top of “Hard Disk” 4. Make sure “Enable IO APIC” is checked 5. Select “Network” and navigate to set a check for “Enable network Adapter 1”,
then select network type as “Internal Network” a.k.a. “intnet”. This means that the VirtualBox’s private network will be used for communicating with other VirtualBox machines present on the host.
6. Click “OK” 7. Click “Start”
As the VirtualBox machine instance starts up, watch the screen. Note the escape-‐key sequence provided on the bottom of the right corner.
5.2 Install and Configure your Server
Note: If you would like to skip this activity in the interest of time, you can “fast forward” through this portion of the lab by restoring your virtual machine from a VirtualBox snapshot titled: “Server Installed”.
As the boot screen renders, you’ll be presented with choices and you’ll have to make selections to indicate your answers, as shown below
During the initial dialogue, we answer the basic questions pertaining to language preference, time zone, disk partition information (opting to use whole disk in our example), create a username and a password, specify a meaningful user name, create a root password and choose to use automatic network discovery.
1.
Boot from a Text Installer image, hit [ESC] for menu, highlight the first entry and hit ‘enter’ to continue. If you want to simply boot into the default menu selection, being the first, then hitting [ESC] is not necessary.
2.
Choose the keyboard layout and language you would like to use during the installation. For the first question hit [Enter] for ‘US-‐English’ keyboard layout. For the second question, hit [Enter] for the ‘English’ language.
Wait for the system to continue booting.
3.
Hit ‘1’ to select ‘Install Oracle Solaris’ and hit [Enter]
4.
Hit F2 to go beyond the ‘Welcome’ screen.
5.
Make the disk selection and hit F2 to continue. Usually leaving the default will suffice. On the next screen, select ‘use whole disk’ and hit F2 to continue.
As there are no pre-‐provisioned system configuration files available when we use the Text Installer, a System Configuration Tool starts up and prompts us for information.
1.
Enter “aiserver” as the computer name and highlight “Manually” to manually configure the network, select F2 to continue.
Note: we do not select it in this example but if you were to select “Automatically” you do not have to enter any network information at all, the configuration would be done for you.
2.
Enter the network settings appropriate for your network and then select F2.
3.
We will not configure DNS at this time, select the appropriate choice and hit F2
4.
We will not set up a name service at this time, select F2.
5.
Select the time zone region appropriate for your location, select F2.
6.
Select the appropriate date and time then select F2.
7.
Complete your configuration by entering a root password, your name, username and user password. Select F2.
For ‘root’ password, use: oow2012
For your real name use your first name.
For a user account, use: ouser and password: ouser1
Verify that the configuration you have chosen is correct and apply the settings by choosing F2. On the following screen you’ll see a progress bar indicating the installation is proceeding.
When the installation is complete, you see the screen summarizing the activity, and you are prompted to reboot.
5.3 Using your Server for the first time
Note: If you would like to skip this activity in the interest of time, you can “fast forward” through this portion of the lab by restoring your virtual machine from a VirtualBox snapshot titled: “Server Installed”.
The installation is complete. When the system reboots, hit ‘ESC’ as soon as you see a message on the top of the screen, prompting you to do so.
1) Then select the ‘Boot from Hard Disk’ option, and hit ‘Enter’. 2) Then login with the username credentials you created during the
configuration dialogue.
The first time the server boots, you’ll notice a number of SMF services being initiated. This initial boot time is, therefore, slightly longer than the system will take to boot on subsequent boot-‐ups.
Log in with the credentials you specified (reminder: suggested values to use were: user: ouser, password: ouser1)
Note: Do not attempt to login as root because (for better security) starting with Oracle Solaris 11, the previously accessible root user is now treated as a role. This means you log in with a regular username, and then assume the root role. This is a security and an auditing benefit.
Ignore the messages about ‘sendmail errors’ shown on console, for now.
5.4 Configure the IPS Repository for local use by the “Server”
Note: If you would like to skip this activity in the interest of time, you can “fast forward” through this portion of the lab by restoring your virtual machine from a VirtualBox snapshot titled: “IPS repo configured locally”.
After you’ve logged in:
1) Assume the root role by running “su” and entering your root password. 2) Turn off sendmail and OCM services to prevent errors from being printed on
your screen in the lab: “svcadm disable sendmail-‐client sendmail”, then “svcadm disable ocm”
3) If you did not restore the VirtualBox snapshot to get to this point, type “eject” to eject the media image that is mounted (this was the boot image that we booted with prior to commencing the installation)
4) On top of the screen, select ‘Devices -‐> CD/DVD Devices -‐> More CD/DVD Images”, select ‘Add’ Note: Instead, in newer versions of VirtualBox, you can go to the bottom of the screen, in the right corner area, position the mouse above the CD image, click and select to ‘Choose a virtual CD/DVD disk file…”
5) In the pop-‐up window, navigate to the location of the file named “sol-‐11-‐1111-‐repo-‐full.iso” and double-‐click it.
Your IPS repository disk is now mounted and ready for use. To configure the IPS repository locally:
1) Remove the default “solaris” publisher from pointing to pkg.oracle.com, run the following command:
root@aiserver:~# pkg unset-publisher solaris
2) Then run the following command (all in one line):
root@aiserver:~# pkg set-publisher –g file:///media/SOL11REPO_FULL/repo solaris
This allows you to run ‘pkg’ commands to perform updates to the “Server” without having to connect to the network, instead from the local ISO file. This does not yet make the IPS Repository service available on the network, for your clients. We will do this as a separate exercise.
5.5 Perform an Installation of additional Software
Note: If you would like to skip this activity in the interest of time, you can “fast forward” through this portion of the lab by restoring your virtual machine from a VirtualBox snapshot titled: “Sample packages installed”.
When you installed Solaris using the Text-‐based interactive Installer, you ended up with a collection of software packages organized into a solaris-‐large-‐server package group name. You can verify this by running:
ouser@aiserver:~$ pkg list | grep group
At this point, let us add a software package that is NOT part of this initial group. Such an example could be adding a VIM editor.
Assuming you’ve still got the root role assumed, run:
root@aiserver:~# pkg install editor/vim
This will take about a minute. After it is installed, you can see which files were touched or modified as a result of this package by running:
root@aiserver:~# pkg contents editor/vim
Notice how there is output referencing boot environments, and how the installation of this specific package does not require automatic creation of any boot environments.
Optionally, to see IPS automatically resolve dependencies in a slightly more involved package installation, we can also use another example: adding “graphics/nvidia” package. To do this run:
root@aiserver:~# pkg install graphics/nvidia
This package will have 16 other packages as dependencies, all of which will automatically be calculated and installed. There will also be 6 services that will be introduced. This time, there will be a backup boot environment that will be created automatically, named “solaris-‐backup-‐1”. Upon completion of this command, go ahead and reboot the system by running:
root@aiserver:~# reboot
5.6 Boot Environments
Note: If you would like to skip this activity in the interest of time, you can “fast forward” through this portion of the lab by restoring your virtual machine from a VirtualBox snapshot titled: “Boot Environments created”.
After the system reboots and presents a boot menu, you’ll be able to select which boot environment to boot into. Go ahead and select “solaris-‐backup-‐1” and hit [Enter].
In this environment we have a state of the machine before the installation of the “graphics/nvidia” package. This is an example of illustrating a safe roll-‐back capability that Oracle Solaris 11 provides out-‐of-‐the-‐box, thus easing configuration and software management. Notice that the “graphics/nvidia” package is not present when you run “pkg info graphics/nvidia”. If you were to boot into the first boot environment in the previous listing seen at the GRUB menu, you would see that package present there.
You could optionally, at will, create and manipulate boot environments. Let us create one now.
Note: We use ‘pfexec’ as part of a Solaris security model that provides for profiles-‐based execution of commands, allowing for delegation of privileges.
ouser@aiserver:~$ pfexec beadm create beforeUpdate
Once you’ve done this, there will be a boot environment created called beforeUpdate.
You can see all the boot environments available by running “beadm list”.
ouser@aiserver:~$ beadm list
Now you can rename that newly created environment into something else, for example, call it “beforeChange”.
ouser@aiserver:~$ pfexec beadm rename beforeUpdate beforeChange
You can activate that boot environment to be the default boot environment to boot into, the next time the system boots, by running:
ouser@aiserver:~$ pfexec beadm activate beforeChange
You can see the listing of your boot environments again, by re-‐running “beadm list”. Notice how (in the “Active” column) the “R” and “N” values move between different boot environments. “R” means the boot environment active on Reboot, and “N” means the boot environment active Now.
You could also mount the boot environments and interrogate them, if you ever needed to look for files. Here’s an example of mounting a boot environment.
1) Create a mount point:
ouser@aiserver:~$ mkdir /var/tmp/someBE
2) Mount the Boot Environment
ouser@aiserver:~$ pfexec beadm mount beforeChange /var/tmp/someBE
3) With the mount point in place, you’ll be able to traverse the file systems that
are associated with that boot environment
ouser@aiserver:~$ ls –la /var/tmp/someBE
Remember to unmount the boot environment when you’re done looking through it.
ouser@aiserver:~$ pfexec beadm unmount beforeChange
At the end, reboot into a “beforeChange” boot environment, by running:
ouser@aiserver:~$ pfexec beadm activate beforeChange ouser@aiserver:~$ pfexec reboot
5.7 Configure the IPS Repository as a network service
Note: If you would like to skip this activity in the interest of time, you can “fast forward” through this portion of the lab by restoring your virtual machine from a VirtualBox snapshot titled: “IPS Service Configured”.
In order to allow machines to connect and receive software being deployed on them, the IPS repository has to be configured as a network service on our server.
Verify the network has a static IP address:
ouser@aiserver:~$ dladm show-link LINK CLASS MTU STATE OVER net0 phys 1500 up -- ouser@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
Note: dladm and ipadm are the commands available to manage network configuration in Oracle Solaris 11.
We take the IPS repository contents as on the ISO file and ensure that it is accessible through a service, persistently even if the server system were to be rebooted.
(Note: we would typically copy the contents of the ISO to a file system, but as that takes time we don’t have the luxury of in this lab, we will not do that copying)
We need to instantiate it as a properly configured service. Since SMF is the Oracle Solaris facility for handling service, we can leverage the known commands for getting this done.
Assume the root role by running “su” and providing the associated password. Then:
root@aiserver:~# svccfg –s application/pkg/server setprop \ pkg/inst_root=/media/SOL11REPO_FULL/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
The next step in getting setup is to point the system to use the locally configured IPS repository. We do so by pointing the pkg IPS client’s solaris publisher to the same host (i.e. itself) in our case.
root@aiserver:~# pkg set-publisher –O http://192.168.1.222 solaris
We can now add another package as a test, to make sure our repository is properly configured and accessible via the network:
root@aiserver:~# pkg install developer/vala
5.8 Using Automated Installer to create the first install service
Note: If you would like to skip this activity in the interest of time, you can “fast forward” through this portion of the lab by restoring your virtual machine from a VirtualBox snapshot titled: “AI Service Installed”.
Now that you have a system that has an IPS package repository, let’s go ahead and create an instance of Automated Installation services.
To complete this task, since we’ve created the Oracle Solaris 11 repository image locally and already 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, we simply run:
root@aiserver:~# installadm create-service –n s11x86service –i 192.168.1.110 –c 20
This will create a service named s11x86service and serve up DHCP clients starting with 192.168.1.110. The –c argument specifies that only 20 IP address should be allocated, and that’s fine for our case we we’re only interested in provisioning one client system in this example.
When prompted about using the default image path, answer ‘y’ for yes.
In creating the installation service, this generates a number of steps:
1) creation of a local DHCP server instance on the Automated Install server
2) creation of a default installation service (named default-‐i386)
Note: If you wanted to create a SPARC service, you would add the “–a sparc” argument to the above command. Additionally, use of the “-‐n” switch during service creation is optional, as the Automated Installer is intelligent to figure out the architecture of the service being created, and to give it a name (if none is specified).
Note: since in our example we are working with the very first instance of a service, we have to use the default service name when implementing modifications to the service. Keep this in mind as there will always be a default installation service that is architecture-‐specific. When executing commands on services that were the first to
be created for the hardware platform, the commands have to reflect the name default-‐i386 instead of the service name (in our example: s11x86service)
At this point, you can see the install service’s status by running:
root@aiserver:~# installadm list
5.9 Installing the client with default values
Note: In this lab we have limited time, so please ONLY READ through this exercise. Do not boot the yet, because we’ll run out of limited lab time.
The next step is to boot the client system off the network and provision it using the Automated Install service that we have just set up.
Make sure that the 2nd VirtualBox machine has “Network” listed first in its boot sequence.
The VirtualBox instances that you see are named: “Server” and “Client”.
Remember that it is our “Client” machine that will act as a system onto which software gets installed in a fully automated fashion. In order to make that happen, we’ve already configured the “Server” machine. Now let’s configure the “Client” machine.
1. Select the “Client” machine and click “Settings” 2. Click on “System” and make sure to check “Network” to enable it, then
highlight “Network” by clicking on it once, then click up arrows to move it on top of the list, above “Hard Disk”. Please remove checks from “Floppy” and “CD/DVD-‐ROM”
3. Make sure “Enable IO APIC” is checked 4. Select “Network” and navigate to set a check for “Enable network Adapter 1”,
then select network type as “Internal Network” a.k.a. “intnet”. This means that the VirtualBox’s private network will be used for communicating with other VirtualBox machines present on the host.
5. Select “USB” and remove the ticks to turn-‐off “Enable USB 2.0” and “Enable USB Controller”
6. Select “Audio” and remove the ticks to turn-‐off “Enable Audio” 7. Click “OK” 8. Click “Start”
As the VirtualBox machine instance starts up, watch the screen.
First you will see the network boot attempt, similar to the below:
Then you will be prompted by a GRUB menu with a timer. The default selection highlights the “Text Installer and command line” option, but you need to press the “down” arrow to select the second option labeled “Automated Install”, then press “Enter”. The reason for this ordering is because there’s a timer in the GRUB menu.
We want to avoid a default behavior of the system being automatically re-‐installed (accidentally) if it were to be booted from the network. See figure below:
What follows is the continuation of a networked boot from the Automated Install server, where 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 the said manifest and then processes it to identify the address of the IPS repository where to obtain images from.
As you watch the screen you’ll see how pkg.oracle.com is the default address of the IPS repository. In our case, however, we had previously created a local IPS repository so we need to make sure that it is our local IPS repository that is being contacted to install the client system.
Some of the valuable information on the screen will be the location of log files and XML manifest being used for this installation, such as shown on the above image.
The default IPS repository that is hard-‐configured in the default Automated Install manifest is hosted by Oracle and the XML code “<origin name=”> is pointing at pkg.oracle.com. If your system were able to reach the Internet, you would see a successful installation process on your screen.
However, since your system is not 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, rendering a failure message, like shown below:
In reality, this is not that big of a deal because most enterprise installations will build internal IPS repositories (like we’ve previously done up above), and point install clients to those instead of allowing Internet-‐facing traffic 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-‐house.
5.10 Customizing the default Automated Install (AI) manifest
Note: If you would like to skip this activity in the interest of time, you can “fast forward” through this portion of the lab by restoring your virtual machine from a VirtualBox snapshot titled: “AI Service Modified”.
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 steps:
1) examine the manifest that the install service uses, 2) modify the manifest, and 3) add the newly modified manifest to the install service
This simple set of steps can be accomplished using the following:
Assume the root role by running “su” and providing the password.
First, get the listing of our installation services and manifests associated with them:
root@aiserver:~# installadm list –m Service Name Manifest Status ------------ -------- ------ default-i386 orig_default Default s11x86service orig_default Default
Then probe the s11x86service and the default manifest associated with it. The –m switch 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 like so:
root@aiserver:~# installadm export –n s11x86service –m orig_default > /var/tmp/orig_default.xml
Second, knowing that we want to modify the location of the IPS repository, we can edit the file and input our changes while doing so. Create a backup copy of this file under a different name and work on the copy, say orig_default2.xml
root@aiserver:~# cp /var/tmp/orig_default.xml /var/tmp/orig_default2.xml
Open this file with an editor.
root@aiserver:~# vi /var/tmp/orig_default2.xml
We want to find and reference the line that reads:
<origin name=”http://pkg.oracle.com/solaris/release”/>
and replace it with a line that reflects our local IPS repository, reading like:
<origin name=”http://192.168.1.222/solaris”/>
Now that we’ve modified the XML file, we need to put it into effect by updating the AI service while registering the contents of the new file.
Typically, when we begin working with many services concurrently, the command to do that would entail referencing the specific AI service name:
root@aiserver:~# installadm update-manifest –n s11x86service –m orig_default -f /var/tmp/orig_default2.xml
However, since in our example we are working with the very first instance of an AI service, we have to use the default service name when applying modifications to the
service, and so the only thing that would change in the above command is the name of the service would need to be default-‐i386 instead of s11x86service. This makes the command we want to execute look like the following:
root@aiserver:~# installadm update-manifest –n default-i386 –m orig_default -f /var/tmp/orig_default2.xml
5.11 Booting the Client with the modified Automated Install (AI) manifest
Note: If you feel you’re running out of time, you can skip doing this step and simply read through it; then go onto the next exercise.
Boot the client now, and as you do, you’ll see a process similar to what you’ve previously seen, but now it will not stop with an error. Instead, it will proceed towards contacting the local IPS repository for packages. The process begins to look like the image below, notice the address in the origin line on the bottom:
There are many more additional types of customizations that could be done to the Automated Install manifest. The guiding principles in instituting these changes are to follow the process outlined above and remember to refer to appropriate install service names.
Once the installation is underway, it completes with the following output:
Prior to the reboot, you may want to login and explore the system, looking at suggested log files, such as the Installation log file (/system/volatile/install_log) or the Automated Install manifest that was used to install the system (/system/volatile/ai.xml)
If you plan to log in before rebooting the system, the default Automated Install image username is root and password is solaris
As you reboot, you’ll be taken thru the manual system configuration dialogue the first time the systems is installed and rebooted. In order to avoid having to go through the interactive manual system configuration process, you would first create a system configuration profile for the client (or, a default profile for all clients) on the server. Automating system configuration is the 2nd component of the Automated Installation process and is discussed in the next exercise.
5.12 Providing a System Configuration profile for the Client System
Note: If you would like to skip this activity in the interest of time, you can “fast forward” through this portion of the lab by restoring your virtual machine from a VirtualBox snapshot titled: “AI Profile Configured”.
When the system is rebooted, it looks for pre-‐provisioned configuration files – and if it finds none, it invokes the interactive System Configuration Tool. Earlier in the document, we had already seen how the System Configuration Tool works when we installed the Server interactively.
In order to fully automate the installation process, we should provision a configuration file that would be made available as part of the installation service. To do that, we either:
1) interactively create a system configuration profile that would contain all the minimum configuration data, or
2) use a pre-‐existing sample system configuration profile (recommended, see further below)
We‘d then add this profile into the installation service that would be used by clients as part of the deployment process.
If opting for the interactive creation of the system configuration profile can be done by using sysconfig(1M) tool. We run this on the Server system. The syntax could look like the following:
root@aiserver:~# sysconfig create-profile –o /var/tmp/sc.xml
This runs the System Configuration Tool and guides us through the process of populating the relevant entries by answering questions. As you go thru the dialogue, enter values that are of interest to you.
Once done, the resulting output profile can be validated by running it against the install service, and specifying the profile filename, like so:
root@aiserver:~# installadm validate –n default-i386 –P /var/tmp/sc.xml
Note: There is a separate How-‐To article that has been published, containing more examples on doing this; refer to the last section.
In this lab we proceed with using a pre-‐existing sample system configuration profile that is delivered as part of the installation service. In the /export/auto_install/s11x86service/auto_install/sc_profiles directory is a file named: sc_sample.xml. Inspecting this text file, we can see that it defines a number of parameters such as the username and a password, a password for root role, keyboard mappings, time zone, DNS configuration and network configuration. If we
want to make changes to this file, we could do so by copying it to a different location, making changes there and then associating it with an installation service.
In our case, we are not going to be making any changes to it, so we’ll accept the default system configuration parameters and just skip to the next step.
The second step involves adding the system configuration profile to an install service. We have to give the profile a name, as well as remember what the actual filename is. We want to copy the original file to /var/tmp, for example, and work with the resulting copy. Let’s do this first:
root@aiserver:~# cp /export/auto_install/s11x86service/auto_install/sc_profiles/sc_sample.xml /var/tmp/sc_client.xml
Next, instantiate a profile with the install service. The syntax for doing this in our case is:
root@aiserver:~# installadm create-profile –n default-i386 -f /var/tmp/sc_client.xml –p sc_client
We can now verify that the install service contains a custom system configuration profile associated with it, via:
root@aiserver:~# installadm list –p
Now switch the window to our Client. When we now reboot our client from the network, we can witness a complete hands-‐off process of installing and configuring the system. We can then login with credentials configured in the sc_client system configuration profile, such as username jack (password: jack), and we can elevate privileges by assuming the root role (password: solaris) as necessary.
5.13 Preparing for Installing a Client With an Automatically Deployed Zone
Note: If you would like to skip this activity in the interest of time, you can “fast forward” through this portion of the lab by restoring your virtual machine from a VirtualBox snapshot titled: “AI Zone Installation”.
In order to provide for automatic deployment with zones, you need to do two things.
1) Create a zone configuration file and host it somewhere on the network
2) Update the AI manifest file to include a reference to this zone configuration file.
Let’s do these 2 steps now:
1) Type in the following sequence at the prompt:
$ cat > /var/tmp/zonecfg.export.txt create –b set zonepath=/export/z1 set brand=solaris set autoboot=false set ip-type=exclusive add anet set linkname=net0 set lower-link=auto set link-protection=mac-nospoof set mac-address=random end
When done, hit [CTRL-‐D] to save the file.
Copy the file to a location where the AI client will be able to access it from. For the purposes of our lab, we’ll use the AI service’s export directory.
root@aiserver:~# cp zonecfg.export.txt /export/auto_install/s11x86service/
Note, you can replace “s11x86service” with a different name of an Install service you may have.
2) Take your previously used AI manifest:
root@aiserver:~# cp /var/tmp/orig_default2.xml /var/tmp/orig_default2-withzone.xml root@aiserver:~# vi /var/tmp/orig_default2-withzone.xml
Make sure to scroll to the bottom of the file, finding the “</ai_instance>” tag at the bottom of the file and entering the following before the </ai_instance> tag.
<configuration type=”zone” name=”z1” source=”http://192.168.1.222:5555/export/auto_install/s11x86service/zonecfg.export.txt”/>
The above specifies a reference to a zone configuration script.
Now, register the updated file with the existing install service, to update the AI manifest named orig_default to reflect the changes you’ve just made above.
root@aiserver:~# installadm update-manifest –n default-i386 –m orig_default -f /var/tmp/orig_default2-withzone.xml
5.14 Booting the Automatically Deployed (but not yet configured) Zone
Switch to your AI Client and hit the host-‐reset key sequence to power-‐cycle the Client and get it to boot off the network again. As it boots up, it’ll go through the already-‐familiar installation sequence. Furthermore, it will result in installation of a zone named “z1” with the zone configuration parameters we’ve specified above.
The default system configuration profile is set with enable_sci.xml, which will enable the interactive System Configuration Tool dialogue.
What we have to do next is to ensure we specify configuration profile data for the zone.
Note: Unless we specify a System Configuration profile, the first time you’ll boot the zone and connect to its console, you’ll be prompted by an interactive invocation of the System Configuration Interface Tool. Its role is to guide you through a dialogue similar to the one you’ve already been through at the beginning of this lab (when we were configuring our Server).
After your client is deployed, it will take a few minutes for the installation of zone to complete.
You can monitor the activity using the logs in the /var directory. Please run:
root@aiserver:~# zoneadm list -vi
Once the state of the zone being installed is shown as ‘installed’, you can boot it via:
root@aiserver:~# zoneadm –z z1 boot
Then, go ahead and login to the zone via console, to complete the interactive configuration:
root@aiserver:~# zlogin –C z1
After you establish the connection to the console of the zone, you’ll se a System Configuration Tool’s dialogue, providing for an interactive way to configure the zone. Wouldn’t it be nice to have a preconfigured configuration profile applied for a zone?
That is the next exercise’s activity.
5.15 Preparing for the Automatically Deployed and Configured Zone
Note: If you would like to skip this activity in the interest of time, you can “fast forward” through this portion of the lab by restoring your virtual machine from a VirtualBox snapshot titled: “AI Zone Installation and Configuration”.
If you would like to fully automate the configuration process of the zone, then you need to specify the configuration profile to use for that zone. Here’s a command that will do this for you:
root@aiserver:~# installadm create-profile –n default-i386 –c zonename=”z1” –f /var/tmp/sc_client.xml –p sc_sample_for_zone
In the above command we are using a “-‐c” flag to specify the installation criteria that matches a name of a zone being “z1”. There are a number of other criteria that are supported; please take a look at the installadm man page for the complete listing.
Now, if you go and re-‐set your client, it will go through a complete cycle deploying the system with the zone (z1, as above is the name of the zone) installed and configured as per the configuration profile sc_sample.xml. You may recognize the same filename; this would be the same configuration information as we used for the Global Zone.
6 Troubleshooting
To aid you in the troubleshooting process, below are various locations of log files that you may want to reference during deployment of systems.
As the client is being built, installation log files are located in /system/volatile directory. You may login into the client image as its being deployed with the following credentials: ‘root’ user, ‘solaris’ password
Automated Zone installation is logged in /system/volatile/zones
After the installation, the log files are located in /var/sadm/system/logs/, specifically looking at the install_log will yield a lot of good information.
When installing Zones once the system has been built, the zone installation is logged in /var/log/zones/
7 Summary
During this lab you have had a glimpse into the processes involved in deploying Oracle Solaris 11 systems. For a 1 hour time limit it is challenging to cover an exhaustive range of possibilities. Hopefully the time spent has given you confidence in the tools and methods available to help you get going when you are ready to proceed upon return to your workplace.
In this lab you learned how to create, install, boot and configure a system using Automated Installer. You learned how an Automated Install manifest can be modified and 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 having to have externally-‐routable connectivity to systems that need to be protected.
8 References
For more information and next steps, please consult additional resources:
Oracle Solaris 11 Technology Spotlights – http://www.oracle.com/technetwork/server-‐storage/solaris11/technologies
Transitioning from Oracle Solaris 10 JumpStart to Oracle Solaris 11 Automated Installer -‐ http://docs.oracle.com/cd/E23824_01/html/E21799/index.html
Oracle Solaris 11 Information Library –http://docs.oracle.com/cd/E23824_01/index.html
Oracle Solaris 11 Product Documentation -‐ http://www.oracle.com/technetwork/server-‐storage/solaris11/documentation/index.html
Advanced Administration with the Image Packaging System on Oracle Solaris 11 -‐ http://www.oracle.com/technetwork/articles/servers-‐storage-‐admin/o11-‐128-‐adv-‐ips-‐admin-‐524550.html
How to Configure Oracle Solaris 11 using sysconfig command -‐ http://www.oracle.com/technetwork/articles/servers-‐storage-‐admin/o11-‐111-‐s11-‐sysconfig-‐524498.html
Oracle Solaris Observatory blog -‐ http://blogs.oracle.com/observatory/
Installing Oracle Solaris 11 Systems: Hands-‐on Lab from Oracle OpenWorld 2011 -‐ http://blogs.oracle.com/unixman/entry/s11_automated_install_hands_on
