5 Replies Latest reply on Jan 31, 2014 9:59 AM by Yanick Girouard

    Linux Patch Catalog not deleting RPMs associated with obsolete/deleted Erratas types

    Yanick Girouard

      We have just discovered an issue that is still being investigated by Premier Support, but I would like to share it with the community in case others have also noticed it (or not noticed it).

       

      We're running BBSA 8.3.02 on Red Hat, and recently started testing Red Hat Linux Patching. Originally, we had created a catalog containing RHEL 5 and 6, and used the "By Errata Type" filtering method, with all errata types selected. Several Catalog Update Jobs have been run with those filters and everything was looking good.

       

      After some validation with the Unix teams in our organization, it was decided to only patch Security Advisory Erratas, so the Product Enhancement and Bug Fix ones were unchecked from the product filters, and a new CUJ was run. All RHEA and RHBA erratas were successfully marked as obsolete, and disappeared from the catalog. We thought everything was fine until we realized that all the RPMs that were related to those Erratas had not been deleted in the process and remained in the catalog as orphans.

       

      Because of the way the Red Hat Patching Job works (basically builds an offline yum repository containing all the RPMs of the catalog), it will still scan for those RPMs and find them as missing even though the Erratas they previously belonged to are no longer in the catalog and that the product filters in the catalog exclude those types of Erratas. Since it's not possible to manually delete RPMs from a Patch Catalog, we are kind of in a pickle and the only thing we can do to fix this is to create a whole new catalog making sure only the Security Advisory types of Erratas are selected.

       

      So far I have been able to reproduce this in two different environment, one at version 8.3.02.332 (SP2 GA), and one at 8.3.02.407 (SP2 Patch 1).

       

      Has anyone else seen this in their environment?

       

      For reference, the ticket I have opened for this issue is ISS04245812. It has been escalated to BMC's engineering team and we're waiting for a fix in the meantime.

        • 1. Re: Linux Patch Catalog not deleting RPMs associated with obsolete/deleted Erratas types
          Bill Robinson

          some of the rpms may be there because of dependencies or because they are in use in deploy jobs or as filters in patching jobs.

           

          what happens if you only choose the noted errata filters - do you get a subset of the rpms ?

           

          what if you don't use the catalog before you switch filters ?

          • 2. Re: Linux Patch Catalog not deleting RPMs associated with obsolete/deleted Erratas types
            Yanick Girouard

            Bill Robinson wrote:

             

            some of the rpms may be there because of dependencies or because they are in use in deploy jobs or as filters in patching jobs.

             

            I thought you might say that Bill, but they are not, I have checked. None of those RPMs have any dependencies. However, even if they had, there's still the issue where they still appear in the PAJ results although their related Erratas are not included in the catalog filters and are not even in the catalog anymore.

             

            what happens if you only choose the noted errata filters - do you get a subset of the rpms ?

             

            Not sure I understand that question, could you clarify?

             

            what if you don't use the catalog before you switch filters ?

             

            You mean if I create a new catalog and play around with the filters several times before I run a CUJ? I haven't tried, but I assume it will only download the Erratas I have selected. The issue I have here is that the RPMs related to the RHEA and RHBA Errata types had already been downloaded before.

            • 3. Re: Linux Patch Catalog not deleting RPMs associated with obsolete/deleted Erratas types
              Bill Robinson

              so i created two catalogs.  one w/ the security filter you mentioned and one w/ all errata filters.

               

              both cuj added the same number of rpms.  the one w/ the single errata filter added 782 errata, where as the other added 2850.

               

              so i think if you want to limit the analysis to the errata you should use the errata smart group filter ?

              • 4. Re: Linux Patch Catalog not deleting RPMs associated with obsolete/deleted Erratas types
                Yanick Girouard

                That is odd, you would think it would only download the RPMs that are related to the erratas. Why is it downloading every RPM despite the Errata filters? Is it because of possible RPM dependencies? Maybe I don't understand how the Red Hat patching works in BBSA then. I'm used to the way a Windows Patch Catalog works, and thought the Red Hat one used the same principle...

                 

                As for scanning using an Errata smart group as an include list, I've tried that, but for some reason, when I do, the CPU of the Linux server I'm scanning goes to 99% and I have to abort the PAJ to stop it or it just takes forever (waited over 5 minutes), while a PAJ with no filters at all on the same server takes literally less than 30 seconds to run. It just gets stuck at the "Copying analysis script to target: TARGET_NAME" step, and on the server I see the BMC python executable clocking at 99%. I took a deeper look at what's happening when I use an include list and when I don't, and sorry to say, but it's pretty ugly...

                 

                When you don't use a list, all patches are checked for updates using the repodata.tar.gz of the catalog, which contains every ARCH types. This is fine. Basically, almost the same as a standard "yum update" command would.

                 

                However when using an include filter to only scan for Security Advisory erratas, it goes through a very long chain of process calls that build an include list containing every single RPM that that the PAJ include list specified (all ARCH types too) and then feeds it to the custom blyum command. It's all this processing that seems to be eating away at the CPU and takes so much time to run (it took a little over 10 minutes to complete on a RHEL 5 server when I let it finish). Is this really the way it was designed or is this not normal?

                 

                That said, the result of the PAJ was not very satisfying, since it listed missing RPMs under each Errata, but duplicated the RPMs if more than one Errata was applying to the same rpm. Here are two screenshots. Note the same RPMs showing as missing for two different erratas that both updated the kernel:

                 

                01-28-14 12-32-28 AM.png

                01-28-14 12-32-48 AM.png

                 

                This is not the output our Patch team is expecting, but rather a simple (distinct) list of missing RPM, matching the types of erratas selected in the catalog. We only want to update RPMs that are related to Security Advisory Erratas, How can we do this if this doesn't really work well for us? Is there another way?

                • 5. Re: Linux Patch Catalog not deleting RPMs associated with obsolete/deleted Erratas types
                  Yanick Girouard

                  I was advised by Premier Support that the issue regarding the display of obsolete Erratas in the PAJ results is a defect that was reported in 8.2, and was fixed in 8.5. We have asked for it to be back-ported into 8.3 as well.

                   

                  See QM001766408 for reference:

                   

                  ISSUE: Patch analysis report obsolete errata's missing with newer RPMS

                  Appserver and Agent: 8.2 SP1

                  Catalog - Red hat 5,6 with 32 and 64 bit.

                   

                  Customer is running analysis in update mode against errata and rpms. Analysis reports obsolete errata missing however if we open the errata it is showing rpms belongs to the latest errata.

                   

                  Example:

                  Screenshot:

                  RHBA-2007:0129    RHES5x86,RHES5x86_64    net-snmp bug fix update

                  RHBA-2011:0287    RHES5x86,RHES5x86_64    lvm2 bug fix update

                   

                  If we compare both the screenshot attached, it has same rpms for both erratas. I have verified from RHN that these rpms are obsolete and the rpms version is also different compared to what we have shown in analysis.

                   

                  There are result exported attached to the ticket.

                   

                  Package and deploy are not affected with this issue however reporting has issues since it list all errata.

                   

                  1. Create a RHN catalog

                  2. Run analysis with update mode including rpms and errata

                  3. Analyze the analysis result.

                   

                  Attached analysis logs as well.

                   

                  Please let me know if there is more information required.