Oracle Solaris 11: First Look

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.

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.

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:

Unfortunately, neither of the following will work:

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:

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

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.

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):

The following commands will not work to match pkg:/developer/build/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

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.

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:

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:

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.

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

pkg set-publisher -g http://your.repo.url solaris

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

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.

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

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.

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

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