Solaris Patch Update Cust July2009

8/8/2019 Solaris Patch Update Cust July2009

1/67

1

Solaris Patch Update

Gerry HaskinsDirector, Software Patch ServicesSoftware Product Engineering

28th July 2009


2/67

2

Contents Recommended Patching Strategy

> Patching Strategy Consideration

> Recommended Patching Strategy

> Patching Best Practices


3/67

3

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


4/67

4

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 ?


5/67

5

Recommended Patching Strategy


6/67

6

Patching Strategy Considerations

Typical objective is to maximize production system availability by optimizingproactive maintenance to prevent issues

> Change implies risk. But minimizing risk is not as simple as minimizingchange. Need to consider best tested and best quality baselines uponwhich to standardize deployments to minimize risk:

Solaris Updates are intensely tested by many teams across Sun and soprovide a good baseline upon which to standardize deployments.


7/677


In comparison, Dim Sum patching (e.g. picking a Kernel patch which is 6months old, a libc patch which is 18 months old, and an LDAP patch which isa week old) may result in a software combination which has never beentested before as a set. However, rigorous processes to ensure patchdependencies are correctly defined, coupled with the patch test andverification procedure means that issues with Dim Sum patching are rare.

> A good customer test environment which accurately replicates theproduction environment and includes good functional test coverage andpeak load testing is the best way to minimize risk


8/678


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 reportedmore than 18 months after a Solaris release has shipped are corner cases. Thatis, they are mostly issues which only occur in highly specific configurations. Onecan argue that the quantity of change included in Solaris 10 Updates resets the

18 month clock to some extent.


9/679

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 inspecific configurations

> Since change implies risk, it's debatable whether applying all corner case fixesfor other customers' configurations is the optimal system maintenance strategyto minimize risk and maximize system availability

> Again, the better the customer's test environment, and the more closely itmatches the production environment, the better risk can be mitigated for anychosen patch strategy


10/6710


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 problematicpatches shows little correlation to any specific sweet spot, although seriouspervasive issues are usually found within 10 days of release.


11/6711

Patching Strategy Considerations>

Sun releases over 5,750 patches every year, for Solaris 8, 9, and 10, SPARCand x86, Middleware products, Developer products, Storage products, etc. Ofthose, approximately 65 are withdrawn after release each year due to seriousissues. 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. ForSecurity, Data Corruption, or System Availability issues, a Sun Alert will also be

issued.


12/6712

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, apatch bundle is made available for each Solaris Update starting with Solaris 105/08 which will patch pre-existing packages to the same software level as the

corresponding Solaris Update. The only difference is that the patch bundledoesn't include any new packages included in the Solaris Update, which may berequired to leverage some new features. However, all Zones and ZFSfunctionality, for example, are entirely contained within patches.


13/6713

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 Availabilityissues. The Recommended Patch Cluster and EIS patch set are both supersetsof 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


14/6714

Patching Best Practice

Always install the latest patch and package utility patches first to helpensure 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 thelive 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 forsystems below Solaris 10 8/07 (Update 4). Infodoc 206844,http://sunsolve.sun.com/search/document.do?assetkey=1-9-72099-1providesfurther information on Live Upgrade patches.
http://sunsolve.sun.com/search/document.do?assetkey=1-9-72099-1http://sunsolve.sun.com/search/document.do?assetkey=1-9-72099-1


15/6715

Patching Best Practice

Conduct pre-deployment testing in a test environment which accuratelyreplicates the production environment and includes good functional testcoverage 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 isrecommended.


16/6716

Background Information

Solaris Fundamentals why thingsare the way they are

Key Solaris 10 patching issues

resolved


17/6717

Solaris Fundamentals

There is effectively a single customer visible code branch for each SolarisNamed Release.

That is, there is one set of patches for all Solaris 8 releases, another set ofpatches for all Solaris 9 releases, and another set of patches for all Solaris10 releases.

This means that the same Solaris 10 patches can be applied to all systemsrunning Solaris 10, irrespective of which Solaris 10 Update release isinstalled on them. This simplifies System Administration and helps providea more homogeneous OS environment.


18/6718


All code changes, e.g. for a new Solaris 10 bug fix, are putback to the tip ofthe Solaris 10 source tree. The resultant patch can be applied to allpreceding Solaris 10 releases. It will also be pre-applied into future Solaris10 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 betterquality

This is what enables Sun to provide ultra long-term support for each releaseof Solaris at reasonable cost to Sun.


19/6719


Since there is effectively a single customer visible source code branch foreach Solaris named release, anychange to pre-existing packages will bereleased as patches.


20/6720

Dynamic tension There's dynamic tension between the desire to provide customers with cool

new features such as Zones enhancements, ZFS, NewBoot, Secure ByDefault, Trusted eXtensions, iSCSI, OPL and other hardware support inSolaris 10 Updates, and the desire to provide production customers withrock 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 thanwhat was allowed into Solaris 8 or 9 Updates.


21/6721

Dynamic tension The resultant issues have been solved through innovative solutions such as

the SplitGate source code gate management process, Live Upgrade, andDeferred Activation Patching.

In particular, Zones introduced a significant amount of complexity to thepatching and upgrade processes, including performance issues which arebeing addressed.

From Solaris 10 8/07 (Update 4) onwards, and for earlier releases patchedup to this level, many of the major patching issues have been resolved.


22/67

22


New features are introduced in each Solaris 10 Update release. TheUpdate releases are built from all available patches plus any new packagesintroduced.

A large new feature may introduce new packages which are typically onlyavailable by installing or upgrading to a Solaris 10 Update release which

includes the new packages. But all features will make at least some changeto pre-existing packages (e.g. hooks for the feature).

Some features, such as Zones and ZFS functionality, are completelycontained within patches, and hence any Solaris 10 system can utilize thelatest Zones and ZFS functionality by installing the appropriate patches.


23/67

23


So some Solaris 10 patches may include new feature code as well as bugfixes. 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 Updateswhich will reduce the risk of introducing functional regressions.


24/67

24


Where multiple code changes intersect, they will typically be included in thesame patch. This can result in large Kernel patches being released at theend of each Solaris 10 Update release.

These Kernel patches may contain significant amounts of latent featurecode. 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.


25/67

25


These large patches undergo a process called rejuvenation, wherebyfuture code changes will be included in a series of new, smaller patches fordifferent areas of functionality, each of which has a requirement on theparent 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 eachUpdate release, with smaller patches containing bug fixes released inbetween Update releases.


26/67

26

Customer visible Solaris 10 Kernel patches

Update 4

Kernel

Patch

Update 5

Kernel

Patch

Update 6Kernel

Patch

Small targeted patches

Larger changes

Larger changesLarger changes

Small targeted patches

12001[12]-14

12711[12]-01 ...12711[12]-11

12712[78]-11

13711[12]-01... ...13711[12]-08

13713[78]-09

13888[89]-01...


27/67

27

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 newSplitGate process to provide better separation of immature feature codefrom customer bug fixes.

SplitGate replaced the older Feature Foldback process.

SplitGate has made a very significant improvement to Solaris 10 patchquality, starting immediately after Kernel patch 118833-36 (SPARC) /118855-36 (x86).


28/67

28

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 sourcegate management model:

SPARC: 34 out of 39 = 87%

x86: 37 out of 39 = 95%


29/67

29

Solaris 10 Kernel PatchID SequenceSPARC x86141444-xx Update 8 141445-xx

141414-xx Sustaining 141415-xx141414-01 141415-xx

139555-08 Update 7 139556-08

138888-08 Sustaining 138889-08138888-01 138889-01

137137-09 Update 6 137138-09

137111-08 Sustaining 137112-08137111-01 137112-01

127127-11 Update 5 127128-11

127111-11 Sustaining 127112-11127111-01 127112-01

120011-14 Update 4 120012-14

125100-10 Sustaining 125101-10125100-04 125101-01

118833-36 Post-U3 118855-36118833-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

SplitGate Model

Feature Foldback Model

*Not Releasable


30/67

30

Deferred Activation Patching and LU

Up to Solaris 10 8/07 (Update 4), there were serious problems patching alive zones environment due to the potential for code newly applied inpatches being invoked duringthe patching process which might beincompatible 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 inproduction.


31/67

31

Deferred Activation Patching and LU>

If issues occur after the new boot environment is activated, the system can berebooted back into the original boot environment enabling production to beresumed immediately and the issue with the new environment can be fixed later.

The problem with patching a live boot environment was solved in a methodknown as Deferred Activation Patching, whereby loopback filesystem (lofs)

mounts are used to overlay the old object on top of the patched object tokeep the system in a fully consistent state during patching. DeferredActivation Patching functionality is provided in the patch utilities patch.


32/67

32

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 (Update7) are currently the only patches which specify application in Deferred

Activation Patching mode. Future Kernel patch included in future Solaris 10Update releases are the likely candidates requiring application usingDeferred Activation Patching.

Deferred Activation Patching (DAP) will be implicitly invoked for any patchrequiring a DAP patch which is applied before rebooting the system.


33/67

33

Deferred Activation Patching

When the system is rebooted, the loopback filesystem (lofs) mounts willdisappear, exposing the patched objects.


34/67


35/67

35

Problematic Solaris 10 patches>

The only other circumstance where a reboot is required before further patching canbe performed using 'patchadd' is for x86 systems running an early version ofSolaris 10, where a potential inconsistency exists between Kernel patches below118844-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 patchesensures 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 tofix CR 6471974 before Kernel patch 120011-14 (SPARC) / 120012-14 (x86) canbe applied.


36/67

36

Bug Fix Process

Ensure any serious issue affecting your environment has a CustomerEscalation 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


37/67

37

Bug Fix Process

Ensure information on issues is as complete and accurate as possible as thiswill 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 Resolveproblem solving methodology which is based upon Kepner-Tregoe's AnalyticTrouble-Shooting methodology. The better the input data, the faster the analysis.


38/67

38

Bug Fix Process>

SunSolve and Google are good sources of info to check if it's a known issue andif there's a solution or workaround already available


39/67

39

Bug Fix Process

Once sufficient information is received to enable successfully analysis of theissue, the bug fix process begins. The bug fix process is rigorous to ensurequality.

> 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


40/67

40

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, thebug fix is permitted to go back into a production release. The soak time

in Nevada helps prevent buggy code getting into a production release.


41/67

41

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 TestPatch.

> Over 230 audits are run to check the structural integrity of the patch


42/67

42

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 testingand System Testing on all Solaris, SunCluster, and some other patches

> The T-Patch is given to Escalating Customers to verify it fixes their issue


43/67

43

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 ofQA 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


44/67

44

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 areclosed to all putbacks except Release Stoppers at the end of eachSolaris Update. This results in a hiatus on Solaris 10 patch production for

up to 10 weeks. Sustaining engineers try to time putbacks to avoid thishiatus.

> An overview of patch testing is available onhttp://sunsolve.sun.com/search/document.do?assetkey=1-9-81064-1
http://sunsolve.sun.com/search/document.do?assetkey=1-9-81064-1http://sunsolve.sun.com/search/document.do?assetkey=1-9-81064-1


45/67

45

Bug Fix Process Overview

Support

SystemTest

Pre-integrationFunctional & Perf

Testing

Integratefix in

Nevada

Analyze

Verify

IDR

Provide

IDR

SustainingFixAvailable?

Customer

y

n

Build Image

PerformanceTest

H/WTest

FunctionalVerification

Design Review ReviewCode Test

FixOK ?

Integratefix in

Solaris 10

Build Image

PatchSystem Test

T-Patch

Patch

OK ?

y

Publish patchon SunSolve

Customerdownloadsreleased

Patch

VerifyT-Patch

ProvideT-Patch

y

Pre-integration

Functional & Perf

Testing

H/WTest

PerformanceTest

SystemTest

FunctionalVerification


46/67

46

Patch Quality Metrics http://pst.ireland/metrics/
http://pst.ireland/metrics/http://pst.ireland/metrics/http://pst.ireland/metrics/


47/67

47

News


48/67


49/67

49

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 configurationsplanned in post-U6 patches and U7.


50/67

50

Patch Entitlement Solaris Patch Entitlement implementation being tightened up:

> Solaris business model changed several years ago from selling Solaris andproviding patches at no cost, to making the Solaris releases available at no costand charging for patches. This policy is not changing. The implementation isbeing 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 anddevelopment systems


51/67

51

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 PodCasthttp://sun.edgeboss.net/download/sun/09b01874/09b01874_01.mp3
http://sunsolve.sun.com/search/document.do?assetkey=1-61-203648-1http://sunsolve.sun.com/search/document.do?assetkey=1-61-203648-1http://www.sun.com/service/subscriptions/entitlements.jsphttp://www.sun.com/service/subscriptions/entitlements.jsphttp://blogs.sun.com/patch/date/20090105http://blogs.sun.com/patch/date/20090105http://sun.edgeboss.net/download/sun/09b01874/09b01874_01.mp3http://sun.edgeboss.net/download/sun/09b01874/09b01874_01.mp3http://blogs.sun.com/patch/date/20090105http://www.sun.com/service/subscriptions/entitlements.jsphttp://sunsolve.sun.com/search/document.do?assetkey=1-61-203648-1


52/67

52

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 whichprovide 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 aZone on a Solaris 10 system

> See http://www.sun.com/bigadmin/topics/vintagepatch/andhttp://www.sun.com/software/solaris/support/sol8.xml
http://www.sun.com/bigadmin/topics/vintagepatch/http://www.sun.com/bigadmin/topics/vintagepatch/http://www.sun.com/software/solaris/support/sol8.xmlhttp://www.sun.com/software/solaris/support/sol8.xmlhttp://www.sun.com/software/solaris/support/sol8.xmlhttp://www.sun.com/bigadmin/topics/vintagepatch/


53/67

53

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 includingimproved install script & patch ordering.

Merge Recommended and Sun Alert patch clusters, Fall 2009

Further enhancements to the new PatchFinder (Dynamic Patch ClusterGenerator) functionality on SunSolve, including dependency resolution andinstallation ordering.

Patchinng Pre-flight Check tool to ensure system is ready to be patched(sufficient space, no leftover lock files, etc.)


54/67

54

Patch Education Resources

Recognized need to better communicate patching best practice and issuesto 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 anddocumentation

> Coming soon: Customer Patch Forum

Overhauled SunSolve Patches & Updates page

Patching Best Practices Videos / Course
http://www.sun.com/bigadmin/hubs/documentation/patch/index.jsphttp://blogs.sun.com/patch/http://blogs.sun.com/patch/http://www.sun.com/bigadmin/hubs/documentation/patch/index.jsp


55/67

55

Patching Tips

Solaris Sun Alert Patch Cluster provides all Solaris patches which fixSecurity, 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
http://sunsolve.sun.com/show.do?target=salert-notice&nav=fsalert.recenthttp://sunsolve.sun.com/show.do?target=salert-notice&nav=fsalert.recent


56/67

56

Patching Tips

Applying rebootimmediate and reconfigimmediate patches to the live bootenvironment using 'patchadd' should be interpreted as requiring a rebootbefore 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 theirown footprint on the target system.


57/67


58/67

58

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 thenon-global zone ran out of disk space during patching)

Zones Update on Attach useful as a method to improve Zones patchingperformance (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-globalZones with Update on Attach, and viola, the non-global Zones will be broughtup to the same patch level at the global Zone

> Zones Update on Attach will only update software, not down-rev it


59/67

59

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


60/67


61/67

61

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


62/67

62

Patching Services Sun Services provide patching services to customers, including tailoring a

patching strategy to customer needs and providing customers with lists ofkey 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 InstallationStandards) methodology

> EIS is the same methodology used for factory pre-installs of Sun hardware andinstallations by Sun field personnel

> The EIS patch set is based on the Recommended Patch Cluster with additionalpatches added for products such as SunCluster, SunVTS, SSP, SMS, QFS,SAM-FS, and firmware updates


63/67

63

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


64/67

64

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 packageswill be available, from bug fix only to bleeding edge development.

> Bart Smaalders and David Comay who are working on the project are veryfamiliar with the issues with the current patch and package architecture
http://blogs.sun.com/sch/http://blogs.sun.com/sch/


65/67

65

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 Systemfunctionality mature into this space

> Image Packaging System is an OpenSolaris project, so you can get involved inthe design and implementation of the next generation packaging architecture


66/67

66

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 - [email protected]


67/67

Solaris Patch Update

[email protected]://blogs.sun.com/patch
mailto:[email protected]:[email protected]

Documents

Solaris Patch Update Cust July2009