[pca] Heads-Up - Withdrawn patches 150400-06, 150400-07, 150401-06 150401-07
Hi, Please note that there's an issue with revs -06 and -07 of the Solaris 10 Kernel patches 15040[01]. Please see Sun Alert 1619580.1 on MOS for further details. A number of Solaris 10 customers have hit the 2nd of the reported issues, which is affecting the patches that have been withdrawn from MOS. We've respun the Solaris 10 January CPU (Critical Patch Update) to revert to rev-05 (now available from MOS), we're expediting a fixed rev-09 (rev-08 won't be released), and have withdrawn revs -06 and -07 from release. 15040[01]-09 will address Bug 17628036 and the current ETA for expedited release is Feb 18. The Solaris 11 fix is also being expedited in Solaris 11.1 SRU16, but Solaris 11 seems to be less prone to the issue. I apologize for the inconvenience caused. Best, -Don -- Don O'Malley Senior Manager, Software Maintenance Engineering Revenue Product Engineering | Solaris | Hardware Block C, East Point Business Park, Dublin 3, Ireland Phone: +353 1 8033883 Team Alias: rpe_sme_ww_...@oracle.com
Re: [pca] Solaris 10 1/13 preinstalled patches
Thanks for the further investigation Martin! I'll follow up.
There is nothing to prevent those patches being added to a system
installed with s10u11, so it would seem prudent to add the Security
fixes indicated below in the case where the patch pkgs are installed
systems. (I've provided details of the pkgs delivered in the 2
patches that you've pointed out below for ease of reference.)
As a general rule of thumb, it is always advisable to apply the
latest Recommended Patchset after installing/upgrading to the latest
Solaris Update to get any fixes relesed after the Solaris Update (or
in this case not delivered as part of the update itself).
Best,
-Don
On 02/13/13 07:12, Martin Paul wrote:
Hi
Don,
Am 12.02.2013 20:00, schrieb Don O'Malley:
I'll take a look into this one and get
back to you.
Thanks for the information you already provided. Apart from that,
it might be worth to at least take a look at these two patches:
Patch IR CR RSB Age Synopsis
-- -- - -- --- ---
---
119213 26 27 RS- 369 NSS_NSPR_JSS 3.13.1: NSPR 4.8.9 /
NSS 3.13.1 / JSS 4.3.2
149453 -- 02 RS- 133 SunOS 5.10: CCR Update
Both of them are "S"ecurity patches, and both of them contain
actual security fixes (which Oracle nowadays often paraphrases as
"problem with X"):
-- 119213-27:
13341290 DIS-TRUST DIGINOTAR ROOT CERTIFICATE
13341314 (CVE-2011-3389) RIZZO/DUONG CHOSEN PLAINTEXT ATTACK
(BEAST) ON SSL/TLS 1.0
PKG=SUNWjss
ARCH=sparc
VERSION=4.0,REV=2004.11.05.02.31
PKG=SUNWpr
ARCH=sparc
VERSION=4.5.1,REV=2004.11.05.02.30
PKG=SUNWprd
ARCH=sparc
VERSION=4.5.1,REV=2004.11.05.02.30
PKG=SUNWtls
ARCH=sparc
VERSION=3.9.5,REV=2005.01.14.17.27
PKG=SUNWtlsd
ARCH=sparc
VERSION=3.9.5,REV=2005.01.14.17.27
PKG=SUNWtlsu
ARCH=sparc
VERSION=3.9.5,REV=2005.01.14.17.27
-- 149453-02
7194816 problem with smpatch / updatemanager
6914463 problem with smpatch / updatemanager
PKG=SUNWr
ARCH=sparc
VERSION=001.000.000
It's kind of strange to get a Solaris release in Feb 2013 with
existing security fixes from up to a year ago not being fixed out
of the box.
Martin.
--
Don O'Malley
Manager, Software Maintenance Engineering
Revenue Product Engineering | Solaris | Hardware
Block C, East Point Business Park, Dublin 3, Ireland
Phone: +353 1 8033883
Team Alias: rpe_sme_ww_...@oracle.com
Re: [pca] patch flood
Hi Martin/All,
Yes, the imminent release of s10u11 is what's triggering the release
of these patches!
The key patches are the s10u11 KU patches - 147147-26 on SPARC and
147148-26 on x86.
Please take the time to read the Special Install Instructions for
these patches prior to applying them to your systems to avoid any
surprises.
If anyone finds any issues with any of the new patches, please do
post to this alias (in addition to filing a Service Request of
course!) and I will follow up.
I'll send on details of the s10u11 announcements to the PCA alias
too in due course.
Best,
-Don
On 02/ 8/13 09:54 AM, Martin Paul wrote:
Judging
from today's patch flood, it's pretty sure that Solaris 10U11 is
right around the corner :)
As usual, I installed all the new patches with PCA on both sparc
and x86 - works fine. Users of PCA's "--safe" option might want to
get the current development release, where I added some whitelist
entries.
Martin.
--
Don O'Malley
Manager, Software Maintenance Engineering
Revenue Product Engineering | Solaris | Hardware
East Point Business Park, Dublin 3, Ireland
Re: [pca] Heads-up on patches 147440-16, 147440-17, 147441-16, 147441-17
Hi Folks, These patches should be withdrawn now. The accompanying SunAlert is https://support.oracle.com/CSP/main/article?cmd=showtype=NOTid=1461565.1 Apologies for any inconvenience. Best, -Don On 05/25/12 15:45, Laurent Blume wrote: Hello Don, Are they? There *were* unavailable this morning CEST (MOS asked for a password with no explanation), but they can be downloaded again now. Laurent Don O'Malley don.omal...@oracle.com a crit: Hi, Quick update. Patches 147440-16, 147440-17, 147441-16 147441-17 are in the process of being withdrawn from MOS. I will share the accompanying SunAlert for the issue as soon as I get it. On 05/24/12 18:46, Don O'Malley wrote: Hi, A small number of customers have reported panics in recent days with Solaris 10 Kernel patches 147440/1 revs -16 and -17. The issue appears to be triggered by heavy network stress and also appears to be have been caused by the fixfor CR 7054587. Investigations are ongoing. It's not yet clear how pervasive the issue is, or under what exact circumstances the issue occurs. 117440-15 (SPARC) and 117441-15 (x86) are the last known good revisions. This should read: 147440-15 (SPARC) and 147441-15 (x86) are the last known good revisions. (Thanks Thomas!) Best, -Don Affected customers should backoff the affected KU's revert to these revisions. I've removed download capability of the affected Kernel patch revisions temporarily to avoid more customers being impacted until we can determine whether they need to be withdrawn permanently. You will see attempts to download these patches via pca failing as a result. A Sun Alert is in the works and I'll provide an update tomorrow. We'll also be respinning the Recommended Cluster to revert to rev-15. Customers should use the April Solaris 10 CPU instead in the interim. This issue will be addressed in rev-19 by backing out the offending putback. Best, -Don -- http://www.oracle.com/ *Don O'Malley* Manager, Software Maintenance Engineering Revenue Product Engineering | Solaris | Hardware Block C, East Point Business Park, Dublin 3, Ireland Phone: +353 1 8033883 Team Alias: rpe_patch_system_test_ww_...@oracle.com mailto:rpe_patch_system_test_ww_...@oracle.com -- http://www.oracle.com/ *Don O'Malley* Manager, Software Maintenance Engineering Revenue Product Engineering | Solaris | Hardware Block C, East Point Business Park, Dublin 3, Ireland Phone: +353 1 8033883 Team Alias: rpe_patch_system_test_ww_...@oracle.com mailto:rpe_patch_system_test_ww_...@oracle.com -- Don O'Malley Manager, Software Maintenance Engineering Revenue Product Engineering | Solaris | Hardware Block C, East Point Business Park, Dublin 3, Ireland Phone: +353 1 8033883 Team Alias: rpe_patch_system_test_ww_...@oracle.com
Re: [pca] Heads-up on patches 147440-16, 147440-17, 147441-16, 147441-17
Hi, Quick update. Patches 147440-16, 147440-17, 147441-16 147441-17 are in the process of being withdrawn from MOS. I will share the accompanying SunAlert for the issue as soon as I get it. On 05/24/12 18:46, Don O'Malley wrote: Hi, A small number of customers have reported panics in recent days with Solaris 10 Kernel patches 147440/1 revs -16 and -17. The issue appears to be triggered by heavy network stress and also appears to be have been caused by the fix for CR 7054587. Investigations are ongoing. It's not yet clear how pervasive the issue is, or under what exact circumstances the issue occurs. 117440-15 (SPARC) and 117441-15 (x86) are the last known good revisions. This should read: 147440-15 (SPARC) and 147441-15 (x86) are the last known good revisions. (Thanks Thomas!) Best, -Don Affected customers should backoff the affected KU's revert to these revisions. I've removed download capability of the affected Kernel patch revisions temporarily to avoid more customers being impacted until we can determine whether they need to be withdrawn permanently. You will see attempts to download these patches via pca failing as a result. A Sun Alert is in the works and I'll provide an update tomorrow. We'll also be respinning the Recommended Cluster to revert to rev-15. Customers should use the April Solaris 10 CPU instead in the interim. This issue will be addressed in rev-19 by backing out the offending putback. Best, -Don -- Don O'Malley Manager, Software Maintenance Engineering Revenue Product Engineering | Solaris | Hardware Block C, East Point Business Park, Dublin 3, Ireland Phone: +353 1 8033883 Team Alias: rpe_patch_system_test_ww_...@oracle.com -- Don O'Malley Manager, Software Maintenance Engineering Revenue Product Engineering | Solaris | Hardware Block C, East Point Business Park, Dublin 3, Ireland Phone: +353 1 8033883 Team Alias: rpe_patch_system_test_ww_...@oracle.com
[pca] Heads-up on patches 147440-16, 147440-17, 147441-16, 147441-17
Hi, A small number of customers have reported panics in recent days with Solaris 10 Kernel patches 147440/1 revs -16 and -17. The issue appears to be triggered by heavy network stress and also appears to be have been caused by the fix for CR 7054587. Investigations are ongoing. It's not yet clear how pervasive the issue is, or under what exact circumstances the issue occurs. 117440-15 (SPARC) and 117441-15 (x86) are the last known good revisions. Affected customers should backoff the affected KU's revert to these revisions. I've removed download capability of the affected Kernel patch revisions temporarily to avoid more customers being impacted until we can determine whether they need to be withdrawn permanently. You will see attempts to download these patches via pca failing as a result. A Sun Alert is in the works and I'll provide an update tomorrow. We'll also be respinning the Recommended Cluster to revert to rev-15. Customers should use the April Solaris 10 CPU instead in the interim. This issue will be addressed in rev-19 by backing out the offending putback. Best, -Don -- Don O'Malley Manager, Software Maintenance Engineering Revenue Product Engineering | Solaris | Hardware Block C, East Point Business Park, Dublin 3, Ireland Phone: +353 1 8033883 Team Alias: rpe_patch_system_test_ww_...@oracle.com
Re: [pca] Heads up on another patch
Thanks Drew! So, just to confirm; this issue is introduced in 143645-03? Should that be 143645-13 by any chance? Is so, then I think the affected revisions are 143645 revs 13, 14, 15, 16 146232 revs 08, 09, 12, 13. I'll get a README note added to these patches to serve as a heads-up to customers. Does the following sound about right: Please do not apply this patch to systems running iSCSI that use Challenge Handshake Authentication Protocol (CHAP), as CHAP is not compatible with this patch revision. The fix for the underlying problem (CR 7031995) is delivered in patch 146232-14. Please install patch 146232-14 in the place of this one on systems running iSCSI that are using CHAP. I've followed up on patch 146232-14 and it is due to be released later today, so should hit MOS overnight. Best, -Don On 16/02/12 19:30, Drew Skinner wrote: Hi; Been lurking here for a while, but have been having great success with pca (thanks Martin). Have handled 1000+ systems in under 2 months w/ lots of different pca configs (based on security requirements). After everything we saw with 144500 / 501-19, I thought I'd share another heads up for everyone. First off, my problems with the above were solved with another patch from Oracle. The next patch only impacts about a dozen machines in this environment, but if you're running iSCSI with CHAP, take note. Bug to the above was introduced in 143645-03 (CHAP stops working). Bug is perpetuated by 146232-13 which obsoleted 143645-16 Bugs on file at Oracle: 7031995 and 7127565 Official fix ftrom Sun / Oracle is due in 7 - 10 days (approx end of February) in the form of 146232-14 Workaround is to turn off CHAP for the time being. Just a heads up for everyone. Drew. -- Don O'Malley Manager, Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] anyone seen patch 145957-09 ? SunOS 5.10: fcp and fcip Patch
led (patch not found)
--
Download Summary: 1 total, 0 successful, 0 skipped, 1 failed
core-sparc #
weird.
dc
--
Don O'Malley
Manager, Patch/Package System Test
Revenue Product Engineering | Solaris | Hardware
Block C, East Point Business Park, Dublin 3, Ireland
Phone: +353 1 8033883
Team Alias: rpe_patch_system_test_ww_...@oracle.com
Re: [pca] anyone seen patch 145957-09 ? SunOS 5.10: fcp and fcip Patch
On 02/16/12 17:12, Wickline, Bob (N-STERLING COMPUTERS CORPORATION) wrote: So when is Oracle simple going to toss out a billion to buy the pca tool and pay off everyone on this mail list ? :-) I'm part of the list, right :-) If only Jonathan was still around... ;) Funny, I just came across this article today: http://www.theregister.co.uk/2012/02/16/schwartz_carezone/ -- Don O'Malley Manager, Patch/Package System Test Revenue Product Engineering | Solaris | Hardware Block C, East Point Business Park, Dublin 3, Ireland Phone: +353 1 8033883 Team Alias: rpe_patch_system_test_ww_...@oracle.com
Re: [pca] can patch 147440-09 be trusted ?
61 I get a warm and fuzzy "The Bug ID is invalid or you do not have permission to view the bug". The same goes for bugid 6382683 which is listed on the MOS page but NOT in the README. Seriously, can Oracle be trusted or is this a case of "trust us, we know, you don't, and you don't need to know." Because that really does not fly well with me. Ok, so the above discussion is all related to the patch content (i.e. what's being fixed). While I understand your frustration here (and admire your attention to detail), what you are experiencing is not new under Oracle. This issue is related to security fixes (though there may be rare cases where other non-security bugs that are not publicly visible either). Before the Oracle acquisition, Sun never published bug reports for any security issues. (Back in the old SunSolve days we would release a "HTML" version of a patch README very similar to https://updates.oracle.com/Orion/Services/download?type=readmebugfix_name=147440-08 that would contain links to bug reports for non-security bugs only.) In addition, the Bug description in the README for a patch was (and still is) reviewed by the security team to ensure that it is not providing enough information on any security-related issues to hackers looking to reverse-Engineer security vulnerabilities into potential attacks. The idea is that you get enough information to decide if you use the particular technology and if you feel it is appropriate for you to install the patch. It's far from perfect, but with security issues we must err on the side of caution. For this reason we do not (and never had) made bug reports for security issues publicly available. HTH, -Don Dennis -- Don O'Malley Manager, Patch/Package System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] Packages are older after upgrading and patching
Hi Laurent, The VERSION of the servicetags pkgs in Solaris have not changed in Solaris 10 Update 10: # grep VERSION /export/images/SPARC/solaris_10*/Solaris_10/Product/SUNWservicetagu/pkginfo /export/images/SPARC/solaris_10_u10/Solaris_10/Product/SUNWservicetagu/pkginfo:VERSION=1.0,REV=2007.05.21.20.36 /export/images/SPARC/solaris_10_u4/Solaris_10/Product/SUNWservicetagu/pkginfo:VERSION=1.0,REV=2007.05.21.20.36 /export/images/SPARC/solaris_10_u5/Solaris_10/Product/SUNWservicetagu/pkginfo:VERSION=1.0,REV=2007.05.21.20.36 /export/images/SPARC/solaris_10_u6/Solaris_10/Product/SUNWservicetagu/pkginfo:VERSION=1.0,REV=2007.05.21.20.36 /export/images/SPARC/solaris_10_u7/Solaris_10/Product/SUNWservicetagu/pkginfo:VERSION=1.0,REV=2007.05.21.20.36 /export/images/SPARC/solaris_10_u8/Solaris_10/Product/SUNWservicetagu/pkginfo:VERSION=1.0,REV=2007.05.21.20.36 /export/images/SPARC/solaris_10_u9/Solaris_10/Product/SUNWservicetagu/pkginfo:VERSION=1.0,REV=2007.05.21.20.36 # grep VERSION /export/images/SPARC/solaris_10*/Solaris_10/Product/SUNWservicetagr/pkginfo /export/images/SPARC/solaris_10_u10/Solaris_10/Product/SUNWservicetagr/pkginfo:VERSION=1.0,REV=2007.05.21.20.36 /export/images/SPARC/solaris_10_u4/Solaris_10/Product/SUNWservicetagr/pkginfo:VERSION=1.0,REV=2007.05.21.20.36 /export/images/SPARC/solaris_10_u5/Solaris_10/Product/SUNWservicetagr/pkginfo:VERSION=1.0,REV=2007.05.21.20.36 /export/images/SPARC/solaris_10_u6/Solaris_10/Product/SUNWservicetagr/pkginfo:VERSION=1.0,REV=2007.05.21.20.36 /export/images/SPARC/solaris_10_u7/Solaris_10/Product/SUNWservicetagr/pkginfo:VERSION=1.0,REV=2007.05.21.20.36 /export/images/SPARC/solaris_10_u8/Solaris_10/Product/SUNWservicetagr/pkginfo:VERSION=1.0,REV=2007.05.21.20.36 /export/images/SPARC/solaris_10_u9/Solaris_10/Product/SUNWservicetagr/pkginfo:VERSION=1.0,REV=2007.05.21.20.36 # grep VERSION /export/images/SPARC/solaris_10*/Solaris_10/Product/SUNWstosreg/pkginfo /export/images/SPARC/solaris_10_u10/Solaris_10/Product/SUNWstosreg/pkginfo:VERSION=1.0,REV=2007.05.21.20.36 /export/images/SPARC/solaris_10_u4/Solaris_10/Product/SUNWstosreg/pkginfo:VERSION=1.0,REV=2007.05.21.20.36 /export/images/SPARC/solaris_10_u5/Solaris_10/Product/SUNWstosreg/pkginfo:VERSION=1.0,REV=2007.05.21.20.36 /export/images/SPARC/solaris_10_u6/Solaris_10/Product/SUNWstosreg/pkginfo:VERSION=1.0,REV=2007.05.21.20.36 /export/images/SPARC/solaris_10_u7/Solaris_10/Product/SUNWstosreg/pkginfo:VERSION=1.0,REV=2007.05.21.20.36 /export/images/SPARC/solaris_10_u8/Solaris_10/Product/SUNWstosreg/pkginfo:VERSION=1.0,REV=2007.05.21.20.36 /export/images/SPARC/solaris_10_u9/Solaris_10/Product/SUNWstosreg/pkginfo:VERSION=1.0,REV=2007.05.21.20.36 root@patchtest # What I reckon has happened is that you have picked up higher Service Tags pkgs somewhere along the line. Did you download and install the Services Tools Bundle perhaps (eg. https://updates.oracle.com/Orion/Services/download?type=readmearu=13841920)? Best, -Don On 21/11/11 14:56, laur...@elanor.org wrote: Hi all, I've done a luupgrade, then patched a system up to the Nov 8th level (-i mrs) After booting on the upgraded BE, trying to reattach a zone, I get the following error: # zoneadm -z zone attach -U zoneadm: zone 'zone': ERROR: attempt to downgrade package SUNWservicetagr 1.1.4,REV=2008.04.25.09.06 to version 1.0,REV=2007.05.21.20.36 zoneadm: zone 'zone': ERROR: attempt to downgrade package SUNWservicetagu 1.1.4,REV=2008.04.25.09.06 to version 1.0,REV=2007.05.21.20.36 zoneadm: zone 'zone': ERROR: attempt to downgrade package SUNWstosreg 1.1.4,REV=2008.04.25.09.06 to version 1.0,REV=2007.05.21.20.36 How is it possible that *after upgrading*, this packages went from v1.1.4 to 1.0? Is that because of patch 138195-04, that was not present in the old BE, but has been installed in the new one? Laurent -- Don O'Malley Manager, Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] Solaris 9 transitioning to Extended Support
Hi,
The latest Solaris 9 KUs will not require an Extended Support
contract.
We have put an exception in place for these KUs as they were in the
our pipeline before Solaris 9 entered Extended support.
The only other patch that will be treated similarly is 115553-31,
due to be released later today.
Best,
-Don
On 04/11/11 07:23, Martin Paul wrote:
Just
a reminder - Solaris 9 has entered vintage support now. The new
kernel patch 122300-61/122301-60 is the first one that requires
"Vintage Solaris" support for download and is therefore not
available via a standard Solaris support contract.
Those of you which still run Solaris 9 systems might want to keep
a copy of the patchdiag.xref from Oct/31/11.
Martin.
Martin Paul wrote:
Solaris 9 will transition to "Vintage"
Support at the end of October. This means that any Solaris 9
patches (or patch revisions) released from Nov 1st onwards will
require "Vintage" support level. Details on Gerry Haskins' blog:
http://blogs.oracle.com/patch/entry/solaris_9_transitioning_to_extended
--
Don O'Malley
Manager,Patch System Test
Revenue Product Engineering | Solaris | Hardware
East Point Business Park, Dublin 3, Ireland
Phone: +353 1 8199764
Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] Solaris 9 transitioning to Extended Support
On 04/11/11 16:24, Don O'Malley wrote:
Hi,
The latest Solaris 9 KUs will not require an Extended Support
contract.
Let me rephrase...
The latest Solaris 9 KUs should not require an Extended
Support contract.
We hit a minor bug with our entitlement code, which we've now
corrected. These patches will become available under standard
Solaris support overnight.
Apologies for the confusion.
Best,
-Don
We have put an exception in place for these KUs as they were in
the our pipeline before Solaris 9 entered Extended support.
The only other patch that will be treated similarly is 115553-31,
due to be released later today.
Best,
-Don
On 04/11/11 07:23, Martin Paul wrote:
Just
a reminder - Solaris 9 has entered vintage support now. The new
kernel patch 122300-61/122301-60 is the first one that requires
"Vintage Solaris" support for download and is therefore not
available via a standard Solaris support contract.
Those of you which still run Solaris 9 systems might want to
keep a copy of the patchdiag.xref from Oct/31/11.
Martin.
Martin Paul wrote:
Solaris 9 will transition to "Vintage"
Support at the end of October. This means that any Solaris 9
patches (or patch revisions) released from Nov 1st onwards
will require "Vintage" support level. Details on Gerry
Haskins' blog:
http://blogs.oracle.com/patch/entry/solaris_9_transitioning_to_extended
--
Don O'Malley
Manager,Patch System Test
Revenue Product Engineering | Solaris | Hardware
East Point Business Park, Dublin 3, Ireland
Phone: +353 1 8199764
Team Alias: rpe_patch_system_test...@oracle.com
--
Don O'Malley
Manager,Patch System Test
Revenue Product Engineering | Solaris | Hardware
East Point Business Park, Dublin 3, Ireland
Phone: +353 1 8199764
Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] Non-existing patch
Hi Martin, Martin Paul wrote: Hi Don, After investigation it turns out that the database could not handle an update to the actual 'requires' field, as there is an integrity check in place to ensure that the 'requires' field is consistent with the info in the pkginfo SUNW_REQUIRES filed (which patchadd uses to resolve patch dependencies). Essentially, this check prevents us updating the database's patch requirements. So the obvious solution - updating the SUNW_REQUIRES field itself - is not an option either, I guess? Not possible or desirable. The patch deliverables cannot be changed once a patch is submitted for testing. This is to ensure that we test what we release and release what we test. This also ensures that only one version of any given patch can exist. This is one of the fundamental rules regarding our release management. Or wouldn't it be possible to add information about 126677 to the patch database? At the end, not much more information than "obsoleted by 124628-03" would be needed, which would then show up in patchdiag.xref, too? This is an option that we are investigating. The problem we face is that our process needs to be extremely robust, so any solution that we try to put in place is future-proof as well as backward compatible, so nothing gets broken (or abused down the line, leading to further complications). In addition, we need to be very careful that all the systems that use the patch metadata we generate (eg. Oracle Enterprise Manager Ops Center, smpatch, MOS) do not get negatively impacted by any changes we make. What I'm trying to convey is that it is not just a case of seeing a problem and putting something in place to fix it; we need to look at the problem from all angles and patchdiag is only one small cog in the wheel. Best, -Don Hope this makes sense! Kind of. Although sometimes I'm glad that certain things don't make sense to me; understanding too much might lead to insanity :) Martin. -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] Non-existing patch - patchdiag wishlist
Hi, So, let me ask this question a slightly different way; what information do you feel you are not getting from patchdiag.xref today? The items that I have on my PCA wishlist/additions are: Patches' product mappings (eg. Solaris 10 Operating System, Solaris Cluster 3.3) Patch's entitlement(s) - eg. OS, SW, FMW, VIN - see MOS - Sun Patch Entitlement for details Zipped patch md5sum Patch properties (rebootafter, etc.) Patch size (zipped) "New Security Fix" flag to identify specific patch revisions that deliver new security fixes (as opposed to new or accumulated security fixes, which the current 'S' flag maps to) "Patch Utility" flag to identify patches required for the full patch utility functionality (i.e. patchadd/patchrm) "Live Upgrade" flag to identify patches required for full live upgrade functionality (i.e. MOS- LU Patch Requirements) SunAlert "Data Loss" and "Availability" flags to identify patches that address "Data Loss" and "Availability" issues (i.e. Weekly Sun Alert Report 2011) Identify architecture on a per pkg basis and have a pkg_name:pkg_version:pkg_arch triplet, rather than the current pkg_name:pkg_version pair (which has arch in a separate field) Assuming we could sort out the patch requirements for non-released patches we were initally discussing and introduce some/all of the above, are there other items missing? Best, -Don Thomas Gouverneur wrote: This sounds to me like an incredible good idea. Don ? On Fri, 28 Oct 2011 15:36:06 +0200 Martin Paul mar...@par.univie.ac.at wrote: *IF* the XML interface proves to be fast and stable, and *IF* Oracle would allow outsiders to offer the contained information (which they don't now, AFAIK), one could think about a service which would get the xref file plus all the extra information from the XML links, combine it into an extended xref file with some new columns, and offer that file, reliable and daily. Like that, the information harvesting at least would have to be done only once, and not by every PCA user. -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] Non-existing patch
Hi Martin, The addition of this note is the result of a looong email thread internally. We were discussing whether we could internally update the backing database which generates patchdiag or not. After investigation it turns out that the database could not handle an update to the actual 'requires' field, as there is an integrity check in place to ensure that the 'requires' field is consistent with the info in the pkginfo SUNW_REQUIRES filed (which patchadd uses to resolve patch dependencies). Essentially, this check prevents us updating the database's patch requirements. For this reason the README update was seen as the best possible alternative... I know it may sound a bit OTT that we cannot override these things, but when you need an extremely scalable solution (as we clearly do with over 30,000 patches available), then each error opportunity you introduce by allowing such audits to be overridden has a massive multiplier effect when you consider the number of individual patches that could have an issue as a result. Bottom line is that the potential cost far outweighs the potential gain. Thanks for sending on the list of additional patches with similar defects; I'll ensure they get similar README updates to indicate the replacement requirements. Hope this makes sense! Best, -Don On 28/10/11 11:11, Martin Paul wrote: Hi Don and all, In the READMEs of the new patches 124630-60 and 119534-29 a note has been added: NOTE: The list of 'patches required with this patch' (above) has been modified from the list specified at patch creation time. The reason for the modification is that one or more of the required patches was either never released or withdrawn after its release. The following substitutions (which are guaranteed to satisfy the original requirements) were therefore made: 124628-03 replaces 126677-02 This replacement is a good thing, but unfortunately it has only taken place in the README and not in the "patchinfo" files nor in patchdiag.xref - those still refer to 126677-02 (which, as the note says, has never been released). Now PCA has always taken care of that by internally replacing 126677-02 with 124628-03 when resolving dependencies, so there's no new problem. It would be nice, though, now that the problem has been noticed, to fix this issue in all places (patch README, patchinfo, patchdiag.xref) to make this consistent again. The same applies to the corresponding x86 patches, BTW (non-existant 126678 required by 124631 and 119535). And just for completeness, here is the list of all non-existant patches to be found as required patches in patchdiag.xref, and how they are taken care of in PCA: ($r eq "125077-02") ($r="120011-09"); # 119757 ($r eq "125078-02") ($r="120012-10"); # 119758 ($r eq "125486-01") ($r="120011-14"); # 126206 ($r eq "125487-01") ($r="120012-14"); # 126207 ($r eq "114431-03") ($r="117172-17"); # 116473 Read like this: Patch 119757 requires 125077-02, which doesn't exist, so it should require 120011-09 instead. Martin. -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] patchdiag.xref inconsistency
Hi Martin,
I followed up with the team that generates patchdiag on Friday.
There was a recent code change to better handle EOL patches that
triggered the issue you reported on Friday.
All should be fixed now.
Best,
-Don
On 03/10/11 08:12, Martin Paul wrote:
Don
O'Malley wrote:
That said, something has happened to
trigger 119081-25 being marked as obsolete (I suspect this is a
result of an internal process).
In the current patchdiag.xref (Oct/02/11) the state of 119081-25
has been reverted to active (not obsolete) again. Same for the
other 7 patches that were affected (106922, 108982, 109082,
109647, 117662, 117851, 119070). So everything is fine again.
I also checked for other possible problematic patches with this
command:
grep '|O|' patchdiag.xref | egrep -vi "Obsoleted by|withdrawn"
It only comes up with 4 old revisions of 118822 now, which are
marked Obsolete and Bad, which is not a problem.
If you ever find an explanation for how this happened, I'd be
interested to hear about it!
Martin.
--
Don O'Malley
Manager,Patch System Test
Revenue Product Engineering | Solaris | Hardware
East Point Business Park, Dublin 3, Ireland
Phone: +353 1 8199764
Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] patchdiag.xref inconsistency
Hi Martin, I'll investigate. In a nutshell the relationship between patches 119081-25 124628-14 is that patch 119081-xx was rejuvenated into patch 124628-xx. Patch rejuvenation is explained a the top of http://blogs.oracle.com/patch/entry/solaris_10_kernel_patchid_progression That said, something has happened to trigger 119081-25 being marked as obsolete (I suspect this is a result of an internal process). I can confirm that there is no patch that obsoletes 124628-xx. Stay Tuned! Best, -Don Martin Paul wrote: In today's patchdiag.xref, patch 119081-25 is suddenly marked as "Obsolete". nut there is no sign by which patch it would have been obsoleted: usually, the synopsis (last column in xref file) contains a note "Obsoleted by xx-xx". As there are two patches which require 119081-25 (namely 124628-14 and 124630-58) this leads to a situation, where patch dependencies can not be resolved. Don - can you check whether the obsoletion of 119081-25 was an error? Or maybe 124628-14 obsoletes 119081-25, but its README and patchinfo file contradict. Martin. -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] Can not exclude 144500-19!?
Hi Robert, I'll leave the whitelist/blacklist stuff to Martin. I'm more interested in why you're ending up in the panic loop! Are you running EMC PowerPath? If so - check out https://support.oracle.com/CSP/main/article?cmd=showtype=NOTid=1358671.1 We have also seen similar nasty reactions to 144500-19 with the following multipathing products: Hitachi HDS Falconstor Dynapath CA Access Control SeOS It seems like in all cases the problem occurs when the multipathing product uses a private Solaris interface, which patch 144500-19 changes. Bottom line is that patch 144500-19 is not compatible with the effected products. To try prevent customers hitting the most prevalent of these issues, which is EMC PowerPath, we have worked with EMC to construct logic which will prevent patch 144500-19 from applying to susceptible systems. This logic is delivered in patch 12-11 (released Monday 19th September). This patch is now in the Recommended Patchset. HTH, -Don Tate, Robert B wrote: Installing this patch puts many of our systems into endless reboots. I have used the following command line to try and exclude this patch (and some others), but it still shows up in the lists. I found a white list in the program which seems to override my commands. Is this correct? How can I get around this? I cannot allow this to be installed until this is fixed and cant get pca to not install it. To get a listing, this is what I use: /usr/tools/adm/SunOS/bin/pca -y -X/usr/tools/adm/SunOS/pca \ --pattern="!VRTS|VERITAS|NetBackup|VxVM|SYMC" \ --ignore=144500-19 --ignore=121430-66 --ignore=127655-07 -l (/usr/tools is a commen NFS mounted tools area we use). - L Robert B. Tate UNIX Systems Administrator, Stf Lockheed Martin - EBS Enterprise BusinessServices Engineering and Computing UNIX Systems Support (ECUSS) Email: mailto:robert.b.t...@lmco.com Office Phone: (407) 306-2720(M-Thu) Home Phone: (407) 830-7319 (Fri) Faster, Cheaper, Reliable: Pick any two. -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] EXTERNAL: Re: Can not exclude 144500-19!?
Hi Bob, All patch 12-11 will do is prevent customers with EMC PowerPath installed from shooting themselves in the foot by installing patch 144500-19 (it will actually prevent installation of 144500-19 on systems that have affected versions of EMC PowerPath installed). In addition, 12-01 does not have similar logic for the Hitachi, Falcon, Dynapath or CA products. Patch 12-11 does not fix the issue. This is not something which can be fixed by Oracle. Instead it is up to each ISV that has coded against private interfaces in Solaris to produce a hotfix for the issue. In the case of EMC, the date I heard for a hotfix for EMC PowerPath was the 7th October. To get further information you need to follow up with the ISV in question. NOTE 9 of "Special Install Instructions" section of the README for 144500-19 is specifically related to this issue: NOTE 9: Currently released EMC PowerPath versions (as of August 18th 2011) are incompatible with this patch. Do not install this patch on systems running EMC PowerPath, until EMC provides a fix for this issue. EMC is working on a fix to resolve this issue and have published ETA emc275344 on https://powerlink.emc.com which contains further information. To prevent this kernel patch from being installed on systems with incompatible PowerPath versions, please first install the following patch: 12-11 (or greater) patch behavior patch HTH, -Don Tate, Robert B wrote: We are running EMC PowerPath and also have Hitachi HDS on some of the servers here. The Panic loop happened last week on the 17th so the new patch wasnt out yet. I will look at 12-11 and make sure it is applied before 144500-19 is attempted. Thank you Don Bob Tate From: pca-boun...@lists.univie.ac.at [mailto:pca-boun...@lists.univie.ac.at] On Behalf Of Don O'Malley Sent: Thursday, September 22, 2011 6:50 AM To: PCA (Patch Check Advanced) Discussion Subject: EXTERNAL: Re: [pca] Can not exclude 144500-19!? Hi Robert, I'll leave the whitelist/blacklist stuff to Martin. I'm more interested in why you're ending up in the panic loop! Are you running EMC PowerPath? If so - check out https://support.oracle.com/CSP/main/article?cmd=showtype=NOTid=1358671.1 We have also seen similar nasty reactions to 144500-19 with the following multipathing products: Hitachi HDS Falconstor Dynapath CA Access Control SeOS It seems like in all cases the problem occurs when the multipathing product uses a private Solaris interface, which patch 144500-19 changes. Bottom line is that patch 144500-19 is not compatible with the effected products. To try prevent customers hitting the most prevalent of these issues, which is EMC PowerPath, we have worked with EMC to construct logic which will prevent patch 144500-19 from applying to susceptible systems. This logic is delivered in patch 12-11 (released Monday 19th September). This patch is now in the Recommended Patchset. HTH, -Don Tate, Robert B wrote: Installing this patch puts many of our systems into endless reboots. I have used the following command line to try and exclude this patch (and some others), but it still shows up in the lists. I found a white list in the program which seems to override my commands. Is this correct? How can I get around this? I cannot allow this to be installed until this is fixed and cant get pca to not install it. To get a listing, this is what I use: /usr/tools/adm/SunOS/bin/pca -y -X/usr/tools/adm/SunOS/pca \ --pattern="!VRTS|VERITAS|NetBackup|VxVM|SYMC" \ --ignore=144500-19 --ignore=121430-66 --ignore=127655-07 -l (/usr/tools is a commen NFS mounted tools area we use). - L Robert B. Tate UNIX Systems Administrator, Stf Lockheed Martin - EBS Enterprise BusinessServices Engineering and Computing UNIX Systems Support (ECUSS) Email: mailto:robert.b.t...@lmco.com Office Phone: (407) 306-2720(M-Thu) Home Phone: (407) 830-7319 (Fri) Faster, Cheaper, Reliable: Pick any two. -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] patchdiag.xref feature request for Don
Sorry for the delay replying to this mail...
I do maintain a 'patchdiag.xref wishlist' myself too :-)
On 08/09/11 08:59, Martin Paul wrote:
dpecka
wrote:
i'm suggesting to think about these
fields:
- patch bundle
I have raised discussions about creating a patchdiag.xref
corresponding to each Solaris Update patch bundle previously. I
assume that's what is meant by patch bundle above, right?
I couldn't get commitment to create them.
I thought that someone on the PCA alias had come up with a mechanism
to create a patchdiag.xref from any given set of patches?
That aside, by installing the Patchsets that Oracle create you do
get the benefit of the installpatchset script that my team created.
- readme md5sum
These are not generated anywhere currently AFAIK.
- zipped patch md5sum
Available from:
https://updates.oracle.com/reports/CHECKSUMS
or on a per-patch basis - eg.
https://updates.oracle.com/Orion/Services/search?bug=120068-02 (see
http://blogs.oracle.com/patch/entry/useful_patch_related_downloads
for further info).
Agree it would be useful in patchdiag.xref too.
I'll add these from my wishlist:
- patch properties (rebootafter, etc.)
Already have this one on my list!
-
patch size (zipped/unzipped)
I have this on my list (definitely the zipped filesize anyway).
-
a new flag "always install first" for the patch utilities patches
etc.
So, what you need is a patch utilities flag then!
Patches required for Live Upgrade to function correctly too perhaps?
I can't think of any other "always install first" scenarios
off-hand.
-
include all patch revisions, not just the latest
Would this not make it more difficult for you to extract the latest
rev?
It'll certainly grow the filesize considerably (We have 30,000
patches currently available).
and then make PCA the official Solaris patch tool. and BTW, peace
on earth would be nice, too :)
:-)
Best,
-Don
Martin.
--
Don O'Malley
Manager,Patch System Test
Revenue Product Engineering | Solaris | Hardware
East Point Business Park, Dublin 3, Ireland
Phone: +353 1 8199764
Team Alias: rpe_patch_system_test...@oracle.com
[pca] How to keep up to date with new SunAlerts
Hi, I just came across the following information at the bottom of the Weekly Sun Alert Report 2011 (https://support.oracle.com/CSP/main/article?cmd=showtype=NOTid=1021776.1) which explains how you can subscribe to receive notification of new SunAlerts, which I thought some of you might be interested in... I've just set this up myself! If I pick up any tips I'll let you know :-) Best, -Don To receive daily notifications of Sun Alert releases (and other Knowledge Articles) including this report, the "Hot Topics" option must be configured for MOS "Flash": Configuring support.oracle.com 1. Go to url https://support.oracle.com/CSP/ui/flash.html 2. Sign in (Oracle employees can use their Single Sign on) 3. Select the tab "More..." -- Settings 4. Select "Hot Topics E-Mail" on the left 5. Update the Hot Topics Settings 1. Toggle the E-Mail to 'On' 2. Ensure set "Send Every 1 Days" 3. Select desired format (text or HTML) 4. Set the item limit to some number larger than 5 (suggest 25) 5. Set Service Request to "None" 6. leave "Product Bugs Marked as Favorites" deselected 6. Add the needed Sun Alert Filter(s) ** Note: To receive all Sun Alerts, use the following filter ** 7. Select "Add..." (new window will pop up) 1. Add the Product "Solaris SPARC Operating System" 2. Add the Platform "GENERIC (All Platforms)" 3. Check the "Knowledge Articles" box 4. Check the "Alerts" box 5. Select "OK" (selection window closes) 8. Select "Save" 1. You should be able to see your Hot Topics filter you just set up. 9. Log out of MOS -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] [[slightly] off-topic Warning]: Solaris 10 SPARC patch 144500-19 and EMC PowerPath
Hi Loris/All, Firstly, apologies that you found this out the hard way. I am in the process of getting a README note added to this KU to warn customers of the issue. This is a late breaking issue that we are currently investigating in partnership with EMC. The cause of this issue is that EMC PowerPath is using private interfaces in Solaris, which Oracle have changed in the latest KU deliverables. While it is not strictly an Oracle problem, we are doing everything we can to find a good solution for our customers that use EMC PowerPath. I will keep the PCA alias in the loop as I know more. Please bear with us. Best, -Don On 18/08/11 09:50, loris.ser...@bnymellon.com wrote: Just FYI, Installing kernel patch 144500-19 on a system with PowerPath will throw the box in a CPU panic boot loop. (learned this the hard way) https://forums.oracle.com/forums/thread.jspa?messageID=9792685 Regards, Loris The information contained in this e-mail, and any attachment, is confidential and is intended solely for the use of the intended recipient. Access, copying or re-use of the e-mail or any attachment, or any information contained therein, by any other person is not authorized. If you are not an intended party to this communication, please notify the sender and delete/destroy any and all copies of this communication. Although we attempt to sweep e-mail and attachments for viruses, we do not guarantee that either are virus-free and accept no liability for any damage sustained as a result of viruses. There are some inherent risks with exchanging e-mails. You understand and agree that we are not, and will not be, responsible for the unauthorized access, interception, or redirection of e-mails including any attachments, nor will we be responsible for the effect on any computer system of any e-mails or attachments. You als! o agree that we will not be responsible for the incorrect or incomplete transmission of information by e-mail The information contained in this communication is not intended or construed as an offer, solicitation, or a recommendation to purchase any security. Opinions, suggestions or views presented in this communication are not necessarily those of The Bank of New York Mellon Corporation or any of its affiliates. Please refer to http://disclaimer.bnymellon.com/eu.htm for disclosures relating to European legal entities -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] [[slightly] off-topic Warning]: Solaris 10 SPARC patch 144500-19 and EMC PowerPath
Hi Martin,
Nope, this is unrelated.
The S10U10 images should never have been made available for download
last Friday. That was the reason that they were pulled!
To re-iterate this EMC issue is not a problem with Solaris per se,
but rather a problem with vendors using private interfaces as public
ones. Then Oracle update one of the private interfaces and all hell
breaks loose.
I'm not trying to get into a finger pointing exercise here, as I
realise that this does not help our customers running Solaris and
EMC PowerPath (though other vendors do also appear to be impacted),
but it is important to explain what went wrong here.
John Horne's indication that "Falcon IPStor with DynaPath" is the
first I've heard that of that product being impacted, though I have
seen reports that a similar issue may affect the "Hitachi Dynamic
Link Manager".
Best,
-Don
On 18/08/11 12:50, Martin Paul wrote:
Don
O'Malley wrote:
This is a late breaking issue that we are
currently investigating in partnership with EMC.
Is this by chance the reason why Solaris 10u10 was pulled, after
the ISOs were available for download for a few hours last Friday?
Martin.
--
Don O'Malley
Manager,Patch System Test
Revenue Product Engineering | Solaris | Hardware
East Point Business Park, Dublin 3, Ireland
Phone: +353 1 8199764
Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] [[slightly] off-topic Warning]: Solaris 10 SPARC patch 144500-19 and EMC PowerPath
Hi Bob, The problem here is not with the patch (or Solaris). Without going down the finger-point route, the problem is a result of EMC PowerPath using private interfaces in Solaris, Oracle subsequently updating them and bang... Only customers running EMC PowerPath have currently confirmed they have the issue. Oracle will not withdraw the Solaris 10 KU patch for this. The following note is being added to 144500-19 to warn EMC customers about the issue: Do not install this patch on systems running EMC PowerPath, as all currently released EMC PowerPath versions (as of August 18th 2011) are incompatible with this patch. EMC PowerPath is using a private Solaris structure which was modified in this patch to fix a race condition. Applications should not use private Solaris interfaces as they are subject to change. EMC PowerPath Engineering is working on a 5.3 patch release to resolve this issue and have published ETA emc275344 on https://powerlink.emc.com, which contains further information. Best, -Don On 18/08/11 16:50, Wickline, Bob (N-STERLING COMPUTERS CORPORATION) wrote: This may be a stupid question but wouldnt something like this warrant pulling/recalling the patch??? From: pca-boun...@lists.univie.ac.at [mailto:pca-boun...@lists.univie.ac.at] On Behalf Of Don O'Malley Sent: Thursday, August 18, 2011 4:31 AM To: PCA (Patch Check Advanced) Discussion Cc: loris.ser...@bnymellon.com; sunmanag...@sunmanagers.org Subject: EXTERNAL: Re: [pca] [[slightly] off-topic Warning]: Solaris 10 SPARC patch 144500-19 and EMC PowerPath Hi Loris/All, Firstly, apologies that you found this out the hard way. I am in the process of getting a README note added to this KU to warn customers of the issue. This is a late breaking issue that we are currently investigating in partnership with EMC. The cause of this issue is that EMC PowerPath is using private interfaces in Solaris, which Oracle have changed in the latest KU deliverables. While it is not strictly an Oracle problem, we are doing everything we can to find a good solution for our customers that use EMC PowerPath. I will keep the PCA alias in the loop as I know more. Please bear with us. Best, -Don On 18/08/11 09:50, loris.ser...@bnymellon.com wrote: Just FYI, Installing kernel patch 144500-19 on a system with PowerPath will throw the box in a CPU panic boot loop. (learned this the hard way) https://forums.oracle.com/forums/thread.jspa?messageID=9792685 Regards, Loris The information contained in this e-mail, and any attachment, is confidential and is intended solely for the use of the intended recipient. Access, copying or re-use of the e-mail or any attachment, or any information contained therein, by any other person is not authorized. If you are not an intended party to this communication, please notify the sender and delete/destroy any and all copies of this communication. Although we attempt to sweep e-mail and attachments for viruses, we do not guarantee that either are virus-free and accept no liability for any damage sustained as a result of viruses. There are some inherent risks with exchanging e-mails. You understand and agree that we are not, and will not be, responsible for the unauthorized access, interception, or redirection of e-mails including any attachments, nor will we be responsible for the effect on any computer system of any e-mails or attachments. You als! o agree that we will not be r esponsible for the incorrect or incomplete transmission of information by e-mail The information contained in this communication is not intended or construed as an offer, solicitation, or a recommendation to purchase any security. Opinions, suggestions or views presented in this communication are not necessarily those of The Bank of New York Mellon Corporation or any of its affiliates. Please refer to http://disclaimer.bnymellon.com/eu.htm for disclosures relating to European legal entities -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764
Re: [pca] Heads-up: New download service
Hi Jeff, To answer both questions: 1) Yes you can expect patch downlaods from limelight too, so aru-llnw.oracle.com and aru-llnw-dl.oracle.com should be added to firewall rules. 2) The dropoff in S10 patches is due to the upcoming release of S10U10. Best, -Don Jeff Earickson wrote: Paul, Don et al, I too am seeing the Limelight networks addresses and I am in the US, not Europe. My pca debug sessions hung on aru-llnw.oracle.com and aru-llnw-dl.oracle.com; I ended up adding 208.111.128.0/24 into my firewall rules to get pca working again. Paul, it would be nice if pca spit up a message if a URL connection times out, even if you are not running in debug mode. That would be a clue that either something was down at the Oracle end, or there is a change/firewall issue. Otherwise you tend to assume that things are working normally. Don, I have noticed a big drop-off in Solaris 10 patches in the past month to six weeks. Is this because a new release of Solaris 10 is about to happen? Jeff Earickson Colby College On Tue, Aug 2, 2011 at 9:03 AM, Martin Paul mar...@par.univie.ac.at wrote: Don O'Malley wrote: Everything went very smoothly, but you may notice that there is now an additional level of redirection added to patch downloads. Requests to getupdates.oracle.com now redirect to updates.oracle.com via login.oracle.com (for authentication). Downloads work for me, but it looks different from your example - at the end I'm getting the patch from "http://aru-llnw-dl.oracle.com/aaruna04/...". Was there a switch from akamai to limelight, or does this depend on where the client is coming from? Martin. -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] patchdiag.xref shrunk
Hi Martin,
When we first migrated patch metadata to MOS (in June 2009) we
never included metadata for patches for products that were EOSL.
As part of the recent MOS 5.3 release we have aligned patchdiag.xref
with the metadata available from MOS.
All of the patches that have disappeared have been for "housekeeping"
reasons, and IMO this is actually an improvement in patchdiag.xref.
We have endeavored to ensure that no dependency chains have been broken
in the cleanup, but if anyone spots any problems with the "cleaned"
patchdiag.xref, please let me know and I'll investigate.
Best,
-Don
Martin Paul wrote:
With
today's patchdiag.xref ("AS OF Jul/12/11") many patches have
disappeared from the file.
At a quick glance, it seems that it affects patches for old Solaris
versions (up to Solaris 7), patches for old unbundled software and
nearly all of the over 5000 unbundled "PTF/RMLS" patches. There are too
many diffs to check all of them manually, but I'm pretty sure that no
patches for reasonably recent software is affected.
Maybe Don can provide more detail, on which groups of patches have been
removed and why?
BTW - a quick comparison of the runtime of a typical PCA command shows
a speedup of about 40%, due to the reduced number of patches to
analyze.
Martin.
--
Don O'Malley
Manager,Patch System Test
Revenue Product Engineering | Solaris | Hardware
East Point Business Park, Dublin 3, Ireland
Phone: +353 1 8199764
Re: [pca] patchdiag.xref shrunk
Don O'Malley wrote:
Hi Martin,
When we first migrated patch metadata to MOS (in June 2009) we
never included metadata for patches for products that were EOSL.
That should be June 2010!
As part of the recent MOS 5.3 release we have aligned patchdiag.xref
with the metadata available from MOS.
All of the patches that have disappeared have been for "housekeeping"
reasons, and IMO this is actually an improvement in patchdiag.xref.
We have endeavored to ensure that no dependency chains have been broken
in the cleanup, but if anyone spots any problems with the "cleaned"
patchdiag.xref, please let me know and I'll investigate.
Best,
-Don
Martin Paul wrote:
With
today's patchdiag.xref ("AS OF Jul/12/11") many patches have
disappeared from the file.
At a quick glance, it seems that it affects patches for old Solaris
versions (up to Solaris 7), patches for old unbundled software and
nearly all of the over 5000 unbundled "PTF/RMLS" patches. There are too
many diffs to check all of them manually, but I'm pretty sure that no
patches for reasonably recent software is affected.
Maybe Don can provide more detail, on which groups of patches have been
removed and why?
BTW - a quick comparison of the runtime of a typical PCA command shows
a speedup of about 40%, due to the reduced number of patches to
analyze.
Martin.
--
Don O'Malley
Manager,Patch System Test
Revenue Product Engineering | Solaris | Hardware
East Point Business Park, Dublin 3, Ireland
Phone: +353 1 8199764
--
Don O'Malley
Manager,Patch System Test
Revenue Product Engineering | Solaris | Hardware
East Point Business Park, Dublin 3, Ireland
Phone: +353 1 8199764
Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] no xref file?
Hi Martin/All, There has been no patchdiag.xref released since July7th due to the MOS 5.3 release over the weekend. MOS 5.3 is a major release for ex-Sun customers, as this release integrated a more native experience for Sun patches on MOS. I realize that this may not be of interest to a lot of folks using PCA, but there are some significant changes as a result of the MOS 5.3 release, including: - Patch metadata is now available for Sun patches from the MOS patch information page, including patch size, # downloads checksum info. - Patch README files for Sun patches are now hosted natively by MOS (so there is no longer any need to punchout to sspatch for patch README's In order to enable this release, we needed to stop publishing patches (and reports like patchdiag.xref) over the weekend, so while there has been no updated version of patchdiag available, there has also been no additional patches released. Normal service should resume later today, so there'll be an updated version of patchdiag tomorrow. Sorry for any confusion. Best, -Don Martin Paul wrote: BABAULT.Daniel wrote: No problem for me patchdiag-110707.xref 07-Jul-2011 23:11 3.4M patchdiag-110708.xref 08-Jul-2011 23:11 3.4M patchdiag-110709.xref 09-Jul-2011 23:11 3.4M patchdiag-110710.xref 10-Jul-2011 23:11 3.4M But if you compare the files, you'll see that nothing has changed since Jul/07/11: $ pca -X . -x Downloading xref file to /tmp/patchdiag.xref Trying https://getupdates.oracle.com/ (1/1) $ head -1 patchdiag.xref ## PATCHDIAG TOOL CROSS-REFERENCE FILE AS OF Jul/07/11 ## $ Even when there are no new patches, the date in the header usually gets updated. Don? :) Martin. -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] ERROR 403: You are not entitled to retrieve this content..
I'll investigate now... Thomas Bleek wrote: same here:-( tb Am 11.07.2011 um 14:22 schrieb Martin Paul: przemol...@poczta.fm wrote: 2011-07-11 11:10:44 ERROR 403: You are not entitled to retrieve this content.. I get the same, for every patch I tried. Maybe another side effect of the MOS 5.3 roll-out mentioned by Don? Martin. -- Dr. Thomas Bleek, Netzwerkadministrator Helmholtz-Zentrum Potsdam Deutsches GeoForschungsZentrum Telegrafenberg G261 D-14473 Potsdam Tel.: +49 331 288- 1818/1681 Fax.: 1730 Mobil: +49 172 1543233 E-Mail: b...@gfz-potsdam.de -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] ERROR 403: You are not entitled to retrieve this content..
Is anyone ABLE to download patches via wget/PCA today? Best, -Don Rajiv Gunja wrote: Thanks Don. -- Rajiv G Gunja Blog: http://ossrocks.blogspot.com On Mon, Jul 11, 2011 at 09:35, Don O'Malley don.omal...@oracle.com wrote: I'll investigate now... Thomas Bleek wrote: same here:-( tb Am 11.07.2011 um 14:22 schrieb Martin Paul: przemol...@poczta.fm wrote: 2011-07-11 11:10:44 ERROR 403: You are not entitled to retrieve this content.. I get the same, for every patch I tried. Maybe another side effect of the MOS 5.3 roll-out mentioned by Don? Martin. -- Dr. Thomas Bleek, Netzwerkadministrator Helmholtz-Zentrum Potsdam Deutsches GeoForschungsZentrum Telegrafenberg G261 D-14473 Potsdam Tel.: +49 331 288- 1818/1681 Fax.: 1730 Mobil: +49 172 1543233 E-Mail: b...@gfz-potsdam.de -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] ERROR 403: You are not entitled to retrieve this content..
Hi,
Quick update on this.
The problem has been identified. I am waiting for an estimate for how
long this will take to fix and possible workarounds.
Apologies for the inconvenience, but in the interim all patches can be
downloaded directly from the "Patches Updates" section of MOS
(http://support.oracle.com).
Best,
-Don
Jeff Wieland wrote:
Doesn't
work for me either.
Jeff Earickson wrote:
Don,
I just moved a patch that I already had out of the way and ran "pca -d
-i -n" to pull it again. Rejected, not authorized.
Jeff Earickson
Colby College
On Mon, Jul 11, 2011 at 9:52 AM, Don O'Malley
don.omal...@oracle.com wrote:
Is anyone ABLE to download patches via
wget/PCA today?
Best,
-Don
Rajiv Gunja wrote:
Thanks Don.
--
Rajiv G Gunja
Blog: http://ossrocks.blogspot.com
On Mon, Jul 11, 2011 at 09:35, Don O'Malley
don.omal...@oracle.com wrote:
I'll investigate now...
Thomas Bleek wrote:
same here:-(
tb
Am 11.07.2011 um 14:22 schrieb Martin Paul:
przemol...@poczta.fm wrote:
2011-07-11 11:10:44 ERROR 403: You are not entitled to retrieve this
content..
I get the same, for every patch I tried.
Maybe another side effect of the MOS 5.3 roll-out mentioned by Don?
Martin.
--
Dr. Thomas Bleek, Netzwerkadministrator
Helmholtz-Zentrum Potsdam
Deutsches GeoForschungsZentrum
Telegrafenberg G261
D-14473 Potsdam
Tel.: +49 331 288- 1818/1681 Fax.: 1730 Mobil: +49 172 1543233
E-Mail: b...@gfz-potsdam.de
--
Don O'Malley
Manager,Patch System Test
Revenue Product Engineering | Solaris | Hardware
East Point Business Park, Dublin 3, Ireland
Phone: +353 1 8199764
Team Alias: rpe_patch_system_test...@oracle.com
--
Don O'Malley
Manager,Patch System Test
Revenue Product Engineering | Solaris | Hardware
East Point Business Park, Dublin 3, Ireland
Phone: +353 1 8199764
Team Alias: rpe_patch_system_test...@oracle.com
--
Don O'Malley
Manager,Patch System Test
Revenue Product Engineering | Solaris | Hardware
East Point Business Park, Dublin 3, Ireland
Phone: +353 1 8199764
Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] ERROR 403: You are not entitled to retrieve this content..
Normal service seems to be resumed! Sorry for the inconvenience! Best, -Don Glen Gunselman wrote: Don, I just downloaded a firmware patch for the T5220: /var/tmp/pca --download 147307-01 --patchdir="/var/tmp/pcatmp" Using /var/tmp/patchdiag.xref from Jul/07/11 Host: zoot (SunOS 5.10/Generic_142900-05/sparc/sun4v) List: 147307-01 (1/0) Patch IR CR RSB Age Synopsis -- -- - -- --- --- --- 147307 -- 01 --- 45 FIRMWARE: SPARC Enterprise T5120+T5220 - Sun System Firmware 7.4.0 Looking for 147307-01 (1/1) Trying Oracle Please enter My Oracle Support Account User: Please enter My Oracle Support Account Password: Trying https://getupdates.oracle.com/ (1/1) Done -- Download Summary: 1 total, 1 successful, 0 skipped, 0 failed I did not try any downloads that failed. Thanks, Glen Gunselman Systems Software Specialist TCS Emporia State University From: pca-boun...@lists.univie.ac.at [mailto:pca-boun...@lists.univie.ac.at] On Behalf Of Don O'Malley Sent: Monday, July 11, 2011 10:37 AM To: Glen Gunselman; PCA (Patch Check Advanced) Discussion Subject: Re: [pca] ERROR 403: You are not entitled to retrieve this content.. Hi Jeff/All, The issue should be resolved now! Could folks do a quick download test of a single patch to confirm? (Jeff, you're a step head of us!) If a couple of folks could just reply to let us know it's working I can feed this back to the Engineering team... (...snip) -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] Oracle removed support from patchdiag.xref for --minimal option in pca?
Hi Jeff, The Oracle Patch Strategy Best Practice is to download and install the CPU (ideally to an Alternate Boot Environment). The CPU does have the advantage of having an excellent install script (written by Ed Clark; a Senior Engineer on my team) and is tested by my team prior to release; two excellent reasons why we recommend that customers use it! It also supports application to an Alternate Boot Environment (ABE). (I know PCA supports patch application to an ABE too...) PCA is a third-party tool, which Martin kindly maintains and makes freely available, so is not the recommended way to apply the CPU. There is no special copy of the patchdiag.xref from the recommended patch cluster the CPU is cut from made available. (The day the CPU is released is not accurate, as we need to cut the CPU a week before to allow time to test.) I know that previously Chris Reece released a tool called Mkpcadir, which created a patchdiag.xref based on the directory structure of the EIS (Enterprise Installation Standards) DVD. I do not know if someone else has created a similar tool that would do something similar for patch clusters??? Each Patch Cluster (eg. Recommended Patch Cluster, CPU Patch Cluster) that Oracle produces does contain a patch_list file, which is a flat file listing the patches the cluster delivers in the order in which they should be applied. I'm not 100% sure of the correct syntax to use with PCA, but I think you should be able to rename this file patchlist.txt and provide it as an input to PCA. Perhaps Martin or someone else could confirm... HTH, -Don Jeff wrote: Guess I didn't understand that was the purpose of --minimal. So based on your answer, there is no way to follow the Oracle Best Practices patch strategy of applying the CPU between update releases using pca? Except maybe grabbing the patchdiag.xref on the day the CPU is released and comparing the patch revisions between patchdiag and the CPU? On Fri, May 27, 2011 at 4:59 AM, Don O'Malley don.omal...@oracle.com wrote: Hi Jeff, The --minimal option never mapped to the contents of the CPU. The --minimal option is mapped to the Recommended Patch Cluster contents, not the CPU. The CPU is effectively an archived version of the Recommended Patch Cluster, so the 2 are closely related. That said, with changes that we made to merge the Recommended Patch Cluster and former Sun Alert Cluster (see Patch Corner - Merging the Solaris Recommended and Sun Alert Patch Clusters for the details), we now only add the lowest revision of a patch required to address SunAlert issues (Security, Data Loss and System Availability). This means that over time customers need to apply less patches to keep up to date with critical fixes. This is the reason that some patches in patchdiag.xref that are Recommended are now longer the latest revs of patches. The only exception to this rule is patches required for the patch utilities on Solaris to function correctly; these patches (eg. 119254) are always kept at the latest available revision. HTH, -Don Jeff wrote: I've been using the --minimal option for pca since it came out to standardize patching based on the most recent CPU. Today I noticed that is looks like Oracle dropped support for in in patchdiag.xref. I'm using the patchdiag.xref I downloaded on May 15th and trying to apply the patches from the April/2011 CPU using pca. I find these patch discrepancies between what is in the CPU and what is in patchdiag.xref: April CPU patchdiag 119254-80 119254-81 122911-24 122911-25 125215-03 125215-04 141552-03 141552-04 143559-07 143559-08 144488-11 144488-14 Previously, patdiag.xref would list both the version of the patch that was in the CPU and the most recent version. Guess the question is to Martin or Don: Do you know if this is intentional? -- Jeff -- Don O'Malley Manager, Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com -- Jeff -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
[pca] Apologies in advance :)
Hi, I'll be on vacation for the next two weeks and my vacation mail is a little over enthusiastic at the best of times... Apologies in advance for the mails that will be sent to the PCA alias over the next two weeks :-) Best, -Don
Re: [pca] getupdates.oracle.com now available for testing!
Hi Martin/All, I was just about to send out a mail about this; looks like you've beaten me to it! Yes, there was a typo with the original mail that was sent out wrt README downloads, which the document now addresses. Also patch 119254-77 has now been released, so AFAICT it has been made public in place of 119254-76. I've retested this morning (using my test MOS SSO) and have successfully downloaded patches for 119318-01 112951-15 113713-28 119254-77 and their associated READMEs. If anyone is still having issues downloading any of the 4 patches listed above, or their READMEs please let me know. Here's the syntax that works for me: wget --http-user="" --http-passwd="" --no-check-certificate "https://getupdates.oracle.com/all_unsigned/119254-77.zip" -O /tmp/119254-77.zip wget --http-user="" --http-passwd="" --no-check-certificate "https://getupdates.oracle.com/readme/120068-02" -O /tmp/README.120068-02 Best, -Don Martin Paul wrote: Martin Paul wrote: Has anybody been successful in downloading a README file? Obviously there was an error in the InfoDoc. A note has been added: http://sunsolve.sun.com/search/document.do?assetkey=1-79-1199543.1-1 18 November 2010: * Corrected error in documentation for downloading readmes. The base URL should read https://getupdates.oracle.com/readme/patch_id. Using /readme/ instead of /readmes/ I could now download the READMEs of all 4 sample patches successfully. This works without specifying --http-user and --http-passwd, too. Martin. -- Don O'Malley Manager, Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] getupdates.oracle.com now available for testing! - certs q
Gerard Henry wrote: On 11/17/10 11:05, Don O'Malley wrote: I've tested downloading patchdiag.xref and 119254-76.zip, both using the certificate file and the --no-check-certificate option and everything looks good: bash-3.00# wget --http-user="" --http-passwd="" --ca-certificate=/tmp/WGET3_getupdates.pem"https://getupdates.oracle.com/reports/patchdiag.xref" -O /tmp/patchdiag.xref --09:49:59--https://getupdates.oracle.com/reports/patchdiag.xref hello, where did you get this certificate called /tmp/WGET3_getupdates.pem ? Is it important? I'm no security expert, but here's my understanding of the certificate info. You must provide 'wget' with direction on how to handle security certificate information. Otherwise, patch downloads via 'wget' will fail. The purpose of the certificates is for customers to be able to verify that the content that you are downloading from Oracle, has actually come from Oracle and has not been intercepted by a "man-in-the-middle" Domains, getupdates.oracle.com a248.e.akamai.net, are signed by trusted Certificate Authorities. (Verisign for Oracle's and GTE Cybertrust for the case of Akamai.) Without a pointer to these certificates being provided to 'wget', download attempts will fail. Which certs are required? (These may have changed since the Oracle acquisition) CN=GTE CyberTrust Global Root CN=VeriSign Class 3 Secure Server CA - G2 What kind of error message can you expect to see from a failing 'wget' request? ERROR: Certificate verification error for getupdates.oracle.com: unable to get local issuer certificate To connect to getupdates.oracle.com insecurely, use `--no-check-certificate'. Unable to establish SSL connection. Issue resolution: If you wish to ignore this failure you can use the '--no-check-certificate' switch in 'wget'. Example of the syntax: # /usr/sfw/bin/wget --http-user="" --http-passwd="xxx" --no-check-certificate "https://getupdates.oracle.com/all_unsigned/119254-77.zip" -O /tmp/119254-77.zip If you wish to check against the certificates, you can use the '--ca-certificate' switch to point to a file containing the certificates. http://sunsolve.sun.com/search/document.do?assetkey=1-79-1199543.1-1 has an attachment called WGET3_getupdates.pem, which is a concatenation of the two certificates. If you save this file locally (eg to /tmp/cacerts.pem), you can use a syntax similar to: # /usr/sfw/bin/wget --ca-certificate=/tmp/cacerts.pem --http-user="" --http-passwd="xxx" "http://sunsolve.sun.com/pdownload.pl?target=142284method=h" -O /tmp/140778-01.zip HTH, -Don the following command works for me, with my valid account: $ wget --http-user="xx" --http-passwd="xxx" --no-check-certificate "https://getupdates.oracle.com/all_unsigned/119254-76.zip" -O 119254-76.zip --17:12:10-- https://getupdates.oracle.com/all_unsigned/119254-76.zip = `119254-76.zip' Resolving getupdates.oracle.com... 192.18.110.9 Connecting to getupdates.oracle.com|192.18.110.9|:443... connected. WARNING: Certificate verification error for getupdates.oracle.com: unable to get local issuer certificate HTTP request sent, awaiting response... 302 Moved Temporarily Location: https://a248.e.akamai.net/f/248/21808/15m/sun.download.akamai.com/21808/patches/patchroot/all_unsigned/119254-76.zip?AuthParam=1290096781_9ed819b85c4f609ba7e00f2d9b7f3472TicketId=C19a%2FE6JV18%3DGroupName=SWUPFilePath=/21808/patches/patchroot/all_unsigned/119254-76.zipFile=119254-76.zip [following] --17:12:13-- https://a248.e.akamai.net/f/248/21808/15m/sun.download.akamai.com/21808/patches/patchroot/all_unsigned/119254-76.zip?AuthParam=1290096781_9ed819b85c4f609ba7e00f2d9b7f3472TicketId=C19a%2FE6JV18%3DGroupName=SWUPFilePath=/21808/patches/patchroot/all_unsigned/119254-76.zipFile=119254-76.zip = `119254-76.zip' Resolving a248.e.akamai.net... 193.51.224.7, 193.51.224.23 Connecting to a248.e.akamai.net|193.51.224.7|:443... connected. WARNING: Certificate verification error for a248.e.akamai.net: unable to get local issuer certificate HTTP request sent, awaiting response... 200 OK Length: 1,708,956 (1.6M) [application/zip] 100%[====] 1,708,956 897.62K/s 17:12:16 (894.74 KB/s) - `119254-76.zip' saved [1708956/1708956] -- Don O'Malley Manager, Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] getupdates.oracle.com now available for testing!
Hi Amy, Currently only the 4 patches explicitly listed in http://sunsolve.sun.com/search/document.do?assetkey=1-79-1199543.1-1 and their REAMDEs are available for customers to verify that they can access the system. All other patches and patch entitlement will be rolled out on the 10th December. Best, -Don amy.r...@tufts.edu wrote: don.omalley Also patch 119254-77 has now been released, so AFAICT it has been don.omalley made public in place of 119254-76. I noticed this yesterday and was able to download 119254-77 at that time. This is why I sarted to look at the status of the patches before the whole site started returning errors. With my support contract linked to my MOS account, shouldn't I be able to download patches that require entitlement, too, though? Maybe that hasn't been implemented yet? -- Don O'Malley Manager, Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] getupdates.oracle.com now available for testing!
Hi Rajiv, Rajiv Gunja wrote: Don, All of them fail for me, including the Xref file. I get these errors: Xref File: --2010-11-19 11:05:23-- https://a248.e.akamai.net/f/248/21808/15m/sun.download.akamai.com/21808/patches/patchroot/reports/patchdiag.xref?AuthParam=1290182758_a9a40aa3e570351d129bfd29146ca317TicketId=C19Y%2B0yKV14%3DGroupName=SWUPFilePath=/21808/patches/patchroot/reports/patchdiag.xrefFile=patchdiag.xref Resolving a248.e.akamai.net (a248.e.akamai.net)... failed: Name or service not known. wget: unable to resolve host address a248.e.akamai.net This is an internal network issue. Patch with Oracle SSO: Reusing existing connection to getupdates.oracle.com:443. HTTP request sent, awaiting response... 403 You are not entitled to retrieve this content. 2010-11-19 11:07:04 ERROR 403: You are not entitled to retrieve this content.. Which patch are you trying to download here? Will you cut and paste the wget command (with xxx for your passwd). Are you sure that this is using the Oracle SSO account credentials you have registered? Patch with Old sunsolve ID: Reusing existing connection to getupdates.oracle.com:443. HTTP request sent, awaiting response... 403 Service Error 2010-11-19 11:07:23 ERROR 403: Service Error. Your old Sun Onlkine Account info will not work with getupdates.oracle.com. I tried this from outside our Proxy. From behind the firewall, I am unable to resolve the getupdates.oracle.com This is an internal networking issue. Best, -Don -GGR -- Rajiv G Gunja Blog: http://ossrocks.blogspot.com On Thu, Nov 18, 2010 at 10:11, Don O'Malley don.omal...@oracle.com wrote: Hi, Is anyone having issues downloading any of the 4 sample patches? Please remember that you must register and use your Oracle Single Sign On (SSO) account (that you register for on My Oracle Support - http://support.oracle.com) as part of the wget requests to getupdates.oracle.com. i.e. --http-user and --http-passwd should be your Oracle SSO. I've seen 2 reports of issues on the PCA alias to date (from Martin Zube). Could you please cut and paste your wget requests into your reply if you are seeing issues ? (Remember to the --http-user and --http-passwd entries) Thanks! -Don Don O'Malley wrote: Hi Martin/All, The new patch download service - getupdates.oracle.com - is now available for testing. Details of how to use the new download service are available in the updated wget document - http://sunsolve.sun.com/search/document.do?assetkey=1-79-1199543.1-1. Please remember that you will need to resister for an Oracle SSO account on MOS (My Oracle Support - http://support.oracle.com) prior to being able to use the new download service, if you have not already done so. Here's an overview of that process: 1) Go to https://support.oracle.com/CSP/ui/flash.html (MOS) click "Register" in the green "Get Started" box 2) Complete required personal info to set up MOS SSO account. 3) Once you have gone through account setup successfully, wait a couple of minutes for your account to be setup and then login to MOS. 4) You are now redirected to MOS "User Registration", where you need to provide the following info: a) Support Contract Identifier agree to the Oracle Terms Of Use: Sun Customers should select the "Sun Contract Identifier" option and enter in their existing Sun Contract ID here. (You find your Sun Contract ID by logging into SunSolve with your existing Sun Online Account username/password and clicking the "Update Account" link on the top right of the page. Your Sun Contract Identifier(s) are the entries in the "Current Contracts:" field on this page.) b) Your contact information 5) When you've completed the Registration form (ensuring that you have a Green tick opposite "Support Identifier, Terms of Use"), click "Send" to complete registration receive confirmation that you have registered successfully. Please note that only the patches indicated in http://sunsolve.sun.com/search/document.do?assetkey=1-79-1199543.1-1 (119254-76, 119318-01, 112951-15, 113713-28) and patchdiag.xref can be downloaded as part of this preview. I've tested downloading patchdiag.xref and 119254-76.zip, both using the certificate file and the --no-check-certificate option and everything looks good: bash-3.00# wget --http-user="" --http-passwd="" --no-check-certificate "https://getupdates.oracle.com/reports/patchdiag.xref" -O /tmp/patchdiag.xref --09:48:39-- https://getupdates.oracle.com/reports/patchdiag.xref = `/tmp/patchdiag.xref' Resolving getupdates.oracle.com... 192.18.110.9 Connecting to getupdates.oracle.com|192.18.110.9|:443... connected. WARNING: Certificate verification error for getupdates.oracle.com: unable to get local issuer certificate
Re: [pca] Sunsolve retirement and actual state
All patch .zip downloads and their associated README's should now be available. Best, -Don Don O'Malley wrote: Hi Daniel/All, There was an issue with some patches that we discovered and fixed last week. This issue effected some unsigned (.zip) patch downloads. I thought that we'd caught and fixed all affected patches, but looks like we've missed some (those that were released at the time of the issue. I am investigating, but for now, if you need any of the affected patches below you can download the signed (.jar) versions of the patch. (Note: Unpack a .jar file using the unzip command) Example of syntax to download a jar file via wget: /usr/sfw/bin/wget --no-check-certificate --auth-no-challenge --http-user="" --http-passwd="xx" "https://sunsolve.sun.com/pdownload.do?target=124863-26method=hs" -O /tmp/124863-26.jar Apologies for any inconvenience. Best, -Don dpecka wrote: short list of todays patches which weren't been fetched but exist in patchdiag.xref file: 124863-26 124864-26 124865-25 126608-03 128224-11 133197-37 134008-44 135794-04 ave, daniel
Re: [pca] Sunsolve retirement and actual state
Hi Daniel/All, There was an issue with some patches that we discovered and fixed last week. This issue effected some unsigned (.zip) patch downloads. I thought that we'd caught and fixed all affected patches, but looks like we've missed some (those that were released at the time of the issue. I am investigating, but for now, if you need any of the affected patches below you can download the signed (.jar) versions of the patch. (Note: Unpack a .jar file using the unzip command) Example of syntax to download a jar file via wget: /usr/sfw/bin/wget --no-check-certificate --auth-no-challenge --http-user="" --http-passwd="xx" "https://sunsolve.sun.com/pdownload.do?target=124863-26method=hs" -O /tmp/124863-26.jar Apologies for any inconvenience. Best, -Don dpecka wrote: short list of todays patches which weren't been fetched but exist in patchdiag.xref file: 124863-26 124864-26 124865-25 126608-03 128224-11 133197-37 134008-44 135794-04 ave, daniel -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] Anyone seen 124864-26 ?
I'm looking into this one; should have it resolved by the end of the day today. Best, -Don Martin Paul wrote: Dennis Clarke wrote: http://sunsolve.sun.com/search/document.do?assetkey=1-21-124864-26-1 SunSolve Errors You have encountered the following error(s) or warning(s): * The document requested could not be found Anyone seen this? Yes, same here, it's still missing. You could try to use the "Feedback" link on the page to report it. If Don is listening, he might be able to do something about it, too. Martin. -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] Sunsolve retirement and actual state
Hi Jon, The issues are totally unrelated to the SunSolve retirement. Both patchdiag.xref and pca will continue to work once SunSolve is retired. This will require you to create an Oracle SSO account to access My Oracle Support (http://support.oracle.com) and subsequently provide your existing Sun Contract ID on initial login in order to be able to automate patch downloads via wget. You should be able to do this today by following these steps: 1) Go to https://support.oracle.com/CSP/ui/flash.html (MOS) click "Register" in the green "Get Started" box 2) Complete required personal info to set up MOS SSO account. 3) Once you have gone through account setup successfully, wait a couple of minutes for your account to be setup and then login to MOS. 4) You are now redirected to MOS "User Registration", where you need to provide the following info: a) Support Contract Identifier agree to the Oracle Terms Of Use: Sun Customers should select the "Sun Contract Identifier" option and enter in their existing Sun Contract ID here. (You find your Sun Contract ID by logging into SunSolve with your existing Sun Online Account username/password and clicking the "Update Account" link on the top right of the page. Your Sun Contract Identifier(s) are the entries in the "Current Contracts:" field on this page.) b) Your contact information 5) When you've completed the Registration form (ensuring that you have a Green tick opposite "Support Identifier, Terms of Use"), click "Send" to complete registration receive confirmation that you have registered successfully. Once you have registered successfully and the migration from SunSolve to MOS is complete, you should be able to see Sun patches via the "Patches Updates" tab in MOS (until then you'll see a page redirecting you to SunSolve). Successful Oracle SSO registration and association of a Sun contract to your SSO account will enable you to wget patch downloads from the new getupdates.oracle.com patch download service. Details of the new patch download service are available from http://sunsolve.sun.com/search/document.do?assetkey=1-79-1199543.1-1. Best, -Don Jon Price wrote: So those problems are not related to sunsolve being retired? Is there any possibility that pca will not work or will work less well when sunsolve is retired? Jon On Tue, Nov 2, 2010 at 6:58 AM, Don O'Malley don.omal...@oracle.com wrote: Hi Daniel/All, There was an issue with some patches that we discovered and fixed last week. This issue effected some unsigned (.zip) patch downloads. I thought that we'd caught and fixed all affected patches, but looks like we've missed some (those that were released at the time of the issue. I am investigating, but for now, if you need any of the affected patches below you can download the signed (.jar) versions of the patch. (Note: Unpack a .jar file using the unzip command) Example of syntax to download a jar file via wget: /usr/sfw/bin/wget --no-check-certificate --auth-no-challenge --http-user="" --http-passwd="xx" "https://sunsolve.sun.com/pdownload.do?target=124863-26method=hs" -O /tmp/124863-26.jar Apologies for any inconvenience. Best, -Don dpecka wrote: short list of todays patches which weren't been fetched but exist in patchdiag.xref file: 124863-26 124864-26 124865-25 126608-03 128224-11 133197-37 134008-44 135794-04 ave, daniel
Re: [pca] zpool unavailable after Kernel Patch 142909-17
Sounds like the kind of problem that DTrace could help to diagnose (though you would need to have a good idea of where the problem is to start with, so you place your probes in the right area)... Perhaps there might be something in the DTrace Toolkit could help - see http://hub.opensolaris.org/bin/view/Community+Group+dtrace/dtracetoolkit DTrace should allow you to examine your system while it's still available (as opposed to forcing the kernel to core dump), though this is obviously not the case if it's hung :) Just a thought... -Don Andy Fiddaman wrote: On Thu, 21 Oct 2010, Paul B. Henson wrote: ; On 10/20/2010 7:29 AM, Glen Gunselman wrote: ; Sun's x86 machines are definitely a step down from the capabilities of their ; SPARC systems, even ones years older. If a problem like this occurred on one ; of my SPARC servers, I'd simply break into the prom and force a kernel panic, ; resulting in a nice juicy crash dump suitable for forensic analysis. As far as ; I can tell, the only way on x86 to make this happen is to initially boot the ; system from the kernel debugger, and leave it running under the debugger ; indefinitely until the problem occurs 8-/. I'm also still disgusted about the ; continued lack of serial console logging support on the ILOM :(. You can force a panic on x86 via an NMI through an IPMI interface if the hardware supports it and you've set the right parameters in /etc/system. Here's an article on how to do it: http://www.cuddletech.com/blog/pivot/entry.php?id=1044 Regards, Andy
[pca] SunSolve Maintenance Window on Monday October 25th
Hi, There is a scheduled maintenance window planned for SunSolve on Monday 25th October from 4 pm to 6 pm (US) Mountain Time. Please be aware that this outage will impact the Patch Download Service during these 2 hours. The following is the related message on SunSolve: SunSolve Planned Maintenance Alert: Start Time: Mon Oct 25th 04:00 pm MT - End Time: Mon 25th 06:00 pm MT. Please be advised that some Patch Downloads will be unavailable during this period. We apologize for any inconvenience. We will remove this message when the outage has ended. Apologies for any inconvenience. Best, -Don
Re: [pca] SunSolve Maintenance Window on Monday October 25th
FYI - Don't think you usually blog about this kind of stuff, but just in case... Don O'Malley wrote: Hi, There is a scheduled maintenance window planned for SunSolve on Monday 25th October from 4 pm to 6 pm (US) Mountain Time. Please be aware that this outage will impact the Patch Download Service during these 2 hours. The following is the related message on SunSolve: SunSolve Planned Maintenance Alert: Start Time: Mon Oct 25th 04:00 pm MT - End Time: Mon 25th 06:00 pm MT. Please be advised that some Patch Downloads will be unavailable during this period. We apologize for any inconvenience. We will remove this message when the outage has ended. Apologies for any inconvenience. Best, -Don -- Don O'Malley Manager, Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] 404 Not Found for today's new patches
Investigating now, will have the patches available asap. Best, -Don Martin Paul wrote: Just FYI - once again, I have troubles downloading the new patches from today's patchdiag.xref. Any attempt to download e.g. 144554-01, 144555-01, 144560-01 or 144914-03 fails with 404 Not Found. Download of other (older) patches seem to work fine. Martin.
Re: [pca] Sunsolve retirement
Hi, I'll do my best to give you as much info as I can before the switchover from SunSolve to MOS (My Oracle Support) happens in November. You will need to create an account in MOS and register prior to being able to download patches from getupdates.oracle.com, but I will make every effort to make the transition as simple as possible for you, by sending mails detailing what you need to do when in order to keep patches flowing through PCA. I'm still trying to find out some of the finer details myself at the moment, but I will post mails to the PCA alias in advance of any changes prior to them going live. There is some info in http://sunsolve.sun.com/search/document.do?assetkey=1-79-1199543.1-1 that is really useful that folks could action now (like requesting any additional firewall rules be added to accommodate getupdates.oracle.com in advance). More to come on this one so stay tuned! Best, -Don Martin Paul wrote: French, David wrote: Hey, I apologize if this was already asked and I missed this before, but what is going to happen to PCA when sunsolve is retired? I just got an email saying it is being retired later this year and site decommissioned. Since pca uses sunsolve for downloads, how will that affect us? Gerry Haskins confirms that the patchdiag.xref and the patch download service will remain available, so PCA will continue to work. Modifications will be necessary, though, as URLs will change and an "Oracle.com Single Sign-On" will be required instead of the "Sun Online Account". There is a new document describing the future interface: http://sunsolve.sun.com/search/document.do?assetkey=1-79-1199543.1-1 The new URLs didn't work for me in a short test. I don't have any information about a schedule regarding activation of the new service and a possible parallel phase yet. Martin. -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] 404 Not Found for today's new patches
These patches shoulb be available in the next couple of hours. Don O'Malley wrote: Investigating now, will have the patches available asap. Best, -Don Martin Paul wrote: Just FYI - once again, I have troubles downloading the new patches from today's patchdiag.xref. Any attempt to download e.g. 144554-01, 144555-01, 144560-01 or 144914-03 fails with "404 Not Found". Download of other (older) patches seem to work fine. Martin. -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] zpool unavailable after Kernel Patch 142909-17
Hi Thomas, I have asked a colleague about this and he believes that you have hit CR 6967658, which is a direct result of installing 142909-17. There is no generic patch delivering a fix yet, but thought this might help if you are contacting support. Best, -Don Bleek Thomas wrote: Hello, just a warning and perhaps a request for some advices. We have a Sun StorEdge SE3510 connected to a V240. This Raid is used as JBOD (12 independend disks, 5x2 mirrored, 2 spares) for ZFS and Patch testings. I have 2 pools, one on this array, another on 2 local scsi-disks. After installing all current patches I can't mount the pool on the Raid, the local one works. The disks are seen with format, zpool status (actually zpool import) gives: r...@nftp:/zpool import pool: tank id: 10696630212093874974 state: UNAVAIL status: The pool is formatted using an older on-disk version. action: The pool cannot be imported due to damaged devices or data. config: tank UNAVAIL insufficient replicas mirror-0 UNAVAIL corrupted data c2t40d0 ONLINE c2t40d1 ONLINE mirror-1 UNAVAIL corrupted data c2t40d3 ONLINE c2t40d2 ONLINE mirror-2 UNAVAIL corrupted data c2t40d4 ONLINE c2t40d5 ONLINE mirror-3 UNAVAIL corrupted data c2t40d6 ONLINE c2t40d7 ONLINE mirror-4 UNAVAIL corrupted data c2t40d8 ONLINE c2t40d9 ONLINE r...@nftp:/ 2 things I have noticed: 1. The two spares have vanished (but they are seen with format) 2. The names of the submirros have changed, before the patch, they are all named simply "mirror". I have still not done a "zpool upgrade" because I assume, that I will not able to mount on the older, unpatched system. After booting into the old BE (thanks, Live Upgrade), the pool is online again. So I tried to find the guilty patch with backing out patch for patch. After backing out the kernel patch 142909-17 the problem has vanished but now I don't know how to proceed:-( Any hints other than opening a case, which I will do after getting no responses? TIA, Thomas -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] Kernel Patch 142909-17
Hi Ron, If you are running Open Solaris, then you will be using the new IPS (Image Packaging System - i.e. pkg command) as opposed to patchadd to apply updates to your system for the core OS??? See http://hub.opensolaris.org/bin/view/Project+pkg/WebHome for details or look at the pkg man page on your OpenSolaris system. Best, -Don Ron Halstead wrote: David, Me again. On my system (Nevada 129), there is no /etc/patch/pdo.conf, just patch.conf and secret.conf. Ron Halstead On 10/11/10 03:28, Don O'Malley wrote: Hi David, Good point re: num_proc. The maximum recommended value for num_proc is 1.5 * number of processors on the system (i.e. output of psrinfo) So, for example a T2000 with psrinfo like this: # psrinfo 0 on-line since 07/13/2010 15:45:39 1 on-line since 07/13/2010 15:45:40 2 on-line since 07/13/2010 15:45:40 3 on-line since 07/13/2010 15:45:40 4 on-line since 07/13/2010 15:45:40 5 on-line since 07/13/2010 15:45:40 6 on-line since 07/13/2010 15:45:40 7 on-line since 07/13/2010 15:45:40 8 on-line since 07/13/2010 15:45:40 9 on-line since 07/13/2010 15:45:40 10 on-line since 07/13/2010 15:45:40 11 on-line since 07/13/2010 15:45:40 12 on-line since 07/13/2010 15:45:40 13 on-line since 07/13/2010 15:45:40 14 on-line since 07/13/2010 15:45:40 15 on-line since 07/13/2010 15:45:40 16 on-line since 07/13/2010 15:45:40 17 on-line since 07/13/2010 15:45:40 18 on-line since 07/13/2010 15:45:40 19 on-line since 07/13/2010 15:45:40 20 on-line since 07/13/2010 15:45:40 21 on-line since 07/13/2010 15:45:40 22 on-line since 07/13/2010 15:45:40 23 on-line since 07/13/2010 15:45:40 24 on-line since 07/13/2010 15:45:40 25 on-line since 07/13/2010 15:45:40 26 on-line since 07/13/2010 15:45:40 27 on-line since 07/13/2010 15:45:40 28 on-line since 07/13/2010 15:45:40 29 on-line since 07/13/2010 15:45:40 30 on-line since 07/13/2010 15:45:40 31 on-line since 07/13/2010 15:45:40 # could have a maximum value of num_proc=48 Obviously, the correct setting for num_proc depends on the number of zones you have on your system (there's no point in setting num_proc higher than the number of zones you have). HTH, -Don French, David wrote: I just wanted to point out that you can modify /etc/patch/pdo.conf and set num_proc to something higher than the default of 1. This will patch num_proc zones in parallel when patchadd runs. For example, if you have many cpus and 10 zones, it shouldn't take much more time than twice what it took to patch the global alone if you set the value to ten, as they will all run in parallel. I have a couple of T2000s with a global and 4 container zones. The first (num_proc=1) took hours (4-5) to add about 120 patches. The other system I made sure the parameter above was set to 5. Patching on that server for the same 120 or so patches (identical setups) took a little over an hour. You can really see the difference with the Java patches. BTW, the parameter is described in the patchadd man page, just search for parallel. --Dave -Original Message- From:pca-boun...@lists.univie.ac.at [mailto:pca- boun...@lists.univie.ac.at] On Behalf Of Diana Orrick Sent: Saturday, October 09, 2010 3:41 PM To: PCA (Patch Check Advanced) Discussion Subject: Re: [pca] Kernel Patch 142909-17 Thanks for the suggestions everyone, will supply more info when time allows. Still working on the cluster... On 10/9/2010 6:18 PM, Rajiv Gunja wrote: You might want to compare the times it took for other patches so that you know if it will take longer that 13*11*x minutes whet x is some random number which it seems to take for patching zones. If the server is ok to run for more time let it run. It took my server 7 hours to patch 200 patches on a server with 3 zones. Sine you have 13 zones it might take longer. -GGR On Oct 9, 2010 12:17 PM, "Martin Paul"mar...@par.univie.ac.at mailto:mar...@par.univie.ac.at wrote: Diana Orrick schrieb: Any suggestions on how to determine if the patching is progressing at all? I guess you could use "truss -f -pPID" on the PID of the "patchadd&quo
Re: [pca] Kernel Patch 142909-17
Hi David, Good point re: num_proc. The maximum recommended value for num_proc is 1.5 * number of processors on the system (i.e. output of psrinfo) So, for example a T2000 with psrinfo like this: # psrinfo 0 on-line since 07/13/2010 15:45:39 1 on-line since 07/13/2010 15:45:40 2 on-line since 07/13/2010 15:45:40 3 on-line since 07/13/2010 15:45:40 4 on-line since 07/13/2010 15:45:40 5 on-line since 07/13/2010 15:45:40 6 on-line since 07/13/2010 15:45:40 7 on-line since 07/13/2010 15:45:40 8 on-line since 07/13/2010 15:45:40 9 on-line since 07/13/2010 15:45:40 10 on-line since 07/13/2010 15:45:40 11 on-line since 07/13/2010 15:45:40 12 on-line since 07/13/2010 15:45:40 13 on-line since 07/13/2010 15:45:40 14 on-line since 07/13/2010 15:45:40 15 on-line since 07/13/2010 15:45:40 16 on-line since 07/13/2010 15:45:40 17 on-line since 07/13/2010 15:45:40 18 on-line since 07/13/2010 15:45:40 19 on-line since 07/13/2010 15:45:40 20 on-line since 07/13/2010 15:45:40 21 on-line since 07/13/2010 15:45:40 22 on-line since 07/13/2010 15:45:40 23 on-line since 07/13/2010 15:45:40 24 on-line since 07/13/2010 15:45:40 25 on-line since 07/13/2010 15:45:40 26 on-line since 07/13/2010 15:45:40 27 on-line since 07/13/2010 15:45:40 28 on-line since 07/13/2010 15:45:40 29 on-line since 07/13/2010 15:45:40 30 on-line since 07/13/2010 15:45:40 31 on-line since 07/13/2010 15:45:40 # could have a maximum value of num_proc=48 Obviously, the correct setting for num_proc depends on the number of zones you have on your system (there's no point in setting num_proc higher than the number of zones you have). HTH, -Don French, David wrote: I just wanted to point out that you can modify /etc/patch/pdo.conf and set num_proc to something higher than the default of 1. This will patch num_proc zones in parallel when patchadd runs. For example, if you have many cpus and 10 zones, it shouldn't take much more time than twice what it took to patch the global alone if you set the value to ten, as they will all run in parallel. I have a couple of T2000s with a global and 4 container zones. The first (num_proc=1) took hours (4-5) to add about 120 patches. The other system I made sure the parameter above was set to 5. Patching on that server for the same 120 or so patches (identical setups) took a little over an hour. You can really see the difference with the Java patches. BTW, the parameter is described in the patchadd man page, just search for parallel. --Dave -Original Message- From: pca-boun...@lists.univie.ac.at [mailto:pca- boun...@lists.univie.ac.at] On Behalf Of Diana Orrick Sent: Saturday, October 09, 2010 3:41 PM To: PCA (Patch Check Advanced) Discussion Subject: Re: [pca] Kernel Patch 142909-17 Thanks for the suggestions everyone, will supply more info when time allows. Still working on the cluster... On 10/9/2010 6:18 PM, Rajiv Gunja wrote: You might want to compare the times it took for other patches so that you know if it will take longer that 13*11*x minutes whet x is some random number which it seems to take for patching zones. If the server is ok to run for more time let it run. It took my server 7 hours to patch 200 patches on a server with 3 zones. Sine you have 13 zones it might take longer. -GGR On Oct 9, 2010 12:17 PM, "Martin Paul" mar...@par.univie.ac.at mailto:mar...@par.univie.ac.at wrote: Diana Orrick schrieb: Any suggestions on how to determine if the patching is progressing at all? I guess you could use "truss -f -p PID" on the PID of the "patchadd" process to see what's going on. If you have to interrupt the patch installation process, the only "good" thing is that PCA is using plain patchadd for the patch install, so there's no extra uncertainty added by the fact that you are using PCA. On the other hand I don't have much practical experience about how "patchadd" reacts to Ctrl-C. I think that it should be pretty save to remove the partly installed patch with "patchrm" afterwards without causing any ill effects. Martin. -- ~~~ Diana Mayer Orrick, System Administrator Information Technology Services, Florida State University Contact: orr...@fsu.edu -- (850) 645-8009 ~~~
Re: [pca] Problems with latest patchdiag.xref
Looking into this... Best, -Don Richard Skelton wrote: Hi Martin, Yes that the conclusion I came to :-) Martin Paul wrote: Richard Skelton wrote: While testing my pca wrapper for my proxy the new "Macromedia Flash Player Plugin Patch" is failing to download:- Same here. All patches which are new in today's patchdiag.xref do not exist on SunSolve (yet). The Patchfinder doesn't find them either. Maybe they got stuck in some step of the publishing process. We'll have to wait and try again later. Martin. -- Don O'Malley Manager, Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] Solaris Update Patch Bundle updates /etc/release
Hi Rajiv,
Short answer is that you should not install it manually, as like I said
previously, /etc/release is only updated by this patch if the Patch
Bundle itself is installed (via the installcluster script). We have
extensively tested this set of patches (and the install script) and so
that is why we are happy to identify when it has been used.
BTW - This patch does not require all patches in the Patch Bundle to be
applied but rather when the bundle is built, the patch requirements for
this "private" patch are calculated as the subset of patches that would
be applicable to the SUNWCrnet metacluster of all earlier update
releases.
Best,
-Don
Rajiv Gunja wrote:
Don,
Thanks for explaining the reasoning. Yes, I understand that it is a
private patch and is part of a bundle. My question was, should we look
into installing it on our system after I determine that all other
patches in the bundle is already present? Or should we stay away from
installing that patch? Please let me know, Thanks.
-GGR
--
Rajiv
G Gunja
Blog:
http://ossrocks.blogspot.com
On Wed, Sep 8, 2010 at 05:16, Don O'Malley don.omal...@oracle.com
wrote:
Hi Rajiv/All,
There are a couple of points of note here...
Essentially Oracle wanted a way of being easily able to determine when
a customer had applied the Patch Bundle for a Solaris Update. The Patch
Bundles are seen as having the closest relationship to upgrading to the
latest Solaris Update, without actually doing an upgrade. Upgrading
systems to the latest Solaris Release is the recommended support
strategy, but we realize that this may not always be possible, due to
issues like needing to re-certify apps on upgrade which is why we
introduced the Patch Bundles.
The solution that we came up with (and there were many alternatives
discussed) to identify when a Patch Bundle has been successfully
applied to a system, was to add a "private" patch to the patch bundle
to update /etc/release to indicate that a particular Patch Bundle had
been applied.
It is worth pointing out here that my team does extensive testing of
the Patch Bundle, starting months before the bundle is due to be
released (which typically happens 2-4 weeks after GA of a Solaris
Update). The "private" patches that make the updates to /etc/release
are not made public, purely because there is no logical reason to do
so; their purpose is to indicate that a particular Patch Bundle has
been applied and this is only true if a customer actually downloads and
installs the bundle itself. We can guarantee that the patches in the
Patch Bundle have undergone extensive testing and there is also logic
in the installcluster script that adds value not available through
automated patching tools.
The advantage to Oracle of having this information is more from the
perspective of support.
Is a customer has an issue and supplies Oracle with an explorer log of
the system in question, then it is very useful for the engineer
examining the system to have a quick reference point in /etc/release
that explains the installation of a couple of hundred patches.
I hope this explains why we have approached this the way that we have...
Best,
-Don
Rajiv Gunja wrote:
Martin,
I just noticed this on Solaris Patch Update Aug 2010.
---
http://blogs.sun.com/patch/resource/Oracle_Solaris_Patch_Update_Aug_2010.pdf
(PAGE 69)
---
Solaris
Update Patch Bundles now update /etc/release to
make
it easier to identify that a system has been patched
to
the software level of a Solaris Update release.
---
How will this effect us? Can we simulate this or is this
addition/change included as a part of kernel patch or part of their
wrapper?
Do you know? Should also be a question for Don. Please advise. Thanks
-GGR
--
Rajiv
G Gunja
Blog:
http://ossrocks.blogspot.com
--
Don O'Malley
Manager,
Patch System Test
Revenue Product Engineering | Solaris | Hardware
East Point Business Park, Dublin 3, Ireland
Phone: +353 1 8199764
Team Alias: rpe_patch_system_test...@oracle.com
--
Don O'Malley
Manager,
Patch System Test
Revenue Product Engineering | Solaris | Hardware
East Point Business Park, Dublin 3, Ireland
Phone: +353 1 8199764
Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] download problems
I'll follow up Martin. Thanks for letting me know. Best, -Don Martin Paul wrote: And here we go again. Can't even get patchdiag.xref this time: Resolving sunsolve.sun.com... 192.18.108.40 Connecting to sunsolve.sun.com|192.18.108.40|:443... connected. ^C Martin.
Re: [pca] download problems
I'm seeing an issue with one of the backend load-balanced download servers. Very few people should be impacted. I'll get it resolved asap. Best, -Don Don O'Malley wrote: I'll follow up Martin. Thanks for letting me know. Best, -Don Martin Paul wrote: And here we go again. Can't even get patchdiag.xref this time: Resolving sunsolve.sun.com... 192.18.108.40 Connecting to sunsolve.sun.com|192.18.108.40|:443... connected. ^C Martin.
Re: [pca] download problems
Hi Dennis, Are you still seeing patch download fails? If so, could you send on an example of a failing patch download request please? Thanks! -Don Dennis Clarke wrote: And here we go again. Can't even get patchdiag.xref this time: Resolving sunsolve.sun.com... 192.18.108.40 Connecting to sunsolve.sun.com|192.18.108.40|:443... connected. ^C Martin. I was able to get patchdiag.xref but not one single patch. I say we organize a class action law suit on terms of breech of contract. Personally I paid money for my support and if I can not get a damn patch that is a breech of contract. If we have several thousand others that feel the same way on a long weekend then we have a class action law suit to file against Oracle Corporation for breech of contract and a few otehr areas of tort. -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] Slightly OT: Patch 124868-14 broken?
FYI - This patch is going to be withdrawn from SunSolve later today and a new rev with a fix will be released asap. Sorry for an inconvenience. Best, -Don Dagobert Michelsen wrote: Hi Dennis, Am 11.08.2010 um 04:47 schrieb Dennis Clarke: I have a problem installing a patch (with PCA, but PCA works as expected): ... I already tried removing/reinstalling the 126498-02 and the previous rev 124868-13 with no luck. There also doesn't seem to be an open issue on this at SunSolve. Any ideas anybody? Just get into the patch pkgmap and fix it .. its trivial : ... You Dago, of all people, should know better. Ahh, thanks for the hint! I vaguely rememberd changing patches was more difficult due to signing issues but obviously this is optional. It has applied now cleanly. Best regards -- Dago
Re: [pca] Slightly OT: Patch 124868-14 broken?
Hi Dago, I'm in the process of getting these patches withdrawn and getting new patches with the correct SUNW_REQUIRES released. Best, -Don Dagobert Michelsen wrote: Hi, Am 10.08.2010 um 16:49 schrieb Dagobert Michelsen: I have a problem installing a patch (with PCA, but PCA works as expected): Installing 124868-14 (3/5) This is obviously the same issue as the previously discussed 124867-15 which I just remembered :-/ Sorry for the noise... -- Dago -- Don O'Malley Manager,Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] 124867-15 fails dependency check
Looking in to this now... Best, -Don Martin Paul wrote: David Gameau wrote: Ah, my apologies here, my diff-explanation wasn't very clear. It appears that an entry in the pkginfo has changed between 124867-14 and -15: 124867-14: SUNW_REQUIRES=124861-07 126495-03 124867-15: SUNW_REQUIRES='124861-07 126495-03' which does seem to match up with the error message. 0 For patch 124867-15, required patch '124861-07 does not exist. Ah, now I see that the problem is. I hadn't looked close enough on your original message. As it's impossible for anybody to install this patch, I'm sure Oracle will fix that without any further on your side. Removing the wrong quotation characters and repackaging the patch shouldn't be a big problem. I'll send a direct Cc: to Don O'Malley anyway. Martin.
Re: [pca] 124867-15 fails dependency check
Hi David/Martin, I've just reproduced and logged a bug for this. It looks like a clear case for patch withdrawal. I will get these patches off SunSolve asap. Thanks for bringing this to my attention and apologies for the inconvenience. Best, -Don Don O'Malley wrote: Looking in to this now... Best, -Don Martin Paul wrote: David Gameau wrote: Ah, my apologies here, my diff-explanation wasn't very clear. It appears that an entry in the pkginfo has changed between 124867-14 and -15: 124867-14: SUNW_REQUIRES=124861-07 126495-03 124867-15: SUNW_REQUIRES='124861-07 126495-03' which does seem to match up with the error message. 0 For patch 124867-15, required patch '124861-07 does not exist. Ah, now I see that the problem is. I hadn't looked close enough on your original message. As it's impossible for anybody to install this patch, I'm sure Oracle will fix that without any further on your side. Removing the wrong quotation characters and repackaging the patch shouldn't be a big problem. I'll send a direct Cc: to Don O'Malley anyway. Martin.
Re: [pca] Error 403: Forbidden
I'll follow up and see what I can find out... Best, -Don Martin Paul wrote: Asif Iqbal wrote: No. I knew about vintage patches, just did not connect the dot. However I posted another email about 503 error on solaris 10. Yes, we're talking about two different problems here. One of them is SunSolve being in a bad state, returning Error 503: Service Unavailable. This seems to have started yesterday, and still persists: Connecting to sunsolve.sun.com|192.18.108.40|:443... connected. HTTP request sent, awaiting response... 503 Service Unavailable 2010-08-04 15:12:16 ERROR 503: Service Unavailable. We'll have to wait for Oracle to fix it. Martin.
Re: [pca] Error 503: Service Unavailable
Hi Asif, I've just checked the patch download servers and they appear to be working fine. Please let me know if you see any further issues. Best, -Don Asif Iqbal wrote: On Wed, Aug 4, 2010 at 9:04 AM, Asif Iqbal vad...@gmail.com wrote: $ pca -V -d 127127 Option download: 1 Option patchdir: /home/iqbala/. Option debug: 1 Command: /opt/csw/bin/pca ARGV: 127127 Version: 20100727-01 CWD: /home/iqbala Found /usr/sfw/bin/wget (1.12, 11200, https) Using /usr/sfw/bin/wget Found /usr/bin/uname Prerequisites for threads not met, setting threads to 0 Never update Expanded patch list: 127127 xref mtime: Tue Aug 3 00:06:03 2010 xref now : Wed Aug 4 12:59:53 2010 xref ctime: Wed Aug 4 12:58:37 2010 xref age : 76 Local file /var/tmp/patchdiag.xref is up to date osname from uname: SunOS Reading from /usr/bin/showrev -p 2/dev/null Using /var/tmp/patchdiag.xref from Aug/02/10 108434-25: Passing on R flag 108435-25: Passing on R flag ... 127755-01 required by 127127: already installed Host: apa-pdr-02 (SunOS 5.10/Generic_120011-14/sparc/sun4u) List: 127127 (1/831) Patch IR CR RSB Age Synopsis -- -- - -- --- --- --- 127127 -- 11 RS- 831 SunOS 5.10: kernel patch Looking for 127127-11 (1/1) Trying SunSolve Please enter Sun Online Account User: iqbala Please enter Sun Online Account Password: Trying https://sunsolve.sun.com/ (1/1) Adding to /tmp/pca.528352: header=Authorization: Basic base64-user-passwd /usr/sfw/bin/wget --progress=dot:binary "https://sunsolve.sun.com/pdownload.do?target=127127-11method=h" --ca-certificate=/opt/csw/bin/pca -O /home/iqbala/./127127-11.tmp --2010-08-04 13:00:03-- https://sunsolve.sun.com/pdownload.do?target=127127-11method=h Resolving sunsolve.sun.com... 192.18.108.40 Connecting to sunsolve.sun.com|192.18.108.40|:443... connected. HTTP request sent, awaiting response... 503 Service Unavailable 2010-08-04 13:00:04 ERROR 503: Service Unavailable. Removing /tmp/pca.528352 Failed (Error 503: Service Unavailable) Failed (patch not found) -- Download Summary: 1 total, 0 successful, 0 skipped, 1 failed It started working again now here is the log, sanitized. Host: apa-pdr-02 (SunOS 5.10/Generic_120011-14/sparc/sun4u) List: 127127 (1/831) Patch IR CR RSB Age Synopsis -- -- - -- --- --- --- 127127 -- 11 RS- 831 SunOS 5.10: kernel patch Looking for 127127-11 (1/1) Trying SunSolve Please enter Sun Online Account User: iqbala Please enter Sun Online Account Password: Trying https://sunsolve.sun.com/ (1/1) Adding to /tmp/pca.405057: header=Authorization: Basic base64-user-passwd /usr/sfw/bin/wget --progress=dot:binary "https://sunsolve.sun.com/pdownload.do?target=127127-11method=h" --ca-certificate=/opt/csw/bin/pca -O /home/iq bala/./127127-11.tmp --2010-08-04 14:25:05-- https://sunsolve.sun.com/pdownload.do?target=127127-11method=h Resolving sunsolve.sun.com... 192.18.108.40 Connecting to sunsolve.sun.com|192.18.108.40|:443... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: https://getupdates2.sun.com/all_unsigned/127127-11.zip [following] --2010-08-04 14:25:31-- https://getupdates2.sun.com/all_unsigned/127127-11.zip Resolving getupdates2.sun.com... 198.232.168.157 Connecting to getupdates2.sun.com|198.232.168.157|:443... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: https://a248.e.akamai.net/f/248/21808/15m/sun.download.akamai.com/21808/patches/patchroot/all_unsigned/127127-11.zip?AuthParam=1735bdTUrl=LDWA8FMyyRPZTicketId=CFA=GroupName=SWUPBHost=sdlc5g.sun.c omFilePath=/patches/patchroot/all_unsigned/127127-11.zipFile=127127-11.zip [following] --2010-08-04 14:25:41-- https://a248.e.akamai.net/f/248/21808/15m/sun.download.akamai.com/21808/patches/patchroot/all_unsigned/127127-11.zip?AuthParam =b735bdTUrl=LyRPZTicketId=CFA=GroupName=SWUPBHo st=sdlc5g.sun.comFilePath=/patches/patchroot/all_unsigned/127127-11.zipFile=127127-11.zip Resolving a248.e.akamai.net... 67.132.30.18, 67.132.30.35 Connecting to a248.e.akamai.net|67.132.30.18|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 63151341 (60M) [application/zip] Saving to: `/home/iqbala/./127127-11.tmp' 0K 0% 969K 63s 384K 1% 4.72M 38s 768K 1% 6.20M 28s 1152K 2% 8.47M 23s [..] 61440K 100% 3.98M=12s 2010-08-04 14:25:54 (4.90 MB/s) - `/home/iqbala/./127127-11.tmp' saved [63151341/63151341] Removing /tmp/pca.405057 Done -- Download Summary: 1 total, 1 successful, 0 skipped, 0 failed
Re: [pca] OS CPU
Both OS Oracle Stack CPUs will be fully tested, just not necessarily together on the same box by the same team... I realize that from your perspective this may be desirable, but please understand that we have limited resources and it is not possible for our team to cover every possible combination of CPU delivery during our testing. Best, -Don Xu, Ying (Houston) wrote: No. We do not have problems using Oracle CPUs on solaris platform. We always schedule separate maintenance windows for OS and oracle patches. Since oracle releases CPUs for OS and Oracle at the same time, we could combine maintenance windows if they are fully tested. We plan to pursue it anyway. Thanks Ying Xu y...@littonloan.com Unix Group Office: 713-218-4508 BB: 832-671-6633 4828 Loop Central Dr. Houston TX 77081 From: pca-boun...@lists.univie.ac.at [mailto:pca-boun...@lists.univie.ac.at] On Behalf Of Don O'Malley Sent: Monday, July 19, 2010 7:32 AM To: PCA (Patch Check Advanced) Discussion Subject: Re: [pca] OS CPU Hi Ying, Each team is responsible for testing the CPU that they produce; we produce the Solaris OS CPU, thus that is what we test. Our team has lots of experience in Solaris System Test (which does include some Oracle testing) and with SVR4-format patches (i.e. standard Sun patches). We would currently not have the bandwidth to take on additional testing of the Oracle CPU, as this would require lots of additional Oracle-specific knowledge and resources, which we do not currently have. (Oracle CPUs are not even the same format as regular SVR4 patches.) There is a separate test team that test the Oracle CPU's and as part of that testing they should test on Solaris. Have you had specific problems using the Oracle CPU's on Solaris previously? Best, -Don Xu, Ying (Houston) wrote: Thanks, Don. Another question, since oracle releases OS CPU at the same time as Oracle CPU, do you think that the QC team would test both CPUs on the same server? We are trying to schedule the down time for both maintenances and try to figure out if we could combine them together. Ying Xu y...@littonloan.com Unix Group Office: 713-218-4508 BB: 832-671-6633 4828 Loop Central Dr. Houston TX 77081 From: pca-boun...@lists.univie.ac.at [mailto:pca-boun...@lists.univie.ac.at] On Behalf Of Don O'Malley Sent: Tuesday, July 13, 2010 11:20 AM To: PCA (Patch Check Advanced) Discussion Subject: Re: [pca] OS CPU Hi Ying, The CPU is not related to the patchdiag.xref file at all. The CPU is simply a snapshot of the Recommended Patch Clusters taken once a quarter, which contains patches that fix all publicly announced Security issues (i.e. Oracle Security Alerts) for the Solaris OS. See http://www.oracle.com/technology/deploy/security/alerts.htm, http://security.sfbay.sun.com/pad.html and http://www.oracle.com/technology/deploy/security/critical-patch-updates/cpujul2010.html and for further information. Best, -Don Xu, Ying (Houston) wrote: I noticed that Oracle/SUN just released its first Critical Patch Updates (CPU). I'm not sure which xref file it uses. Does PCA have an option to download/patch CPU? Its README has update date of 7/6, but the xref file on 7/6 that I downloaded has kernel patch of 142900-14 instead of 142900-13. Thanks. Ying --- DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to this message and then delete it from your system. Use, dissemination or copying of this message by unintended recipients is not authorized and may be unlawful. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. --- DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to this message and then delete it from your system. Use, dissemination or copying of this message by unintended recipients is not authorized and may be unlawful. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally
Re: [pca] Cluster, zones, noreboot.
Thoughts from a colleague - Enda O'Connor - inline... Best, -Don Enda O'Connor wrote: Hi Some people have recommended Update On Attach see http://wikis.sun.com/display/BluePrints/Maintaining+Solaris+with+Live+Upgrade+and+Update+On+Attach and also the following for a description of how update on attach works in conjunction with patching. http://www.sun.com/bigadmin/features/articles /zone_attach_patch.jsp#Patching it is important to first read the bigadmin article to understand how it works before goign down this route. Enda On 13/07/2010 16:32, Enda O'Connor wrote: Hi David the major issue with patching a live system with a failover zone is if the zone failed over for any reason during patching. This would cause patch corruption, one would need to suspend the HA container resource, i.e. clrg suspend the resource group detach zones on remaining node apply patch attach zone on other node clrg resume the resource group But one would need to take some care to identify patches that can be applied in such fashion. the following doc has section on applying patches that require Single User Mode in failover zone environment. http://docs.sun.com/app/docs/doc/819-2971/z476997776?a=view I have cc'ed Chris who has lots of experience in this area. But the main concern is that the zone might failover during such patching. Enda On 13/07/2010 10:56, Don O'Malley wrote: Hey Enda/Ed, Any thoughts on this? In addition to the no reboot question, is it better to detaches your zones and use update on attach to bring the local zones back in sync, or is there no difference between the two (I thought update on attach was quicker)? Best, -Don David Stark wrote: Hi List. A bit off-topic, but PCA's involved, so I'm going to push my luck. We've got a number of Sun Cluster installs using (lots of) failover zones and with no LiveUpgrade alt. boot space set up, which we need to patch. If we were to patch the clusters node-by-node (including the kernel patches that don't like zones being booted when they're applied), the zones would fail over between the nodes and never get patched themselves, and since kernel (and some other?) patches can't be applied from inside zones we would end up in a situation where the zones' patch databases are out of sync with the Global zone. I know from very bitter experience that this is a Bad Thing, so to avoid that we're currently bringing the clusters down to patch them. This obviously isn't optimal - people expecting 100% uptime from the clusters are naturally a bit annoyed at having their applications down for several hours while we unleash the mighty PCA. So, to minimise downtime I'd like to apply the noreboot patches, say, the night before, and have a more minimal patch run with the clusters down. This brings me to the question: Has anyone ever had any problems with noreboot patches applied to live systems? Any weirdness at all? I've patched plenty of test machines in multi-user mode, but never busy production boxes - these are fairly large Oracle and SAP environments for the most part. Anyone with experience patching Sun Cluster care to share any top tips? Cheers! Dave
Re: [pca] PCA not working since Oracle buy out.
Hi Juergen, What version of wget have you on your system? (# wget --version) If you've got version 1.11.1 or higher can you execute the following wget command and send me the output in a mail and I'll follow up: (Replace SOA_username SOA_passwd with your Sun Online Account username password) # /usr/sfw/bin/wget --no-check-certificate --auth-no-challenge --http-user=SOA_Username --http-passwd=SOA_Passwd https://sunsolve.sun.com/pdownload.do?target=145005-01method=hs; -O 145005-01.jar Alternatively if the version of wget you are using is between 1.10.2 and 1.11, could you # /usr/sfw/bin/wget --no-check-certificate --http-user=SOA_Username --http-passwd=SOA_Passwd https://sunsolve.sun.com/pdownload.do?target=145005-01method=hs; -O 145005-01.jar Could you please include your SOA_Username in the mail too. Could you also provide more detail about the issues you are having with the Patch Basket (I'm assuming were talking about the PatchFinder tool - http://sunsolve.sun.com/patchfinder/ - here...) too please? It seems to work ok for me... Best, -Don Jürgen Mengeling wrote: On 28.06.10 15:10, Don O'Malley wrote: Hi, Could you please also ensure that you have completed Step 5 - Register for patch download automation on the Update Account link also. The TC on SunSolve changed after the Oracle acquisition, so you will need to accept the new TC prior to being able to download patches via wget (which is used by PCA). If you are continuing to have issues please let me know. Best, -Don Martin Paul wrote: Techie wrote: My PCA is no longer working since the Oracle buy out of SUN. I went directly to SUNSOLVE and I cannot download directly from there either. First thing to check is whether your contract number is listed correctly in the Update Account section on SunSolve. Ensure that you have the correct Entitlements for getting access to the patch you try to download. If you can't even download patches from SunSolve directly, you should really contact Sun Support. Tell them that you can't use a service that you already paid for, which is unacceptable. Martin. Hello * similar behaviour here (de), pca download failed ( 403 You are not entitled to retrieve this content.) --- 8 --- Trying https://sunsolve.sun.com/ (1/1) Adding to /tmp/pca.862815: header=Authorization: Basic [base64:usenname:passwd removed] /usr/sfw/bin/wget --progress=dot:binary https://sunsolve.sun.com/pdownload.do?target=145005-01method=hs; --ca-certificate=./scripts/pca -O /net/nfsremote/storage/VolGroup02-00/clients/solaris/patches/./145005-01.tmp --2010-06-29 08:54:59-- https://sunsolve.sun.com/pdownload.do?target=145005-01method=hs Resolving sunsolve.sun.com... 192.18.108.40 Connecting to sunsolve.sun.com|192.18.108.40|:443... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: https://getupdates2.sun.com/all_signed/145005-01.jar [following] --2010-06-29 08:55:02-- https://getupdates2.sun.com/all_signed/145005-01.jar Resolving getupdates2.sun.com... 198.232.168.157 Connecting to getupdates2.sun.com|198.232.168.157|:443... connected. HTTP request sent, awaiting response... 403 You are not entitled to retrieve this content. 2010-06-29 08:55:09 ERROR 403: You are not entitled to retrieve this content.. Removing /tmp/pca.862815 Failed (Error 403: You are not entitled to retrieve this content.) Failed (patch not found) --- 8 --- [not being pedantic but: send/log username/password as base64 coded??, just a quick google gives some new accounts -)] manual patch download working (green lock is always shown): mostly, sometimes I get also not entitled message but after checking Update Account everything is ok. Current Contracts are marked as valid, Patch Entitlements: Solaris10SoftwareUpdates ContractRequired SolarisSoftwareUpdates Public, Step 5: your are already been registered. basket download also not working. greetings juergen
Re: [pca] PCA not working since Oracle buy out.
Hi, Could you please also ensure that you have completed Step 5 - Register for patch download automation on the Update Account link also. The TC on SunSolve changed after the Oracle acquisition, so you will need to accept the new TC prior to being able to download patches via wget (which is used by PCA). If you are continuing to have issues please let me know. Best, -Don Martin Paul wrote: Techie wrote: My PCA is no longer working since the Oracle buy out of SUN. I went directly to SUNSOLVE and I cannot download directly from there either. First thing to check is whether your contract number is listed correctly in the Update Account section on SunSolve. Ensure that you have the correct Entitlements for getting access to the patch you try to download. If you can't even download patches from SunSolve directly, you should really contact Sun Support. Tell them that you can't use a service that you already paid for, which is unacceptable. Martin.
Re: [pca] sunsolve https not working?
Hi Martin, There was an issue on one of the SunSolve servers fixed and hour or so ago. Can you confirm that you are no longer having issues downloading patches via http or https now please? Thanks! -Don Don O'Malley wrote: I'll see what I can find out... dpecka wrote: same here .. i can't even download .xref file (pca -x --debug) .. it hangs up. Probably we are persecuted, prosecuted, abominated, aggravated and pestered by using pca .. these hang-ups occur more and more oftenly then *before Oracle kingdom began walking on theirs path to glory .. regards, daniel On Mon, 2010-06-28 at 09:50 +0200, Martin Paul wrote: I still have problems downloading files from https://sunsolve.sun.com/. Right now, every attempt to download a patch with pca hangs for about 90 seconds before sunsolve answers: Mon Jun 28 09:42:24 2010: Connecting to sunsolve.sun.com|192.18.108.40|:443... connected. Mon Jun 28 09:43:56 2010: HTTP request sent, awaiting response... 302 Moved Temporarily Martin.
Re: [pca] sunsolve https not working?
Hi Martin, I just checked this out and all appears to be working fine for me; longest delay was about 7 seconds... Can you confirm you're still seeing the long delays? Thanks! -Don Martin Paul wrote: Hi Don, There was an issue on one of the SunSolve servers fixed and hour or so ago. Can you confirm that you are no longer having issues downloading patches via http or https now please? The downloads I tried now all worked, but sunsolve.sun.com is still slow and it takes 10-30 seconds until it redirects the client to getupdates2.sun.com. The most basic test case to show the problem is: /usr/sfw/bin/wget --no-check-certificate 'https://sunsolve.sun.com/pdownload.do?target=patchdiag.xref' Martin.
Re: [pca] sunsolve https not working?
Hi Jeff, Could you please ensure that you have completed "Step 5 - Register for patch download automation" on the "Update Account" link. The TC on SunSolve have changed since the Oracle acquisition, so you will need to accept the new TC prior to being able to download patches via wget (which is used by PCA). If you are continuing to have issues please let me know. Best, -Don Jeff wrote: Yep, I can download them manually straight from Sunsolve, and I did register for patch automation downloads a long time ago but suddenly it stopped working. Guess I'll need to open a ticket and see if my account can get fixed. On Mon, Jun 28, 2010 at 1:29 PM, Martin Paul mar...@par.univie.ac.at wrote: Jeff Tejnecky schrieb: If I download through pca, I see in the verbose output a couple of redirects before it downloads what looks like a sunsolve authentication page. Anybody having this problem? That's usually pointing at the Sun Online Account not being valid (anymore). Can you login interactively on SunSolve and download files from there? Martin. -- Jeff -- Don O'Malley Manager, Patch System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com
Re: [pca] Patch 138261-02 problems..
Hi Andy, Does backing off patch 138261-02 fix the problem? Also, can you provide a case#, so I can follow this up please? Thanks! -Don Glenn Satchell wrote: On 06/18/10 18:09, Andy Fiddaman wrote: Since installing 138261-02 here I'm seeing problems which cause cron to stall.. Whenever logadm tries to rotate the cron log file, there seems to be a deadlock between cron and logadm, and /var/cron/log attains the l flag.. # cd /var/cron # ls logolog # tail log ^C # ls -l total 2570 -rw---l--- 1 root sys 531501 Jun 16 00:00 log -rw--- 1 root sys 528384 Jun 16 00:00 olog # date Wed Jun 16 08:08:23 GMT 2010 You might want to skip that patch for the moment.. I've opened a case with Sun but nothing back yet. A. Hi Andy Interesting. I have that patch installed on a couple of systems and have not seen this. The cron log files have rotated since the patch was installed. I installed all available patches (not just recommended or security). Please advise any further info you get from Sun/Oracle. This might be one waiting to get me.
Re: [pca] sunsolve https not working?
Hi, This issue was a result of an internal network change. It is back online about 12 hours now. Let me know if you are continuing to experience issues with https access. Best, -Don Don O'Malley wrote: Looking at this now... I'm seeing the same issue... I'll pass it on to the SunSolve team. Sorry for the inconvenience. Best, -Don Martin Paul wrote: Bleek Thomas wrote: I have problems to connect via https (pca, wget and also web-browser), http works. every day another problem. Same here. Quite annoying. Martin.
Re: [pca] sunsolve https not working?
Looking at this now... I'm seeing the same issue... I'll pass it on to the SunSolve team. Sorry for the inconvenience. Best, -Don Martin Paul wrote: Bleek Thomas wrote: I have problems to connect via https (pca, wget and also web-browser), http works. every day another problem. Same here. Quite annoying. Martin.
Re: [pca] support contract expired, need to renew/buy new, where?
I'll see what I can find out.. John Horne wrote: On Mon, 2010-05-10 at 17:00 -0700, Don Jackson wrote: Hope nobody else has a contract expire until this gets resolved. Hi, Our contract (covering 3 servers) expired last autumn, but it has taken till March (or was it April) this year until they renewed it. We have had Sun contracts for over a decade, but this time they were absolutely hopeless. Numerous phone calls and emails didn't seem to make any difference, neither did trying to escalate the problem! We had no patch access for months. John.
Re: [pca] Fun with entitlement again
Hi, Unfortunately I don't have any confirmation on the pricing structure for the support plans, so all I can suggest for now is that you contact your local sales rep. Sorry, I don't have anything more concrete to share here. I can however confirm that once you have purchased hardware support (i.e an Oracle Premium System Plan), that you will have access to all hardware patches (not just hardware patches applicable to your specific machine), along with Solaris support. HTH, -Don Martin Paul wrote: Jan Holzhueter wrote: Martin Paul wrote: and I've heard that it may cost like 20% of the price of the machine, per year. It's not that much. I read 12% for Hard- and Software and 8% for Software only. But I still need to see a real price. Better, but still about half the machine price for a usage period of 4 years. BTW, does anybody have heard about special conditions for research education customers, both for hardware and support contracts? Just want to know if they can download all firmware stuff or only the System they have support for? I'm 99.999% sure that the answer to this is all firmware stuff, but a confirmation would be nice indeed. Martin.
Re: [pca] rebuild patch level
Martin Paul wrote: Hi, Ihsan Dogan wrote: Is it possible to install only the missing patches on host a, which are installed on host b? A flash archive, as suggested by Michele, is definitely the best way to go. If that's not an option, you can get a list of all patches installed on host b (in the correct order) with ls -rt /var/sadm/patch/. You could then feed this list into pca -i on host a. Never tried that in a real-world scenario, though. E.g. some driver patches might not apply to host a, if it isn't the same architecture as host b. Just to reiterate Martin's point here, to use a flash archive (flar) from one system and apply it to another both machines should be as closely matched as possible. They'll obviously need to have the same system architecture and ideally should be the same model (i.e. from one SunFire T2000 to another SunFire T2000), to ensure that the drivers from machine a will work on machine b. I've used flars to clone test systems before and have to say that they are extremely useful for scenarios that are suited to them. You need to be careful using flars with systems that have certain machine specific configurations. For example, suppose you have a machine - machine1 - that is running a web server and the web server's configuration file contains a reference to the hostname - say machine1.mydomain.com. If you take a flar of that machine and apply it to another similar system - machine2 - then the new system will have a web server configuration file with a reference to machine1.mydomain.com... Also, flars do not play well with zones, so if your machine is a Solaris 10 machine with zones, you may need to look for an alternative... HTH, -Don Martin.
Re: [pca] 403 errors even with valid contract
Hi, Just to confirm the tweets and other info; all Solaris Patch Download behaviour should be back to exactly how it was a couple of weeks back before and changes were made to the entitlement system. I am working with some of my colleagues to get the descriptions of the various service offerings to clarify exactly what is/is not covered by the various support offerings. I will share any further information I receive with the alias. Best, -Don Martin Paul wrote: Martin Paul wrote: Glen Gunselman wrote: I see some comments at the bottom of http://wikis.sun.com/display/SunSolve/How+Entitlement+Works indicating problems with entitlements after recent changes on Sun's end ... Thanks for pointing me at this - I seem to have the same problem as reported by kevinriver. Starting a few days ago it suddenly wasn't possible for me to download Solaris 9 patches anymore; Solaris 10 patches work fine. Solaris 9 patch downloads have started to work again for me. It's just like described in the tweet on http://twitter.com/SunSolve : Good News - Solaris 9 Patches, the issue has been resolve via a work around. Your account might not show access but you will have access. Martin.
Re: [pca] Where have all the patch related email reports gone?
I'll see if I can figure out what's going on... Myers, Mike wrote: I haven't been getting these either. I'd just assumed my subscription had been lost in the whole Sun-Oracle transfer but I re-verified it last week and still no emails... Cheers, - Mike.Myers at nwdc.net -Original Message- From: pca-boun...@lists.univie.ac.at [mailto:pca-boun...@lists.univie.ac.at] On Behalf Of Glen Gunselman Sent: Friday, March 05, 2010 8:29 AM To: pca@lists.univie.ac.at Subject: [pca] Where have all the patch related email reports gone? In the past I relied on several Sun email reports to keep me somewhat informed about patches: SunSolve Online Notification of New Documents SUN ALERT WEEKLY SUMMARY REPORT Patch Club Report Newsletter It looks like my subscriptions are correct but the last reports I received are dated 2/18/2010 or 2/22/2010. From the blog at http://blogs.sun.com/security/category/alerts it sure looks like there have been new alerts since 2/22/2010. Thanks for any insight, have a good weekend, Glen Gunselman Systems Software Specialist TCS Emporia State University
Re: [pca] view required PROM updates?
Hi, We have been working over the past number of months to introduce a product based search in to PatchFinder - http://sunsolve.sun.com/patchfinder/. pca is really designed to download and install Sun standard svr4 format patches. It does not and should not have the capability to handle firmware patches. As Martin has pointed out, these patches do not use Sun's standard patchadd tool to apply, but instead typically require the user to place a file in a particular location and then reboot the machine with specific options to pick up the firmware update. For these reasons information regarding firmware patches which firmware patches to apply to your system should not be derived from information in the patchdiag.xref file. If you want a tool capable of performing bare metal provisioning, then perhaps you want a heavyweight patching tool like Oracle Enterprise Manager Ops Center - http://www.oracle.com/us/products/enterprise-manager/opscenter/index.html - but this is not a free tool! So, where can you find firmware information? Like I said initially, we are in the process of introducing a product based search into PatchFinder. This will enable you to navigate to products, such as the SunFire V890 and see all firmware patches specific to it. In the meantime you do have few other options: 1) Use the Big Admin Patching Center Firmware section (http://www.sun.com/bigadmin/patches/firmware/) - For example, info for the v880/890 is at http://www.sun.com/bigadmin/patches/firmware/release_history.jsp#V880 2) For older systems you may find what you need in http://sunsolve.sun.com/search/document.do?assetkey=1-61-204156-1 3) Use the existing PatchFinder tool to do a Synopsis line search for 890 (be sure to check the Show Obsolete checkbox to see all patches and not just the latest): http://sunsolve.sun.com/patchfinder/?max%3D20%26entitlementFilter%3D%26keyword%3D%26state%3DAVAILABLE%26uiForm%3DY%26securityFilter%3D%26uiAdvForm%3DN%26isObsolete%3DTRUE%26modifiedFrom%3D%26patchId%3D%26architecture%3DAll%26sortDir%3D%26patchProperty%3D%26releasedFrom%3D%26sunsolve%3D%26sortBy%3D%26file%3D%26releasedBefore%3D%26synopsis%3Dv890%26osRelease%3DAll%26bugId%3D HTH, -Don Martin Paul wrote: John Lyman wrote: Is there a way to view required PROM updates along with missing patches? Eric and Glenn are correct - the only bit of information that pca could use to correlate firmware patches with a certain machine is the textual description of the patch. This might look simple at first, but often there are multiple firmware patches for e.g. V880. Or just look at these: 119232 -- 02 --- 999 Hardware/PROM: Sun Blade 2500 (non Silver) Sun Fire V250 Flash PRO 119233 -- 02 --- 999 Hardware/PROM: Sun Blade 2500 (Silver) Flash PROM Update The uname command doesn't have information about the color of the machine. Then there's much more firmware in a system than you might imagine (disks, dvd drive, back plane, service processor, etc.), all of which require different patches. It's not that it's technically impossible to find a solution for this problem. Sun could have given a unique ID to any device with patchable firmware, provide a command which lists all the IDs and firmware versions in a system, and list the IDs/versions in patchdiag.xref with each patch. Now you have all ingredients to make a tool like pca work for firmware patches as well. In a closed environment of Sun hard- and software that would have been doable, but as soon as you add third-party hardware, everything gets very complicated .. Martin.
Re: [pca] SunSolve forgot about contract
Hi, I'll follow up and see if I can find out what's happened... Best, -Don Alexander Skwar wrote: Hi. On Fri, Feb 12, 2010 at 09:28, Martin Paul mar...@par.univie.ac.at wrote: Alexander Skwar wrote: Sorry for the bad style - but are you able to (re-)submit an existing contract? I'm not. I entered a contract number, but even after clicking on "refresh session" (or logging out and back in), the system doesn't show that a contract is assigned. Same here - there's no error, but the contract number doesn't show up either. I used the "+" (Feedback) link to report the problem, but as I'm supposed to rate the website there and got the following response, I wonder whether this will be of any help: Going to follow that example. Would it help to raise a normal ticket by calling Sun? Alexander
Re: [pca] SunSolve forgot about contract
All should be working again now... Best, -Don Don O'Malley wrote: Hi, I can confirm that we have identified the system that is the cause of the contract issues. Apologies for any inconvenience. We are working as quickly as we can to resolve the issue. I will post to this alias to let you know when the issue is resolved. We have additionally posted the following message to the SunSolve homepage to communicate this problem: NOTICE: Please be advised that some Patch Downloads and Update Account are currently unavailable. We apologize for any inconvenience. We will remove this message when the outage has ended. Best, -Don Don O'Malley wrote: Hi, I'll follow up and see if I can find out what's happened... Best, -Don Alexander Skwar wrote: Hi. On Fri, Feb 12, 2010 at 09:28, Martin Paul mar...@par.univie.ac.at wrote: Alexander Skwar wrote: Sorry for the bad style - but are you able to (re-)submit an existing contract? I'm not. I entered a contract number, but even after clicking on "refresh session" (or logging out and back in), the system doesn't show that a contract is assigned. Same here - there's no error, but the contract number doesn't show up either. I used the "+" (Feedback) link to report the problem, but as I'm supposed to rate the website there and got the following response, I wonder whether this will be of any help: Going to follow that example. Would it help to raise a normal ticket by calling Sun? Alexander
Re: [pca] sunsolve flunks for me, anybody else?
We've just posted a message on SunSolve to this affect too: Alert: wget customers ~ Please log into SunSolve to re-accept the new Software License Agreement prior to running any wget scripts. You can also look under "Update Account" and refer to: Step 5: Register for patch download automation Check the box to confirm that you read the license and save the changes. Downloads will work as normal at this point. Best, -Don Dominique Frise wrote: Martin, I can confirm the same behaviour. Dominique Martin Paul wrote: Jeff, I just read these messages on http://twitter.com/SunSolve : SunSolve rebranding to Oracle colors just went live, Users have to accept a new Software License prior to downloading patches or updates. Alert: wget customers - Please log into SunSolve to re-accept the new Software License Agreement prior to running your wget script. As I got the same "Error 401: Unauthorized", I looked at SunSolve to see whether I would be presented with a new license. I wasn't, but under "Update Account" there's: Step 5: Register for patch download automation Check the box to confirm that you read the license and save the changes. Downloads started to work for me immediately. It would be great if somebody could confirm this procedure, so I can put a note on the PCA website and to the pca-news list! Martin.
Re: [pca] Bad IP Filter patches
Thanks for the heads up Martin. I'll follow up with the engineers involved with the patch to confirm. I'll keep you posted. Best, -Don Martin Paul wrote: Hi, A word of warning for all of you who are running Solaris IP Filter. It is strongly suspected that the current ipf patches are faulty: 141505 -- 05 RS- 11 SunOS 5.10_x86: ipf patch 141506 -- 05 RS- 11 SunOS 5.10: ipf patch I just helped a colleague fixing a problem where a machine became unresponsive on the network about 5-6 minutes after reboot. Here's a thread on Sun's Networking Forum started by someone who had the same issue: http://forums.sun.com/thread.jspa?threadID=5420590tstart=0 There are other threads describing problems with these patches in the same forum - look for the patch numbers in the subject: http://forums.sun.com/forum.jspa?forumID=903 No idea whether there's an open case already, but *I* would definitely put these patches on the ignore list on any system running Solaris IP Filter until they are marked as BAD or new revisions are available. Martin.
[pca] Patch Download Service Unavailable
Hi, Just in case you are trying to download patches at the moment, there is an outage in the Patch Download Service at the moment. The following message is has been posted on SunSolve: Outage Maintenance on boundary applications: Start Time: Wed December 17th 10:00 am MT End Time: Wed December 17th 12:00 noon MT. NOTICE: Please be advised that some software patch downloads will be unavailable during this outage. We apologize for any inconvenience caused. We will remove this message once this outage has ended. Best, -Don
Re: [pca] Failing downloads
Hi Martin, There was an unscheduled outage this morning between 08.05 and 10.45. Apologies for the inconvenience. I didn't have any fore-warning to provide a heads-up. I'm really trying to get folks to communicate when we hit these issues by putting a notification on SunSolve, but it's not always easy with the unplanned outages. Best, -Don Martin Paul wrote: Hi, Just FYI - right now, with every download from SunSolve I try (no matter whether via wget or via the webpage) I only get a 28-byte file containing: error, service unavailable The error is returned from getupdates2.sun.com. Martin.
[pca] SunSolve maintenance window this weekend
Hi, Just a quick heads up... There is a scheduled Maintenance Window for SunSolve this weekend. The SunSolve homepage contains the following notification related to this: Outage Maintenance on boundary applications: Start Time: Nov 14th 9:00 AM MT - End Time: Nov 15th 11:00 AM MT. Please note: existing users should not be effected. Any new user or wget user will not have access until the end of the outage window. We apologize for this inconvenience. I'm in the process of getting confirmation that there will be no wget access during this outage and will confirm this later. Best, -Don
Re: [pca] Understanding --fromfiles
Hi Martin, Assuming everything is working as intended I believe your approach below is correct. SunSolve getupdates2 do adhere to the standard HTTP return codes. This is a complete list of the return codes I have seen from SunSolve/getupdates2 to date: 401 Unauthorized 403 Forbidden 404 Not Found 500 Server Error 503 Service Unavailable 504 Gateway Timeout So, while the messaging around the different return codes may change, the actual return code itself (and it's meaning) will not. If possible I would code to extract the return code and interpret from there. Best, -Don Martin Paul wrote: Mauricio Tavares wrote: Now if I could make it tell me whether I am not allowed to download a patch (as opposite of it not being available) instead of just saying Trying https://sunsolve.sun.com/ (1/1) Failed Failed (patch not found) I made up my mind, as some more details on failed patch downloads definitely would be nice. It will also make support easier, as I won't have to ask for debug output anymore in certain cases. So the current development version of pca analyzes output from wget, looks for errors, and displays them on failed donwloads of any file. Example: Looking for 142675-01 (1/1) Trying https://sunsolve.sun.com/ (1/1) Failed (Error 403: Forbidden) ... I've also added a table of known errors to pca's documentation under DOWNLOAD ERRORS: $ pca --man ... DOWNLOAD ERRORS If downloads of patches, patch READMEs or the patchdiag.xref file fail, the displayed error might help to diagnose the problem: Unauthorized (401) The user/passwd you provided is not correct. Forbidden (403) The user/passwd is correct, but the SOA is not connected to a support contract, which is needed for the requested file. Not Found (404) The requested file does not exist on SunSolve. Server Error (500) The SunSolve server is in a bad state. Retry later. I just hope that both wget's output format and SunSolve's HTTP replies won't change to often, forcing me to adapt my code. I tried to keep it as generic as possible. Martin.
Re: [pca] SunSolve maintenance window this weekend
Hi, I just got confirmation that this outage should NOT affect existing wget users. The message on SunSolve will be updated accordingly. Best, -Don Don O'Malley wrote: Hi, Just a quick heads up... There is a scheduled Maintenance Window for SunSolve this weekend. The SunSolve homepage contains the following notification related to this: Outage Maintenance on boundary applications: Start Time: Nov 14th 9:00 AM MT - End Time: Nov 15th 11:00 AM MT. Please note: existing users should not be effected. Any new user or wget user will not have access until the end of the outage window. We apologize for this inconvenience. I'm in the process of getting confirmation that there will be no wget access during this outage and will confirm this later. Best, -Don
Re: [pca] Understanding --fromfiles
Hi Fred, It's not only patches containing a security fix that Sun currently makes freely available. We also make patches that match the following criteria freely available: - Any patch required for the Solaris Patch Utilities or Patch Tools to function correctly - Any patch required for Live Upgrade to function correctly - Any patch required for Sun Hardware Support - Any patch required for Java to function correctly - Any patch fixing an issue that is likely to seriously impact a wide number of customers (i.e. a "CNN moment" - eg. Some Daylight Savings Time patches released last year were freely available ) - Any patch required by any of the above If you want to have access to all Solaris patches, then you need to buy a Solaris Subscription (which starts at $324 for system - see http://www.sun.com/service/subscriptions/index.jsp). If you do not want to purchase a Solaris Subscription, but still want access to bug fixes/features released in patches, the alternative is to wait until Sun release a Solaris Update and upgrade your system. Please bear in mind that Sun's primary objective is to make money, not give patches away for free. We will not be investing time money in any effort to advertise which patches are free vs. which patches require a support contract. That said we have recently added new lock symbol functionality to the PatchFinder Tool (http://sunsolve.sun.com/patchfinder/) to indicate which patches are public, which patches your support contract entitles you to and which you are not entitled to. Best, -Don Fred Chagnon wrote: Am I wrong in my understanding that Sun will let you download only security patches without a service contract? If this is correct, then you can get those with a: pca -i --fromfiles /path missings On 11/11/09, Mauricio Tavares raubvo...@gmail.com wrote: On Wed, Nov 11, 2009 at 5:15 PM, Bliss, Kevin L bliss.ke...@con-way.com wrote: Try it without the "*". That worked indeed. Thanks! Now if I could make it tell me whether I am not allowed to download a patch (as opposite of it not being available) instead of just saying Trying https://sunsolve.sun.com/ (1/1) Failed Failed (patch not found) I would be golden. -Original Message- From: pca-boun...@lists.univie.ac.at [mailto:pca-boun...@lists.univie.ac.at] On Behalf Of Mauricio Tavares Sent: Wednesday, November 11, 2009 2:13 PM To: pca@lists.univie.ac.at Subject: [pca] Understanding --fromfiles I am having a bit of an issue with --fromfiles. After installing pca, I ran uname -a, showrev -p, and pkginfo -x and save output in a directory called solaris8: bash-3.00# ls /export/pub/sol8/patches/solaris8 pkginfo.out showrev.out uname.out bash-3.00# When I ask pca to download the patches, I get the following message: bash-3.00# ~/pca --fromfiles=/export/pub/sol8/patches/solaris8/* -d missing ERROR: Can't find pkginfo/showrev/uname output with prefix /export/pub/sol8/patches/solaris8/* bash-3.00# Anything I did wrong?
Re: [pca] Interesting thing about Xref
Rajiv Gunja wrote: $ -- diff patchdiag.xref.Nov.04.09 patchdiag.xref.Nov.05.09 1c1 ## PATCHDIAG TOOL CROSS-REFERENCE FILE AS OF Nov/04/09 ## --- ## PATCHDIAG TOOL CROSS-REFERENCE FILE AS OF Nov/05/09 ## Not sure about this one... $ -- diff patchdiag.xref.Nov.06.09 patchdiag.xref.Nov.09.09 1c1 ## PATCHDIAG TOOL CROSS-REFERENCE FILE AS OF Nov/06/09 ## --- ## PATCHDIAG TOOL CROSS-REFERENCE FILE AS OF Nov/09/09 ## I know that the Engineer responsible for releasing patches was ill on Monday and that as a result no patches were released between 6th November 10th November (taking the w/e into account). This is primarily due to recent layoffs in Sun and the need to find a new backup person to take on Patch Release. The patchdiag.xref is generated by a cron job (or at least when it works it is) at the end of the day Us Pacific Time. No patches released means no updates to patchdiag (apart from the date), which is what you are seeing. If you do a diff between the patchdiag from the 9th and yesterday's/today's one you should see some changes as the backlog is cleared. Best, -Don -GGR -- Rajiv G Gunja Blog: http://ossrocks.blogspot.com
Re: [pca] Failed (no Sun Online Account data)
Probably also worth mentioning ~/.wgetrc is another configuration file that may be supplying username/passwd info to the wget calls made by pca. That said, I think Martin's right... :) Martin Paul wrote: Wei, I double-checked and I know for sure that I specified the correct account name and password in /etc/pca-proxy.conf on my proxy server. Doesn't pca go to Proxy Server's /etc/pca-proxy.conf to get Sun Online Account info? The problem you have is on your local pca proxy. Judging from the the output you provided, it's the proxy which fails to download patches. Then pca on the client tries to download the patch, and only succeeds when you provide SOA data to it. If you have an old version of pca installed as cgi-bin/pca-proxy.cgi, the first thing to try is to update it to the most recent version. Then check /etc/pca-proxy.conf to see if it has the correct login/passwd. If it still doesn't work, put debug=1 into pca-proxy.conf, which should write debug output from pca-proxy.cgi to /tmp/pca-proxy-debug.txt - now try to download a patch on the client (e.g. pca -d 120068-02) and send us the output from /tmp/pca-proxy-debug.txt. Martin.
Re: [pca] Failed (no Sun Online Account data)
Hi Wei, This looks like a problem with the Sun Online Account information that you are providing to pca. Are you using a pca configuration file (/etc/pca.conf or similar)? If so, can you double check the SOA username/passwd that you have provided in it is correct. Have you recently associated a contract to your SOA account? If so, there may be a delay of up to 48 hours before automated patch downloads will work for you (though the error you are seeing does not indicate that this is the case). I would suggest that you try a wget download of a patch directly initially to confirm that this is working and then see if you can download the same patch via pca. Details of how to download a patch via wget are available at http://sunsolve.sun.com/search/document.do?assetkey=1-9-240066-1. (I suggest you try download 120068-02 (a public patch) and 140778-01 (a patch requiring a contract).) Please include output of any failed wget download attempts with your reply. Best, -Don wei@dot.gov wrote: I am able to download both of the following two patches manually from sunsolve, but both failed when download them via pca. Why does it say patch not found? I mean I can find them on sunsolve and am able to download them manually. Thanks for your help. -- Looking for 119247-36 (8/82) Trying http://10.22.44.47:2020/cgi-bin/pca-proxy.cgi? /usr/sfw/bin/wget http://10.22.44.47:2020/cgi-bin/pca-proxy.cgi?119247-36; --timeout 3600 -O /var/tmp/pca_client_patch_dir/119247-36.tmp --23:30:43-- http://10.22.44.47:2020/cgi-bin/pca-proxy.cgi?119247-36 = `/var/tmp/pca_client_patch_dir/119247-36.tmp' Connecting to 10.22.44.47:2020... connected. HTTP request sent, awaiting response... 500 119247-36 not found 23:31:44 ERROR 500: 119247-36 not found. Failed Failed (no Sun Online Account data) Failed (patch not found) -- 119281 17 21 -S- 34 CDE 1.6_x86: Runtime library patch for Solaris 10 Looking for 119281-21 (9/82) Trying http://10.22.44.47:2020/cgi-bin/pca-proxy.cgi? /usr/sfw/bin/wget http://10.22.44.47:2020/cgi-bin/pca-proxy.cgi?119281-21; --timeout 3600 -O /var/tmp/pca_client_patch_dir/119281-21.tmp --23:31:44-- http://10.22.44.47:2020/cgi-bin/pca-proxy.cgi?119281-21 = `/var/tmp/pca_client_patch_dir/119281-21.tmp' Connecting to 10.22.44.47:2020... connected. HTTP request sent, awaiting response... 500 119281-21 not found 23:32:32 ERROR 500: 119281-21 not found. Failed Failed (no Sun Online Account data) Failed (patch not found) From: pca-boun...@lists.univie.ac.at on behalf of Asif Iqbal Sent: Mon 11/9/2009 11:13 PM To: PCA (Patch Check Advanced) Discussion Subject: Re: [pca] Failed (no Sun Online Account data) On Mon, Nov 9, 2009 at 10:57 PM, wei@dot.gov wrote: Yes. I was able to download those failed patches manually from sunsolve. could be something wrong with your proxy. it should not say no sun online account. you may want to post a verbose output for more help From: pca-boun...@lists.univie.ac.at on behalf of Asif Iqbal Sent: Mon 11/9/2009 10:42 PM To: PCA (Patch Check Advanced) Discussion Subject: Re: [pca] Failed (no Sun Online Account data) On Mon, Nov 9, 2009 at 5:39 PM, wei@dot.gov wrote: Thanks Derek for your response. My Sun account has a valid support contract and I should be entitled to all the patches. I tried pca -a and got the same error message. I just don't understand why 10 patches were downloaded successfully but 72 failed. Does anybody else have the same problem? How do find out what's wrong here? can you download any of those failed patch manually from sunsolve? -Original Message- From: pca-boun...@lists.univie.ac.at [mailto:pca-boun...@lists.univie.ac.at] On Behalf Of Derek Terveer Sent: Friday, November 06, 2009 4:57 PM To: PCA (Patch Check Advanced) Discussion Subject: Re: [pca] Failed (no Sun Online Account data) Probably 10 were public patches and 72 required the account. Try running pca with -a to prompt you for your account login/password. derek On Fri, Nov 06, 2009 at 04:55:28PM -0500, wei@dot.gov wrote: I haven't used pca for 4-5 months. Today I updated pca and ran pca -d missingrs to download the patches for my Solaris 10 x86 system. 72
Re: [pca] Missing patch files
Hi Edward, Edward J. Corbett wrote: Hi all, I am having problems with most patches failing due to: Failed (patch not found). I have seen the News post from 10/23 indicating that Sun is aware of this and working on it. But it is unclear to me if the [pca] New release: 20091030-01, is supposed to be the fix to this. I am also starting to have issues with patches failing because /var/sadm/pkg is getting full. My first inclination would be to delete the old patch directories which now amount to about 2GB; but of course things like that are never a good idea, without knowledge. If I can't delete them, what is the alternative? Since there is really no other place to move them. See http://sunsolve.sun.com/search/document.do?assetkey=1-61-208057-1 for details of how to free up space in /var. HTH, -Don
Re: [pca] 403 Service Error (again)
Hi All, Yes, there are issues with SunSolve's Download Service again over the past 24 hours (from Sunday 8th November @ 08:00 - Monday 9th November @ 06.30). The issues appear to be resolved now. Apologies for any inconvenience experienced. If you continue to see issues downloading patches, please let me know (including pca/wget output of the failed download). Thanks! -Don Greg Putrich wrote: Same here... no go on 9 of them with the same error. Tried to grab the following patches: Patch IR CR RSB Age Synopsis -- -- - -- --- --- --- 118668 23 24 RS- 6 JavaSE 5.0_x86: update 22 patch (equivalent to JDK 5.0u22) 118669 23 24 RS- 6 JavaSE 5.0_x86: update 22 patch (equivalent to JDK 5.0u22), 64bit 119758 16 17 RS- 5 SunOS 5.10_x86: Samba patch 119961 05 06 --- 2 SunOS 5.10_x86, x64, Patch for profiling libraries and assembler 119964 18 19 --- 2 SunOS 5.10_x86: Shared library patch for C++_x86 122676 03 04 RS- 5 SunOS 5.10_x86: SunFreeware samba man pages patch 123591 10 11 RS- 9 SunOS 5.10_x86: PostgresSQL patch 137081 03 04 RS- 2 SunOS 5.10_x86: libpng Patch 141501 -- 04 RS- 13 SunOS 5.10_x86: kinit patch Greg On Nov 8, 2009, at 10:57 AM, Dominique Frise wrote: Today Sun Nov 8 17:54:58 CET 2009, I was unable to download patches. # pca -dV 137080 ... Trying https://sunsolve.sun.com/ (1/3) /usr/sfw/bin/wget https://sunsolve.sun.com/pdownload.do?target=137080-04method=h; --ca-certificate=/usr/local/bin/pca --header=Authorization: Basic ZGZyaXNlOnN1bl9pbg== -O /var/tmp/pca/137080-04.tmp --17:42:42-- https://sunsolve.sun.com/pdownload.do?target=137080-04method=h = `/var/tmp/pca/137080-04.tmp' Resolving sunsolve.sun.com... 192.18.108.40 Connecting to sunsolve.sun.com|192.18.108.40|:443... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: https://getupdates2.sun.com/all_unsigned/137080-04.zip [following] --17:42:47-- https://getupdates2.sun.com/all_unsigned/137080-04.zip = `/var/tmp/pca/137080-04.tmp' Resolving getupdates2.sun.com... 198.232.168.157 Connecting to getupdates2.sun.com|198.232.168.157|:443... connected. HTTP request sent, awaiting response... 403 Service Error 17:42:47 ERROR 403: Service Error. Dominique
Re: [pca] patch issue
Hi, Just to give you a quick update on this. AFAICT we are expecting patches to be submitted to resolve CR 6797442 (fp_cache_constructor() causes fm-capability ereports) later today. This would mean that, assuming that no issues are discovered during test verification, these patches could be available as early the next 2 weeks. The patch ids containing the fix will be 141874-05 141875-05. If you have escalated this issue through the regular support channels you may be able to get access to the patch while it is in the T-Patch state (though this obviously comes with the caveat that the patch has not yet completed testing and should be used with caution). I have also flagged the issue with our Sun Alert team and they are preparing a SunAlert for this issue. There is another possible workaround being discussed to prevent the constant error notification generation: Add the following line to /kernel/drv/emlxs.conf: fm-capable=0; Then reboot the host. This workaround has one side effect; it will disable all DDI FMA related ereport, not just for dvr-name = fp. This is currently just a suggestion and has not yet been tested (also you will need to reboot), so I am not advocating you use it. I'm just sharing the information with you... I'll pass on more information as I get it. Best, -Don Dominique Frise wrote: Hi Don, We have about 10 Sparc servers with emlxs drivers impacted by this issue. In other words: we are also waiting for a fix ! Thanks, Dominique Don O'Malley wrote: Hi Kevin/Brian, As this CR has Escalations open against it there should be a patch containing the fix available for it before May 2010. I'm not sure roughly when you could expect a fix; I'll do some digging and see if I can find out. Best, -Don Bliss, Kevin L wrote: I spaced that one, but that makes the delivery date way out there, I hope the SE is wrong or I will have to back out the existing patch. Thanks -Original Message- From: pca-boun...@lists.univie.ac.at [mailto:pca-boun...@lists.univie.ac.at] On Behalf Of Brian R Myers Sent: Tuesday, November 03, 2009 11:29 AM To: PCA (Patch Check Advanced) Discussion Subject: Re: [pca] patch issue Kevin, Update 8 was just released the beginning of last month. If Sun's schedule holds constant, update 9 should be released in May 2010. -Brian -Original Message- From: pca-boun...@lists.univie.ac.at [mailto:pca-boun...@lists.univie.ac.at] On Behalf Of Bliss, Kevin L Sent: Tuesday, November 03, 2009 10:49 AM To: 'PCA (Patch Check Advanced) Discussion' Subject: Re: [pca] patch issue I opened a case with Sun, the engineer opened a bug, they found that the bug was a duplicate so closed the new one. The fix is supposedly complete but won't be available until Sol 10 update 9 (which I thought was available). In case you are interested the bug is CR6797442. Not as much detail as you received in your ticket but neither is complete. -Original Message- From: pca-boun...@lists.univie.ac.at [mailto:pca-boun...@lists.univie.ac.at] On Behalf Of Hannu Kivimäki Sent: Tuesday, November 03, 2009 6:23 AM To: pca@lists.univie.ac.at Subject: Re: [pca] patch issue Hi, On Thu, 2009-10-22 at 11:09 -0700, Bliss, Kevin L wrote: This is not a pca issue but may be helpful to those on the list. A recent Solaris 10 patch has created a compatibility issue with fmd which causes it to log 10+ errors per second to /var/fm/fmd/errlog. I only noticed because one of the systems patched was running low on space. I opened a case with Sun yesterday morning but so far have not received any useful information, including which patch caused the problem. The system is the following error being logged several times a second: Oct 21 2009 12:35:09.061332556 ereport.io.ddi.fm-capability nvlist version: 0 class = ereport.io.ddi.fm-capability ena = 0x2196595e6b07001 detector = (embedded nvlist) nvlist version: 0 version = 0x0 scheme = dev device-path = / (end detector) dvr-name = fp __ttl = 0x1 __tod = 0x4adf626d 0x3a7dc4c A quick note about this older topic - I patched some servers yesterday and noticed /var/fm/fmd/errlog getting filled with ereport.io.ddi.fm-capability messages (500+ MB of them overnight). Contacted Sun Support and they told me to back out Emulex patch 141876-05. FMA support was introduced in 141876-03 and apparently something broke it already in 141876-05. We never had any revisions of 141876 installed before, so after removing 141876-05, we are now back to Emulex patch 139608-05 with no fmd issues. I guess we have to wait for 141876-06 before trying patching Emulex HBA drivers again. Hannu
Re: [pca] OT: timing of Sun patch releases?
Hi, Sorry for the delay coming back to you on this. I think most of the major points have been covered already. In short, no, Sun do not have any release schedule for patches. Patches are released as they complete testing and are deemed to be release-ready. From this perspective, we do not introduce any unnecessary waiting periods for patches that have completed testing verification, like Microsoft may do with their Patch Tuesday. The Big Admin article Jan pointed out at http://www.sun.com/bigadmin/hubs/documentation/patch/patch-docs/abugslife.pdf gives a good insight into the patch creation process. The big rule to take from this article is that all changes get put back to the development release (Solaris Next) first and must soak there for 4 weeks prior to being allowed back into a Patch Gate for Solaris 8, 9 10. From there to release there are a number of internal processes that come into play to determine how long it will take for a patch to get created, tested and released. (The main issue here is that the Patch Gate for a particular Solaris Release will not always be open to put code back into and subsequently create a patch from.) As Marin points out, when a Solaris Update is Release Ready, there will be typically in the region of 80-100 patches that will be released pretty much at the same time (each obsoleting a previous sustaining patch). Sun do recommend that, where possible, customers upgrade to the latest Solaris release and then apply patches thereafter in line with their specific patching strategy. By upgrading you would have these 80-100 patches already pre-applied or freshbitted in the Solaris Update, and so avoid the need to manually apply them. I realize that in practice this may not always be practical, with upgrade sometimes requiring customers to recertify their applications. Let me know if you've any other questions on this and I'll try and provide more information if I can... Best, -Don Martin Paul wrote: Jeff A. Earickson wrote: I've noticed that patches seem to come in unpredictable waves; generally a new wave hits the day after I've done rebootable patches during scheduled downtime. There's one kind of event which always creates a huge wave of new patches - right after a new Solaris has been published, many patches are obsoleted by new patches, and the new kernel patches also replaces a lot of other patches. This is happening right now, after the release of Solaris 10 10/09. This is due to the SplitGate model used for Solaris 10 update releases. Gerry Haskins writes about that, e.g. in: http://blogs.sun.com/patch/entry/solaris_10_kernel_patchid_progression hth, Martin.
Re: [pca] failing patch downloads - 141870-01
Hi Martin, I can see why this is happening; Patch 141870-01 seems to have somehow avoided being processed by our Entitlement code on its release. The end result is that it has no Entitlements associated with it, so all attempts to download it are failing as the entitlement offerings have nothing to match against for this patch. Now to find out what went wrong and if other patches are affected too. Hopefully this is an isolated incident. I'll be back with more on this in a couple of hours. Best, -Don Martin Paul wrote: Don O'Malley wrote: The issues with the patch download service on SunSolve have been fixed. ... Can you please let me know if you are continuing to have issues? The download of patch 141870-01 via pca/wget fails with ERROR 403: Forbidden, other new patches as of today downloaded fine. When I search for the patch in Patchfinder, it shows up with a lock icon (Not Entitled) and I can't download it there neither. The patch entitlements in Update Account look fine. Martin.
[pca] All Patch Downloads Failing
Hi, More bad news. Not been a good week for patch downloads... :( All patch/readme/patchdiag downloads are currently broken. I've identified where the problem is and am waiting for the team that own it (it's the new patch download service getupdates2) to investigate. I flagged the issue about 30 mins ago and it has been happening for the past 30-50 mins. I'll keep you posted on the progress. Sorry for any inconvenience. Best, -Don
Re: [pca] All Patch Downloads Failing
Hi, getupdates2.sun.com is down for scheduled maintenance apparently. It should be back up in the next 30 mins I'm told. Apologies for the shocking lack of notice to you that there was maintenance scheduled on such a key piece of our infrastructure. I'll do my best to ensure that you are notified of such maintenance windows ahead of time in future. I'll let you know when the system is back online. Best, -Don Don O'Malley wrote: Hi, More bad news. Not been a good week for patch downloads... :( All patch/readme/patchdiag downloads are currently broken. I've identified where the problem is and am waiting for the team that own it (it's the new patch download service getupdates2) to investigate. I flagged the issue about 30 mins ago and it has been happening for the past 30-50 mins. I'll keep you posted on the progress. Sorry for any inconvenience. Best, -Don
Re: [pca] All Patch Downloads Failing
Hi, getupdates2 is back online. I've tested the SunSolve servers and all are working again. Apologies again for the lack of notice prior to this outage and any inconvenience it caused. Best, -Don Don O'Malley wrote: Hi, getupdates2.sun.com is down for scheduled maintenance apparently. It should be back up in the next 30 mins I'm told. Apologies for the shocking lack of notice to you that there was maintenance scheduled on such a key piece of our infrastructure. I'll do my best to ensure that you are notified of such maintenance windows ahead of time in future. I'll let you know when the system is back online. Best, -Don Don O'Malley wrote: Hi, More bad news. Not been a good week for patch downloads... :( All patch/readme/patchdiag downloads are currently broken. I've identified where the problem is and am waiting for the team that own it (it's the new patch download service getupdates2) to investigate. I flagged the issue about 30 mins ago and it has been happening for the past 30-50 mins. I'll keep you posted on the progress. Sorry for any inconvenience. Best, -Don
