Currently using Satellite 5.4, to provide a "gatekeeper" function similar to WSUS in the Windows environment. The two key functions being to be sure we apply the patches to test/dev system before production, and that the patches applied to prod are exactly the same (regardless of what Red Hat may have released in the days between test & prod patching runs).

Errata notices: the big "point upgrades" (e.g. 5.9 to 5.10 or 6.4 to 6.5) are overwhelming, and generally not studied in much detail unless something goes wrong on the test/dev systems. The normal stream of security/bug-fix patches is not a big deal.

I have some concerns about Satellite 6.0 not providing functionality equivalent to RHNSat 5.x (mostly the "Systems" view, with a concise list of systems & their outstanding-errata state/errata count/"channel" membership (i.e., major version & locally-cloned vs. Red Hat default channel membership)). I can find screens that list multiple systems, or show a single system in (sometimes excessive) detail, but not both at the same time.

So - I have a few things that come to mind (and I anticipate I would be updating this list over time)
My issues might be my own lack of understanding ;-)

• I would like if errata, as a general rule, was date-based. For example, if I want to sync a system to a point-in-time that ALL the packages that are XYZ-compliant will align with that date. It seems that now Red Hat packages respect a date-release whereas other vendors do not. (This example is specific to an issue I have with spacewalk-clone-by-date - all of the Red Hat provided packages are fine, but the 3rd-party vendor packages do not seem to follow the same standard and therefore either none get cloned, or ALL get cloned - regardless of date)

• It woudl be cool if Errata packages had a "reboot" flag - I do not know of an easy way to identify whether a package will require a reboot once applied, or restart a service.

I really wish Red Hat would revisit this bugzilla (feature request):
https://bugzilla.redhat.com/show_bug.cgi?id=677296

ie. Being able to instruct yum to only download packages up to a certain date.

I know the bug comments state that there are issues because the date the patch is added to the repo isn't captured so yum can't leverage it, but surely something can be worked out / incorporated? perhaps with a plugin that gathers this information from Satellite?

3 years on from this bug being closed and I still frequently see this causing issues in Red Hat environments, with the general workaround to 'clone by date' on the Satellite side, which is a tedious task when maintaining multiple environments.

If someone can suggest a cleaner alternative I would love to hear it, because I have seen this solved the same way everywhere I go.

Scenario: You want to patch your dev/test/prod environments to the same patch level so testing carried out in development validates patches to be applied to test, and then production.

Often, the change process imposes restrictions / delays on patch release through environments so the patches can be tested and regression checked. I accept it isn't the most ideal process, but it is common. I am not interested in suggestions on how to change this business process, but more interested in how the available Red Hat tools can be used to enhance the process.

1. Week 1 (1st of August). Patch development
2. Week 2 (8th of August). Patch test
3. Week 3 (15th of August). Patch production

Scenario 1: Patching to latest available version
Week 1 you patch all outstanding updates to development. Red Hat then release errata on August 5th, so patching to test to the latest available version results in a patch that has not been tested being applied to test and then production. Any patches released between the 2nd and the 14th will go into production without first going through development.

Scenario 2: Clone by date in Satellite
Week 1 you clone the available Red Hat updates to a channel called eg.. '1st of August'. Subscribe development servers to this channel and patch. On the 8th of August subscribe test to the '1st of August' channel and patch. On the 15th of August subscribe the production channel to the '1st of August' channel and patch.

I see this method work, but then you run into issues with cloning future errata to the '1st of August' channel and you end up making a lot of work for yourself to keep the different channel 'snapshots' maintained. One way to solve the errata maintenance issue is to move these servers back to the main OS channels after they have been patched with the cloned channel.

Scenario 3: Yum transaction log suggested in the Bugzilla above
Week 1 you patch the development environment to the latest available patches and store a yum transaction log of this process. On the 8th you run this transaction log in the test environment. On the 15th you run this transaction log in production. No cloning of channels is required in Satellite so no ongoing maintenance of cloned channels. The only concern I have with this approach is if there are any package discrepancies between environments, they may not be patched if the transaction log doesn't capture these packages in development. (eg. someone installed curl in test, but curl doesn't exist in development, so isn't capture in
the transaction log for patching)

There is mention of this patch being supplied to upstream but I haven't followed it up. Can anyone confirm if/when this made its way into the Red Hat shipped yum packages?

Scenario 4: If yum supported '--update-to-date'
Week 1, patch your environment with 'yum --update-to-date 20140801'
Week 2, patch your environment with 'yum --update-to-date 20140801'
Week 3, patch your environment with 'yum --update-to-date 20140801'

This way you ensure that only patches released up to and including the date of deployment into the development environment (1st of August) are deployed to test and production. Satellite channels don't need to be created so additional ongoing management burden of additional channels isn't created. The errata problem doesn't exist because the servers are still subscribed to the primary OS channel receiving the errata updates.

If you have another method to approach this style of staged patching I would be keen to hear about it! If you use one of the above methods, I would appreciate if you dropped a message so I can see what others are doing :)

I wish that Satellite could easily display the point release that each server is at. (5.11, 6.5, etc). You can get this indirectly by using space-cmd and then matching the kernel levels to releases. I really wish the Satellite GUI would just display the release level as it would help us quickly determine which boxes are most out of date. (200+ patches for a 5.8 vs 5.9 box kind of appear similar in the current GUI!)

We patch the critical stuff as needed but past that our patching policy is based on point releases and the age of the release, with minimum supported levels. Seeing a number like 200+, 53, or whatever number of outstanding patches per system isn't helpful to us. In a large shop, most systems are going to be out of date and the number just ends up being arbitrary number rather than helpful indicator.

Native CentOS Errata support would be nice too. We have a RHEL site subscription but we have a number of CentOS systems left to migrate. Satellite is a paid product, so I think its fair to ask for the feature. ;) I've done the various hacks to import the CentOS errata, but native support really should be there as I'm sure there are other sites in similar situations.

I recently came up with a new approach to solve the problem of "which patches are outstanding for X hosts" which is problematic if you are using cloning methods because they are only cloned to a specific date (I have full details in a post above).

This solution meets the following requirements (which I have found quite common across sites):
1. Standard base installation 'snapshotted' at a specific date
2. Only security related errata is applied to these servers after the chosen snapshot date

Channel configuration is as follows:

-+-Base channel RHEL 6.x SNAPSHOT 201401010
 +---Child channel RHEL 6.x Security updates (updated nightly)

ie. The server is subscribed to two channels on build, the base channel that is a snapshot of the primary OS channel at a specific date and the security updates child channel which has all security updates.

Unfortunately, constructing this configuration with automated processing is a little painful because clone-by-data (which can filter for security only) doesn't appear to be able to target just a child channel, ie. I can't say "clone the security errata from the primary OS channel to the following child channel", and softwarechannel_adderrata is all errata, it can't be filtered for security only.

So the automated process is as follows:
1. Download nightly into primary OS channel
2. Use clone-by-date to clone only security errata into OS-Security (this is where the filtering of errata occurs)
3. Use spacecmd softwarechannel_adderrata to copy security only errata from the OS-Security channel into the child security channel of each snapshot

The most basic channel configuration to use this workflow looks like the following:

-+-Base channel RHEL 6.x OS (updated nightly from RHN)
-+-Base channel RHEL 6.x Security only (updated nightly from OS base channel)
-+-Base channel RHEL 6.x SNAPSHOT 201401010 (updated/created manually)
 +---Child channel RHEL 6.x Security updates (updated nightly from Security base channel)

I would really appreciate if either softwarechanne_adderrata or clone-by-date were updated to allow the cloning of security only errata directly into child channels from base channels for the above workflow... unless someone can suggest an alternative method to get this errata into the right locations?

So. In Satellite 6 it's not even possible to create your own errata. I've created a RFE for this.. Hopefully this mistake will be corrected ASAP. Using package filters for content views does not scale.

how do you determine that errata needs a reboot or not?