Re: [pca] Wrong patches downloaded
On Sun, Dec 14, 2008 at 5:17 PM, Ron Halstead wrote: > Thank you Mike. I'll use your reply as the root cause. Yes, it has to be > perfect. My company is in the nuclear industry for the Department of Energy. > Nuclear culture does not allow mistakes as they can cause things to "glow in > the dark". Thus, the culture covers everything, including patching. well, I hope that the rest of *their* process is as perfect as you are looking for, such as regression testing in a lab with new patches for all existing software, rolling out through live upgrade, and other such "RAS" processes that reduce complexity and handle failures well.
[pca] pca dealing with patch ZFS alternate boot environments.
Have been using pca for several months now to maintain my home systems, after having successfully used it to update Studio 12 patches on SXCE. I'm now using ZFS root on S10U6, and am looking to figure out how to use pca to either generate a good patch list, or to find out if pca can patch an alternate boot environment as described in the page: http://docs.sun.com/app/docs/doc/819-5461/ghnnv?a=view In the short term, I suppose I can convert the output of ./pca -I to generate a patchlist to hand live upgrade. Am I missing something in pca? Thanks, Ben
Re: [pca] Generate List
On Tue, Mar 10, 2009 at 12:36 PM, Gehring, Andrew
wrote:
> I’ve searched the archive, possibly using bad keywords…
>
>
>
> However, I’m trying to find a way to generate a list of patches installed on
> a system, to use to patch another system so the they match “patch level”
Assuming you have used pca with the "host" system, and have not cherry
picked patches, you should be able to use the patchdiag.xref file that
you used to install those patches, on the target system.
If you're not sure, then you need to do your homework as follows:
./pca -l all 2>&1 | egrep -v "NOT FOUND IN CROSS REFERENCE
FILE|^Using|^Host|^List|^Patch|^--" | awk '{ printf "%s-%s\n", $1,
$4 }' > host-patchlist.txt
will generate the list of patches using the patchdiag.xref on the system you
want to replicate. (there may be an option to not print the verbose
headers, didn't see it)
Then push the same patchdiag.xref file to the new system and run that same
command, as well as
./pca | awk '{ printf "%s-%s\n", $1, $4 }' > target-need-patchlist.txt
which will generate a list of the patches from the patchdiag.xref file
that you need
to install.
Then cross reference the files, and you should be able to generate a
list of patches
you want pca to install.
Re: [pca] Functionality with Patching?
On Tue, Mar 10, 2009 at 1:32 PM, Open Source Rocks wrote: > All, > We are patching a whole lot of servers whose OS update varies from 2003 > actual release to U1 to U4. > > I wanted to know if I patch these OSes to Dec 2008 (patchdiag.xref frozen to > end of Dec 2008), will I get the same functionality as U6? Meaning > capability of ZFS boot, auto-update on container move, which comes with U6? AFAIK, only U4 and U5 can be patched forward to U6. U1-U3 must be upgraded to U4 before you can patch forward.
Re: [pca] April 8th proxy xref?
On Mon, Apr 27, 2009 at 4:49 PM, Jon Whitehouse wrote: > Ok. I’m really confused I have a proxy setup for pca. Everything appears > setup correctly. > > > > On proxy: > > > > Webserver: > > -rwxr-xr-x 1 webservd webservd 138810 Apr 8 07:59 pca-proxy.cgi > > > > -rw--- 1 webservd webservd 93 Mar 17 11:24 /etc/pca-proxy.conf > > -rw-r--r-- 1 700 root 312 Apr 16 17:01 /etc/pca.conf > > > > # cat /etc/pca-proxy.conf > > xrefdir=/pca-proxy/pca > > patchdir=/pca-proxy/pca > > user= > > passwd= > > > > # cat /etc/pca.conf > > # PCA Patching Directories > > patchdir=/pca-proxy/pca > > # PCA Proxy > > wgetproxy=http://proxy-server:8080 > > # PCA - Sun ID & Password > > user= > > passwd= > > # Try to download 5x > > dltries=5 > > # Keep pca updated > > update=auto > > # Write successful patches to user syslog > > syslog=user > > # set ssprot > > ssprot=http > > > > Now when I run pca it looks correct: > > > > # pca > > Using /var/tmp/patchdiag.xref from Apr/24/09 > > > > Now if I go to another box that I want to connect to the main server and run > pca > > > > # pca > > Using /tmp/patchdiag.xref from Apr/08/09 > > > > Why is it using one from April 8th??? It doesn’t matter what other box I go > to, it always trys to default to April 8th…. Here is the config from a box > that keeps saying it only has one from the 8th... I’m stumped. > > > > # cat /etc/pca.conf > > # Patch Check Advanced - Configuration File > > # Conf File Updated: 04/27/2009 > > # > > # Patch Directories > > patchdir=/tmp > > xrefdir=/tmp > > # Use Local Proxy > > patchurl=http://pca-proxybox/cgi-bin/pca-proxy.cgi > > xrefurl=http://pca-proxybox/cgi-bin/pca-proxy.cgi > > # Try to download 5x > > dltries=5 > > # Keep pca updated > > pcaurl=http://pca-proxybox/cgi-bin/pca-proxy.cgi > > # Write successful patches to user syslog > > syslog=user > > # Do not use https > > ssprot=http > Run in debug/verbose mode, then remove the offending /var/tmp/patchdiag.xref file and run again in debug/verbose mode. there may be an issue with the proxy and how that update is being handled... Ben
Re: [pca] PCA issue
On Tue, Apr 28, 2009 at 12:04 PM, Young Kevin wrote: > HI, I’m currently using PCA to download and install missing patches for our > UNIX farm, but unfortunately I’m experiencing issues, the error I receive is > > > > Tue Apr 28 09:23:32 2009: Trying https://sunsolve.sun.com/ (1/1) > > Tue Apr 28 09:23:32 2009: /usr/sfw/bin/wget > "https://sunsolve.sun.com/pdownload.do?target=118683-03&method=h"; --execute > http_proxy=http://05echo:3128 --ca-ce > > rtificate=/var/apache2/cgi-bin/pca-proxy.cgi --header="Authorization: Basic > Z2VycnltY2Y6aGVucmlrNw==" -O /pca/118683-03.tmp >>/tmp/pca-proxy-debug.txt > 2>&1 > > --09:23:32-- > https://sunsolve.sun.com/pdownload.do?target=118683-03&method=h > > => `/pca/118683-03.tmp' > > Resolving sunsolve.sun.com... failed: node name or service name not known. ding ding ding. Name resolution? networking get out of whack?
Re: [pca] SunSolve: 403 Forbidden with valid Contract
My problem has repeatedly been that my account gets "deactiviated", and I have had to go through this at least 3 times in the last 4 months, with have a valid Platinum support contract. Pretty depressing that there are this many issues. On Thu, May 28, 2009 at 3:28 PM, French, David wrote: > You may also want to try adding --ssprot=http if using the latest > versions of pca. I discovered for my setup that using https will fail > downloading a lot of patches, but as soon as I use --ssprot=http > everything is much more reliable. In fact once last weekend everything > was failing using https, but worked perfectly when switched to http. > And yes, https had worked before. > > Anyway, just a thought... > > --Dave > >> -Original Message- >> From: pca-boun...@lists.univie.ac.at >> [mailto:pca-boun...@lists.univie.ac.at] On Behalf Of Scott Severtson >> Sent: Thursday, May 28, 2009 7:34 AM >> To: PCA (Patch Check Advanced) Discussion >> Subject: Re: [pca] SunSolve: 403 Forbidden with valid Contract >> >> We've used PCA successfully in the past with this SunSolve account. >> >> However, I discovered yesterday that my contract number was >> no longer associated with the account for some reason. I've >> added the contract back in, but given your confirmation, I'm >> wondering if it may be an account configuration issue. >> >> I'll follow up with Sun for now. >> >> Thanks! >> --Scott >> >> >> On Thu, 2009-05-28 at 16:08 +0200, Martin Paul wrote: >> > Scott Severtson wrote: >> > > Via the SunSolve web site, I'm able to download patches >> that require >> > > a contract, but via PCA/wget, I'm seeing a 403: Forbidden. >> > >> > Is this a new problem, ie. has it worked before, or is it the first >> > time you're using pca to download patches? >> > >> > If you have special characters in your password, try to put >> it into a >> > configuration file instead of specifying it on the command line, or >> > quote correctly. >> > >> > > Is anyone else experiencing this? Is this an issue at Sun's end? >> > >> > I just tried, and it worked for me. Can you post the debug output >> > anyway (remove/overwrite the "Authorization: Basic XXX" setting), >> > maybe we can spot something. >> > >> > Martin. >> > >> >> > >
[pca] Sunsolve access acting weird
I was downloading some patches this morning, to patch an Alternate Boot Environment. pca got 63 of 170, but I got a bunch of 403 errors, which made me wonder if my sunsolve access hadn't been revoked again (4 times in the last 3 months.). However, one of the patches that failed to download with pca, I was able to download from the sunsolve web page. Thoughts? Ben -- 137035 01 < 02 --- 5 SunOS 5.10_x86: ttymon patch Looking for 137035-02 (46/160) Trying https://sunsolve.sun.com/ (1/1) /usr/sfw/bin/wget "https://sunsolve.sun.com/pdownload.do?target=137035-02&method=h"; --ca-certificate=./pca --header="Authorization: Basic " -O /opt/software/install/patches/custom/./137035-02.tmp --11:56:11-- https://sunsolve.sun.com/pdownload.do?target=137035-02&method=h => `/opt/software/install/patches/custom/./137035-02.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... 403 Forbidden 11:56:12 ERROR 403: Forbidden. Failed Failed (patch not found) --
Re: [pca] PCA bug
On Thu, Sep 10, 2009 at 6:46 PM, Jon Whitehouse wrote: > Ah. How come I never got that before? I've been running pca on that box for > a long time and never got that error before. I think some guts were put in pca to look for appropriate wget. Your debug log should indicate which version got picked up. Ben > > --- > Jon Whitehouse > Systems Engineer - IT, Server Support > MS 5221 > 1800 W. Center Street > Warsaw, IN 46580 > (574) 371-8684 > (574) 377-2829 (cell) > jonathan.whiteho...@zimmer.com > > >> -Original Message- >> From: pca-boun...@lists.univie.ac.at [mailto:pca- >> boun...@lists.univie.ac.at] On Behalf Of Dennis Clarke >> Sent: Thursday, September 10, 2009 2:39 PM >> To: PCA (Patch Check Advanced) Discussion >> Subject: Re: [pca] PCA bug >> >> >> > This is a new one on me from a Solaris 9 box I have setup in cron to >> check >> > for latest pca. >> > >> > pca --update now >> > ld.so.1: wget: fatal: libc.so.1: version `SUNW_1.22' not found >> (required >> > by file /usr/local/bin/wget) >> > ld.so.1: wget: fatal: libc.so.1: open failed: No such file or >> directory >> > Use of uninitialized value in scalar chomp at /usr/sbin/pca line >> 1031. >> > Use of uninitialized value in substitution (s///) at /usr/sbin/pca >> line >> > 1032. >> > Use of uninitialized value in split at /usr/sbin/pca line 1032. >> > Use of uninitialized value in multiplication (*) at /usr/sbin/pca >> line >> > 1033. >> > Use of uninitialized value in multiplication (*) at /usr/sbin/pca >> line >> > 1033. >> > ld.so.1: wget: fatal: libc.so.1: version `SUNW_1.22' not found >> (required >> > by file /usr/local/bin/wget) >> > ld.so.1: wget: fatal: libc.so.1: open failed: No such file or >> directory >> > Use of uninitialized value in concatenation (.) or string at >> /usr/sbin/pca >> > line 1036. >> > No new version available >> >> That is not a PCA bug. That is a bug you have in some version of wget >> that >> you are running. It was compiled with a newer rev of Solaris ( or who >> knows what ) and thus the libC version SUNW_1.22 is something you don't >> have. >> >> Go get wget at www.blastwave.org. Just install pkgutil and use it. >> >> -- >> Dennis Clarke >> dcla...@opensolaris.ca <- Email related to the open source Solaris >> dcla...@blastwave.org <- Email related to open source for Solaris >> >> > > >
Re: [pca] iconv error
When you say "rebuilt", do you mean "reinstalled", or reimaged from backups? ldd /usr/local/bin/wget will probably indicate which SunFreeware packages you may have forgotten to install. On Tue, Oct 6, 2009 at 4:39 PM, McGranahan, Jamen wrote: > Has anyone seen this error before? I haven’t been able to find much about it > via Google, so thought I would check here - idn_decode failed (9): `System > iconv failed'. We have had to rebuild this server and we want to get it > patched asap. I’ve installed the most recent version of wget and all of its > dependencies, so I’m not sure what is going on here. Here is the debug > output: > > > > # perl pca.pl -i --debug > > Option install: 1 > > Option patchdir: /opt/patches/. > > Option user: x > > Option passwd: xx > > Option syslog: local0 > > Option debug: 1 > > ARGV: missing > > Version: 20090408-01 > > Config files: ./pca.conf pca.conf > > Using /usr/local/bin/wget (1.12, 11200, https) > > Prerequisites for threads not met, setting threads to 0 > > Never update > > Expanded patch list: missing > > Downloading xref file to /var/tmp/patchdiag.xref > > Trying https://sunsolve.sun.com/patchdiag.xref (1/1) > > /usr/local/bin/wget "https://sunsolve.sun.com/patchdiag.xref"; > --ca-certificate=pca.pl -O /var/tmp/patchdiag.xref > > --2009-10-06 15:36:51-- https://sunsolve.sun.com/patchdiag.xref > > idn_decode failed (9): `System iconv failed' > > Resolving sunsolve.sun.com... failed: node name or service name not known. > > wget: unable to resolve host address `sunsolve.sun.com' > > Failed > > Failed (patchdiag.xref not found) > > Reading from /usr/bin/showrev -p 2>/dev/null > > > > ERROR: Can't open xref file /var/tmp/patchdiag.xref (No such file or > directory) > > Cleanup > > > > *** > > * Jamen McGranahan > > * Systems Services Librarian > > * Library Information Technology Services > > * Vanderbilt University > > * Suite 700 > > * 110 21st Avenue South > > * Nashville, TN 37240 > > * (615) 343-1614 > > * (615) 343-8834 (fax) > > * jamen.mcgrana...@vanderbilt.edu > > *** > >
Re: [pca] new kernel patches
On Fri, Oct 16, 2009 at 2:41 AM, Dominique Frise wrote: > Martin Paul wrote: >> >> Dominique Frise wrote: >>> >>> # pagesize >>> ld.so.1: pagesize: fatal: libc.so.1: version `SUNW_1.22.5' not found >>> (required by file /usr/bin/pagesize) >>> ld.so.1: pagesize: fatal: libc.so.1: open failed: No such file or >>> directory >>> Killed >>> >>> Can someone can confirm this ? >> >> pagesize works for me. What do you get from these commands: >> >> ldd /usr/bin/pagesize >> ls -l /lib/libc.so* >> >> I think that the kernel patch brings in a new libc.so.1, maybe it hasn't >> been installed correctly. I see: >> >> # ls -l /lib/libc.so* >> lrwxrwxrwx 1 root root 9 May 6 09:58 /lib/libc.so -> >> libc.so.1 >> -rwxr-xr-x 1 root bin 1411852 Sep 14 15:35 /lib/libc.so.1 >> -rwxr-xr-x 1 root root 1411316 Aug 8 01:21 >> /lib/libc.so.1.111423 >> -rwxr-xr-x 1 root root 1411316 Aug 11 23:29 >> /lib/libc.so.1.120373 >> -rwxr-xr-x 1 root root 1411308 Jun 23 02:43 >> /lib/libc.so.1.147951 >> -rwxr-xr-x 1 root root 1411308 May 19 19:21 >> /lib/libc.so.1.173521 >> -rwxr-xr-x 1 root root 1411312 Jun 8 20:04 >> /lib/libc.so.1.210511 >> -rwxr-xr-x 1 root root 1411316 Jul 2 20:00 >> /lib/libc.so.1.218871 >> -rwxr-xr-x 1 root root 1411312 Jun 8 21:13 >> /lib/libc.so.1.286721 >> -rwxr-xr-x 1 root root 1411316 Jul 14 16:41 /lib/libc.so.1.52501 >> >> Martin. >> > Sun is looking into this issue. This seems to happend on x86 systems with > ZFS boot. > If your are concerned, wait for a fix/workaround. Anyone know if this problem is observed when using Live Upgrade on x86 with ZFS root? Ben
Re: [pca] synchronization between "recommended patch cluster" and patchdiag.xref?
On Tue, Oct 20, 2009 at 6:35 PM, Paul B. Henson wrote: > > On a currently open support request, Sun is complaining that the patches on > our server are way out of date and we should install the recommended patch > cluster. Did you send them an explorer? > We don't do patch clusters; we do pca :). > > A number of the patches they indicate should be installed do not appear to > be marked as recommended in the patchdiag.xref (my current one is dated > Oct/14/09), including for example: > >> ALERT: 140789 missing (current -01): SunOS 5.10_x86: nfsd, nfs4cbd, lockd >> patch > > 140789|01|May/18/09| | | | > |10_x86|i386;118855-36;120012-14;127128-11;|SUNWnfscu:11.10.0,REV=2005.01.21.16.34;SUNWnfssu:11.10.0,REV=2005.01.21.16.34;|SunOS > 5.10_x86: nfsd, nfs4cbd, lockd patch > >> ALERT: 140388 missing (current -01): SunOS 5.10_x86: statd patch > > 140388|01|May/14/09| | | | > |10_x86|i386;118855-36;120012-14;|SUNWnfscu:11.10.0,REV=2005.01.21.16.34;|SunOS > 5.10_x86: statd patch > >> ALERT: 141933 missing (current -02): SunOS 5.10_x86: unshare patch > > 141933|02|Aug/20/09| | | | > |10_x86|i386;137138-09;141734-02;|SUNWnfssu:11.10.0,REV=2005.01.21.16.34;|SunOS > 5.10_x86: unshare patch > > If they would have been marked as recommended, we would have already had > them installed. Since NFS isn't necessary to a machine, it's no wonder it isn't recommended. If you have NFS problems, then it's no wonder they're saying you're out of date. I usually push back if some solution center yo-yo tries to tell me I should be updating patches that have nothing to do with the issue. That's the solution center's basic mantra. Update, update, update. Which I can't fault them for. It those in-duh-viduals which insist that some patch be installed which has no correlation to the problem at hand which raises my ire. More times than I can count, some indeterminate problem has arisen on our systems, and the solution center will tell me to patch, because they have no more tools to debug the problem. At that point, I'm usually talking to backline. > Has anyone compared the contents of the recommended patch cluster to the > patchdiag file lately? I recall reading in the past occurrences where they > were not the same. With ZFS root, I'm just installing patches into a boot environment. I don't have the cycles to match against recommended, and so I just let pca update to current. That also makes it easier with the solution center (many times I've called in a problem and the first response is about patching. So nice to say, updated as of "yesterday") > It seems they really should be. Perhaps our resident Sun ambassador could > provide some feedback :)? Not really. Clusters are point in time "bundles", usually about every 4-6 weeks. The patchdiag.xref file is constantly moving. That's why I don't bother with clusters or recommended. patch to current, and I usually solve the issue of solution center asking about patches. It's really a PITA when some solution center engineer is holding up a real problem because of some perceive problem with a patch not being there.
Re: [pca] Bitten by 141445-09
On Thu, Oct 22, 2009 at 9:46 AM, Allen Eastwood wrote: > A while back I posted about using the combination of ZFS roots and > Live Upgrade when patching. I've made that my default patching > strategy and in doing so have avoided the last few major issues that > have come up with patches, including this one. That's the beauty of Live Upgrade. When it doesn't break. > My ZFS root pools do not have /var on a separate dataset. do you mean a separate file system, or do you mean in a different pool? > Even if you are on UFS root still, you can use Live Upgrade...it takes > longer, but patching an ABE on an alternate mount point seems to be > MUCH safer. I've applied this, and the last few kernel patches on > multiple sparc, CMT and x86 systems completely without incident. Agreed. I have regularly used multiple 20G / with ABE space for 8, 9 and 10 (pre-zfs) for this exact purpose. Depending on the size of the physical disk (and I was almost always mirroring with SDS) was the determining factor for sizing. for 300G disk, I leaned towards 30-40G, depending on how the system resources were to be used. I'm real crazy about not having a separate /var, but the recoverabilty far outweighs the issue for me about having /var on a / slice. Real monitoring of disk space (along with notification) mitigates space issues that might arise from something running away with /var space.
Re: [pca] patchdiag vs pca
On Tue, Oct 27, 2009 at 12:42 PM, Baldwin Sung wrote: > We are looking to standardize on a patch management tool. The two tools we > are working with is patchdiag and pca. Does anybody know if patchdiag is > officially supported by Sun? patchdiag is a many year old perl script which generates a report against the patchdiag.xref file. Beyond that, it doesn't do much else. And as it hasn't changed much in 7-8 years (It's been at V 1.0.4 for as long as I can remember using it) maybe longer. Is it supported by Sun? I guess. However, patchdiag is a shadow of functionality compared to pca.
Re: [pca] Missing patch files
On Mon, Nov 9, 2009 at 9:25 PM, Edward J. Corbett wrote: > > 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. You may want to consider the recurrance of this happening, and take this opportunity to flash archive the system, and jumpstart it back with a more reasonable file system layout. Instead of doing some hokey stuff to move files around or delete things that you may need to backout to. As has been witnessed here before, if you start doing surgery on your system to try and address space issues, it will continue to occur, and more than likely, odd behaviors will start appearing on your system that no one else can reproduce.
Re: [pca] Failed (no Sun Online Account data)
I was unable to download a specific patch this morning. Went to sunsolve, tried to download it, got a new "agreement", agreed, it downloaded. Once that happened, I was able to download with pca the same patch from my normal system. Kind of annoying. On Tue, Nov 10, 2009 at 11:53 AM, Don O'Malley wrote: > 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, 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, 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. >
Re: [pca] Failed (no Sun Online Account data)
I've been doing wget downloads for months. Every so often, they stop working and I have to resort to downloading from SunSolve. Fortunately, with your voice around, I have come to expect the irregular "update account" dance that has to be done so I can continue to use PCA. Thanks, Ben On Tue, Nov 10, 2009 at 3:29 PM, Don O'Malley wrote: > Hi Ben, > > For wget downloads there is a once off SLA that you need to agree to once. > > This is the section "Step 5 - Register for patch download automation" at the > bottom of the "Update Account" page > (http://sunsolve.sun.com/edit-user-form.do) you'll see linked on the top > right of the page when logged into SunSolve. > (See the "Prerequisites for using wget" section of > http://sunsolve.sun.com/search/document.do?assetkey=1-9-240066-1 also.) > > There have been some very isolated download issues earlier this morning > resulting in "ERROR 403: Service Error" responses from getupdates2.sun.com, > so you may have hit them. > > Best, > -Don > > Ben Taylor wrote: > > I was unable to download a specific patch this morning. > > Went to sunsolve, tried to download it, got a new "agreement", agreed, > it downloaded. > > Once that happened, I was able to download with pca the same patch from my > normal system. > > Kind of annoying. > > > On Tue, Nov 10, 2009 at 11:53 AM, Don O'Malley wrote: > > > 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, wrote: > > > Yes. I was able to download those failed patches manually from > sunsolve. &
Re: [pca] [OT] OpenSolaris / IPS support & patching
On Tue, Dec 15, 2009 at 6:23 PM, Jones, Dave wrote: > > Hi Team. > > This is a bit off-topic but I have a few questions about OpenSolaris as > it regards to to support & patching. > I thought someone on the list (maybe even Don) might know the answers. > > 1) Do the Sun support subscriptions for OpenSolaris offer the same > levels and types of support as they do for Solaris? > 2) Is anyone on the list running OpenSolaris in th place of Solaris on > Test/Dev/Prod? If so what are your experiences? > 3) Does IPS/OpenSolaris/Sun still "require" you perform patch installs > in Single User mode on OpenSolaris? > > We are strongly considering migrating off of Sun if we cannot get out of > the 8 - 12 hour patch windows we currently need to patch some of our > systems. bad process and design. > Live Upgrade is not an option because of several factors in our > environment, including excapsulated root disks with VxVM That's a pretty lame excuse for not using live upgrade. there is absolutely zero value add for VxVM on the root disk. SVM or ZFS is a much better option. >and several containers per host. So you must be running Solaris 10. You really need to look at ZFS root, and Live upgrade with boot environments. We are using them in production. > We cannot justify staying on Solaris under these conditions when Linux > allows us to patch the whole box in minutes while still at run level 3. > In fact, with Ksplice we do not even need to reboot to change kernels in > Linux anymore. another lame argument. Architect and design your systems with the proper design constraints, and you won't have to make these outlandish arguments. > If OpenSolaris and IPS does meets our needs then we can move in that > direction. If you're that concerned about stuff, you shouldn't be talking about Open Solaris. Ben
Re: [pca] PCA & LiveUpgrade questions and comments
On Wed, Feb 10, 2010 at 9:35 PM, Glenn Satchell wrote: >> Am 10.02.2010 um 20:17 schrieb Don Jackson: >>> >>> Finally, my question: >>> >>> Given that I am using the above to patch an alternate boot environment >>> (ABE), and given that ABE is not active/running, is it safe to just go >>> ahead and apply all the patches? >>> That is, can I not worry about the "apply as single user and reboot >>> afterwards" patches, and just go ahead and install those patches just >>> like all the other patches? >> >> I'm doing it this way all the time. > > Mostly it should be ok, but you need to be careful if a patch delivers new > functionality that a later patch relies on. I got caught out with a kernel > patch last year (forget the exact version) and wound up with as system > thast wouldn't boot. Learned vey quickly about booting from cd and using > patchrm -R to back out the last few patches :) failsafe mode wouldn't boot? >>> The idea is that after I finish patching the new ABE, I will make it the >>> default/active BE, reboot, and I will be running a fully patched OS. >> >> Yes. Why don't you try it? It simply works if you have installed the >> required Patches for using LU of course. >> >> thomas > > And if it doesn't work you have the old BE to boot from while you repair > the new one. Assuming that it is going to work more often that it fails > then you will stiff be in front. lol
Re: [pca] PCA & LiveUpgrade questions and comments
On Fri, Feb 12, 2010 at 5:32 PM, Don Jackson wrote: > > On Feb 11, 2010, at 8:33 AM, Rajiv Gunja wrote: > > Martin, > We should also note that luupgrade will install all patches in a given > directory in sequence. You have built into PCA, the logic to install a few > cyclic redundant patches (120011-14, 122660-10 and 125547-02) which SUN > requires to be installed before using LU, but luupgrade will not install. > > luupgrade will work fine if you have already installed LU patch cluster, > else I would suggest using PCA for patching standalone OS or OS running > non-global zones. > > Here is what I do: 1. Upgrade SUNWlu packages to the one from U6 > DVD.(SUNWluu, SUNWlur, SUNWlucfg and SUNWluzone) 2. Install latest "patch > utility patch" and Zone/LU patch (can be installed in multi-user and does > not require a reboot - 121428, 121430 and 119254) 3. Create BE and mount it > (I always use explicit directory to mount the BE, as I script most of it) 4. > Patch the BE. > > Yes, that is very similar to what I am doing now: > I install the solaris10_u8 image, then I install the following two patches: > 119255 70 < 72 RS- 22 SunOS 5.10_x86: Install and Patch Utilities Patch > 121431 43 < 44 --- 66 SunOS 5.8_x86 5.9_x86 5.10_x86: Live Upgrade Patch > Then I reboot (not 100% sure this is necessary), > Then I create the new BE, mount, patch, unmount, and activate the new BE. > So far, so good. > I am going to experiment with installing the two patches above in the Finish > script of a JumpStart install, so that once the install is done, I am ready > to finish the patching via a new BE. > I can't believe I didn't know about Live Upgrade before now, and that anyone > would not use after understanding it! There are times when it becomes frustrating. I ran into a failsafe boot bug where my separate /var didn't get mounted but the /var/home did. When it came time to do a live upgrade, it always failed the lucreate. On this particular system, I eventually tracked down that the ROOT device had a /var/home directory created in it. Of course, that meant having to take the system down to failsafe, clean the dir, and then redo the lucreate. Now it's working again... > The final piece of this puzzle will be if I can ever make jumpstart installs > of flash archives with ZFS root ever work. If I ever can, then I can build > the patched OS as per the above, > then replicate via subsequent JumpStart installs. JET can do this, and has been able to for over a year. Check Bigadmin for a link, or catch me offlist and I'll be happy to help. Ben
Re: [pca] PCA goes interactive
On Tue, Mar 2, 2010 at 4:10 PM, wrote: > Hi > > all of a sudden PCA is asking for Sun Online account user and password. Even > if I put in the details the download fails with patch not found (debug > output below). With the same account details I downloaded the same patch > from SunSolve through a web browser - no problem. Both pca client and proxy > are latest stable 20091216-02. > > Is anyone else seeing this problem? Any idea how to get back to downloading > patches non-interactively? > You have to go to the sunsolve account information and specifically indicate that you wish to download patches non-interactively. That should fix your problem. Ben
Re: [pca] Patch 142901-05: installation woes
Escalate higher. This is a ridiculous argument by some clueless Sunsolve engineer. On Tue, Mar 9, 2010 at 12:01 AM, Scott A. Severtson wrote: > All, > > Per Sun's support engineer: > > --- > PCA is not a supported way to apply patches and it must be used at the > user's own risk. > > This system is not supportable. I recommend we close this case and ask the > customer to use upgrade media to return to a supportable state. If the issue > persists you or he can open a new case referencing this original. > --- > > That's fantastic. > > --Scott > > On 03/08/2010 05:05 PM, Scott A. Severtson wrote: > > Alan, > > We have a case open with Sun (#72559404), which you may want to > reference. They've done some diagnostics, and have some clues, but > nothing definitive yet. > > All the machines involved run Postgres within a zone, regardless if the > patch was successful or not. > > However, I'm glad to know I'm not crazy :) > > --Scott > > On 03/08/2010 04:55 PM, Alan Wilson wrote: >> >> >>> Has anyone else successfully deployed 142901-05? Any ideas what we're >>> doing wrong? >>> Many thanks, >>> --Scott Severtson >>> >> >> We're having exactly the same issue as you >> >> The patch installed fine on one x4140 but not the other. >> >> We had exactly the same symptoms as you. >> >> The only difference is the problem server runs postgres. >> >> Is that the case with you? >> >> Our solaris support people recommended we open a >> support case with Sun. >> >> Alan >> >> >> >> >
Re: [pca] Patch 142901-05: installation woes
On Tue, Mar 9, 2010 at 11:15 PM, Scott A. Severtson wrote: > Follow-up from the support engineer: > >>> PCA uses patchadd internally to apply patches. Would we be having >>> this discussion if we had used PCA to download the patches, then applied >>> each one manually using patchadd? What if we had written a shell script >>> to loop through the patches, and run patchadd? >>> >>> How would the latter be different than using PCA to apply the patches? >> >> We also do not provide support assistance for any custom scripts which >> apply >> multiple patches; only for the Sun-provided patch cluster installation >> scripts >> and even those are provided mostly as a convenience. Any issues with any >> such tools must be reproduced using manual installation methods to receive >> full support. > > --- SNIP --- > >> The only methods to *repair* the system and return it to a supportable >> configuration are as follows: >> >> 1) reinstall >> 2) upgrade install >> 3) revert to a point before PCA was used and return to the current patch >> levels without it. If the issue persists we can begin developing a fix as >> mentioned above so you can revert once more and then apply the fix. >> >> In order to assist further, we need you to perform one of the above >> actions. >> The issue either will or it will not persist and we can resume the >> investigation >> from that point, if necessary, with renewed confidence in the integrity of >> the >> rest of the system. > > We're going with the "upgrade install" route - don't have the time/energy to > fight this battle while the server is non-functional. I would still follow up with said engineer's boss to discuss how unhelpful this has been Blaming it on the tool or procedure is a favorite game of support, instead of trying to analyze why it's broke. Also, if you're doing Solaris 10, I can highly recommend ZFS root with live upgrade. There's a few warts, but nothing that would make me want to go back to ufs with vxvm or svm.
Re: [pca] 403 errors even with valid contract
On Tue, Mar 23, 2010 at 2:51 PM, Dennis Clarke wrote: > >> Hi, >> >> Dennis Clarke wrote: >>> I don't like stating truisms, however if you look outside and see that >>> water is falling from the sky, this is because it is raining. If you see >>> that you can not get patches for free anymore for Solaris 8 or 9 or 10 >>> then that is because you can not get patches for them anymore. At least >>> not freely. >> >> Just like stated in the subject of the thread, both the original poster >> and me *do* have a contract we pay for. It's not that we want something >> for free, just what already gets paid for. > > whoa. > > Do you have a support contract for Solaris 8 and Solaris 9 also ? > > I only have Solaris 10 covered on my servers here and those all work as > expected but the Sol 8 and 9 patches fell of the availability list some > time ago. If you hold a legacy support contract ( very large dollars by > the way ) then by all means something is very wrong. Unless the access and > delivery interfaces for those services are different. My company has a support contract but not legacy (though we still have some S8 boxes around - had to reboot some 1700 day uptime systems yesterday...). We have been able to get S9 and S8 (well, except anything released since 4/1/09), but I have tried since the "changeover"
Re: [pca] well .. now I see the issue
On Mon, Dec 20, 2010 at 3:57 PM, Dennis Clarke wrote: > > # ./pca --user dcla...@blastwave.org --passwd --supplevel > Determining MOS Support Levels > > In spite of having a paid support contract .. I seem to have no MOS level > support at all. > > Must look into that. Not rocket science. Login to sunsolve, get redirected to Oracle MOS, do your contract stuff, PCA access works right after the registration... Ben
Re: [pca] Download all patches
On Tue, Feb 22, 2011 at 8:07 PM, little help wrote: > Is there a way to go through the patchdiag.xref and download all missing > patches. I know I can go to a client and download local copies, but I would > like to periodically do this on the proxy servers. I tried pca --download > but this seems to be a one off for each client it is run on. Thanks. > give it a list of patches you want. I regularly have to do this when some of my systems cannot reach the oracle site and I have to do it from a host I know that doesn't have network constraints. Ben
Re: [pca] SunRay (x86) patches don't show if not installed
On Fri, Mar 25, 2011 at 6:17 AM, Jan Holzhueter wrote: > Hi, > > Am 25.03.11 11:04, schrieb Martin Paul: > >> I have seen no notification of any change in the Sun Ray patch policy, >> and I see no technical reason why the patches shouldn't be available >> like all other patches, so I hope it's just an accident. Maybe Don can >> find out? > > They did change it. You need an SW entitlement for those too. > So they enforce the support stuff now for it. > > http://wikis.sun.com/display/SRS/Downloading+a+Sun+Ray+Software+Release+Update > > I would bet this will happen for the Sun/Solaris Studio patches too in > the future since those need a SW entitlement too. Oracle Solaris Studio 12.2 and Sun Solaris Studio 12.1 require contracts. I am still able to download the Sun Solaris Studio 12 patches while not being able to download 12.1 or 12.2 patches.
Re: [pca] Sunsolve is dead, long live to sunsolve...
On Wed, May 11, 2011 at 6:45 PM, Ron Halstead wrote: > I think it is a great idea and tool. Please make it available to all > sysadmins who care to use it (if they are smart). > > One suggestion: in the Synopsis column, use left justification instead of > center justification, its easier on the eyes when scanning down the column. > > Well done. > > Ron Halstead > > On 05/11/11 01:45 AM, Gouverneur Thomas wrote: >> >> Dear sysadmins, >> >> Days ago, I was wondering how I could ease my daily job dealing with >> patching, bugs, >> problem finding with Solaris. My missing tool was something to quickly >> find and correlate >> information. I didn't wanted to do my daily TLP/PCA -> Oracle MOS -> >> Readme files, ... anymore. >> >> I've then collected up some informations about patches, bugids and >> inter-dependancies between them, >> I've managed to gather a lot of information about that and I just begun to >> code some tools to >> find/treat information. >> >> This is why I end up here. My dilemn is, should I keep theses tools and >> information for myself, >> or could I make other sysadmin and people around there happier with them ? >> >> First of all, you could see what my current work consist of here: >> http://sunsolve.espix.org >> >> My questions are: >> >> * Will Oracle accept this kind of website ? >> * If yes, should the name of the website changed ? >> (I'm not attached to it, just the first thing that came to head) >> * If no, which information on the website are "too much" ? >> >> The goal of this (maybe) future website would be to help sysadmin out >> there, then, indirectly, to help >> oracle satisfying customers... >> >> On another hands, on the technical part, I've also some questions: >> >> * Have you got any usage of such website ? >> * Have you got any suggestion of a new tool or something that you want to >> see there ? >> >> * Anything to say? >> >> >> Thanks for reading, I'm waiting for your feedbacks ;-) This surely has more potential than Oracle's search tool, which I already gave up on.
Re: [pca] Patch 147440-25 issue
On Wed, Oct 17, 2012 at 3:01 PM, Culver, Michael wrote: > Recently installed 147440-25 on a t5120 which rendered it unbootable. After > no help from Oracle on the matter I removed the patch and regained access to > the system. Oracle’s response is that because I am not patching with the > patch cluster the patches are being installed in the wrong order. Even if I > ignored the history of 147400 I don’t believe that’s true. I’ve been using > PCA for years and haven’t had a problem till now. Having said all that, is > there any validity to the idea that the order of patch install may be a > factor? Are you running VxVM 6.0? We ran into a problem several months ago with VxVM 6.0 root mirrors and one of the kernel patches, that eventually caused the systems not to boot. We had to backout the kernel patch. I was recently notified that the version of VxVM 6.0SP1 has been released which should alleviate the incompatibility between the kernel patch and VxVM 6.0. Ben
Re: [pca] different directory for patches
On Thu, Jan 24, 2013 at 2:00 PM, Martin Paul wrote: > Am 23.01.2013 16:52, schrieb Stevenson, Bradley (NE): > >> Great! Does anyone know if the script will do disk space checking so it >> knows >> How much disk space it needs to install the patches. Or does anyone have a >> Script to do this ? > > > PCA doesn't do space checking. It's not that I wouldn't have thought about > adding it, but I never found a reliable method to compute the required > space, especially without extracting all patches before starting > installation (like the cluster does). > > With patchadd using temporary space (/tmp, /var/run), making (multiple) > backup copies of replaced files it's hard to find a reliable and provable > method to compute required space. > > The good thing is that patchadd (which PCA uses for the actual patch > installation) usually deals fine with interrupted patch installations, not > leaving any partly installed patches. It's always amazing to me all the consternation about working around space issues when patching with Solaris 10 (or even 9 since I think that's supported). Considering live upgrade can be used to reorganize boot disks space utilization issues (especially in the case of not using ZFS)
Re: [pca] xref aged 1603 considered up to date?
Are you running the LDOM manager (OVM 2.2) ? Ben On Wed, Oct 30, 2013 at 11:31 AM, Glen Gunselman wrote: > This does not seem right to me. Am I missing something? Isn’t the > number of days since last December less than 1603? I thought pca would > download a new xref file if the one it found was over 1 day old. > > ** ** > > ** ** > > ex=0 1030 10:20:43 zoot ~ notme $sudo /var/tmp/pca -V --list 149668 -- > xrefdir="/var/tmp" --patchdir="/var/tmp/pcatmp" > > Option list: 1 > > Option patchdir: /var/tmp/pcatmp > > Option debug: 1 > > Command: /var/tmp/pca > > ARGV: 149668 > > Version: 20130502-01 > > CWD: /home/gunselmg > > 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: 149668 > > xref mtime: Thu Dec 20 20:45:08 2012 > > xref now : Wed Oct 30 10:20:58 2013 > > xref ctime: Wed Oct 30 09:54:15 2013 > > xref age : 1603 > > Local file /var/tmp/patchdiag.xref is up to date > > osname from uname: SunOS > > Reading from /usr/bin/showrev -p 2>/dev/null > > patchdiag.xref size: 2241259 > > Using /var/tmp/patchdiag.xref from Dec/20/12 > > SUNWswmt patches: 108987 108988 110763 112951 114194 119254 119255 > > Host: zoot (SunOS 5.10/Generic_147440-25/sparc/sun4v) > > List: 149668 (1/356) > > ** ** > > Patch IR CR RSB Age Synopsis > > -- -- - -- --- --- > --- > > 149668 -- < 01 --- 356 VM Server for SPARC 2.2 ldmd patch > > ex=0 1030 10:21:06 zoot ~ notme $ > > ** ** > > ** ** > > ** ** > > Glen Gunselman >
Re: [pca] xref aged 1603 considered up to date?
Thanks for mentioning this. We're slowing getting rid of Solaris, but being able to snapshot a patchdiag.xref file with the patches, and not have to deal with it trying to look up a new one make our process very consistent. Ben On Mon, Nov 4, 2013 at 4:53 PM, Glen Gunselman wrote: > Martin, > > > BTW, do you know PCA's "-y, --nocheckxref" option? It will make PCA skip > > the check for updates of the xref file. If you use it with a frozen > > patchdiag.xref file, everything should be fine. > > > I find both: > > --nocheckxref and --xrefdir > > very useful. > > Thanks, > GlenG > >
[pca] patch access
I downloaded a patch on Monday (bash patch) and was successful. Now, a big pull from different data centers (different egress points to the internet) result in the same results. Here's the output from one of the failures. Looking for 151487-01 (134/134) Trying Oracle Trying https://getupdates.oracle.com/ (1/1) Failed (Error 401: Unauthorized) Failed (patch not found) Password is the same that works with MOP. Ideas? Ben
Re: [pca] patch access
I think it was something transient. Later in the day, I had no problem downloading a big list of patches. Thanks, Ben On Fri, Oct 10, 2014 at 5:08 AM, Martin Paul wrote: > Am 10.10.2014 10:53, schrieb Thomas Roos: > >> Try this in /etc/pca.conf, worked for us. Couldn’t download patches >> anymore with dltries=2, because of all the redirects at the other end. >> >> dltries=5 >> > > Actually the redirects should not matter in the "dltries" (they are > handled by wget, pca only receives the final result). > > But after years of fighting with Sun's and Oracle's patch download servers > I have no problem with Voodoo-like remedies, as long as they work :) > > Martin. > >
Re: [pca] pca broken for sparc architecture
http://lmgtfy.com/?q=How+do+I+get+off+the+pca+mailing+list On Thu, Apr 16, 2015 at 8:57 AM, Hewitt, Lenny wrote: > How do I get taken off this list? > > -Original Message- > From: pca [mailto:pca-boun...@lists.univie.ac.at] On Behalf Of Borut > Sent: Thursday, April 16, 2015 2:42 AM > To: pca@lists.univie.ac.at > Subject: Re: [pca] pca broken for sparc architecture > > I downloaded the latest patchdiag.xref from https://support.oracle.com, > but pca couldn't find sparc patches: > > # pca -si 151908 --wgetopt="--no-check-certificate --secure-protocol=TLSv1" > --user=xxx --passwd=xxx -R /.alt.s10u11-p9 Using /var/tmp/patchdiag.xref > from Apr/15/15 > Host: stereo (SunOS 5.10/Generic_150400-21/sparc/sun4u) > Root: /.alt.s10u11-p9 > List: 151908 (1/3) > > Patch IR CR RSB Age Synopsis > -- -- - -- --- --- > --- > 151908 -- < 01 --- 3 SunOS 5.10: sed patch > > Looking for 151908-01 (1/1) > Trying Oracle > Trying https://getupdates.oracle.com/ (1/1) Failed (Unknown Error) Failed > (patch not found) > > Installing 151908-01 (1/1) > Failed - missing patch file (08:29:53/00:00:00/00:01:04, 1/1, 0/0/1) > > -- > Download Summary: 1 total, 0 successful, 0 skipped, 1 failed Install > Summary : 1 total, 0 successful, 0 skipped, 1 failed # > > However, the same patch for i386 is installed perfect: > > # pca -si 151909 --user=xxx --passwd=xxx Using /var/tmp/patchdiag.xref > from Apr/15/15 > Host: secchi (SunOS 5.10/Generic_150401-21/i386/i86pc) > List: 151909 (1/3) > > Patch IR CR RSB Age Synopsis > -- -- - -- --- --- > --- > 151909 -- < 01 --- 3 SunOS 5.10_x86: sed patch > > Looking for 151909-01 (1/1) > Trying Oracle > Trying https://getupdates.oracle.com/ (1/1) Done > > Installing 151909-01 (1/1) > Unzipping patch > Checking files for safe patch installation Running patchadd Successful > (08:33:25/00:00:13/00:00:18, 1/1, 1/0/0) > > -- > Download Summary: 1 total, 1 successful, 0 skipped, 0 failed Install > Summary : 1 total, 1 successful, 0 skipped, 0 failed # > > Best regards, > Borut > > > > >
