Hi,
I know that some people use pca under non-Solaris systems like Linux,
e.g. to read patch READMEs, download patches, etc. While this was
already working fine when used in combination with the --fromfiles
option, this was a little cumbersome. So I decided to make a few changes
to allow pca
Craig Bell wrote:
Thank you very much Martin -- this is cool. =-)
Glad you like it :)
After a bit of testing, it looks like the running summary appears
after Done, but not Skipped or Failed.
You're right, I guess it makes sense to show the stats on any outcome.
I've added that now in
Gerard Henry wrote:
i'm wondering if anybody here has a better solution to deal with the
following process:
Here's a few things which might at least ease the process. Collect this
output from any Solaris system and copy the three *.out files to the
Linux machine once:
uname -a uname.out
Craig Bell wrote:
A casual request: Could pca show a brief session summary after each
patch? Perhaps something like:
Done -- 12:34:56 PST -- 00:10:30 elapsed, 02:30:40 total -- 103
successful, 1 skipped, 0 failed
I've recommended wrapper scripts for that in the past, too, but I
understand
Rajiv Gunja wrote:
It looks like the Usage page on your web site is missing. It shows up
blank.
Oops, thanks for the notification. Seems as if something went wrong with
my update script yesterday in the afternoon. I've fixed it.
Martin.
Hi,
1. Will pca pickup all the patches needed to support kernel patch 141444? (I
think I'm asking if I can trust the dependence list for 141444.)
Yes, that should be no problem.
2. Is it a bad idea to pick just a kernel patch out of the set of missingrs?
(The missingrs set includes 111
Don O'Malley schrieb:
All should be working again now...
It does for me. My contract is listed again, and patch downloads are
working.
Thanks a lot for your effort, once again!
Martin.
Laurent and Craig,
I agree on that this seems to be the same issue in both your messages.
It's due to the changed behaviour of pca now asking for SOA data by
default when it needs it (the former askauth option).
Rarely, the proxy times out (or some other minor error occurs) and the
client
Hi,
Where am i wrong?
I guess you don't have SRSS 4.0 installed, that's why 127553 doesn't
show up as missing. And supposedly you have all patches for your actual
version of SRSS installed, that's why no patch shows up as missing.
Verify with pca -l all | grep -i ray.
I've seen your
Hi,
In today's patchdiag.xref I noticed that the OBP (Flash PROM) patches
for some machines have been withdrawn. The patch READMEs refer to a
problem with certain machines on OBP firmware 4.30.3 being unbootable
when a PCI card with an internal pci-pci bridge is installed in a
certain PCI
Hi Dave,
Given that the --safe and --noreboot switches are in PCA, has Martin
Co. considered adding a check in the README to skip patches that must be
applied in single mode, or does the --noreboot switch cover that
already? My impression from talking with Sun is that reboot-required
does not
Don O'Malley wrote:
I'm hoping we'll have the accompanying SunAlert for this issue published
early next week.
Here's the SunAlert:
Solaris 10 IP Filter (ipfilter(5)) Patches (WITHDRAWN) May Cause a
Memory Leak for Systems With IPF's Stateful Filtering Configured
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.
Hi Edwin,
Modification of a read-only value attempted at ./pca-proxy.cgi line 2208.
Thanks a lot for the report and the patch! I've integrated the fix into
the current development release and scanned pca for other similar
possible issues (it was the only one of this kind).
I'm planning a
Hi Dennis,
Dennis Clarke wrote:
The most recent pca release causes an error on Solaris 8 servers thus :
# /export/medusa/dclarke/build/pca/pca/bin/pca -f $PCA_FROMFILES -l
missing /export/medusa/root/pca_data/$MACHINE/patch_report_missing
Can't locate File/Temp.pm in @INC (@INC contains:
Lee,
The results you reported and your setup look absolutely fine.
Using truss without --debug with my command line (i.e. a failure), I see
no attempt at wget execution.
I'm stumped. In your first message you show it failing with:
...
Trying https://sunsolve.sun.com/ (10/10)
Failed
Hi Lee,
$ /dss/bin/pca --version
pca 20091030-01
$ /support/bin/pca --getxref --wget=/usr/local/bin --xrefdir=/tmp
Are these two copies of pca? I assume that the version is the same?
I can't imagine a reason why --debug should alter the behaviour of pca
when downloading the xref file;
Hi,
There's one thing I never was happy with - pca is providing the Sun
Online Account data (user and passwd) to wget via a --header option.
Any user on the same machine can get the full command line of the wget
process while it's running with ps, revealing the base64 encoded (not
Dražen Kačar wrote:
Martin Paul wrote:
I've found an elegant workaround now - if $WGETRC or ~/.wgetrc exists,
pca copies it to a temporary wgetrc file (mode 600) and appends the
header options for the SOA data. Before running wget, $WGETRC is set
to point at this temporary file, which
Hi Sebastian,
The somewhat adjusted 500 error message came from an intermediary proxy.
pca-proxy.cgi responded with HTTP/1.1 500 SOA missing which the proxy
translated into HTTP/1.0 500 Internal Server Error. Once i skipped the
proxy everything went smoothly. Seems as if our internal proxy
Martin Paul wrote:
Gerard Henry wrote:
before applying the liveupgrade procedure, we need to verfiy a bunch
of patches on this document:
http://sunsolve.sun.com/search/document.do?assetkey=1-61-206844-1
I'm attaching a small script I've used for the same purpose in the past.
Run it like
Hi Sebastian,
Couldn't you just use a custom authentication scheme to handle auth
between pca-proxy.cgi and pca?
You pointed me at HTTP custom headers, which are made available to the
CGI script by Apache via environment variables - that's a promising way
to get data from the client to the
Sebastian Kayser wrote:
Sounds like a very flexible, architectural decision. Maybe with an
exclusion list for certain variables like xrefdir/patchdir? Or the other
way round, an explicit inclusion list. People might be concernced about
external requests setting xrefdir/patchdir. I know, this
Hi Don,
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:
Thanks for the verification and the list! I've changed:
Server Error (500)
to
Server Error, Service Unavailable,
On Fri, Nov 13, 2009 at 05:13:21PM +0100, Alexander Skwar wrote:
Dunno how feasible it is, but couldn't you implement it so, that the
proxy does a HTTP Basic Auth Request? And the username/password
thus supplied is then passed on as the Sun Account details?
I had the same idea on the way home
Mauricio,
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
...
Failed (patch not found)
Usually, a patch not being available is the same as not being allowed to
download it. The only exception might be
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
Hi,
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.
Patch
Asif Iqbal wrote:
would be nice if I could ask pca to download the recommended cluster. lazy
me :-)
I'm lazy, too :) and I don't have an idea about how to add this easily
to pca without breaking the consistency of the command line interface
(accepting e.g. 10_Recommended as a standard
A new release of PCA has just been published. Here's a list of
new features and changes:
* New option to skip check for UID 0 (--norootchk)
* Change URL used to download patchdiag.xref with HTTPS
* Show debug output on stderr instead of stdout
* Do not append / to local URL if last character
Xu, Ying (Houston) wrote:
We would like to use security patch
cluster to make minimal changes to the environment but fix sun alert
issues.
Here's one possible procedure you could use, e.g. for a monthly patch cycle:
On a certain date, e.g. mid-month, you install all the current security
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?
There's still a download page for Patchdiag 1.04:
Glen Gunselman wrote:
It's my understanding that the patching process ignores SST hardening.
I have seen patching undo hardening on Solaris 9.
It's been a long time since I used JASS/SST, but I guess it does its
hardening mostly by changing some configuration (files), disabling
services,
Bliss, Kevin L wrote:
I am having problems with patch downloads again, is it down again?
As much as it is failing, perhaps the better question is it up yet!
I see some failures to download the xref file in the proxy's logfile
from yesterday, but today all downloads worked fine here.
Martin.
Hi Michele,
echo * Package SUNWjass is installed. Be prepared to audit your *
echo * JASS settings after patching and possibly re-apply JASS. *
It's probably fine to do such things in a wrapper, like other local
checks, or advices from the senior to the junior administrators.
The fact
Don O'Malley wrote:
getupdates2 is back online.
.. and back offline, as it seems. All I get is:
error, service unavailable
when downloading any patch.
Martin.
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
Hi Don,
The servers are now back up, so we should see
http[s]://sunsolve.sun.com/patchdiag.xref fall back in sync overnight.
If not, I'll do more investigation I guess :)
$ wget http://sunsolve.sun.com/patchdiag.xref -O - | head -1
...
# PATCHDIAG TOOL CROSS-REFERENCE FILE AS OF
The default URL used by pca to download the patchdiag.xref file
currently provides an outdated version of the file (Oct/19/09). There is
an alternative URL - which requires wget with HTTPS support - which has
the correct file (Oct/21/09).
I've now made a change to the development release of
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.
...
A number of the patches they indicate should be installed do not appear to
be marked as recommended in the
Don,
The issues with the patch download service on SunSolve have been fixed.
Good to hear that, as always :)
Can you please let me know if you are continuing to have issues?
All downloads of patchdiag.xref, READMEs and patches I tried worked fine.
I see a new design of the SunSolve main
Don,
It seems as if no update to patchdiag.xref has been published today,
as I still get yesterday's version Oct/19/09 instead of the expected
Oct/20/09.
http://sunsolve.sun.com/pdownload.do?target=patchdiag.xref appears to be
correct:
Yes, that link has the current file. It's not the
Don,
It seems a little coincidental that this version of patchdiag has not
been updated after moving to the new SunSolve release.
Yes, that's what makes me extremely nervous ..
As a workaround for now, pca users can set xrefurl to get the current
xref file:
pca
So this time it's me, reporting failed patch downloads. I get ERROR
403: Forbidden for many (but not all) of the new patches from today's
patchdiag.xref. Can anybody download one or more of these successfully?
Patch IR CR RSB Age Synopsis
-- -- - -- --- ---
Thanks Frank and Thomas for checking the download. So it seems as if
it's now my SOA which is a victim of the mysterious suddenly doesn't
work anymore symptom.
I tried to download the patches via the browser from SunSolve, but it
also told me that I'm not entitled to do so. Looking at the
Gerard,
2 days ago, i installed this patch with pca on a sparc machine, and pca
said that the patch is installed:
Oct 17 07:55:57 mombasa pca: [ID 702911 local6.notice] Installed patch
120185-19
You can look at /var/sadm/patch/120185-19/log to see if it reports problems.
As far as pca is
Frank Langelage wrote:
Looking for 142539-01 (22/22)
...
22:43:01 ERROR 403: You are not entitled to retrieve this content..
For some days now I'm seeing the problem described, but as I said the
support contract is still alive and assigned in my profile.
Unfortunately I can do nothing in
Michele Vecchiato wrote:
I want configure my dedicated local patch server(pca proxy mode with web
server, no NFS way) to work with any pca client by https
connections(port 443 by default). I want use Apache V2 Web server on
Solaris 10 U7(05/09) on my SPARC system(Sun Fire V490). Will serve
Don O'Malley wrote:
Infodoc 81509 : Configuring SSL for Apache 2 bundled in Solaris 10
which sounds exactly like what you want, but this document doesn't
seem to exist (anymore); strange.
That document now lives at:
http://sunsolve.sun.com/search/document.do?assetkey=1-61-210954-1
gerard wrote:
yes, you're right:
/var/sadm/pkg/SUNWstaroffice-sunsearchtoolbar/save/120185-19/undo: --
file unchanged
compress(1) returned error code 2
The SUNWstaroffice-sunsearchtoolbar backout package will not be compressed.
Continuing to process backout package.
Installation of
Brian,
However in the pca code there is a line that checks your id and asks
if it is '0'. If not pca exits and says you must be root. However
since we are running as sudo we are effectively root, but do not have
roots UID.
Good point. With sudo and RBAC it's not a safe assumption that UID==0
Frank,
Looking for 142539-01 (22/22)
...
22:43:01 ERROR 403: You are not entitled to retrieve this content..
I can download the patch when using my SOA which is connected to a
support contract. When using another SOA without support, I get:
09:38:56 ERROR 403: Forbidden.
For whatever
Francois wrote:
./pca -r 141879
Using /scripts/./patchdiag.xref from Oct/15/09
Downloading README for 138218-01
Patch-ID# 138218-01
[...]
Why readme of 138218-01 is returned instead of 141879 ?
Look at pca -l 141879. As you specify a patch ID without revision, pca
will resolve patch
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
The new kernel patches for Solaris 10 (from 10/09) have been published
today:
141444-09: SunOS 5.10: kernel patch
141445-09: SunOS 5.10_x86: kernel patch
As always, the README states that they should be installed in
single-user mode and a reconfiguration boot should follow the
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'.
Never seen the message before. Try wget
https://sunsolve.sun.com/patchdiag.xref; to check whether
dpecka wrote:
1) stdout normal output like list of patches etc
2) stderr:
2.1) headers which could be maintained by -H switch
2.2) --debug messages which should be printed on stderr anyway
but its only my proposal ;) ..
There's probably no one-size-fits-all solution here,
Cromwell, Ray, VF-IE wrote:
This has always worked with http://10.162.69.230 , however I have
changed just to eliminate and still same error .
Ok, so wget probably just ignores the http://; part.
Has wget always used ssl , as you can see from my output its not using
https --
wget
Cromwell, Ray, VF-IE wrote:
I have updated PCA to latest version and changes sshost=sunsolve.sun.com
Previously was sshost=sun.com
It's best to remove the sshost setting altogether. About the only
situation where using this option makes sense is on a system without or
with broken DNS
Gurugunti, Mahesh wrote:
My downloads seems to broken on the same lines, still unable to
download. For example as below:
Looking for 141910-01 (1/1)
Locking /pcarepo/.pcaLock.download.141910-01 failed
This seems to be a different problem. Either a second instance of pca is
trying to download
Georg Schwarz wrote:
That's pretty much the same problem that I have. Pca is only able to
download patches from the akamai server. Downloads from the
getupdates2 server are not possible at all and fail.
To be precise - the actual download will always be from the akamai
server. As far as I
Hi,
It is not allowed to add packages after that patching or you have to
install ALL (also already installed patches) again. This is obvious to
me because otherwise the new packages will only eventually only
partially patched. This has been discussed on the list some weeks ago.
B.T.W.: Is it
Hi,
thanks for your help. I did try to add the mentioned packages but after
that I got even more of these error messages, so I did not try further.
Yes, the problem is that package A again will require package B and C,
and so on, and finally you end up installing Entire Distribution
anyway.
Jon Whitehouse wrote:
# /usr/sfw/bin/wget --no-check-certificate
https://sunsolve.sun.com/patchdiag.xref
--09:07:14-- https://sunsolve.sun.com/patchdiag.xref
= `patchdiag.xref'
Resolving sunsolve.sun.com... 192.18.108.40
Connecting to sunsolve.sun.com|192.18.108.40|:443... failed:
Don,
While it has not yet been decided the timeframe of the fix for this (it
could be October), I was advised that there is a operand method-tr
(obviously news to me too!) that can be used instead of method=r to
retrieve a patch README.
I didn't know about method=tr either, but it seems to
Don O'Malley wrote:
I have confirmed that the patchdiag.xerf will remain on SunSolve.
Thanks. I guess I will make pca use HTTPS for the xref file when wget
supports it, and HTTP if it doesn't (as a fallback) and deprecate
--ssprot (as soon as I know what's going to happen with the READMEs).
Techie wrote:
2) I have local files associated with my EMC array, should I use the
-s or safe option when running the install command for these patches?
Yes, using --safe in such a situation is recommended. Actually, I'm
using it whenever I'm installing patches. It does no harm (besides
Hi Don,
Here's some internal analysis of the certificate issues (it's pretty
much what you have below)...
Thought it was worth passing on all the same.
Yes, thanks. I just remembered that I had started a thread on
comp.unix.solaris about this last year, see:
Daniel,
So I do cat our_certificate /patches/pca/pca and It works
As there is no option to use external certificate file in pca.conf ,
I will have to do this each time I upgrade it
When dealing with certificates, you should try to fix the problem with
wget instead. I think
David,
I'd like to add that the ldd test for SSL support in wget will not work
in Solaris 9 if you are using the SUNWwget* packages, as SSL support is
statically linked into that version.
You're right. I've read that part of your previous message only after
sending that information, and I
dpecka wrote:
sorry for molesting, this issue is probably in progress, but since last
week, i am unable to download readmes ::
Same here. Although right now I see a different failure pattern (see
below). A zero-byte text/html is returned by SunSolve whenever
requesting a patch README (using
dpecka wrote:
strange is, that for *some patches can be README file fetched with no
problems ..
119906-13 .. README works
119906-14 .. README doesnt work
Both don't work for me. Are you sure that it's not somewhere on a pca
proxy or in the current directory already? Output from e.g. pca
Hi Don,
Works for me...
I can now download the patchdiag.xref file again, both via HTTP and
HTTPS. Is it planned to keep HTTP support for that file at least? If
possible, I'd prefer to stick to HTTP for the xref file, as it wouldn't
force those people who use pca for analysis only to get
Eric Ham wrote:
On Wed, Aug 12, 2009 at 6:47 AM, McGranahan,
Jamenjamen.mcgrana...@vanderbilt.edu wrote:
Hmmm, according to pkginfo -l command, we have this package installed on our
system:
r...@lib480:/#pkginfo -l SUNWwsr2
PKGINST: SUNWwsr2
NAME: Solaris Product Registry Web Start
A new release of PCA has just been published. Here's a list of
new features and changes:
* Fix for wgetproxy option not being honored when HTTPS is used
* New option to disable patch dependency resolution (--nodep)
* Fix typo in error message
* Documentation: Posting to the pca mailing list
Hi,
it works fine, but sometimes it downloads *nothing as readme due ?some
server/client side timeout.
It would be interesting to know why the downloads fail for you. You can
check that with pca's --debug option.
can be inside pca script added some test if for example readme was
Hi John,
Running 'pca -V' I get a 403 Forbidden error. I tried using
'--ssprot=http' but that made no difference. I tried logging in directly
to Sunsolve, we have an account, and could access the patch but only
after accepting their 'SUN MICROSYSTEMS USER LICENSE AGREEMENT'.
Since the patch I
amy.r...@tufts.edu wrote:
Our Sun rep says that they're going to be moving people to their new support
infrastructure SMC, and I was wondering if anyone was using that and pca and
if they were still compatible?
While I haven't used an of Sun's enterprise management tools, I'm pretty
sure that
Hi,
Don O'Malley wrote:
All is fixed and a later version of the patchdiag is now available.
The new xref file and most patch downloads worked fine, but I have
problems to download this one:
140124 01 02 --- 1 SunOS 5.10_x86: kernel/drv/dnet patch
I get 403 Forbidden consistently. The
McGranahan, Jamen wrote:
Pkginfo -x = nothing returns
/var/sadm/pkg = one zip file (119788-09.zip)
That's not good. Solaris keeps information about all installed packages
in this directory, and it seems to be gone from your system. Without
this information, you will never again be able to
[Jamen contacted me directly, I'm sending the reply to the list]
McGranahan, Jamen wrote:
Well, I think I found them. Someone moved the files from
/var/sadm/pkg to /apps/sadm/pkg.
That was my first suspicion ..
Can I force pkginfo to look in this directory? You stated that a
softlink would
Myers, Mike wrote:
There's definitely something up at Sun...again.
Seems as if no new patchdiag.xref has been published today neither. I
still get ## PATCHDIAG TOOL CROSS-REFERENCE FILE AS OF Jun/16/09 ## as
of today.
Martin.
Hi,
Is it possible to convince the PCA script to generate a non-host specific
report using data from patchdiag.xref?
I'd like to generate an HTML report to show *all* (any OS version,
unbundled, etc.) patches from Sun in the last 14 days.
Maybe this is what you want:
pca --maxage 14
Paul,
Yes, all connections to the outside world must go through the proxy. I
have now set http_proxy in /etc/wgetrc to the proper address and enabled
it with http_proxy=on.
That's a typo and you have use_proxy=on, right?
On the last line of the debug file I see Connecting to
Gerard,
i've set a proxy server on my network, and it is a os2008.11 machine.
Is this a pca proxy, or a standard web proxy?
And somatimes, i need to download individual patches. If i do it on the
client machine, the patch isn't downloaded on the proxy server.
Hm, when a client is
Gerard,
pike-root% /etc/scripts/pca -l 137137
...
pike-root% /etc/scripts/pca -d 137137-09
That's a common issue. pca behaves differently when you specify either a
patch ID or a patch ID plus revision. In the first case, it resolves
dependencies and shows you all required patches as well.
Hi,
Just to add some more now that I have checked a 2009.06 box :-)
Thanks for the information!
I guess you could try Martins suggestion. If that works then perhaps
there is an argument for pca not to need patchadd/showrev when just
doing a --download operation.
Yes, although downloading
Gerard,
13:13:33 ERROR 500: Update option unavailable: Can't write to
/var/apache2/2.2/cgi-bin/pca-proxy.cgi.
...
The server is configured as follow:
r...@www2:/var/apache2/2.2/cgi-bin# cat /etc/pca-proxy.conf
...
update=auto
That's the problem. If update is set to auto, pca (in that case
Jon,
The question I have
is if a server calls the proxy server and doesn't find a patch, it
then tries to go to sunsolve and fails (my thinking is because I
didn't put the wgetproxy in there because I want the local boxes to
use the proxy). Shouldn't the pca proxy box if it doesn't see the
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
Ronald Valente wrote:
I moved the files to /var/apache2/cgi-bin and everything worked. So
apache wasnt able to contact the /var/tmp/pca folder, even though it was
owned by webservd.
Something else must have been involved. As you say, it's only the
ownership/permissions of the xrefdir which
Don O'Malley wrote:
Yeah, I do realize that it may seem like a huge difference to you as
you are very close to patching related issues, but unfortunately many
customers if given the choice, would prefer to always install the
latest revision of a particular patch. I guess the logic is that
Hi Don,
I'll look into it and come back to you.
Thanks. I tried it multiple times in the past two hour, and sometimes it
works, sometimes it doesn't (on the same machine). Right now it works
from two machines, but not from a third machine.
Another user reported the same issue to me
Hi Don,
Among the many of the changes made on the backend, we do now have a more
user-friendly Patch Cluster Patch Bundle download page at
http://sunsolve.sun.com/show.do?target=patches/patch-access.
Looks much better than before, thanks for the notification!
One thing I wonder about is
Hi Don,
I've found an issue on one of the load balanced backend servers now,
whereby you can't download patchdiag.xref but patch downloads are
working fine.
Ah, right. I forgot to mention that only the xref file is affected,
patch downloads worked fine for me.
I'll follow up with the
Jon Whitehouse wrote:
Just out of curiosity, what is the latest xref from sun? I'm showing Apr 7th...
Mine is current:
Using /var/tmp/patchdiag.xref from Apr/16/09
I haven't noticed any problems with the daily updates (Mon-Fri) in the
last few weeks.
Martin.
Hi,
Is there anything that pca can do to help?
I can only give the usual, very general advice on such issues:
If a patch fails to install outside of pca with patchadd, too, you
should report that issue to Sun. As pca uses patchadd for patch
installation, this is true in most if not all
A new release of PCA has just been published. Here's a list of
new features and changes:
* Use HTTPS as default when connecting to SunSolve if wget supports it
* Use arch from pkginfo instead of uname to check if a patch applies
* Allow both directory or file to be specified with the wget
Hi,
should the --stop option apply to a simulation also? I just stumbled
upon --stop, but it neither stops a simulation nor does it stop a
listing.
stop and some other options like ignore, minage, etc. only work
when a patch group like missing or installed is used. When
specifying explicit
Gerry Haskins has published a Solaris patch presentation on his blog:
http://blogs.sun.com/patch/entry/patch_presentation_for_customers
It's a good summary about the current situation about patching Solaris,
worth reading.
Very useable as well if somebody has to justify the usage of a
301 - 400 of 503 matches
Mail list logo
