Home Cloud & Networking Oracle Solaris 11: First Look

Oracle Solaris 11: First Look

By Philip P. Brown
books-svg-icon Book
eBook $16.99 $10.99
Print $32.99 $18.99
Subscription $15.99 $10 p/m for three months
$10 p/m for first 3 months. $15.99 p/m after that. Cancel Anytime!
What do you get with a Packt Subscription?
This book & 7000+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with a Packt Subscription?
This book & 6500+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with eBook + Subscription?
Download this book in EPUB and PDF formats, plus a monthly download credit
This book & 6500+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with a Packt Subscription?
This book & 6500+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with eBook?
Download this book in EPUB and PDF formats
Access this title in our online reader
DRM FREE - Read whenever, wherever and however you want
Online reader with customised display settings for better reading experience
What do you get with video?
Download this video in MP4 format
Access this title in our online reader
DRM FREE - Watch whenever, wherever and however you want
Online reader with customised display settings for better learning experience
What do you get with video?
Stream this video
Access this title in our online reader
DRM FREE - Watch whenever, wherever and however you want
Online reader with customised display settings for better learning experience
What do you get with Audiobook?
Download a zip folder consisting of audio files (in MP3 Format) along with supplementary PDF
What do you get with Exam Trainer?
Flashcards, Mock exams, Exam Tips, Practice Questions
Access these resources with our interactive certification platform
Mobile compatible-Practice whenever, wherever, however you want
BUY NOW $10 p/m for first 3 months. $15.99 p/m after that. Cancel Anytime!
eBook $16.99 $10.99
Print $32.99 $18.99
Subscription $15.99 $10 p/m for three months
What do you get with a Packt Subscription?
This book & 7000+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with a Packt Subscription?
This book & 6500+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with eBook + Subscription?
Download this book in EPUB and PDF formats, plus a monthly download credit
This book & 6500+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with a Packt Subscription?
This book & 6500+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with eBook?
Download this book in EPUB and PDF formats
Access this title in our online reader
DRM FREE - Read whenever, wherever and however you want
Online reader with customised display settings for better reading experience
What do you get with video?
Download this video in MP4 format
Access this title in our online reader
DRM FREE - Watch whenever, wherever and however you want
Online reader with customised display settings for better learning experience
What do you get with video?
Stream this video
Access this title in our online reader
DRM FREE - Watch whenever, wherever and however you want
Online reader with customised display settings for better learning experience
What do you get with Audiobook?
Download a zip folder consisting of audio files (in MP3 Format) along with supplementary PDF
What do you get with Exam Trainer?
Flashcards, Mock exams, Exam Tips, Practice Questions
Access these resources with our interactive certification platform
Mobile compatible-Practice whenever, wherever, however you want
  1. Free Chapter
    IPS – The Image Packaging System
About this book
Oracle Solaris provides innovative, built-in features that deliver breakthrough high availability, advanced security, efficiency, and industry-leading scalability and performance to help businesses grow. "Oracle Solaris 11: First Look" covers the new features and functionality of Oracle Solaris 11 and how these new features and improvements will make it easier to deploy services to the enterprise while improving performance and reducing total cost of ownership.This book starts with coverage of Image Packaging System and the new installation methods. It then moves swiftly to network configuration. The book also includes some security features and improvements.  
Publication date:
January 2013
Publisher
Packt
Pages
168
ISBN
9781849688307

 

Chapter 1. IPS – The Image Packaging System

This chapter introduces the new Solaris packaging system. The first part will introduce key concepts to be understood. The second part will give specific examples of the most common tasks a sysadmin will need to perform.

The details about installing a new Solaris machine from scratch are covered in Chapter 2, Solaris 11 Installation Methods, in this book. This chapter primarily deals with package management on an already running Solaris 11 system.

Tip

If you wish to try out Solaris 11 package management commands without going through the hassles of a full install, Oracle provides freely downloadable VM images of Solaris 11—for both VirtualBox and VMWare—that are ready to go out of the box.

 

The brave new world of IPS


Solaris 11 has an all new packaging system for OS-related packages, in which the packages are primarily accessed via the pkg command. This new command handles the acquisition/downloading of OS packages, as well as local installation and removal of the files on local storage.

Legacy format packages, also known as System V Release 4 (SVR4) style packages, are still supported; pkgadd and related commands still work. This is not merely for third-party developers. Oracle itself still distributes some Solaris 11-related packages in SVR4 packages.

Even though Oracle has not stopped using SVR4 packages, the new pkg interface has some notable benefits, such as extra hooks to integrate safely with zones, and automatic use of ZFS snapshots for certain types of package upgrades. It is for this reason that Solaris 11 does not support UFS as a root filesystem. The new packaging system requires ZFS for part of its standard operations.

This chapter breaks down the concepts of the new package system into four main areas:

  • An overview of package repositories

  • Understanding package naming

  • Understanding conceptually how packages are installed

  • Practical use of the pkg command

The majority of the chapter is taken up with the practical use section.

 

Repositories/repos


The new pkg style is primarily network-based, rather than file-based.

While it has recently become possible to transfer a single .p5i package via the file transport mechanism of your choice, you lose the automatic upgrade capability of IPS. For that, it requires a repository to be running somewhere (commonly referred to as a repo). That said, it is certainly possible to have a copy of the full Solaris repository on your own machine.

A point of interest is that the new pkg system is differential-based in an attempt to be network efficient. If you have an older version of a package, and if you request that a new version be installed, it will only pull the newer files from the repository server, rather than the entire package.

Note

The good news (or bad news) is that the default repo is provided by Oracle itself at oracle.com. It is a highly robust and high-bandwidth public server. Because of this, it is no longer strictly required to have a fully up-to-date local repository for network installs. You can get by with a small bootstrap image somewhere.

It is important to note that Oracle most likely logs access to its repo, so you should probably not be updating a score of machines from it unless you are confident of your licensing status.

It is possible to have a locally running repository server if you wish. Oracle provides a Repository Image download in the same place where it provides regular ISO image downloads for Solaris 11. If you do decide to run a repository yourself, the standard Service Management Facility (SMF) name for the IPS-specific service is svc:/application/pkg/system-repository. More details on how to do this is given in the Creating your own IPS repository and packages section in this chapter.

It is also possible to serve a local repository out using NFS and using file:/// style URLs to access it. However, Oracle recommends using the custom server at this time.

Repository URIs, also known as origins

A Solaris machine is configured to know about a particular repository, using a repository URI. This type of URI is sometimes referred to as an origin.

It is actually possible to access multiple, separate repositories via the same repository URI as long as they are provided by separate publishers. The standard publisher name used for the Solaris OS is "solaris", not "oracle".

An IPS client is configured to point to one or more publisher-repository combinations as a source for packages.

The standard Oracle URI for Solaris 11 is http://pkg.oracle.com/solaris/release.

To configure your system to know about it (even though it is already known), you can use the following command:

pkg set-publisher -g http://pkg.oracle.com/solaris/release solaris

This tells your system the URI to use for the publisher named solaris.

It should be noted that, while the address of an IPS repository is given with an http: or https: URL, the repository itself is not browsable with a web browser in the way you might expect. While the Oracle repository server does allow a web browser to connect and even query packages, there is no single link that says "here, download the package you want". For that, you have to use the appropriate client-side tool.

 

Package naming schemes


Packages are now named and referred to with a naming scheme that is somewhat similar to the SMF style naming introduced in Solaris 10.

Package references in the IPS format look like this:

pkg:/somebase/leafname@version,num-here
pkg://publisher/somebase/leafname@version,num-here

Specific examples of the previously mentioned IPS format are:

pkg:/runtime/java/jre-6@1.6.0.0-0.175.0.0.0.2.0
pkg://solaris/runtime/java/jre-6@1.6.0.0-0.175.0.0.0.2.0

Note that even though both the standard Solaris repository URL and the publisher component from the previously mentioned pkg FMRI have the string solaris in them, they are in completely different namespaces. Changing one would not affect the other.

The good news in this confusion is that, as with SMF, you can use short forms most of the time. For example, the following commands all give the same output:

  • pkg list pkg://solaris/runtime/java/jre-6

  • pkg list pkg:/runtime/java/jre-6

  • pkg list /runtime/java/jre-6

  • pkg list runtime/java/jre-6

  • pkg list jre-6

In summary, for most uses, you can ignore everything to the right of the @ symbol in the FMRI, and to the left of any forward slashes (/) in the FMRI, in order to get a short form name.

The bad news is that, sometimes, a short form that you might expect to work does not work. So, if an abbreviated form turns up nothing for a command, make sure to try the long form as well, and/or wildcards.

Tip

For most purposes, you can ignore the version part after the @ sign, even for long form purposes. The version part only really matters at times when you have to consider whether or not to update a package.

Understanding the quirks of pkg name references

Note that, at the current moment in time, Oracle uses package naming and version information inconsistently.

First of all, the same package may have two different long forms. Taking a package at random, let's examine the installed gzip package. The first two listings in the following output show it as /compress/gzip.

However, the full information on the package, via pkg info, gives a longer reference for the gzip package (calling it an FMRI), with the additions of /solaris and extra numbers in the version part of it. More details on version numbers will be given later on, in the next section.

Once again, there is good news and bad news. The bad news is that these inconsistencies exist when they shouldn't. The good news is that the pkg system is somewhat flexible about accepting any of the variants as input most of the time. So, reading the output becomes simpler, if you can train yourself as to which parts can be safely ignored.

A comparison between the different output types is as follows:

$ pkg search gzip
PACKAGE
pkg:/compress/gzip@1.3.5-0.175.0.0.0.2.537

$ pkg list gzip
NAME             VERSION
compress/gzip    1.3.5-0.175.0.0.0.2.537

$ pkg info gzip|grep FMRI
FMRI
pkg://solaris/compress/gzip@1.3.5,5.11-0.175.0.0.0.2.537:20111019T091246Z

As mentioned previously, the @ version parts can usually be ignored. So the thing of interest then becomes the //solaris component. This is an artifact of the network source of the package.

In this case, solaris is not the product or package name, but what Oracle chose to name the publisher of this set of packages in its repository. The full output of the pkg list gzip command would show this as the case.

99 percent of Solaris users will most likely be using only one publisher (solaris), so this component can usually be ignored.

Understanding pkg FMRI version fields

Note that the version indicator (the stuff to the right of the @ sign) must be strictly numeric at this time. This may cause problems if one tries to match some "freeware" programs up with this scheme, where letters (a, b, c, and d) are used as a part of the version number scheme as well.

As demonstrated earlier, the version part is unfortunately used inconsistently by Oracle at this time.

Some subcommands of the pkg command display it as @{release}-{branch}. For example:

pkg:/compress/gzip@1.3.5-0.175.0.0.0.2.537

For other subcommands, the same package may be displayed as @{release},{build}-{branch}. For example:

pkg://solaris/compress/gzip@1.3.5,5.11-0.175.0.0.0.2.537

For packages provided with Solaris itself, the {build} section (here, 5.11) is described by Oracle as being the version of the OS under which it was compiled, in this case, Solaris 11, or SunOS 5.11.

The 0.175 in Oracle Solaris packages represents a particular build number of Solaris branch that folks external to Oracle might think of as the subrelease identifier or perhaps similar to a patch level. All packages associated with that subrelease of Solaris seem to get a branch identifier mostly in the same numeric range. An earlier release of Solaris 11 seems to have mostly 0.151 as its associated branch identifier, whereas the 11/11 release seems to mostly have 0.175.0 as a branch identifier Solaris 11.1 uses 0.175.1.

 

Overview of package and patch installation


In this section we'll first summarize the old system of packages and patching before covering how they have changed.

The traditional methods

The old style of packages had only three basic pieces of information for a sysadmin to care about:

  • The package name; for example, SUNWcsr

  • The package description/name; for example, core binaries

  • The package version (and corresponding patch level)

All of this information was mostly contained in the package itself. To update it, you should either have installed an entirely new version of the package, or applied a patch, which would have updated one or more packages to different patch versions.

Prior to Solaris 11, patches were downloaded and applied manually unless you used a tool such as PCA or Sun's smpatch utility. Then, even if you applied the package, there was a slight disconnect between the package version and the patch level of a package.

Previously, new Sun/Oracle packages were copied from a DVD (physical or virtual image) and then manually applied. New vendor packages were similarly copied, or sometimes downloaded, unless you had a network-aware tool such as pkg-get, which is similar to Debian's apt-get.

Now, things are very different. Almost every facet mentioned previously has changed with Solaris's new pkg system.

New Solaris 11 patch and package installation methods

With IPS, new OS patches, packages, and even new minor OS versions are all handled via a unified mechanism. If there is a bugfix available for a package, it comes in the form of a newer version of that package. There are no more hidden patch levels internal to a package; variants of a particular version of a package generate a new branch of a version. It is no longer possible to have multiple patches applied to a single package; you always have only a single version of it, with a single, unique number-based identifier for it.

 

Practical examples of pkg command usage


This section of the chapter contains practical examples of how to use the pkg command. This section will not describe all options and usage methods as there are many possible options. Just the most useful are shown here, in detail.

Automatic package dependency use

It is important to note that, at times, requesting that a single package be installed results in multiple packages being installed.

Installation dry run

One of the new beneficial features is the ability to do an installation dry run. You can find out basic or detailed information on what the impact to your system will be. Given that requesting a single package install may trigger a cascade of 10, 20, or more required dependencies, having a dry run is useful for those systems where disk space or bandwidth may be at a premium.

The following command will tell you how many packages will be installed, how many services will be affected, and whether a backup Boot Environment will be created as a safety measure:

pkg install -n [pkg-list ...]

To also find out how much space will be used, we can add the -v option, as follows:

pkg install -nv pkg-list

Finding packages that you want

When you are looking for a particular piece of functionality, you first need to decide whether you wish to look by package name or by filename.

One of the commands you can use is the pkg search command.

It is crucial to note, however, that the pkg search command is multifaceted. It can search for more than just filenames. Among other things, it can also search for basenames of files as well as full paths. It can also search for dependencies of packages and descriptions of packages.

Because of this, if you only want to search for a filename, it is best to limit its search to only be on filenames or you may get much more output than you actually need. The best way to do this is given later in this chapter.

There is a shortcut for searching package names (rather than files) called the pkg list command. By default, it only works for already-installed packages. It gives additional information regarding whether a package is installed, not installed, or frozen, if you use the -a command option.

There is unfortunately some amount of overlap between the pkg search and pkg list subcommands. There is also some slight incompatibility between valid search strings for each of them, as mentioned in the following tip.

Sysadmins familiar with grep—the most common sysadmin search tool—will expect that, if your search pattern matches anything in a line, that line will show up. Searches in pkg are more similar to shell-level wildcarding. However, there are some inconsistencies even with that comparison.

Tip

pkg search and pkg list have a different set of matching rules from grep, and sometimes, they are slightly different even from each other.

To limit pkg search to only search package names, we must use the following modifier: pkg.fmri.

However, even using that, we will note the following inconsistency:

  • The pkg search pkg.fmri:/system/zones command fails to return a value

  • The pkg list /system/zones command correctly returns the full package FMRI

Unlike the filename search, it is best not to use a leading / for package name searches even though the actual search results contain one. That way, both tools will match similarly, albeit with slightly different output.

  • The pkg search pkg.fmri:system/zones command returns a match

  • The pkg list system/zones command returns a match

  • The pkg search pkg.fmri:zones command returns a match

  • The pkg list zones command returns a match

Searching by filename (pkg search)

Sometimes, you are looking for a tool and want to know what package to install to get it.

If you already know the key filename you are interested in and have it conveniently in a cut-and-paste buffer, you can use the following type of command:

pkg search -r /full/path/to/filename

Otherwise, you can use wildcards if needed. The most important thing is to start the filename search with a / character.

Note

The pkg search command searches multiple levels of information, such as filenames, package names, descriptions, and so on. If you want to avoid voluminous output, be sure to give it some hint of what layer of information you wish to search through.

The -r flag stands for "remote" and ensures that you search the remote listing of what is actually available rather than what you have already installed.

In contrast, if you have a particular local file and want to know the package name for it, you can search with the local flag, -l.

pkg search -l some-filename

Be warned that the pkg search command thinks it is "smart" and that it knows what you want better than you do. For people who are used to using grep, this can be counterintuitive.

If for example, you are trying to find the package containing the command /usr/bin/zonestat, the following will work:

  • pkg search zonestat

  • pkg search /usr/bin/zonestat

Unfortunately, neither of the following will work:

  • pkg search bin/zonestat

  • pkg search usr/bin/zonestat

Tip

It is important to note that even though normal pkg search output has no leading /, you are required to put one in your search string or a leading wildcard; otherwise, it will not return anything.

For filename searches, unlike other search types such as pkg name, you cannot use a multisegment match of the right-hand side. You must match the entire path exactly, or exactly the end part (the "basename" component), or else, you must use a wildcard. Wildcard styles that work are similar to the following:

  • pkg search '*bin/zonestat'

  • pkg search '*/zonestat'

If you wish to search for an exact match of the last component only, and if you wish to be a little more efficient than the last wildcard search shown, you can use a special indexed file search modifier, as shown in the following command:

pkg search basename:zonestat

Searching by package names (pkg search)

If you would like to avoid learning multiple ways to search for packages and don't care about knowing the installed status of a package, you can also search for package names using the pkg search command. However, this general search tool may pull up much more information related to a package than just its name. To avoid unnecessary output, add the modifier pkg.fmri: in front of your search token.

Generally speaking, pkg search pkg.fmri:NAME and pkg list -a NAME will match the same things. However, the output will be different. For one thing, pkg list output is usually formatted to fit in 80 columns, and so may be preferable in many cases.

Searching by package names (pkg list)

When searching for packages, a subcommand has been provided that can be easier than the general pkg search tool. Using pkg list leads to slightly cleaner output.

Remember that, as mentioned earlier, these commands do not behave like grep style searching.

Let's say you are looking for information about the following installed package: pkg:/developer/build/make.

All the following commands will work (although some may match additional packages):

  • pkg list /developer/build/make

  • pkg list developer/build/make

  • pkg list build/make

  • pkg list '*/make'

  • pkg list '*make*'

  • pkg list make

The following commands will not work to match pkg:/developer/build/make:

  • pkg list /build/make

  • pkg list 'make*'

So, as you can see, you need to match the whole line, except when you don't (ha ha). The important thing is to match whole words, and in particular, the rightmost words. Matching from the left-hand side does not work unless you use wildcards. Note that unlike filename searches, you can get away with doing multiple right side token matches with pkg names rather than rightmost only. That is to say that searching for "build/make" will match "pkg:/developer/build/make". In contrast, if you were attempting to do a filename search of a similar name that way, you would not find it.

If you wish to search for those packages that are available for install on the remote server, you can add the -a flag to pkg list. If using a search that has multiple matches, you should take note of which packages may be installed already.

pkg list -a editor/*

The command will tell you which editors you have installed support for, versus which additional ones may be available to download. In the following abbreviated output for this command, the dia package is not installed, the gedit package is already installed, and the ghex package is flagged as being "obsolete".

NAME (PUBLISHER)                       VERSION                    IFO
editor/diagram/dia                     0.97.1-0.175.0.0.0.0.0     ---
editor/gedit                           2.30.4-0.175.0.0.0.2.0     i--
editor/ghex                            2.24.0-0.175.0.0.0.0.0     --o

Listing files in a package

Let's say that you are considering removing a package but are not sure what this will affect. To find out which files will be removed by a pkg remove operation, you can use the following command:

pkg contents pkg/name

Alternatively, if you are curious about the contents of a package that has not yet been installed, you must add the -r flag to query the remote side for information.

Searching for installation groups

This procedure might be more commonly associated with installation time; however, sometimes (even after initial installation), you want to upgrade an existing installation from a "bare-bones" system to a more fully-fledged set of packages.

There are a few predefined collections of packages, somewhat akin to the old Core/Developer/Full package cluster choices. They are organized under the group subdivision of Oracle's FMRI listings for Solaris 11.

The ones that are currently visible are as follows:

  • group/system/solaris-auto-install (the default small system install)

  • group/system/solaris-desktop

  • group/system/solaris-large-server

  • group/system/solaris-small-server

There are a few different ways with which you can view which groups are available from the repo server. Any of the following commands will work; they just generate output in different formats:

  • pkgrepo list -s http://pkg.oracle.com/solaris/release \

    'group/system/*'

  • pkg info -r 'group/system/*' | grep Name

  • pkg list -a 'group/system/*'

Less-used pkg commands

There is an assortment of other day-to-day pkg subcommands that can be found in the manpage, some of which are avoid, unavoid, fix, revert, mediator, freeze, unfreeze, variant, and facet.

However, after 20 years of observing the problems generated by people using similar features on other systems, my recommendation to you is to avoid all of the previously mentioned advice entirely and stick to the basics. One of the worst things to have to debug as a sysadmin is attempting to repair a seemingly normal system on which you've forgotten that you did something clever a year or three back.

The one additional rarely used command I shall take time to mention is the history command.

pkg history [-l]

This command will give you a history of all pkg related activity on the machine timestamped. If you want to identify an activity at a particular time of interest, you can then use the -l flag to get more details.

 

Dealing with repositories


At the current point in time, there are not too many public IPS repositories running. That said, it is good to know how to query them. As briefly mentioned just now, the pkgrepo tool is the command to interact with repositories at the top level.

To find the repositories that your system is currently using, you can use the following command:

pkg publisher

You can then take the URI field from each of the output lines and run pkgrepo against it.

Official Oracle URIs for repositories are usually of the following format:

http://host.on.network/publisher/XXXXXXX

Once you have the URI of the repository you are interested in, you can query it for high-level information such as how many total packages are in the repository and the last time it was updated, as shown in the following output:

pkgrepo info -s http://pkg.oracle.com/solaris/release

This command will lead to the following output:

PUBLISHER    PACKAGES  STATUS    UPDATED
solaris      4292      online    2011-11-09T15:23:27.281209Z

Do note that, for some reason, Oracle has chosen the publisher in this case to be solaris, rather than oracle, so there is some unexpectedness in naming choices to get used to.

One advantage of using the pkgrepo command over the pkg command is that you can query packages from repos that are not currently configured as your current installation source.

pkgrepo list -s http://pkg.oracle.com/solaris/release \
'group/system/*'

While it is also possible to do a similar search with the pkg search -s http://... command, the output format of pkgrepo, in this case, is more readable, at least to me.

You can also use pkgrepo to get a list of potentially useful properties that the administrators of the repo may have set (somewhat akin to ZFS properties, using zfs get).

For example, the following command lets you know that there is a mirror of the Oracle repository available:

pkgrepo get -p all  -s http://pkg.oracle.com/solaris/release \
repository/mirrors

The preceding command will lead to the following output:

PUBLISHER  SECTION     PROPERTY  VALUE
solaris    repository  mirrors   (http://pkg-cdn1.oracle/com/solaris/release/)

Creating your own IPS repository and packages

At some point, you may wish to create your own IPS repository, particularly if you wish to have some custom scripts applied to automated installs. The old jumpstart "finish script" concept no longer exists; instead, hooks are given to load in custom services, which must be referenced through custom packages. Or, you may simply wish to have a local copy of the Solaris packages available.

Before you can create a package, you must first create a local repository. The old workflow of generating a single file.pkg to distribute is gone. The new tools are geared towards uploading files directly into a repository.

Creating a local repo

Happily, creating a simple repository with no access controls is relatively easy, so long as you follow the guidelines of always doing your packaging work on the same system that your repository lives on.

To make a repo in a designated directory, such as /var/pkgrepo, you just need to initialize the directory with the magic tool, as follows:

pkgrepo create /var/pkgrepo

This creates the directory, and a single master file inside it, called pkg5.repository.

If you plan on serving many files to many machines, Oracle recommends that you create a separate zfs filesystem for it, with access time (atime) turned off, for example:

zfs create somepool/repo
zfs set atime=off somepool/repo

Once you have created the basic top-level repo, you will want to create a publisher section. This can be done for your own company or for a copy of outside repositories, or both.

Copying the Oracle Solaris repository

The publisher designation for Solaris packages is not oracle.com but solaris. Therefore, if you plan to create a local copy of Solaris packages, you will effectively be setting up a mirror for the publisher named solaris.

Once you have created the top-level repository, use the pkgrecv command to mirror all packages in the Oracle repository to it. We can use the following command:

pkgrecv -s http://pkg.oracle.com/solaris/release -d /var/pkgrepo '*

Once that is done, you can override the default settings for where the system gets the Solaris packages by using the following command:

pkg set-publisher -g http://your.repo.url solaris
Creating your own company repository

Creating a namespace for your own company is easy. You simply need to set aside a designated publisher area for it, as shown in the following command:

pkgrepo add-publisher -s /var/pkgrepo "yourcompany.com"

Creating a package

Unlike the SVR4 pkg creation tools, you should normally dedicate an entire, untouched directory tree for your package creation efforts.

For clarity, let's presume a standard location for this that we'll call /stageroot.

Then, when you would normally install a program to /usr/local/bin/prog, for packaging purposes, it will get installed to /stageroot/usr/local/bin/prog.

Once you have assembled all the contents of your potential package under /stageroot, you must then generate a manifest for it with the following command:

pkgsend generate /stageroot >mypkg.mf

Next, you need to give the package an identity. This can be done by adding a single line, such as the following command, anywhere in the mypkg.mf file to designate its identity:

set name=pkg.fmri value=pkg://yourcompany.com/prog@1.0

Keep in mind that the value field can be as simple, or as complicated, as you like, within the boundaries of the IPS package naming scheme previously mentioned. For example, you may instead choose it to be pkg://yourcompany.com/utils/lowlevel/prog@1.0.1-75.

Uploading packages to the repository

Now that you have a complete manifest file and a staged tree of files for your package contents, you may integrate your package into your repository. This only takes one command, as follows:

pkgsend publish -s /var/pkgrepo -d /stageroot mypkg.mf

Tip

The pkgsend command will happily publish the exact same package collection multiple times, resulting in redundant packages in your repository. Be sure you have your versioning correct.

If the publish subcommand is completed successfully, you should be able to see the new version of your package, with the following command:

pkgrepo -s /var/pkgrepo list

Technically, it is quite possible to publish a package from normally installed program locations (that is to say, without a /stageroot prefix). Unfortunately, the IPS tools do not support the same functionality as the old pkgproto utility, which used to let you pass it a simple list of files and would then do the rest. This was allowed for relatively safe automated strategies such as:

find /usr/local -newer xyz | pkgproto >prog.template

Instead, with IPS, you would be required to hand-edit the manifest to have the needed paths in it, after which you could run the publish step without the -d option. However, this may lead to the creation of incomplete packages. Therefore, it is recommended that you use the method just explained, using the full but previously empty /stageroot.

Configuring machines to use your local repository

Once you can see your new packages successfully with a local test via pkgrepo, it is appropriate to open up access to the repository for other machines that need it.

The simplest way to do that is to share that directory via NFS and allow machines in your network to use your new repository. This can be done with the help of the following command:

pkg set-publisher -O /net/servername/var/pkgrepo yourcompany.com

Alternatively, you can set up a full IPS package server by configuring and enabling the application/pkg/server SMF service, as follows:

svccfg -s application/pkg/server setprop pkg/inst_root=/var/pkgrepo
svccfg -s application/pkg/server setprop pkg/readonly=true
//optionally, change the port number it runs on, with
svccfg -s application/pkg/server setprop pkg/port=(someportnum)

svcadm refresh application/pkg/server
svcadm enable application/pkg/server

Tip

If you have stuck with our example location of /var/pkgrepo, you will not actually have to mess around with svccfg properties. The default pkg/inst_root location is /var/pkgrepo. The default port is 80.

If you follow the SMF route, you will be able to configure clients with the following command:

pkg set-publisher -O http://your.server yourcompany.com

Once you have set a publisher entry for your custom repository, you should be able to run normal pkg commands on any client machines, thus:

pkg install prog

Or, you can use:

pkg install pkg://yourcompany.com/prog
 

Package updates and patching


As mentioned in the first half of this chapter, patching as a separate process no longer exists. To patch, you must upgrade to a newer version of the software package in question.

At a simple level, to update all packages on your system, if newer versions are available on your configured repository, you can just run the following command:

pkg update

If you are unsure whether you need to run an update or would like to know which packages need an update first, you can use the following command:

pkg list -u

If you want to downgrade a package, or similarly, do not want to upgrade it to the latest version, you can also call the update subcommand with a specific version of a package if it is available, for example:

pkg update somepkg@1.2.3

That being said, Solaris packages are usually locked into a particular set of revisions via a meta package called entire. It is normally not possible to manually install a package from a newer release of Solaris 11: one must first explicitly upgrade to a newer entire package. To see the available versions, use the following command

pkgrepo list -s (repo_url) entire

If you have chosen to previously set up your own repository for Solaris, (as mentioned in the first part of this chapter, by downloading your own Solaris Repository Image from Oracle), you might add your own local repository. As pkg update and pkg install will by default install the latest version of a package, if it finds that multiple are available, there is not much risk involved in having this available as a fallback.

Here's an example of configuring your own repository to be the primary source for Solaris packages, with the Oracle site as a backup:

pkg set-publisher -g http://your.site solaris
pkg set-publisher -m http://pkg.oracle.com/solaris/release solaris

Gaining access to the latest versions of Solaris packages (that is, patch updates) requires a support contract to get access to a private repository. Full details for this can be found at:

https://pkg-register.oracle.com/

 

Summary


The new IPS package tools are a drastic change for anyone used to the long-time standard of SVR4 style packages in Solaris. Where to get them has changed. How to get them has changed. How to install and uninstall them has changed. How to list and query them has changed. Even the style of naming packages has changed.

There are some similarities to popular Linux package management tools but there are differences as well. IPS is truly a system unto itself and requires some unique learning.

While it is possible to continue using the old tried-and-true SVR4 packaging for in-house software, being a Solaris 11 system administrator requires learning at least the basics covered in the first half of this chapter. While it may not be required to know how to set up and create your own packages, it is critical that the System Administrator understands the basics of IPS package administration.

For a quick reference of IPS commands, see the Appendix A, IPS Package Reference, part of this book.

About the Author
  • Philip P. Brown

    Philip P. Brown was introduced to computers at the early age of 10, by a Science teacher at St. Edmund's College, Ware, UK. He was awestruck by the phenomenal power of the ZX81's 3 MHz, Z80 CPU, and 1 K of RAM, showcasing the glory of 64 x 48 monochrome block graphics! The impressionable lad promptly went out and spent his life savings to acquire one of his very own, and then spent many hours keying in small BASIC programs such as "Ark Royal", a game where you land a block pretending to be an aircraft, on a bunch of lower blocks pretending to be an aircraft carrier. Heady stuff! When birthday money allowed expanding the ZX81 to an unbelievable 16 K of RAM, he also felt the need to acquire a patch cable to allow him to actually save programs to audio cassettes. Once this was deployed to the family cassette recorder, he was not seen or heard from for many months that followed. Phil's first exposure to Sun Microsystems was at U.C. Berkeley in 1989, as part of standard computer science classwork. Students were expected to do their classwork on diskless Sun 3/50 workstations running SunOS 4.1.1. During this time, he wrote his first serious freeware program, "kdrill", which at one time was part of the official X11 distribution, and remains in some Linux distros to this day. He eventually acquired a Sun workstation for personal use (with a disk and quarter-inch tape drive) and continued his home explorations, eventually transitioning from SunOS to Solaris, around Solaris 2.5.1. The principles of the original, pre-GPL freeware licenses prevalent in 1989 inspired Phil the most. Led by their example, he has contributed to an assortment of free software projects along the way. A little-known fact is that he is responsible for "MesaGL" morphing into the modern GLX/OpenGL implementation it is known for today. At the time, MesaGL was primarily an OpenGL workalike with a separate, non-X11 API, as author Brian Paul did not believe that it could function in a speed-effective way. In 2003, Phil wrote the first GLX integration proof-of-concept code, which convinced Brian to eventually commit to true GLX extension support. In 2002, Phil created pkg-get, inspired by Debian's apt-get utility, and started off CSW packaging. This, at last, brought the era of network-installed packages to Solaris. All major public Solaris package repositories prior to Solaris 11 still use pkg-get format catalogs for their software. In reality, Phil also had an impact on the existence of Solaris itself. In 2002, Sun Microsystems was on the road to canceling Solaris x86 as a product line. The community was outraged, and a vote in the old "solarisonintel" Yahoo! group resulted in six community representatives making the case for x86 to Sun. Phil was one of those six who eventually flew to Sun HQ to meet the head honchos and banish the forces of evil for a while. Phil's current hobbies include writing (both articles and code), riding motorcycles, reading historical fiction, and keeping his children amused. The Solaris-specific part of his website is http://www.bolthole.com/solaris. Most of his writing until this point has been done online, for free. His website has a particular wealth of Solaris information, and includes a mix of script writing, driver code, and Solaris sysadmin resources. As far as books go, he was only a prepublication reviewer for Solaris Systems Programming, Rich Teer. However, the first time any of his articles got published was in Rainbow magazine (a publication for the Tandy Color Computer) on page 138 of the May 1989 issue, under a column named Tools for Programming BASIC09 (http://ia700809.us.archive.org/26/items/rainbowmagazine-1989-05/The_Rainbow_Magazine_05_1989_text.pdf).

    Browse publications by this author