[pca] --minimal -l missingr not working as expected

[Brookins, Neil (Philadelphia)]

I think I can explain what is happening. The Age column is simply when the patch was originally released. Not when it first became recommended.
In some cases, the patch could be released for a long time without the recommended flag set; then at a later time the recommended flag could be set.
When this happens the "-l" list report will show a high "Age" value for the patch that is now recommended, but was not previously installed due to it not being recommended at the previous patch cycle.

Here is an actual example from my own server which was patched less than 4 months ago:
Patch  IR   CR RSB Age Synopsis
145953 06 < 07 R-- 455 Obsoleted by: 149173-03 SunOS 5.10: emlxs driver Patch

It now recommends a patch with an Age of 455.
I can assure you that this patch did exist 4 months ago -- but it was not Recommended at that time; which is why it was not installed back then.

You need to tell your auditors that its normal when this happens and it doesn't prove that any patches were missed at the last cycle.
You need to run the PCA report using the patchdiag from when the patches were last installed -- then you will see that none were missed.
When I run PCA on my server with the patchdiag from 4 months ago, it doesn't say I'm missing 145953. In fact, it correctly says that no patches are missing:

Using /<censored>/patchdiag.xref from Mar/03/13
Host: <censored>
List: missingr-minimal (0/0)

If I show my auditors the above empty report, they are happy that no patches are missing.

Neil G. Brookins
Identity and Authentication Solutions - IT Global Solutions
Towers Watson
1500 Market Street | Philadelphia, PA 19102
Phone: +1 215 246 6046
neil.brookins at towerswatson.com<mailto:neil.brookins at towerswatson.com>

From: pca-bounces at lists.univie.ac.at [mailto:pca-bounces at lists.univie.ac.at] On Behalf Of Terry Bohaning
Sent: Thursday, August 08, 2013 12:02 PM
To: pca at lists.univie.ac.at
Subject: [pca] --minimal -l missingr not working as expected


Greetings!

I wondered if anyone has seen this behavior before? I've been thru the archives and have not found anything that helps so far.

I'm running a remote data collection of all of the Solaris clients in my environment and storing them off on a directory in my machine running Red Hat.

What I'm seeing is this.

pca -f ./ahost_ --minimal -l missingr

and it consistently returns patches that are not in the recommended set. A sample is below:

List: missingr-minimal (105/32541)

Patch IR CR RSB Age Synopsis

------ -- - -- --- --- -------------------------------------------------------

118666 34 < 53 RS- 52 JavaSE 5.0: update 51 patch (equivalent to JDK 5.0u51)

118667 34 < 53 RS- 52 JavaSE 5.0: update 51 patch (equivalent to JDK 5.0u51), 64bit

119059 60 < 61 RS- 435 Obsoleted by: 119059-62 X11 6.6.2: Xsun patch

119213 26 < 27 RS- 547 NSS_NSPR_JSS 3.13.1: NSPR 4.8.9 / NSS 3.13.1 / JSS 4.3.2

119757 21 < 27 RS- 111 SunOS 5.10: Samba patch

119764 06 < 07 RS- 373 Obsoleted by: 119764-08 SunOS 5.10 : ipmitool patch

119783 21 < 25 RS- 293 Obsoleted by: 119783-26 SunOS 5.10: BIND patch

119810 06 < 07 RS- 387 SunOS 5.10: International Components for Unicode Patch

120460 19 < 20 RS- 609 Obsoleted by: 120460-21 GNOME 2.6.0: Gnome libs Patch

119812 13 < 16 RS- 435 Obsoleted by: 119812-17 X11 6.6.2: FreeType patch

119900 13 < 16 RS- 271 GNOME 2.6.0: GNOME libtiff - library for reading and writing TIFF

120543 25 < 31 RS- 70 SunOS 5.10: Apache 2 Patch

What concerns me are the lines similar to patch 119213 where the age exceeds the last set of patches that were installed. This is giving my auditors issues as they keep asking why we are not fully patching the systems.

Other than suppressing all patches with dates older than the last patch date, is there any way to not display these patches? Or with PCA is this just an expected result?

Thanks!

Terry

Notice of Confidentiality
This transmission contains information that may be confidential. It has been prepared for the sole and exclusive use of the intended recipient and on the basis agreed with that person. If you are not the intended recipient of the message (or authorized to receive it for the intended recipient), you should notify us immediately; you should delete it from your system and may not disclose its contents to anyone else.


This e-mail has come to you from Towers Watson Delaware Inc. or Towers Watson Pennsylvania Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20130808/986ca04b/attachment-0001.html>