Solaris 11 Express awesome update

Solaris 11 Express was a transitional version from Solaris 10 to Solaris 11, post OpenSolaris 2009.06. Since it became publicly available everybody could see by that time how promising Solaris 11 would be, in many ways, part because of OpenSolaris community. Nowadays, one can better recognize what has been achieved up to Solaris 11.3, which by the time of this writing, has been around about 3 years. There's also an early announcement that Solaris 11.4 will be available by mid-2018, and according to planned EoLN (end-of-life notices) chances are that many desktop features will be further trimmed out, although GCC should be finally upgraded, hopefully to version greater than 7, let's see.

NOTE

Although by now Solaris 11 Express is officially obsolete and OpenSolaris has been left behind by Oracle, there are still community efforts to reestablish open-source variants, such as OpenIndiana and SmartOS, both running over a lagging-behind kernel called Illumos based on the original open-source version of the SunOS 5.11. But unfortunately, that kernel isn't as nearly modernized and optimized as Oracle's current closed-source product.

But in spite of all that, Solaris 11 Express major benefit was to early incorporate many Solaris advancements over Solaris 10 and still run under a legacy 32-bits platform! Yes! This is key, because despite the official business strategies and propaganda focusing on 64-bits mid and high-end big-iron, the truth is that there's a lot of legacy hardware can still be put to good service to the crowds on the 3rd world which are thriving to evolve and that do not count on a lot of money and other powerful and current resources.

The initial GA release of Solaris 11 Express didn't perform well, perhaps due to a lot of debugging hooks (code assertions) and conservative strategies, after all it was a key transitional milestone of Solaris. But fact is that those who had payed for a support contract could benefit from regular updates, called SRU (service release updates), which fixed many issues and greatly improved the system performance, including booting speed. By the last general SRU, SRU-13, things were noticeably better.

For instance, Solaris 11 Express SRU-13 rivals the speed of Solaris 11.3 GA and certainly runs faster than OpenIndiana 2017.04. In my opinion, a relative comparison among "recent" Solaris distros could be depicted by the following table:

But wait! Things could become even better because Engineered Systems for high-performance grid-computing started to see the light of the day and some of them were to be driven by Solaris 11 Express! This transitional version of Solaris then became so acclaimed and accredited that it deserved a additional and special SRU update targeted to Exalogic, the SRU-14. The SRU-14 could not be applied to ordinary systems because it had a special dependency associated to Exalogic Engineered System. Of course, there should be good reasons for such constrain. But fact is or at least seems to be that in general it runs amazingly well on ordinary systems too!
To enjoy all the power of SRU-14 on ordinary systems, some homework is necessary in order lift the impeding constrain embedded on the update.

NOTE

I'll assume that a support repository has already been made available by means described on procedures I've visited on the past, such as, the IPS repository update post. 

For instance, consider the following local support repository:

# zfs list -o mountpoint -H -r /depot
/depot
/depot/solaris
/depot/solaris/11e
/depot/solaris/11e/release
/depot/solaris/11e/sru-13
/depot/solaris/11e/sru-14

At first, an usual update attempt from SRU-13 to SRU-14 fail:

# pkg update --be-name solaris-11e-sru-14
Creating Plan ...
pkg update: No solution was found to satisfy constraints
Plan Creation: Package solver has not found a solution 
               to update to latest available versions.
               This may indicate an overly constrained 
               set of packages are installed.

latest incorporations:

  pkg://solaris/consolidation/gnome/gnome-incorporation@...151.0.1.14...
  pkg://solaris/consolidation/sfw/sfw-incorporation@...151.0.1.14...
  pkg://solaris/consolidation/osnet/osnet-incorporation@...151.0.1.14...
  pkg://solaris/entire@...151.0.1.14...

The following indicates why the system cannot update to the latest version:

    Reject:  pkg://solaris/entire@...151.0.1.14...
    Reason:  A version for 'require-any' dependency on
             pkg:/system/platform/exalogic/firstrun cannot be found

From the diagnostic messages above it's possible to realize that the SRU-14 was crafted to be applied as part of an automated installation of Solaris 11 Express target to the Exalogic Engineered System. The only constrain was a missing IPS package delivering a one-time-run SMF service performing initial configurations to Exalogic:

pkg:/system/platform/exalogic/firstrun.

NOTE

It's noticeable that in more recent releases, the description of the technique for tailoring a one-time-run IPS packages has evolved while it was completely lacking on Solaris 11 Express. Nevertheless, the simpler and straightforward instructions found on Solaris 11/11 Information Library is enough to perfectly work under Solaris 11 Express. Despite the evolution in documentation it still lacks a lot of clarity by sticking to do it that way instead of building knowledge, unfortunately. For this post I'll stay as much as possible with the clearer and simpler procedures which seem to still work equally well in terms of backward compatibility.

The major steps in creating the missing package are:

1. Creating a SMF service manifest for a dummy service.
2. Deploying the special IPS package unlocking SRU-14.

The above steps does nothing more than completing the set of requirements that unlock the SRU-14 installation. I'm not sure if I could create an "empty" package, that is, maybe the dummy SMF service is unneeded after all. Anyway, the difficulties rely just on the intrinsics of these steps themselves, not on the big picture. Let's visit each of the above steps in more detail:

1. Creating a SMF service manifest for a dummy service.

In recent versions of Solaris, this has been somewhat simplified by svcbundle(1M), but I won't rely on it at this moment. I prefer to know all the details and stay in control as much as possible.

# mkdir /tmp/sru-14-unlock
# cd !!$

# cat sru-14-unlock.xml

...
<?xml version="1.0" ?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">

<service_bundle name="sru-14-unlock" type="manifest">

  <service name="sru-14-unlock" type="service" version="1">

    <create_default_instance enabled="false"/>
    <single_instance/>

    <dependency name="multi_user" type="service" grouping="require_all" restart_on="none">
      <service_fmri value="svc:/milestone/multi-user:default"/>
    </dependency>

    <exec_method name="start"   type="method" exec=":true" timeout_seconds="60"/>
    <exec_method name="stop"    type="method" exec=":true" timeout_seconds="60"/>
    <exec_method name="refresh" type="method" exec=":true" timeout_seconds="60"/>

    <!-- must be defined at this exact place -->
    <property_group name="startd" type="framework">
      <propval name="duration" type="astring" value="transient"/>
    </property_group>

  </service>

</service_bundle>

# svccfg validate !!$
...

2. Deploying the special IPS package unlocking SRU-14.

This amounts to the creation and installation of the missing package.
What matters most is the package name, highlighted below.

# pwd
/tmp/sru-14-unlock

# mkdir -p ./prototype/lib/svc/manifest/site
# cp sru-14-unlock/sru-14-unlock.xml !!$
...

# cat sru-14-unlock.p5m
set \
  name=pkg.fmri \
  value=system/platform/exalogic/firstrun@1.0,5.11

set \
  name=pkg.summary \
  value="SRU-14 unlock."

set \
  name=pkg.description \
  value="Dummy package to unlock SRU-14 installation."
 
set \
  name=org.opensolaris.smf.fmri \
  value=svc:/sru-14-unlock

set \
  name=org.opensolaris.consolidation \
  value=userland

set \
  name=info.classification \
  value="org.opensolaris.category.2008:System/Packaging"
 
file \
  path=lib/svc/manifest/site/sru-14-unlock.xml \
  mode=0444 owner=root group=sys

NOTE

The extension .p5m most probably means package v5 manifest.

# pkglint !!$
Lint engine setup...
Starting lint run...
 
This package must be placed into a package repository, from which it can be subsequently installed. If the installation is to be part of an automated install (AI), then the repository must created on a location accessible to AI clients during the first boot. On this post I'm not using AI, so I'll just create the repository under /tmp which suffices to a one-time interactive install.

# pwd
/tmp/sru-14-unlock

# pkgrepo create ./repo
# pkgrepo add-publisher -s ./repo solaris

# pkgsend publish -d ./prototype -s ./repo sru-14-unlock.p5m
pkg://solaris/system/platform/exalogic/firstrun@1.0,5.11:...Z
PUBLISHED

# pkg list -af -g ./repo
NAME (PUBLISHER)                     VERSION    IFO
system/platform/exalogic/firstrun    1.0        ---

# pkg info -g ./repo firstrun
       Name: system/platform/exalogic/firstrun
    Summary: SRU-14 unlock.
Description: This dummy package...
      State: Not installed
  Publisher: solaris
    Version: 1.0
... Release: 5.11
     Branch: None
   ... Date: ...
       Size: 928.00 B
       FMRI: pkg://solaris/system/platform/exalogic/firstrun...

# pkg install -g ./repo -nv firstrun
           Packages to install:        1
     Estimated space available:   ... GB
Estimated space to be consumed: 14.31 MB
       Create boot environment:       No
Create backup boot environment:       No
          Rebuild boot archive:       No

Changed packages:
solaris
  system/platform/exalogic/firstrun
    None -> 1.0,5.11:...

# pkg install -g ./repo -v firstrun 
...
DOWNLOAD               PKGS       FILES    XFER (MB)
Completed               1/1         1/1      0.0/0.0

PHASE                                        ACTIONS
Install Phase                                    7/7

PHASE                                          ITEMS
Package State Update Phase                       1/1
Image State Update Phase                         2/2

PHASE                                          ITEMS
Reading Existing Index                           8/8
Indexing Packages                                1/1

# pkg info firstrun
       Name: system/platform/exalogic/firstrun
    Summary: SRU-14 unlock.
Description: Dummy package to unlock SRU-14 installation.
   Category: System/Packaging
      State: Installed
  Publisher: solaris
    Version: 1.0
...

# svcadm restart manifest-import

On the console one sees:
Loading smf(5) servicd descriptions: 1/1

# svcs -a |grep sru-14
disabled       19:36:52 svc:/sru-14-unlock:default

And voilà!

For a default text-installation of Solaris 11 Express with SRU-13 one gets:

# pkg update -nv --be-name solaris-11e-sru-14
            Packages to update:        15 
     Estimated space available:    ... GB
Estimated space to be consumed: 366.68 MB
       Create boot environment:       Yes
     Activate boot environment:       Yes
Create backup boot environment:        No 
          Rebuild boot archive:       Yes

Changed packages:

solaris
  SUNWcs
    0.5.11,5.11-0.151.0.1.13:... -> 0.5.11,5.11-0.151.0.1.14:...
  consolidation/gnome/gnome-incorporation
    0.5.11,5.11-0.151.0.1.13:... -> 0.5.11,5.11-0.151.0.1.14:...
  consolidation/osnet/osnet-incorporation
    0.5.11,5.11-0.151.0.1.13:... -> 0.5.11,5.11-0.151.0.1.14:...
  consolidation/sfw/sfw-incorporation
    0.5.11,5.11-0.151.0.1.13:... -> 0.5.11,5.11-0.151.0.1.14:...
  database/sqlite-3
    3.6.23,5.11-0.151.0.1.4:...  ->  3.7.5,5.11-0.151.0.1.14:...
  entire
    0.5.11,5.11-0.151.0.1.13:... -> 0.5.11,5.11-0.151.0.1.14:...
  image/library/libpng
    0.5.11,5.11-0.151.0.1:...    -> 0.5.11,5.11-0.151.0.1.14:...
  library/desktop/gtk2
    0.5.11,5.11-0.151.0.1:...    -> 0.5.11,5.11-0.151.0.1.14:...
  library/libtasn1
    0.5.11,5.11-0.151.0.1:...    -> 0.5.11,5.11-0.151.0.1.14:...
  runtime/python-26
    2.6.4,5.11-0.151.0.1:...     ->  2.6.4,5.11-0.151.0.1.14:...
  system/file-system/zfs
    0.5.11,5.11-0.151.0.1.11:... -> 0.5.11,5.11-0.151.0.1.14:...
  system/kernel
    0.5.11,5.11-0.151.0.1.13:... -> 0.5.11,5.11-0.151.0.1.14:...
  system/kernel/platform
    0.5.11,5.11-0.151.0.1.12:... -> 0.5.11,5.11-0.151.0.1.14:...
  system/library
    0.5.11,5.11-0.151.0.1.13:... -> 0.5.11,5.11-0.151.0.1.14:...
  system/network/nis
    0.5.11,5.11-0.151.0.1.8:...  -> 0.5.11,5.11-0.151.0.1.14:...

# pkg update --be-name solaris-11e-sru-14
            Packages to update:  15
       Create boot environment: Yes
Create backup boot environment:  No

DOWNLOAD               PKGS       FILES    XFER (MB)
Completed             15/15   1743/1743    41.8/41.8

PHASE                                        ACTIONS
Removal Phase                                  58/58
Install Phase                                  52/52
Update Phase                               4258/4258

PHASE                                          ITEMS
Package State Update Phase                     30/30
Package Cache Update Phase                     15/15
Image State Update Phase                         2/2

PHASE                                          ITEMS
Reading Existing Index                           8/8
Indexing Packages                              15/15

A clone of ... exists and has been updated and activated.
On the next boot the Boot Environment solaris-11e-sru-14 will be
mounted on '/'.  Reboot when ready to switch to this updated BE.

----------------------------------------------------------
NOTE: Please review release notes posted at:

http://www.oracle.com/pls/topic/lookup?ctx=E23824&id=SERNS
----------------------------------------------------------

# init 6

And this concludes this post.
 

VirtualBox VM autostart

The VirtualBox VM autostart feature first appeared in version 4.2.0. It's intended purpose is not only to automatically start selected virtual machines upon the host system startup, but to automatically and gracefully stop them upon the host system shutdown. But, of course, unless perhaps the VM is interactive, the stop part of the intent is fictional, specially on headless Solaris server systems. Thus for the stop part the feature acts like a placebo, at least for Solaris hosts.

I've been almost comfortable with headless startups for some time so I've never feel inclined to use the autostart, but now on version 5.1.18 I'm using VirtualBox frequently enough to justify taking some time to set it up and relax about manually starting (but not stopping!) VMs, now a tedious task.

There is a bare minimum documentation about this feature, as it's the case with many other features. In general, there are some mistakes and many omissions in the community provided documentation. Eventually it shall catch up but it would be wise not counting so much on it, anyway...

In a Solaris host environment the solution mechanism is elegant (yet unfortunately there some bugs requiring workarounds) as the autostart feature has been integrated/encapsulated into a SMF service:

Solaris 10 parallel zone patching

By a zoned Solaris 10 system I mean the existence of many non-global zones (NGZ).
There's perhaps a less known tunning that allows for parallel updating of multiple zones.
     
The num_proc setting is at /etc/patch/pdo.conf and described at pdo.conf(4).
The recommendation is to have num_proc equal to the on-line CPUs.
  
Thus, on a system with 4 online CPUs:
  
# psrinfo
0       on-line   since 10/18/2012 06:28:18
1       on-line   since 10/18/2012 06:28:18
2       on-line   since 10/18/2012 06:28:18
3       on-line   since 10/18/2012 06:28:18
 
A setting of 4 is recommended:
 
# cp -p /etc/patch/pdo.conf{,.0}
# vim /etc/patch/pdo.conf
# grep num_proc= /etc/patch/pdo.conf
# num_proc=
# num_proc=1 # default entry
num_proc=4
    

Patching the boot miniroot

Assume that the setup is according to Custom JumpStart framework setup.
Consider that no operations have happened yet from /install/Solaris_10/Tools.
The booting miniroot should be unpacked to a subdirectory, not a ZFS dataset.
  
IMPORTANT
It can be considered best practice to patch the boot miniroot as soon as possible.
It's known to be necessary when performing a flash install of an updated ZFS-root image.
/install/Solaris_10/Tools should already exist as per the previous assumptions.
For correct patchadd behavior patch 119255-86 / 119254-86 must be installed.
  
The whole operation is as follows:
  
# mkdir /patch/miniroot
# /boot/solaris/bin/root_archive
    unpackmedia /install /patch/miniroot 

# cp -p /patch/miniroot/sbin/rc2{,.0}
# cp -p /patch/miniroot/sbin/sulogin{,.0}
  
# smpatch download -d /tmp -f -i 147441
147441-23 has been validated.
  

# patchadd -C /patch/miniroot /tmp/147441-23 

Patch 147441-23 has been successfully installed.
See /patch/miniroot/var/sadm/patch/147441-23/log for details
Executing postpatch script...
Patch packages installed:
  SUNWbtool
  SUNWcakr
  SUNWckr
  SUNWcsl
  SUNWcslr
  SUNWcsr
  SUNWcsu
  SUNWesu
  SUNWgss
  SUNWmdb
  SUNWmdbr
  SUNWmptsas
  SUNWnfsckr
  SUNWnfscr
  SUNWnfscu
  SUNWnfsskr
  SUNWnfssu
  SUNWos86r
  SUNWxvmpv
  SUNWzfskr
  SUNWzfsr
  SUNWzfsu
  SUNWzoneu
  

# export SVCCFG_REPOSITORY=/patch/miniroot/etc/svc/repository.db
  
# svccfg -s system/manifest-import setprop start/exec = :true
# svccfg -s system/filesystem/usr setprop start/exec = :true
# svccfg -s system/identity:node setprop start/exec = :true
# svccfg -s system/device/local setprop start/exec = :true
# svccfg -s network/loopback:default setprop start/exec = :true
# svccfg -s network/physical:default setprop start/exec = :true
# svccfg -s milestone/multi-user setprop start/exec = :true
  
# mv /patch/miniroot/sbin/rc2{.0,}
# mv /patch/miniroot/sbin/sulogin{.0,}

# /boot/solaris/bin/root_archive
    packmedia /install /patch/miniroot

Now, other boot and/or JumpStart servers can be more easily updated.
Assuming that the updated server js-01 can (rw) mount js-02:/install:
  

js-01 # cd /install
js-01 # find boot Solaris_10/Tools/Boot |
          cpio -pdum /net/js-02/install

   

Custom JumpStart flash install

Assume that the setup is according to Custom JumpStart framework setup.
Consider 192.168.0.12 as the IP address of the js-01 X86 Custom JumpStart server.
 
Solaris have always addressed the enterprise needs.
Automated installation is just another example of that.
All that's needed is already included built-in.
 
Solaris is continuously evolving and since Solaris 10 U9, support for Flash Archives have been incorporated to ZFS-root-based Custom JumpStart installations.
 
Compared to the conventional process, the flash install option is simpler.
The main benefit is that a fully updated system can be deployed in one step.
The conventional process requires a time-consuming post-installation update.
Since Solaris has many updates, currently U10 for Solaris 10, the catch-up is long.
Nonetheless, the conventional process is still invaluable to get to consistent images.
 
Another benefit is that it can be part of a disaster recovery procedure for a global zone (GZ).
This assumes, of course, that the non-global zones are backed up by other means.
My preferred NGZ backup option is through ZFS snapshots and streams.

The initial step is, of course, to create a Flash Archive base installation image.
As mentioned, the conventional Custom JumpStart can be used as a starting point.
In fact, I'd say that, for consistency, it's the preferred way to start creating an image.
  
Don't create NGZs for applications yet as they'll be carried out on a later phase.
  
Next, fully update the system.
Begin by applying the most recent patchset for the bulk part.
Wrap up by taking advantage of smpatch for a more fine grained control. 
Use no alternate BEs (ABE) as they aren't supported in the image.
   
Perform some clean-up before creating the image. 
Verify /var/tmp and possibly delete /var/run and inactive BEs (boot environments).
  
Finally, archive the image to where it can be used by Custom JumpStart.
 

js-01:~ # zfs create
            -o mountpoint=/images
            -o sharenfs='rw=base-01,ro=...' ...

js-01:~ # chmod 1777 /images 
 
base-01:~ # mount -F lofs -o nosub / /mnt
base-01:~ # [ -d /mnt/var/run ] && rm -r /mnt/var/run
base-01:~ # ls -la /mnt/var
base-01:~ # umount /mnt
base-01:~ # rm -r /var/tmp/...
base-01:~ # ludelete -R
 
base-01:~ # flarcreate
              -S -n base-01 /net/js-01/images/base-01.flar
 

js-01:~ # chown root:root /images/base-01.flar
  
If not going to use a Flash Archive file anytime soon, consider compressing it.
To achieve the highest compression ratio 7za is the answer.
 

# 7za a base-01{,.flar}

# [ -f base-01.7z ] && rm base-01.flar
  
A few adjustments to the Custom JumpStart profile and rules are needed as follows:
  

# cat rules

# 
# keyword value   begin-script  profile          finish-script
# ------- ------- ------------- ---------------- ---------------
  karch   i86pc   -             profile_x86_flar finish_x86_flar

# cat profile_x86_flar
#
# keyword               value
# --------------------  -------------------------------------
  install_type          flash_install
  archive_location      nfs 192.168.0.12:/images/base-01.flar
  partitioning          explicit
  pool                  rpool auto auto auto mirror any any

# cat finish_x86_flar
#!/bin/sh
  
BASE=/a
BIN=$BASE/usr/bin
SBIN=$BASE/usr/sbin

#................................................................
# X86 fix - The boot device isn't where Solaris was installed
  
$BIN/sync
$SBIN/reboot
   
There's still one important problem: patching the boot miniroot.
Due to the natural evolution of ZFS, the miniroot must be updated accordingly.
The original booting miniroot can't handle the recent ZFS updates on a fully updated image.
   

Custom JumpStart conveniences

Assume that the setup is according to Custom JumpStart framework installation.
Needless to say how convenient is to add essential packages and patches at install time.
 
The most critical patch is the one related to "Update Connection System Client".
Without it, a Solaris 10 update 10 system cannot get further updates.
See Solaris 10 smpatch configuration for more information.

 

# smpatch download -d /patch -f -i 121119  (or 121118 for SPARC) 
121119-20 has been validated.
# unzip -q /patch/121119-20.zip -d /patch
# rm /patch/121119-20.zip
    
It may be worthy to immediately make sure "Live Upgrade" is up-to-date.

# smpatch download -d /patch -f -i 121431  (or 121430 for SPARC)
121431-84 has been validated.
# unzip -q /patch/121431-84.zip -d /patch
# rm /patch/121431-84.zip
  
You can do the same for the "Common Agent Container (cacao)":
123896 for X86 or 123893 for SPARC.
   
For options and architectures of third-party general purpose packages to add go to:
 

• Sunfreeware (specially Solaris 10 Companion CD/DVD Project)
• Blastwave

 
To me, the most essential of such packages to put (uncompressed) in /package are:
 

• VIM (SFWncur + SFWvim)
• Screen (SFWscrn) 

  
If you have a support contract then you'll be able to add even more.
For example, to add STB (Service Tools Bundle):
 

• Download it from the My Oracle Support;
• Extract it to a temporary directory;
• Copy install_stb.sh to /jumpstart/extras
• Make sure to make it executable (a+x).

  

Solaris 10 update cache cleanup

To cleanup the update cache of patchsvr and/or smpatch perform the following:
    

• Stop the patch server:
  
  # patchsvr stop
      
• On the patch server:
  
  # cd /var/sadm/spool
  # rm patchsvr/*
  # rm cache/xml/*
  # rm cache/updatemanager/analysis.results/*
  # rm cache/entitlement/*
  # rm cache/Database/*
  # rm cache/collection/*
  # rm cache/category/*
  # rm cache/*detectors*
      
• On the patch client:
  
  # cd /var/sadm/spool
  # rm cache/xml/*
  # rm cache/updatemanager/analysis.results/*
  # rm cache/entitlement/*
  # rm cache/Database/*
  # rm cache/*detectors*
    
• Start the patch server:
  
  # patchsvr start
      
• Rebuild server cache first, then the client's:
  (run the following command on the server, then on the client)
  
  # smpatch analyze 

   

Solaris 10 registration

Registration with an adequate MOS credential is important to get patches.
Particularly, smpatch and patchsvr won't work if the system is not registered.
Make sure to have a properly configured Internet connection and DNS resolution.
There are many hard to pinpoint possibilities that may cause a registration attempt to fail.
For the latest details check My Oracle Support website and consider the following hints:
     

• Make sure to have at least, patches:
  (with something such as $ showrev -p | grep 99999 | cut -c 1-17)
  SPARC: 121118-19, 123005-09, 124171-08, 123630-04, 123893-25
  X86:   121119-19, 123006-09, 124187-08, 123631-04, 123896-25
       
• Install required patches, beginning by the Common Agent Container:
  
  # cacaoadm stop
  # patchadd 123896-XX
  # cacaoadm start
  # patchadd 121119-XX
  # patchadd 123006-XX
  ...
        
•  Make sure registration database is clean:
  
  # cacaoadm stop
  # rm /var/scn/persistence/SCN*
  # /usr/lib/cc-ccr/bin/eraseCCRRepository
  # cacaoadm start
      
• Edit registration profile, setting MOS credentials and proxy information only:
  
  # REG_FILE=RegistrationProfile.properties
  # cp /usr/lib/breg/data/$REG_FILE /tmp
  # vi /tmp/$REG_FILE
     
• Perform the registration:
  
  # sconadm proxy -r /tmp/$REG_FILE
  # sconadm register -a -r /tmp/$REG_FILE
    
• Adjust the patch source (and proxy, if needed):
  
  # smpatch set patchpro.patch.source=https://updates.oracle.com/
  # smpatch set patchpro.proxy.host=proxy-1
  # smpatch set patchpro.proxy.port=8080
  # smaptch set patchpro.proxy.user
  # smpatch set patchpro.proxy.passwd
     
• For testing, attempt an update operation.

   
IMPORTANT
As for Solaris 10 Update 11 (aka 1/13) sconadm has been removed.
To register such new systems a cool hack has been recently indisclosed.
Perhaps (I haven't tested) it may help register other boxes too (U9 and U10).

s10-u10# cd /var/cc-ccr
s10-u10# tar cvf /tmp/cc-ccr.tar .
s10-u10# scp /tmp/cc-ccr.tar s10-u11:/tmp
s10-u10# rm -r /tmp/cc-ccr.tar

s10-u11# cd /var/cc-ccr
s10-u11# tar /tmp/cc-ccr.tar
s10-u11# rm -r /tmp/cc-ccr.tar

Note: Unfortunately patchsvr may not work either due to latest U10 Tomcat updates.
     

Solaris 10 patchsvr configuration

The Sun Update Connection Proxy is commonly called "Patch Server" or LPS.
To take advantage of patchsvr make sure you have at least patch 119788-11 / 119789-11.

IMPORTANT 
Don't ever install patch 148150-03 or newer on the patchsvr host!
The patch will remove Tomcat 4 which will break patchsvr.
 
Optionally, point the repository cache to a different location:

# zfs create -o mountpoint=/patchsvr data/patchsvr

# patchsvr setup -c /patchsvr

 
Make sure the patch source URL is up-to-date:

# patchsvr setup -p https://updates.oracle.com/
    
If behind a proxy/firewall:

# patchsvr setup -x proxy-1:8080

# (umask 77; vi /tmp/proxy_password)

# patchsvr setup -u proxy_user -s /tmp/proxy_password

# rm /tmp/proxy_password
   
Check configurations:

# patchsvr setup -l

  
Start and enable boot-time startup:

# patchsvr start

# patchsvr enable
  
Check that only one instance is running, otherwise kill them all and start over.

# /usr/ucb/ps -auxwww | grep java | grep ccr

...
   
On the patchsvr machine, also configure smpatch to point directly to Oracle.
That is, use patchpro.patch.source=https://updates.oracle.com/

If you ever need to clear the cache due to client reconfiguration:
 
# patchsvr stop
# cd /var/sadm/spool
# rm patchsvr/*        (or the actual path to repository cache, if changed)
# rm cache/xml/*
# rm cache/updatemanager/analysis.results/*
# rm cache/entitlement/*
# rm cache/Database/*
# rm cache/collection/*
# rm cache/category/*
# rm cache/*detectors*
  

Solaris 10 patchsvr

The patchsvr is an important complement to smpatch.
It's not a repository of patches, but a centralized update proxy and site local cache.
The benefits are:
  

• Patches are downloaded and cached so later requests are served much faster.
• The cache also preserves the Internet uplink (no redundant downloads).
• Internal servers never access the Internet (they entirely rely on patchsvr).
• It's built-in with few requirements, but disk space for the downloaded patches.
• It can serve both SPARC and X86 architectures.
   

On large companies, a chain of patchsvr servers can be set up for distribution.
There's no control of multiple patch versions or point-in-time patches.
   
IMPORTANT
Unfortunately patchsvr is broken since one latest Tomcat update in Solaris 10 U10.
At least by the release of Solaris 10 U11 no solution is available.
   

Live Upgrade together with smpatch

Integration of smpatch and liveupgrade is a powerful and great combination.
It eliminates risks and reduces downtime inherent to the patching activity.
Together with ZFS, smpatch and liveupgrade turn it all peace-of-cake.
Going straight, while the system is fully operational:

• Make sure you have the latest LU patch (121430 for SPARC, 121431 for x86);
   
  # smpatch download -t -f -i 121430 | head
   
  Note the latest level (81 in this example) printed on the first line and use it next:
   
  # smpatch download -i 121430-81
  # smpatch add -i 121430-81
    
•  Prepare /etc/lu/synclist accordingly; see synclist(4).
   
• Create a new alternate boot environment (ABE);
  (if only the initial unamed BE exists, add the -c option to give it a name)
   
  # lucreate -n be-2012-may-u1
  # lustatus
       
• Perform off-line patching operations to this new ABE;
  (the undocumented -C option works around a bug: operation not fully off-line)
   
  # smpatch analyze > /tmp/be-2012-may-u1.analyze
  # smpatch update -b be-2012-may-u1
      -C patchpro.install.types=
         rebootimmediate:rebootafter:
         reconfigimmediate:reconfigafter:
         standard:interactive:singleuser
    
• Wait until the next reboot window to the activated and updated ABE.
   
  # init 6
    
• In case of any problems with the new BE, go back to the previous one:
   
  # luactivate -n be-2012-april-u1
    

Keep out of the way with sub-datasets related to /var.
Don't create sub-datasets of zones' datasets or liveupgrade will fail.

Single patch installation via smpatch

One useful operation out of many others is the handling of individual patches.
Say you just want to install the 147441-23 kernel patch.
You just need to:

# smpatch download -t -i 147441-23 > /tmp/README-147441-23
# smpatch download -i 147441-23
# smpatch add -i 147441-23

Patches that are marked interactive must be installed this way.
Until recently, this was the case for Live Upgrade own patches.
 

Update life-cycle with smpatch

The most basic usage pattern of smpatch comprises the following tasks:

• Identify all patches that are needed to fully update the system.
   
  $ smpatch analyze
   
• Apply all the patches needed to fully update the system.
   
  # smpatch update
   
• Gracefully reboot the system.
   
  # init 6

The analysis can be saved for further information or later reference.
The default allows the immediate installation of patches with no special handling.
Reboots are frequent due to the nature of many patches, such as kernel and drivers.
     

Introducing the smpatch update tool

I think that the regularly updated patchsets are great to update baseline images.
But in my opinion, smpatch is the best tool to maintain Solaris 10 up to date.
It's simple to use yet very powerful in getting the job done.
It's built-in and easy to configure as well.

Here's a few goodies:

• Update level analysis;
• Download specific patches;
• Perform partial or full updates;
• Target a specific boot-environment (BE);
• Update Solaris 10 zones in Solaris 11 system.

Furthermore, it's possible to point to a local update proxy/cache of patches.
This offloads the Internet link by avoiding redundant downloads.
Of course, it speeds up the update process as well.
This mode doesn't require system registration.