Tuesday Apr 29, 2014

New in 11.2 - pkg exact-install

As part of the platinum customer program we had some customer discussions regarding the need to 're-baseline' a machine - basically, the ability to return the installed set of package to a specified set (plus dependencies), removing any additional packages that may have been added by other administrators, and add any missing ones. After thinking about the problem for a while we came to the understanding that this approach also resolves some of the requests we've had for recursive uninstall - a feature IPS had prior to 11 FCS but proved about as useful as a chainsaw with two bars and no handles.

The new option is named 'exact-install' ( a name few liked, but no one could come up with a better one).

 It functions exactly as the install command does except that it behaves as if you're installing onto a blank system with respect to package tenancy - any installed packages not a direct or indirect dependent of the packages specified on the command line are removed.  Note that configuration files, etc. on remaining packages are left alone just as if you used pkg install.

This is also quite handy in maintaining and auditing configuration; if you publish a package that has dependencies on all desired packages and call it baseline,

pkg exact-install baseline

will remove any packages currently installed that are not require by the packages named in the baseline pkg.

Also,

pkg  exact-install -n baseline

will return an exit code of 4 (nothing to do) if all is well, but will specify work to be done with exit code 0 if someone has added or removed a package.



Wednesday Oct 24, 2012

Controlling server configurations with IPS

I recently received a customer question regarding how they best could control which packages and which versions were used on their production Solaris 11 servers.  They had considered pointing each server at its own software repository - a common initial approach.  A simpler method leverages one of dependency mechanisms we introduced with Solaris 11, but is not immediately obvious to most people.

Typically, most internal IT departments qualify particular versions for production use.  What this customer wanted to do was insure that their operations staff only installed internally qualified versions of Solaris on their servers.  The easiest way of doing this is to leverage the 'incorporate' type of dependency in a small package defined for each server type.  From the reference " Packaging and Delivering Software With the Image Packaging System in Oracle┬« Solaris 11.1":

 The incorporate dependency specifies that if the given package is installed, it must be at the given version, to the given version accuracy. For example, if the dependent FMRI has a version of 1.4.3, then no version less than 1.4.3 or greater than or equal to 1.4.4 satisfies the dependency. Version 1.4.3.7 does satisfy this example dependency. The common way to use incorporate dependencies is to put many of them in the same package to define a surface in the package version space that is compatible. Packages that contain such sets of incorporate dependencies are often called incorporations. Incorporations are typically used to define sets of software packages that are built together and are not separately versioned. The incorporate dependency is heavily used in Oracle Solaris to ensure
that compatible versions of software are installed together. An example incorporate dependency is:

depend type=incorporate fmri=pkg:/driver/network/ethernet/e1000g@0.5.11,5.11-0.175.0.0.0.2.1

So, to make sure only qualified versions are installed on a server, create a package that will be installed on the machines to be controlled.  This package will contain an incorporate dependency on the "entire" package, which controls the various components used to be build Solaris.  Every time a new version of Solaris has been qualified for production use, create a new version of this package specifying the new version of "entire" that was qualified.  Once this new control package is available in the repositories configured on the production server, the pkg update command will update that system to the specified version.  Unless a new version of the control package is made available, pkg update will report that no updates are available since no version of the control package can be installed that satisfies the incorporate constraint.

Note that if desired, the same package can be used to specify which packages must be present on the system by adding either "require" or "group" dependencies; the latter permits removal of some of the packages, the former does not.  More details on this can be found in either the section 5 pkg man page or the previously mentioned reference document.

This technique of using package dependencies to constrain system configuration leverages the SAT solver which is at the heart of IPS, and is basic to how we package Solaris itself.


Tuesday Nov 08, 2011

New York

I'm in New York this week, visiting Solaris customers and preparing for tomorrow's launch of Solaris 11.

As readers of my occasional blog may know, I've been working on IPS, the new packaging system used in Solaris 11.  We've recently finished the first version of the developer's guide for IPS.  For those folks interested in how to use IPS to deliver their own software, or just want to better understand how Solaris uses IPS, we hope the developer's guide will be useful reading.

You can find the new guide here.

For those of you interested in attending either the live webcast, or happen to be in the area and want to join us at Gotham Hall in New York City, the registration link is here.

<updated Dec 22, 2011 to fix now broken link to developer's guide>
About

An engineer's viewpoint on Solaris...

Search

Archives
« September 2015
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today