Solaris Patch Update

Gerry Haskins
Director, Software Patch Services
Software Product Engineering
28th July 2009
1
Contents
• Recommended Patching Strategy
> Patching Strategy Consideration
> Recommended Patching Strategy
> Patching Best Practices

2
Contents
• Background Information
> Solaris Fundamentals
> Dynamic tension
> Solaris Updates
> Kernel patch functional “stepping stones” and smaller interim patches
> “SplitGate” process improvements and benefits
> Deferred Activation Patching and Live Upgrade
> Problematic Solaris 10 patches
> Bug Fix Process Overview
> Patch Testing Overview
> Patch Quality Metrics

3
Contents
• News
> Zones patching performance improvements
> Other patch utility improvements
> Stricter Patch Entitlement implementation
> Solaris 8 Vintage Patch Service
> Patch milestones over the next 6 months
> Patch Education Resources
> Patching Tips
> Patching Tools
> Patching Services
> The next generation: Image Packaging System
> How can we further improve your patching experience ?

4
Recommended Patching Strategy

5
 Patching Strategy Considerations
• Typical objective is to maximize production system availability by optimizing
proactive maintenance to prevent issues
> Change implies risk. But minimizing risk is not as simple as minimizing
change. Need to consider best tested and best quality baselines upon
which to standardize deployments to minimize risk:
– Solaris Updates are intensely tested by many teams across Sun and so
provide a good baseline upon which to standardize deployments.

6
Patching Strategy Considerations
– In comparison, “Dim Sum” patching (e.g. picking a Kernel patch which is 6
months old, a libc patch which is 18 months old, and an LDAP patch which is
a week old) may result in a software combination which has never been
tested before as a set. However, rigorous processes to ensure patch
dependencies are correctly defined, coupled with the patch test and
verification procedure means that issues with “Dim Sum” patching are rare.
> A good customer test environment which accurately replicates the
production environment and includes good functional test coverage and
peak load testing is the best way to minimize risk

7
Patching Strategy Considerations
• Why not apply all patches ?
> Applying all patches is a perfectly reasonable strategy. However, Jim “Jimmo”
Moore, Solaris Sustaining Director EMEA, states that almost all issues reported
more than 18 months after a Solaris release has shipped are corner cases. That
is, they are mostly issues which only occur in highly specific configurations. One
can argue that the quantity of change included in Solaris 10 Updates resets the
18 month clock to some extent.

8
Patching Strategy Considerations
> Although code changes in patches go through an intensive review, verification,
and test process, there's still a finite risk of a fix introducing regressions in
specific configurations
> Since change implies risk, it's debatable whether applying all corner case fixes
for other customers' configurations is the optimal system maintenance strategy
to minimize risk and maximize system availability
> Again, the better the customer's test environment, and the more closely it
matches the production environment, the better risk can be mitigated for any
chosen patch strategy

9
 Patching Strategy Considerations
• What about timing of patch application ?
> Patches are intensely tested, but issues specific to certain configurations can still
occasionally slip through.
> Some customers like to wait until a patch has been released for a period of time
– e.g. 30 days – before applying it unless it fixes a urgent security issue.
Analysis of the time between patch release and the withdrawal of problematic
patches shows little correlation to any specific “sweet spot”, although serious
pervasive issues are usually found within 10 days of release.

10
Patching Strategy Considerations
> Sun releases over 5,750 patches every year, for Solaris 8, 9, and 10, SPARC
and x86, Middleware products, Developer products, Storage products, etc. Of
those, approximately 65 are withdrawn after release each year due to serious
issues. A patch is withdrawn if it does more harm than good to most customers.
For corner case issues, information may be added to the patch READMEs. For
Security, Data Corruption, or System Availability issues, a Sun Alert will also be
issued.

11
Recommended Patching Strategy
• Upgrade to a recent Solaris 10 Update release during your next major
maintenance window
> Each Solaris Update is intensely tested and so provides a good quality baseline.
> For customers whose change control procedures make it difficult to upgrade, a
patch bundle is made available for each Solaris Update starting with Solaris 10
5/08 which will patch pre-existing packages to the same software level as the
corresponding Solaris Update. The only difference is that the patch bundle
doesn't include any new packages included in the Solaris Update, which may be
required to leverage some new features. However, all Zones and ZFS
functionality, for example, are entirely contained within patches.

12
 Recommended Patching Strategy
• Keep as up to date as possible with the contents of the Sun Alert patch
cluster in between major maintenance windows
> The Sun Alert cluster provides the minimum amount of change required to get all
Solaris patches which fix Security, Data Corruption, and System Availability
issues. The Recommended Patch Cluster and EIS patch set are both supersets
of this and are reasonable alternatives.
• Keep as up to date as possible with Firmware patches
• Apply any additional patches to address issues specific to your environment

13
Patching Best Practice
• Always install the latest patch and package utility patches first to help
ensure correct patch application.
• Use Live Upgrade to patch or upgrade an inactive boot environment.
LU avoids much of the risk and downtime associated with patching the
live boot environment and provides a simple roll-back mechanism.
> The “Solaris 10 Live Upgrade Zones Starter Patch Bundle” on SunSolve provides
the prerequisite patches to start using LU in a Zones on UFS environment for
systems below Solaris 10 8/07 (Update 4). Infodoc 206844,
http://sunsolve.sun.com/search/document.do?assetkey=1-9-72099-1provides
further information on Live Upgrade patches.

14
Patching Best Practice
• Conduct pre-deployment testing in a test environment which accurately
replicates the production environment and includes good functional test
coverage and peak load testing. This is the best way to minimize risk.
> While Sun tests all software prior to release, it's impossible to test all possible
configuration permutations, including 3rd party and home grown applications, etc.
Therefore, testing in the specific customer environment prior to live deployment is
recommended.

15
Background Information

Solaris Fundamentals – why things

are the way they are

Key Solaris 10 patching issues

resolved

16
Solaris Fundamentals
• There is effectively a single customer visible code branch for each Solaris
Named Release.
• That is, there is one set of patches for all Solaris 8 releases, another set of
patches for all Solaris 9 releases, and another set of patches for all Solaris
10 releases.
• This means that the same Solaris 10 patches can be applied to all systems
running Solaris 10, irrespective of which Solaris 10 Update release is
installed on them. This simplifies System Administration and helps provide
a more homogeneous OS environment.

17
Solaris Fundamentals
• All code changes, e.g. for a new Solaris 10 bug fix, are putback to the tip of
the Solaris 10 source tree. The resultant patch can be applied to all
preceding Solaris 10 releases. It will also be pre-applied into future Solaris
10 Update release images.
• Therefore each Solaris Update contains all bug fixes which were available
when the Update was built. This, each Solaris Update is successively better
quality
• This is what enables Sun to provide ultra long-term support for each release
of Solaris at reasonable cost to Sun.

18
Solaris Fundamentals
• Since there is effectively a single customer visible source code branch for
each Solaris named release, any change to pre-existing packages will be
released as patches.

19
Dynamic tension
• There's dynamic tension between the desire to provide customers with cool
new features such as Zones enhancements, ZFS, NewBoot, Secure By
Default, Trusted eXtensions, iSCSI, OPL and other hardware support in
Solaris 10 Updates, and the desire to provide production customers with
rock solid stability. Getting the balance correct is tricky.
• New features must not introduce regressions in pre-existing functionality.
• The scope of features allowed into Solaris 10 Update releases is larger than
what was allowed into Solaris 8 or 9 Updates.

20
Dynamic tension
• The resultant issues have been solved through innovative solutions such as
the “SplitGate” source code gate management process, Live Upgrade, and
Deferred Activation Patching.
• In particular, Zones introduced a significant amount of complexity to the
patching and upgrade processes, including performance issues which are
being addressed.
• From Solaris 10 8/07 (Update 4) onwards, and for earlier releases patched
up to this level, many of the major patching issues have been resolved.

21
Solaris Fundamentals
• New features are introduced in each Solaris 10 Update release. The
Update releases are built from all available patches plus any new packages
introduced.
• A large new feature may introduce new packages which are typically only
available by installing or upgrading to a Solaris 10 Update release which
includes the new packages. But all features will make at least some change
to pre-existing packages (e.g. hooks for the feature).
• Some features, such as Zones and ZFS functionality, are completely
contained within patches, and hence any Solaris 10 system can utilize the
latest Zones and ZFS functionality by installing the appropriate patches.

22
Solaris Fundamentals
• So some Solaris 10 patches may include new feature code as well as bug
fixes. New features are almost always switched off by default in patches.
NewBoot is a notable exception. The rule is to avoid surprises.
• The scope of new features is likely to diminish in future Solaris 10 Updates
which will reduce the risk of introducing functional regressions.

23
Solaris Fundamentals
• Where multiple code changes intersect, they will typically be included in the
same patch. This can result in large Kernel patches being released at the
end of each Solaris 10 Update release.
• These Kernel patches may contain significant amounts of latent feature
code. These patches are very intensely tested by Sun as part of the Solaris
10 Update QA processes, as well as being tested as individual patches.

24
Solaris Fundamentals
• These large patches undergo a process called “rejuvenation”, whereby
future code changes will be included in a series of new, smaller patches for
different areas of functionality, each of which has a requirement on the
parent patch from which it was rejuvenated.
• The result is that there are “stepping stones” to key functional enhancement
“baselines” contained in the large Kernel patches released after each
Update release, with smaller patches containing bug fixes released in
between Update releases.

25
 Customer visible Solaris 10 Kernel patches

Larger changes Larger changes

Update 4 Update 5
Small targeted patches
Kernel Kernel
Patch Patch
12711[12]-01 ...12711[12]-11
12001[12]-14 12712[78]-11
Larger changes
Update 6
Small targeted patches
Kernel
Patch
13711[12]-01... ...13711[12]-08 13888[89]-01...
13713[78]-09
26
“SplitGate” process improvement
• The process to manage the internal source code gate for core Solaris (“ON”)
was changed after the Solaris 10 11/06 (Update 3) release to the new
“SplitGate” process to provide better separation of immature feature code
from customer bug fixes.
• “SplitGate” replaced the older “Feature Foldback” process.
• “SplitGate” has made a very significant improvement to Solaris 10 patch
quality, starting immediately after Kernel patch 118833-36 (SPARC) /
118855-36 (x86).

27
SplitGate Benefits
• Kernel patch quality improvement:
> Releasable Solaris 10 Kernel Patches using old “Feature Foldback” ON
source gate management model:
– SPARC: 21 out of 66 = 32%
– x86: 12 out of 66 = 18%
> Releasable Solaris 10 Kernel Patches using new “SplitGate” ON source
gate management model:
– SPARC: 34 out of 39 = 87%
– x86: 37 out of 39 = 95%

28
Solaris 10 Kernel PatchID Sequence
SPARC x86
141444-xx Update 8 141445-xx
141414-xx Sustaining 141415-xx
141414-01 141415-xx
139555-08 Update 7 139556-08
138888-08 Sustaining 138889-08
138888-01 138889-01
137137-09 Update 6 137138-09
137111-08 Sustaining 137112-08
137111-01 137112-01
127127-11 Update 5 127128-11 SplitGate Model
127111-11 Sustaining 127112-11
127111-01 127112-01
120011-14 Update 4 120012-14
125100-10 Sustaining 125101-10
125100-04 125101-01
118833-36 Post-U3 118855-36
118833-33 * Update 3 118855-33*
118833-17 Update 2 118855-14*
118833-02 118855-01
118822-30 118844-30
118822-25 Update 1 118844-26*
118822-01 118844-01

Feature Foldback Model

*Not Releasable
29
Deferred Activation Patching and LU
• Up to Solaris 10 8/07 (Update 4), there were serious problems patching a
live zones environment due to the potential for code newly applied in
patches being invoked during the patching process which might be
incompatible with processes running in memory.
• Sun strongly recommends the use of Live Upgrade to patch an inactive boot
environment to avoid such issues
> Live Upgrade also reduces the downtime and risk associated with patching, as
the inactive boot environment can be patched while the system is still in
production.

30
Deferred Activation Patching and LU
> If issues occur after the new boot environment is activated, the system can be
rebooted back into the original boot environment enabling production to be
resumed immediately and the issue with the new environment can be fixed later.
• The problem with patching a live boot environment was solved in a method
known as “Deferred Activation Patching”, whereby loopback filesystem (lofs)
mounts are used to overlay the old object on top of the patched object to
keep the system in a fully consistent state during patching. Deferred
Activation Patching functionality is provided in the patch utilities patch.

31
Deferred Activation Patching
• Kernel patch 12001[12]-14 which is included in Solaris 10 8/07 (Update 4),
Kernel patch 12712[78]-11 which is included in Solaris 10 5/08 (Update 5),
Kernel patch 13713[78]-09 which is included in Solaris 10 10/08 (Update 6),
and Kernel patch 13955[56]-08 which is included in Solaris 10 5/09 (Update
7) are currently the only patches which specify application in Deferred
Activation Patching mode. Future Kernel patch included in future Solaris 10
Update releases are the likely candidates requiring application using
Deferred Activation Patching.
• Deferred Activation Patching (DAP) will be implicitly invoked for any patch
requiring a DAP patch which is applied before rebooting the system.

32
Deferred Activation Patching
• When the system is rebooted, the loopback filesystem (lofs) mounts will
disappear, exposing the patched objects.

33
Problematic Solaris 10 patches
• Deferred Activation Patching is not retrospective, so for systems using a
Solaris version older than Solaris 10 8/07 (Update 4), some complex patches
need to be managed:
> Kernel patch 118833-36 (SPARC) / 118855-36 (x86) uses loopback filesystem
(lofs) mounts within the scripts in the patch itself to ensure system consistency
during application to a live boot environment, and was the forerunner of the final
Deferred Activation Patching solution. A reboot is required after installing this
patch before other patches can be applied. This is enforced by the patch utilities.

34
Problematic Solaris 10 patches
> The only other circumstance where a reboot is required before further patching can
be performed using 'patchadd' is for x86 systems running an early version of
Solaris 10, where a potential inconsistency exists between Kernel patches below
118844-19 running in memory and libc changes delivered in patch 121208-02 and
-03, and 118855-xx which obsoletes it. Code in the scripts of these patches
ensures that a later Kernel patch, e.g. 118844-20, must be active before these
patches can be applied.
> There may be additional reboot constraints for higher level patch automation tools
such as xVM Ops Center due to their own footprint on the target system.
> Obsolete Zones patch 122660-10 (SPARC) / 122661-08 (x86) must be installed to
fix CR 6471974 before Kernel patch 120011-14 (SPARC) / 120012-14 (x86) can
be applied.

35
Bug Fix Process
• Ensure any serious issue affecting your environment has a Customer
Escalation for you associated with it
> Just because a CR (Change Request, a.k.a. bug report) exists for the issue,
doesn't mean it'll be automatically fixed immediately
> Asking Sun Support to ensure a call record for your company is associated with
the CR will help increase its priority
> The more customers who are associated with a CR, the higher the priority it will
typically be given to fix

36
Bug Fix Process
• Ensure information on issues is as complete and accurate as possible as this
will speed up the process
> Include all error messages and any relevant log files, core dumps, etc.
> What precisely is the problem observed ?
> When is it observed ?
> When is it not observed ?
> What changes were made recently ?
> What is the configuration ? Zones ? IPv6 ? VxVM ? BSM ? etc.
> All Sun Sustaining and most QA staff are trained in the Sun Global Resolve
problem solving methodology which is based upon Kepner-Tregoe's Analytic
Trouble-Shooting methodology. The better the input data, the faster the analysis.

37
Bug Fix Process
> SunSolve and Google are good sources of info to check if it's a known issue and
if there's a solution or workaround already available

38
Bug Fix Process
• Once sufficient information is received to enable successfully analysis of the
issue, the bug fix process begins. The bug fix process is rigorous to ensure
quality.
> The design for the bug fix will be peer reviewed
> The code for the bug fix will be peer reviewed
> The bug fix will be unit and link tested by the Sustaining engineer
> An IDR (Interim Diagnostics or Relief) may be produced to provide relief to
Escalating Customers or, if required, to help diagnose the problem
> The bug fix will go through functional Pre-Integration Testing

39
Bug Fix Process
> The bug fix will be integrated into “Nevada” (Solaris “11”)
> The bug fix will be tested by dozens of QA teams across Sun who test
each bi-weekly build of “Nevada”
> If no issues are found after 4 weeks (2 builds) “soak” time in “Nevada”, the
bug fix is permitted to go back into a production release. The “soak” time
in “Nevada” helps prevent buggy code getting into a production release.

40
 Bug Fix Process
• Continued...
> The bug fix may now be scheduled for integration into the relevant
production release(s) on which the issue was reported
> For Solaris 10, the back-ported bug fix goes through functional Pre-
Integration Testing
> A patch is created containing the bug fix
> The patch is submitted to the “Patch Pipeline” which manages the patch
test, verification, and release processes. It is called a “T-Patch” or Test
Patch.
> Over 230 audits are run to check the structural integrity of the patch

41
 Bug Fix Process
• Continued...
> Each engineer who contributed code to the patch must test the patch and
explicitly verify that their fix(es) work as intended
> The Patch System Test team perform automated Install/Backout testing
and System Testing on all Solaris, SunCluster, and some other patches
> The “T-Patch” is given to Escalating Customers to verify it fixes their issue

42
Bug Fix Process
• Continued...
> For Solaris 10, the patch is included in builds of the next Solaris Update
> For Solaris 10, each Solaris Update build is intensely tested by dozens of
QA teams across Sun
> When the patch test and verification process is complete, the “T-Patch”
designation is removed from the patch and it is released to SunSolve
> All this takes time, but is designed to ensure the quality of patches
produced for production releases

43
Bug Fix Process
• Continued...
> If a Solaris 10 Update is about to ship, putbacks to Solaris 10 may be
delayed until after the Solaris Update ships, as the Source Gates are
closed to all putbacks except “Release Stoppers” at the end of each
Solaris Update. This results in a hiatus on Solaris 10 patch production for
up to 10 weeks. Sustaining engineers try to time putbacks to avoid this
hiatus.
> An overview of patch testing is available on
http://sunsolve.sun.com/search/document.do?assetkey=1-9-81064-1

44
Bug Fix Process Overview
n
Support Fix Sustaining
Available?
Customer
Analyze Design Review Code Review Test
y
Provide
Verify IDR
IDR Pre-integration Build Image
Integrate
Provide fix in Functional & Perf
Verify
T-Patch
T-Patch “Nevada” Testing
Functional System Performance H/W
Customer Verification Test Test Test
downloads Fix
released OK ?
Patch
y Pre-integration Build Image
Integrate Functional & Perf T-Patch
Publish patch fix in
on SunSolve Solaris 10 Testing
y Patch Functional System Performance H/W
System Test Verification Test Test Test
Patch
OK ?
45
Patch Quality Metrics http://pst.ireland/metrics/

46
News

47
 Zones Patching Performance
• Three solutions:
> Use Live Upgrade to patch or upgrade an inactive boot environment
> Zones Parallel Patching enhancement to the patch utilities which improves
Zones patching performance by ca. 3x. Available in the patch utiliities patch from
revision 11925[45]-66.
> Zones “Update on Attach” (available in Kernel patch 13713[78]-09) is even more
performant
• Zones “Update on Attach” is also useful to fix non global zones which are out
of sync with the global zone (e.g. due to running out of disk space during
patch application).

48
Other Patch Utility Improvements
• Improved 'patchadd -M' design to reduce risk of getting Zones out of sync.
• Live Upgrade support for SVM fixed.
• Limited Live Upgrade support for Zone roots on ZFS in Solaris 10 10/08
(Update 6). Enhanced support for an expanded number of configurations
planned in post-U6 patches and U7.

49
 Patch Entitlement
• Solaris Patch Entitlement implementation being tightened up:
> Solaris business model changed several years ago from selling Solaris and
providing patches at no cost, to making the Solaris releases available at no cost
and charging for patches. This policy is not changing. The implementation is
being tightened up.
> Percentage of free Solaris patches reduced from >70% previously to 28% in
Phase 1 (January 2009) and will fall further to 19% in later phases
> Customers need a support contract which covers Solaris for all systems on
which they wish to apply entitlement-required patches, including test and
development systems

50
Patch Entitlement
> Customers need a support contract which covers Solaris in order to download
and use any patch cluster
> Hardware warranties and hardware-only support contracts do not provide
entitlement to Solaris patches
> See http://sunsolve.sun.com/search/document.do?assetkey=1-61-203648-1,
http://www.sun.com/service/subscriptions/entitlements.jsp,
http://blogs.sun.com/patch/date/20090105, and the following PodCast
http://sun.edgeboss.net/download/sun/09b01874/09b01874_01.mp3

51
 Solaris 8 Vintage Patch Service
• Solaris 8 began End of Service Life Phase 2 on April 1, 2009
> Only customers who sign up to the Solaris 8 Vintage Patch Service will be able
to access Solaris 8 patches produced after April 1, including patches which
provide security fixes
> Recommendation is for customers to migrate to the latest Solaris 10 Update,
currently Solaris 10 10/08
> As a migration aid, customers may wish to sign up for Solaris 8 (and/or 9)
Containers, which enables a Solaris 8 (and/or 9) environment to be run on a
Zone on a Solaris 10 system
> See http://www.sun.com/bigadmin/topics/vintagepatch/ and
http://www.sun.com/software/solaris/support/sol8.xml

52
Patch milestones over next 6 months
• Solaris 10 10/09 (Update 8)
• Corresponding Solaris 10 10/09 Patch Bundle on SunSolve
• Improvements to the Recommended and Sun Alert patch clusters including
improved install script & patch ordering.
• Merge “Recommended” and Sun Alert patch clusters, Fall 2009
• Further enhancements to the new PatchFinder (Dynamic Patch Cluster
Generator) functionality on SunSolve, including dependency resolution and
installation ordering.
• Patchinng Pre-flight Check tool to ensure system is ready to be patched
(sufficient space, no leftover lock files, etc.)

53
Patch Education Resources
• Recognized need to better communicate patching best practice and issues
to customers and the field. Initiated:
> Big Admin Patching Hub,
http://www.sun.com/bigadmin/hubs/documentation/patch/index.jsp
> Patch Corner blog, http://blogs.sun.com/patch/
> Tidy-up and overhaul of other customer facing patch related policies and
documentation
> Coming soon:
– Customer Patch Forum
– Overhauled SunSolve Patches & Updates page
– Patching Best Practices Videos / Course

54
 Patching Tips
• Solaris Sun Alert Patch Cluster provides all Solaris patches which fix
Security, Data Corruption, and System Availability issues
> Sign up for Sun Alert notifications on
http://sunsolve.sun.com/show.do?target=salert-notice&nav=fsalert.recent

55
 Patching Tips
• Applying “rebootimmediate” and “reconfigimmediate” patches to the live boot
environment using 'patchadd' should be interpreted as requiring a reboot
before normal operations are resumed.
> It's usually OK to continue to apply further patches before initiating the reboot.
On the rare occasion where this is not the case, such as 118833-36 / 118855-36,
the patch will contain code to prevent the user continuing without rebooting.
> Higher level patch automation tools may have additional constraints due to their
own footprint on the target system.

56
Patching Tips
> See http://sunsolve.sun.com/search/document.do?assetkey=1-61-249046-1
> Don't run other applications until the reboot is performed as the system is in a
potentially inconsistent state
> Again, using Live Upgrade to patch an inactive boot environment avoids such
issues

57
 Patching Tips
• Zones “Update on Attach” very useful to sync up non-global Zones which are
out of sync with the global zone regarding their patch level (e.g. because the
non-global zone ran out of disk space during patching)
• Zones “Update on Attach” useful as a method to improve Zones patching
performance (with some constraints)
> Detach non-global Zones, apply Solaris patches including Kernel patch 137137-
09 to the global zone, reboot to activate the new Kernel, reattach the non-global
Zones with “Update on Attach”, and viola, the non-global Zones will be brought
up to the same patch level at the global Zone
> Zones “Update on Attach” will only update software, not down-rev it

58
Patching Tips
> Any 'patchrm' operation must be performed while the zones are attached, e.g. if
'patchrm' is being used to remove a withdrawn patch

59
Patching Tools
• Patch Check Advanced (pca) is a simple and highly popular 3rd party patch
automation tool, developed and supported by Martin Paul
> 'pca' is available from http://www.par.univie.ac.at/solaris/pca/
• xVM Ops Center is a much more comprehensive virtualization and
provisioning management tool which has a patch management component,
based on the Aduva product which Sun acquired a couple of years ago. It
supersedes UCE.
> xVM OC support for Live Upgrade is due Summer 2009

60
Patching Tools
• 'smpatch' and Update Manager are older Sun patch management tools
based on Sun's “PatchPro” technology
> A major enhancement to the back end of these tools has recently been rolled
out which should significantly increase reliability and robustness

61
 Patching Services
• Sun Services provide patching services to customers, including tailoring a
patching strategy to customer needs and providing customers with lists of
key patches to install on their specific systems
> Many of these services are based on the TLP (Traffic Light Patching) tool,
SRAS (Sun Risk Analysis Service) and the EIS (Enterprise Installation
Standards) methodology
> EIS is the same methodology used for factory pre-installs of Sun hardware and
installations by Sun field personnel
> The EIS patch set is based on the Recommended Patch Cluster with additional
patches added for products such as SunCluster, SunVTS, SSP, SMS, QFS,
SAM-FS, and firmware updates

62
Patching Services
> The monthly EIS “Patch Baselines” are now available through xVM Ops Centre
1.0 and UCE
> New proactive patching services are currently in development

63
Image Packaging System
• Solaris 10 and earlier employs a 2-tier package and patching model. This
increases complexity.
• The strategic solution for is to move to a single tier architecture, Image
Packaging System (IPS), in OpenSolaris and “Nevada” (Solaris “11”)
> See Dr. Stephen Hahn's blog, http://blogs.sun.com/sch/
> To get bug fixes, users will update packages. Different streams of packages
will be available, from “bug fix only” to “bleeding edge” development.
> Bart Smaalders and David Comay who are working on the project are very
familiar with the issues with the current patch and package architecture

64
Image Packaging System
> The primary target audience for OpenSolaris currently is developers and the
current Image Packaging System functionality is concentrating on their needs
> As the target audience for OpenSolaris / “Nevada” matures towards ISVs and
production customers, one can expect to see the Image Packaging System
functionality mature into this space
> Image Packaging System is an OpenSolaris project, so you can get involved in
the design and implementation of the next generation packaging architecture

65
 How can we further improve your
patching experience ?
• Solaris Patch Utilities ?
• Patch Automation Tools ?
• SunSolve ?
• Patch Services ?
• Patch Best Practices / Education ?
• Patch Quality ?
• Faster Time to Release Patches ?
• Other ?
• Please let me know - Gerry.Haskins@sun.com

66
Solaris Patch Update
Gerry.Haskins@sun.com
http://blogs.sun.com/patch

67