1 2 Previous Next 19 Replies Latest reply on Jul 28, 2016 2:58 PM by Bill Robinson

    Can I create a red hat patch smart group by OS release (ex: 6.1, 6.2, 6.3...)

    Chad Johnson

      We want to minimize our patching work.  We currently use 3 different catalogs, RH by OS Level (containing 5.7 and 6.11), Errata and rhn-tools. This environment is BSA 8.6.  The problem here is that the OS team requires a specific OS release for their base (essentially point in time patching).

       

      We are evaluating BSA 8.8 (primarily due to bug fixes and the support of red hat child channels).  In this, it is our desire to have 1 catalog for the OS level, errata and rhn-tools.  This is to reduce the number of Patch Analysis / Deployment jobs we must execute in a patching cycle (we have very, very short maintenance windows).

       

      I would *like* to create a smart group for all OS patches for a given OS minor release.  Effectively creating a smart group that mimics a OS Level patch catalog.

       

      Is this possible?

        • 1. Re: Can I create a red hat patch smart group by OS release (ex: 6.1, 6.2, 6.3...)
          Bill Robinson

          i don't believe redhat provides this information in their metadata.  if you have the list of rpms (eg, from the iso) you could tag the rpm objects in the catalog w/ a property and then smart group on that.

          • 2. Re: Can I create a red hat patch smart group by OS release (ex: 6.1, 6.2, 6.3...)
            Chad Johnson

            Thanks for the input Bill.  I couldn't find anything in the metadata either.  What confuses me though is the fact that I can make a catalog with a minor version (6.7 per se).  If I create a catalog by release this does just what I want.  The problem being, it does not contain all errata then.

             

            If I can create the OS level catalog, it seems like I should be able to create a smart group to get the same thing.  Or, is it that bladelogic is pulling a specified OS level from Red Hat and really does no sorting or processing on it?

            • 3. Re: Can I create a red hat patch smart group by OS release (ex: 6.1, 6.2, 6.3...)
              Bill Robinson

              When you use the update level catalog we pull down the iso.

              • 4. Re: Can I create a red hat patch smart group by OS release (ex: 6.1, 6.2, 6.3...)
                Chad Johnson

                I was afraid it was something like that

                 

                Thanks for confirming.  It looks like I may need to pull down an OS level catalog to just get all the RPM names (with versions) and use it to create a smart group somehow.  Either by name, include / exclude list, properties, etc.

                • 5. Re: Can I create a red hat patch smart group by OS release (ex: 6.1, 6.2, 6.3...)
                  Bill Robinson

                  Afaik redhat doesn’t provide any information other than that about what rpms are in an update level.  the update levels seem to be “what rpms did we release last quarter = next update level”.

                  • 6. Re: Can I create a red hat patch smart group by OS release (ex: 6.1, 6.2, 6.3...)
                    Chad Johnson

                    This seems to be quite the oversight in how the Linux community actually patches.  Very few places I have been apply everything.  This leaves us with a very limited number of options. 

                    1. Create individual catalogs for each group (OS release i.e. 6.7, child channel, etc)
                      1. This is what we had in 8.6 but having multiple catalogs means multiple patching jobs.  With very small patching windows, this is not practical.
                    2. Download 'everything' we may want, edit it by hand, and make an offline catalog of it.
                      1. This may work but it creates a lot of work when minor updates or changes are required.
                    3. Change the corporate patching policy to align with the limitations of BSA
                      1. This is highly unlikely.  Most policies were put in place for very good reasons, the limitations of a tool will not change this

                     

                    None of these are great solutions.  It seems to me that BMC should be able to set some intrinsic properties when the catalog is downloaded.  Simply setting a property with the channel/filter it came from would add a large amount of flexibility to the tool.

                    • 7. Re: Can I create a red hat patch smart group by OS release (ex: 6.1, 6.2, 6.3...)
                      Bill Robinson

                      since redhat doesn't seem to provide any mapping between a rpm and what update level it's associated w/ on the rpm itself, i don't see how we can provide the same.

                       

                      Create individual catalogs for each group (OS release i.e. 6.7, child channel, etc)

                      1. This is what we had in 8.6 but having multiple catalogs means multiple patching jobs.  With very small patching windows, this is not practical.

                      -> why is having multiple patching jobs impractical and what does having a small patching window have to do w/ having multiple jobs ?

                       

                      Download 'everything' we may want, edit it by hand, and make an offline catalog of it.

                      1. This may work but it creates a lot of work when minor updates or changes are required.

                      -> edit what by hand ?  why not use the 'update level' catalog type ?

                       

                      Change the corporate patching policy to align with the limitations of BSA

                      1. This is highly unlikely.  Most policies were put in place for very good reasons, the limitations of a tool will not change this

                      -> the bsa limitations being what ?  not being able to do something redhat isn't providing ?

                       

                      "In this, it is our desire to have 1 catalog for the OS level, errata and rhn-tools."

                      -> if you are patching to the update level, why do you need errata in the catalog?  the rpms are the errata.  what are 'rhn-tools' ? if you are including errata in the patching job then you are not keeping to the update level.

                       

                      what is the patching policy you are trying to replicate in bsa ?

                      • 8. Re: Can I create a red hat patch smart group by OS release (ex: 6.1, 6.2, 6.3...)
                        Chad Johnson

                        Bill,

                         

                        If you have a filter, you have the knowledge of where it ‘resides’.  It doesn’t seem like too much of a stretch to use the filter provided in BSA to ‘stamp’ the content retrieved via said filter.

                        • 9. Re: Can I create a red hat patch smart group by OS release (ex: 6.1, 6.2, 6.3...)
                          Bill Robinson

                          as i mentioned – for the update level filter we are pulling down the iso.  So that’s just blindly adding whatever rpms are part of the update level iso.  The rpms that are part of the main server channel – eg rhel-server-6 – are downloaded differently.

                          • 10. Re: Can I create a red hat patch smart group by OS release (ex: 6.1, 6.2, 6.3...)
                            Yanick Girouard

                            Chad, there is no information tying a specific rpm release to a specific minor version of Red Hat. The errata doesn't have it (will just state it's for which major version and which platforms are affected), and the rpm's metadata itself doesn't have it either. In fact, you could very well install a package that hasn't been updated in over 2 releases, which means it would apply for both RHEL 6.0, 6.1, and 6.2. It's not like every single rpm package out there gets a revision every time Red Hat decides to "declare" a new minor release.

                             

                            What you could do in your case, is create "frozen" catalogs. Basically, you update the catalog on a given day, and you don't update it anymore until you're ready to move forward with patching to a later "timestamp". That would let you patch all severs in your environment to the same level and make that your new baseline. When you're ready, you just update to the latest and keep on going.

                             

                            There is simply no way, even with yum (which is the native way) to say "update my server up to the packages released on a certain day". There "is" however a way to lock a system within its minor release, but that requires yum or a Red Hat Satellite server (How to tie a system to a specific update of Red Hat Enterprise Linux? - Red Hat Customer Portal ) and is not possible with BSA, although it would indeed be very neat if it was.

                             

                            I have however rarely seen this feature being used so I'm not sure how many would use it. Normally on Red hat, when you update, you update to the latest minor release, which comes with the updated kernel and all other fixes. When Red Hat releases updates to a package, they always increment the same release, and don't fork different versions for different minor releases of Red Hat (within the same major I mean...).

                            • 11. Re: Can I create a red hat patch smart group by OS release (ex: 6.1, 6.2, 6.3...)
                              Bill Robinson

                              There is a way to ‘lock’ – use an update level catalog and only patch from that version.  though nothing prevents you from pushing rpms from some other catalog…

                               

                              now, if you are talking about the EUS updates – where updates are provided on top of a particular version – eg 6.1 – that do not bump the kernel or whatever makes it ‘6.1’ – you can also subscribe to those channels through bsa if you have the entitlements for them.

                              • 12. Re: Can I create a red hat patch smart group by OS release (ex: 6.1, 6.2, 6.3...)
                                Chad Johnson

                                I think my point is being lost here.  This is not limited to OS release version (However that would be great).  I fully realize this information is not present in the RPM itself.

                                 

                                When I pick an OS level as my filter you pull down the iso and place all the content into the repository.  This means you know the filter used as well as the content.  How hard would it be to stamp a property on each rpm with the filter used to obtain it?

                                 

                                The same goes for errata, child channels, etc.

                                 

                                Also, the ability to have more than one filter for an OS/architecture would be wonderful, again, stamped with the filter information for smart group use.

                                • 13. Re: Can I create a red hat patch smart group by OS release (ex: 6.1, 6.2, 6.3...)
                                  Bill Robinson

                                  When I pick an OS level as my filter you pull down the iso and place all the content into the repository.  This means you know the filter used as well as the content.  How hard would it be to stamp a property on each rpm with the filter used to obtain it?

                                  -> afaik you can't have more that one update level per catalog can you ?  or have the update level mixed w/ other filters...  and the update level filter doesn't include errata does it ?

                                   

                                   

                                  Also, the ability to have more than one filter for an OS/architecture would be wonderful, again, stamped with the filter information for smart group use.

                                  -> such as what ?  the filter is the os and arch and those properties are already there.

                                   

                                  can you explain exactly what patching policy you are trying to replicate ?  what patches do you need to put on the servers ?

                                  • 14. Re: Can I create a red hat patch smart group by OS release (ex: 6.1, 6.2, 6.3...)
                                    Yanick Girouard

                                    I thought update level was only downloading the ISO and creating the catalog from that. Are you telling me it's also fetching updates for it within that same release ? (i.e. start with flat 6.1 rpms, and get all updates between 6,1 and 6,2 ?)

                                     

                                    I also think it's not a different channel per say in RHEL 7 and above...

                                     

                                    # subscription-manager release --set=6.4
                                    # yum clean all

                                    # subscription-manager repos
                                    Repo ID: rhel-6-server-rpms
                                    Repo Name: Red Hat Enterprise Linux 6 Server (RPMs)
                                    Repo URL: https://cdn.redhat.com/content/dist/rhel/server/6/6.4/$basearch/os
                                    Enabled: 1

                                     

                                    See the repo URL above. They basically only hardcode the exact release instead of using latest. As opposed to this:

                                     

                                    # subscription-manager release --unset
                                    # yum clean all
                                    # subscription-manager repos

                                    Repo ID: rhel-6-server-rpms
                                    Repo Name: Red Hat Enterprise Linux 6 Server (RPMs)
                                    Repo URL: https://cdn.redhat.com/content/dist/rhel/server/6/$releasever/$basearch/os
                                    Enabled: 1

                                     

                                    The name of the channel (Repo ID) stayed the same... Ideally, if BSA could do the same, it would be awesome.

                                    1 2 Previous Next