Support Repository Updates and the Solaris 11.4 patching model: SRUs, CPUs, and checking what is installed

What it is

Oracle Solaris 11.4 has no separate "patch" mechanism the way Solaris 10 did: applying updates is the same IPS operation as installing any other package, and the entire installed software set is tracked by one incorporation package, entire, whose version identifies exactly which update level is installed. Oracle ships fixes as Support Repository Updates (SRUs) in the support repository, approximately monthly. Every third SRU is also a Critical Patch Update (CPU) SRU, with content more focused on security fixes: "CPU" is Oracle's quarterly security release, and on Solaris an SRU is the vehicle that delivers it.

Why it matters

Because updates flow through the ordinary pkg update path, the boot-environment safety net described elsewhere in this series (a new BE per update, rollback with beadm activate) applies to security patching automatically — an agent does not need a separate patch-rollback procedure. Knowing the exact SRU level installed is also the fastest way to answer whether a host is missing a specific fix, since Oracle indexes its SRU release notes by SRU number.

How to apply

• Check the currently installed update level: pkg info entire reports the version of the entire incorporation, and an SRU "contains only one version of pkg:/entire" — so that version string is the update-level fingerprint of the host. On 11.4 the SRU number is the field after 11.4. in the branch: entire@11.4-11.4.0.0.1.15.0 is the 11.4 GA release, 11.4-11.4.1.0.1.4.0 is SRU 1; the Summary line also names the level in readable form. pkg list -af entire shows which levels the configured publishers offer, and pkg update entire@<version> targets one specific SRU instead of the newest.
• Access fixes online at https://pkg.oracle.com/solaris/support/ (needs a support contract and an installed certificate and key), or download an SRU from My Oracle Support into a local repository for hosts without internet access.
• Apply the update the same way as any other package operation: pkg update against a publisher pointed at the support repository (or a local mirror of it) — see the IPS article in this series for the resulting boot-environment behaviour.
• Treat SRUs as cumulative in content: each one "includes all fixes and enhancements that were delivered by previously released SRUs," so a host can update straight to the newest SRU without stepping through the intermediate ones. What is not cumulative is the downloadable SRU repository: it "include[s] only packages for that SRU" and "does not contain any other SRUs," so a local mirror must be built on the full base repository, and Oracle recommends integrating each SRU into it monthly.
• Know Oracle's lifecycle stages: new fixes and security updates come only during Premier Support and, for an additional fee, Extended Support; Sustaining Support gives access to pre-existing fixes only. Check Oracle's lifetime-support documents for Solaris 11.4's current dates rather than a remembered year.

Pitfalls

• Assuming pkg update silently pulls security fixes regardless of publisher configuration: if the configured publisher is the public release repository (http://pkg.oracle.com/solaris/release/, updated at GA releases plus some FOSS updates) rather than the support repository, pkg update will not see SRU content at all.
• Treating "Solaris 11.4" as a single, static target for patch-currency reporting: within one major release, the SRU level is the meaningful measure, not the release name.