Thursday Apr 09, 2015

Getting fixes faster

Time is money.

I remember my first unplanned downtime as a Sys Admin on-site at a major Aluminum Mill in up-state New York.  The Operations Manager was literally poking me in the back of the neck asking me "Don't you know downtime costs us $250,000 per hour ?  How long will it take to get back up ?", to which I replied "It'll be faster if you stop poking me in the neck!".  I had the Systems back up in 20 minutes.

For Solaris and other Oracle Sun products, we try to release bug fixes as fast as possible, balancing the need for speed with the need for quality.

Since an Operating System performs many disparate functions for many disparate workloads, testing that a fix isn't toxic in any supported scenario is complex and takes time.

But we can and do provide faster relief to the customer(s) who raised the specific issue as it's easier to ensure the fix is correct for their specific environments. 

We do this by supplying Interim Diagnostics and Relief (an IDR).  As the name suggests, it provides relief for the issue until the final fix is available in a Support Repository Update (SRU) or Solaris Update release (for example, Solaris 11.3).  For hard to diagnose issues, an IDR may also provide additional diagnostic instrumentation to get to the root cause of an issue.

Like many things in Solaris 11, the IDR mechanism is far smoother thanks to the Image Packaging System (IPS) than it was in Solaris 10 and earlier releases.

SRUs for Solaris 11 and patches for Solaris 10 are released on a monthly cadence. These are tested as a unit to ensure quality.

In Solaris 11, IDRs are automatically superseded by later SRUs or Solaris Updates which include fixes for all the bugs the IDR addresses.  An IDR terminal package is included in the SRU Repo for superseded IDRs.  This tells IPS it's OK to overwrite the IDR on the target system.  Therefore, it is no longer necessary to manually remove such IDRs before updating to a later SRU or Solaris Update.

This automatic superseding typically saves customers the need for an additional reboot, since it's no longer necessary to remove an IDR, reboot, apply an SRU, reboot.  Instead, simply 'pkg update' to the desired SRU, reboot once to activate it, and you're done.

If the issues addressed by an IDR are not yet fixed in the later SRU or Solaris Update, IPS will warn the user and a Service Request (SR) should be filed requesting a new IDR at the later software version for the outstanding issues.

Normally, IDRs are provided to the specific customers who have filed Service Requests (SRs) for a specific bug. 

To accelerate the release of fixes for public security vulnerabilities, we intend to release Security IDRs to the SRU Repo and My Oracle Support (MOS) so that all customers can get relief from such vulnerabilities quicker.  Customers should continue to file Service Requests (SRs) for such bugs, so we know there's demand for a Security IDR.

These security fixes will be included into the next SRU to be released, which will automatically obsolete the Security IDRs, so customers need have no concern about installing such Security IDRs in advance of the SRU being available. The Security IDR simply provides a faster delivery mechanism.

As mentioned in a previous post, there's now a security Critical Patch Update (CPU) package which can be installed and updated on Solaris 11 systems to provide all available Criticial Vulnerabilities and Exposures (CVE) security fixes in the minimum amount of change to satisfy security compliance requirements.  This package automagically pulls in the security fixes via IPS dependencies.

There are also significant new security compliance features in Solaris 11.2.

Also in Solaris 11.2 is support for a new Package Group install option: solaris-minimal-server, which provides the minimum useful bootable environment.  Use this and install additional packages as required to support your applications.  This is useful for security compliance as if the vulnerable software isn't installed, you ain't vulnerable, and you don't need to expend unnecessary time and effort applying fixes. 

There's lots of other new stuff in Solaris 11.2 including Open Stack and the Oracle 12c Database Prerequisite Package.  Check it out!

Friday Mar 13, 2015

New ORAchk Version 12.1.0.2.3 Released

The new ORAchk release 12.1.0.2.3 is now available to download.

New Features in ORAchk 12.1.0.2.3

Deeper Product Support

ORAchk now supports upgrade checks for 12.1.0.2, enabling you to do pre and post upgrade checking for Oracle Database 12.1.0.2 to avoid the most common upgrade problems.

ORAchk now supports ASM checks and patch recommendations for single instance databases as well as the already supported RAC instances.

ORAchk can now query details related to the OS resource consumption of different GoldenGate processes, identifying any components using excessive resources. It also identifies if GoldenGate is configured to avoid known performance problems.

Oracle Enterprise Manager Agent support has now been added to the existing support for Enterprise Manager Repository checks. The agent checks now appear in a new “Enterprise Manager” section of the report. With the new EM 12c Agent checks, you will quickly identify common EM Agent configuration mistakes that if undetected can result in poor performance or a failure to run the Agent process.

New Report Section “Findings Needing Further Review”

There are certain things ORAchk can only do a partial check for, where a complete check requires information outside the scope of the machine or that require other customer specific knowledge. These partially identified checks now appear in the new section marked “Findings needing further review”. If you review these checks and verify they are not problematic you can choose to exclude them in the same way as any other checks, see Document 1268927.2 for further details.

Improved Health Score Calculation

The ORAchk Health Score calculation has been improved with version 12.1.0.2.3. Certain INFO level checks, which only communicate best practice and do not confirm a problem in your environment, no longer deduct points from your health score. This means that if you follow the recommended advice for excluding any non relevant “Findings needing further review” then a health score of 100 is now obtainable.

Over 60 New Health Checks

This release of ORAchk adds new checks for some of the most impactful problems seen to Oracle Customer Support specifically in the areas of:

  • Database performance, install, scalability & ASM
  • Cross stack checks for Oracle Applications running on Solaris & Oracle Hardware
  • Enterprise Manager Agents performance and failure to run
  • Oracle EBS Accounts Payables

For more details and to download the latest release of ORAchk see Document 1268927.2

Friday Aug 01, 2014

Solaris 11.2 released with security and other enhancements

Solaris 11.2 is released!

There's a huge amount of new and improved features in Solaris 11.2 as well as thousands of bug fixes.  In short, it's our best Solaris ever!

For security conscious customers, Solaris 11.2 delivers significant compliance enhancements (see the docs) and provides the new "solaris-minimal-server" Install group, which is an excellent basis for installing secure, minimized (hardened) systems.

Hardening (minimizing) a system in Solaris 10 and earlier was as much an art form as a science.  It was hard to be sure that the system was as minimized as possible.

In Solaris 11.2, the "solaris-minimal-server" Install group dramatically simplifies the process.  It's a new install option in addition to the existing "solaris-small-server", "solaris-large-server", and "solaris-desktop" install groups.

"solaris-minimal-server" does exactly what it says.  It provides the minimal set of packages to provision a minimal supported command-line Oracle Solaris environment.  You will typically need to add packages to this minimal set which are required to support your applications.

For example, install a test domain with "solaris-minimal-server", your application, and any additional packages which you know your application requires - for example JRE7 and the application installer.  Test it, and add in any additional packages which you discover your application requires - for example, for it's user GUI/BUI.  That's the minimum install footprint for your application.  Repeat as desired for other applications.

By reducing the install footprint, you reduce the "attack surface", ensuring you system is exposed to the minimum number of vulnerabilities.  This in turn reduces the need to patch for security compliance, further reducing your TCO.

Since installing an Oracle Database would be a common scenario, Solaris 11.2 also
provides an additional group package for the database:

    group/prerequisite/oracle/oracle-rdbms-server-12-1-preinstall

So, if you want to install the Oracle Database (single instance), you can simply add the above package to your solaris-minimal-server and you will have the required packages to install the database.

It's just one of many new features in Solaris 11.2 which I think you'll like.  Please take a few minutes to browse the "What's New" and other documentation released with 11.2.

As with any Solaris Update release, expect a number of important bug fixes in the first few Solaris 11.2 SRUs which didn't make the Solaris 11.2 release.

More details on "solaris-minimal-server":

$ pkg contents -mr -g ./s11u2 group/system/solaris-minimal-server                                          
set name=pkg.fmri value=pkg://solaris/group/system/solaris-minimal-server@0.5.11,5.11-0.175.2.0.0.42.0:20140623T214938Z
set name=pkg.summary value="Oracle Solaris Minimal Server"
set name=pkg.description value="Provides the minimal, supported command-line Oracle Solaris environment"
set name=info.classification value="org.opensolaris.category.2008:Meta Packages/Group Packages"
set name=org.opensolaris.consolidation value=solaris_re
set name=variant.arch value=i386 value=sparc
set name=variant.opensolaris.zone value=global value=nonglobal
depend fmri=network/ping type=group
depend fmri=service/network/ssh type=group
depend fmri=shell/tcsh type=group
depend fmri=shell/zsh type=group
depend fmri=system/network type=group
depend fmri=developer/debug/mdb type=require
depend fmri=editor/vim/vim-core type=require
depend fmri=group/system/solaris-core-platform type=require
depend fmri=package/pkg type=require
depend fmri=release/name type=require
depend fmri=release/notices type=require
depend fmri=shell/bash type=require
depend fmri=shell/ksh93 type=require
depend fmri=system/core-os type=require
depend fmri=system/library/platform type=require

The packages with group dependencies in the list above can be removed to further minimize the system.  For example, if you don't want 'ssh', you don't have to install it.

More details on group package with Oracle Database 12.1 install pre-requisites:

$ pkg contents -mr -g ./s11u2 group/prerequisite/oracle/oracle-rdbms-server-12-1-preinstall                
set name=pkg.fmri value=pkg://solaris/group/prerequisite/oracle/oracle-rdbms-server-12-1-preinstall@0.5.11,5.11-0.175.2.0.0.42.0:20140623T214934Z
set name=pkg.summary value="Prerequisite package for Oracle Database 12.1"
set name=pkg.description value="Provides the set of Oracle Solaris packages required for installation and operation of Oracle Database 12."
set name=info.classification value="org.opensolaris.category.2008:Meta Packages/Group Packages"
set name=org.opensolaris.consolidation value=solaris_re
set name=variant.arch value=i386 value=sparc
depend fmri=x11/diagnostic/x11-info-clients type=group
depend fmri=x11/library/libxi type=group
depend fmri=x11/library/libxtst type=group
depend fmri=x11/session/xauth type=group
depend fmri=compress/unzip type=require
depend fmri=developer/assembler type=require
depend fmri=developer/build/make type=require

The benefits of SuperCluster to other Solaris 11.x users

As you may know, my team and I have been heavily focused on SuperCluster Engineered Systems for the last few years.

The intense work we've done for SuperCluster - especially on expediting fixes for scalability and availability issues - has a significant trickle down benefit for all Solaris customers.  All of these critical fixes are in Solaris 11.2 SRU1.

Did you know that 97% of all customer SuperCluster domains / zones run Solaris 11.x ?  Only 3% run Solaris 10.  The reason for this massive adoption of Solaris 11.x is due to it's compelling features, excellent quality, and superb stability.  It really is time to move to Solaris 11.x.  It's like going from horses to motor cars.  It is that big a difference.

Even if you are not in a position to adopt Solaris 11.2 immediately, please do consider using a recent Solaris 11.1 SRU, such as Solaris 11.1 SRU19.6 or later.  This includes fixes for 110 critical issues encountered on SuperCluster and which are also relevant for other T4/T5/M5/M6/M10 users.  This is our current recommended version for SuperCluster and our experience with it to date has been excellent. 

We'll be moving up to Solaris 11.2 shortly to leverage more of the exciting features it provides.

Best Wishes,

Gerry.

Friday Apr 12, 2013

Solaris 11 SRU naming convention change

We're tweaking the naming convention used by Oracle Solaris SRUs (Support Repository Updates) to use a 5-digit taxonomy.

For example, Oracle Solaris 11.1.6.4.0

The digits represent Release.Update.SRU.Build.Respin

For the above example, the old name would have been Oracle Solaris 11.1 SRU 6.4. 

As with Oracle Solaris 10 and below, all bug fixes are putback to the tip of the source tree for Solaris 11, which is currently Solaris 11.1.x.y.z. 

Therefore, these same SRUs are also the way to get fixes for systems installed with Oracle Solaris 11 11/11, in exactly the same way that Solaris 10 Kernel patches included code from all preceding Solaris 10 Updates.

As discussed in previously postings, systems should be updated to a later SRU, for example from Oracle Solaris 11 11/11 SRU13.4  to Oracle Solaris 11.1.6.4.0.

If you maintain a local Solaris Repository behind your firewall, both Solaris 11.1 and whichever subsequent SRUs you are interested in should be added to your Repo.  This is because SRUs only contain the change delta relative to the preceding Solaris Update.

Solaris's long standing Binary Compatibility Guarantee coupled with the technical benefits of Image Packaging System (IPS) help to ensure a smooth update experience.

Thursday Oct 25, 2012

Solaris 11.1 released!

Oracle Solaris 11.1 now available live at:

Documentation is also live in the docs library

Oracle Solaris 11.1 will be live on the Oracle Software Delivery Cloud (OSDC) tomorrow October 26

Enjoy!

Tuesday Oct 23, 2012

Solaris 11 SRU / Update relationship explained, and blackout period on delivery of new bug fixes eliminated

Relationship between SRUs and Update releases

As you may know, Support Repository Updates (SRUs) for Oracle Solaris 11 are released monthly and are available to customers with an appropriate support contract.  SRUs primarily deliver bug fixes.  They may also deliver low risk feature enhancements.

Solaris Updates are typically released once or twice a year, containing support for new hardware, new software feature enhancements, and all bug fixes available at the time the Update content was finalized.  They also contain a significant number of new bug fixes, for issues found internally in Oracle and complex customer bug fixes which  require significant "soak" time to ensure their efficacy prior to release.

Changes to SRU and Update Naming Conventions

We're changing the naming convention of Update releases from a date based format such as Oracle Solaris 10 8/11 to a simpler "dot" version numbering, e.g. Oracle Solaris 11.1. Oracle Solaris 11 11/11 (i.e. the initial Oracle Solaris 11 release) may be referred to as 11.0.

SRUs will simply be named as "dot.dot" releases, e.g. Oracle Solaris 11.1.1, for SRU1 after Oracle Solaris 11.1.

Many Oracle products and infrastructure tools such as BugDB and MOS are tailored towards this "dot.dot" style of release naming, so these name changes align Oracle Solaris with these conventions.

No Blackout Periods on Bug Fix Releases

The Oracle Solaris 11 release process has been enhanced to eliminate blackout periods on the delivery of new bug fixes to customers.

Previously, Oracle Solaris Updates were a superset of all preceding bug fix deliveries.  This made for a very simple update message - that which releases later is always a superset of that which was delivered previously.

However, it had a downside.  Once the contents of an Update release were frozen prior to release, the release of new bug fixes for customer issues was also frozen to maintain the Update's superset relationship.

Since the amount of change allowed into the final internal builds of an Update release is reduced to mitigate risk, this throttling back also impacted the release of new bug fixes to customers.

This meant that there was effectively a 6 to 9 week hiatus on the release of new bug fixes prior to the release of each Update.  That wasn't good for customers awaiting critical bug fixes.

We've eliminated this hiatus on the delivery of new bug fixes in Oracle Solaris 11 by allowing new bug fixes to continue to be released in SRUs even after the contents of the next Update release have been frozen.

The release of SRUs will remain contiguous, with the first SRU released after the Update release effectively being a superset of both the the Update release and all preceding SRUs*. 

That is, later SRUs are supersets of the content of previous SRUs.

Therefore, the progression path from the final SRUs prior to the Update release is to the first SRU after the Update release, rather than to the Update release itself.

The timeline / logical sequence of releases can be shown as follows:

Updates: 11.0                                                11.1                               11.2     etc.

                 \                                                         \                                    \

SRUs:       11.0.1, 11.0.2,...,11.0.12, 11.0.13, 11.1.1, 11.1.2,...,11.1.x, 11.2.1, etc.

For example, for systems with Oracle Solaris 11 11/11 SRU12.4 or later installed, the recommended update path is to Oracle Solaris 11.1.1 (i.e. SRU1 after Solaris 11.1) or later rather than to the Solaris 11.1 release itself.  This will ensure no bug fixes are "lost" during the update*.

If for any reason you do wish to update from SRU12.4 or later to the 11.1 release itself - for example to update a test system - the instructions to do so are in the SRU12.4 README, https://updates.oracle.com/Orion/Services/download?type=readme&aru=15607102

For systems with Oracle Solaris 11 11/11 SRU11.4 or earlier installed, customers can update to either the 11.1 release or any 11.1 SRU as both will be supersets of their current version.  My colleague, Pete Dennis, explains the step-by-step process here.

Please do read the README of the SRU you are updating to, as it will contain important installation instructions which will save you time and effort.

*Nerdy details:

  • SRUs only contain the latest change delta relative to the Update on which they are based.  Their dependencies will, however, effectively pull in the Update content.  Customers maintaining a local Repo (e.g. behind their firewall), need to add both the 11.1 content and the relevant SRU content to their Repo, to enable the SRU's dependencies to be resolved.  Both will be available from the standard Support Repo and from MOS.  This is no different to existing SRUs for Oracle Solaris 11.0, whereby you may often get away with using just the SRU content to update, but the original 11.0 content may be needed in the Repo to resolve dependencies.
  • The following bug fixes in SRU12.4 are not in Oracle Solaris 11.1.  They'll be available in 11.1.1 (SRU1 for Oracle Solaris 11.1):
7166132 vim should be able to run its test suite
7190213 libibmad and associated files need to be delivered in an NGZ
7191495 mkisofs install is incomplete
7195687 Update fetchmail to version 6.3.22
7195704 Problem with utility/fetchmail
7196234 Problem with network/dns
7197223 vim shows high CPU usage when editing dtrace script with syntax
        highlighting enabled
7071362 tcp_icmp_source_quench and other tunables may no longer be field
        modifiable
7181137 sol_umad should allow userland MAD operations in NGZs
7196540 After 7174929 integration 0.9.0 is shown for first disk in
        secondRAID volume

Friday Oct 19, 2012

October 2012 Security "Critical Patch Update" (CPU) information and downloads released

The October 2012 security "Critical Patch Update" information and downloads are now available from My Oracle Support (MOS).

See http://www.oracle.com/technetwork/topics/security/alerts-086861.html and in particular Document 1475188.1 on My Oracle Support (MOS), http://support.oracle.com, which includes security CVE mappings for Oracle Sun products.

For Solaris 11, Doc 1475188.1 points to the relevant SRUs containing the fixes for each issue.  SRU12.4 was released on the CPU date and contains the current cumulative security fixes for the Solaris 11 OS.

For Solaris 10, we take a copy of the Recommended Solaris OS patchset containing the relevant security fixes and rename it as the October CPU patchset on MOS.  See link provided from Doc 1475188.1

Doc 1475188.1 also contains references for Firmware, etc., and links to other useful security documentation, including information on Userland/FOSS vulnerabilities and fixes in https://blogs.oracle.com/sunsecurity/

Thursday Apr 12, 2012

How To Update Oracle Solaris 11

My colleague, Glynn Foster, has published a nice article on how to update Oracle Solaris 11 which I think you may find interesting.
About

This blog is to inform customers about Solaris 11 maintenance best practice, feature enhancements, and key issues. The views expressed on this blog are my own and do not necessarily reflect the views of Oracle. The Documents contained within this site may include statements about Oracle's product development plans. Many factors can materially affect these plans and the nature and timing of future product releases. Accordingly, this Information is provided to you solely for information only, is not a commitment to deliver any material code, or functionality, and SHOULD NOT BE RELIED UPON IN MAKING PURCHASING DECISIONS. The development, release, and timing of any features or functionality described remains at the sole discretion of Oracle. THIS INFORMATION MAY NOT BE INCORPORATED INTO ANY CONTRACTUAL AGREEMENT WITH ORACLE OR ITS SUBSIDIARIES OR AFFILIATES. ORACLE SPECIFICALLY DISCLAIMS ANY LIABILITY WITH RESPECT TO THIS INFORMATION. Gerry Haskins, Director, Software Lifecycle Engineering

Search

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