Satellite 6 Content View Based on GA Releases such as 6.4, 6.6, 6.7 etc

Latest response

Hi all,

I want to create content views based on the GA Releases of specific versions of RHEL. These should correspond to the DVD image. The idea is that we can keep certain servers on older releases, but at least report on security issues (and hopefully apply the errata later!)

https://access.redhat.com/articles/3078 lists the errata number and release date associated with each release such as RHEL 6.7, 6.6, 6.5, etc.

However, there is a short lag between the DVD image being created and the errata release date. This seems to prevent me from creating a CV that maps directly to the DVD content using errata dates.

Example. The RHEL6.4 Server DVD appears to have been produced on 2013-01-30. The product was then made available on 2013-02-21. During this time some packages were updated (to be expected).

I built a server using the RHEL 6.4 DVD. I then created a content view using errata up to and including 2013-02-21 (the RHEL 6.4 GA date). I subscribed the server to the content view and attempted to do an update. Ideally nothing should be updated if the CV matches the DVD release.

[root@rhel64 ~]# yum list-sec
Loaded plugins: package_upload, product-id, security, subscription-manager
rhel-6-server-rpms | 2.1 kB 00:00
RHBA-2011:1395 bugfix dmidecode-1:2.11-2.el6_1.x86_64
RHSA-2013:0250 Moderate/Sec. elinks-0.12-0.21.pre5.el6_3.x86_64
RHSA-2013:0216 Important/Sec. freetype-2.3.11-14.el6_3.1.x86_64
RHSA-2013:0245 Critical/Sec. java-1.6.0-openjdk-1:1.6.0.0-1.54.1.11.6.el6_3.x86_64
RHSA-2013:0273 Critical/Sec. java-1.6.0-openjdk-1:1.6.0.0-1.56.1.11.8.el6_3.x86_64
RHSA-2013:0247 Important/Sec. java-1.7.0-openjdk-1:1.7.0.9-2.3.5.3.el5_9.x86_64
RHSA-2013:0247 Important/Sec. java-1.7.0-openjdk-1:1.7.0.9-2.3.5.3.el6_3.x86_64
RHSA-2013:0275 Important/Sec. java-1.7.0-openjdk-1:1.7.0.9-2.3.7.1.el5_9.x86_64
RHSA-2013:0275 Important/Sec. java-1.7.0-openjdk-1:1.7.0.9-2.3.7.1.el6_3.x86_64
RHSA-2013:0271 Critical/Sec. libproxy-0.3.0-4.el6_3.x86_64
RHSA-2013:0271 Critical/Sec. libproxy-bin-0.3.0-4.el6_3.x86_64
RHSA-2013:0271 Critical/Sec. libproxy-python-0.3.0-4.el6_3.x86_64
RHSA-2013:0219 Moderate/Sec. mysql-libs-5.1.67-1.el6_3.x86_64
RHBA-2013:0537 bugfix selinux-policy-3.7.19-195.el6_4.1.noarch
RHBA-2013:0537 bugfix selinux-policy-targeted-3.7.19-195.el6_4.1.noarch
updateinfo list done

Some of the packages seem to be the same, but just a 'minor' update. Eg:

DVD image: selinux-policy-3.7.19-195.el6.noarc
Content view: selinux-policy-3.7.19-195.el6_4.1.noarch

How can I create a Content View that matches the content of the GA DVD ISO image?

Richard.

Responses

Richard,

Before presenting a possible solution to your requirements, I need to clarify one point. Why do you want to "..create a Content View that matches the content of the GA DVD ISO image"? I ask because you said that you want to at least be aware of, and later apply, errata issued by Red Hat. The ISO images are a snapshot of packages at a point in time, so there seems to be a conflict between your requirement to be aware of errata, but have a content view match the contents of the ISO.

If I understand correctly, you want to achieve a common requirement: maintain Red Hat Enterprise Linux (RHEL) servers at a fixed major and minor version (e.g. RHEL 6.4, or RHEL 6.7) while still being able to track errata applicable to that combination major and minor release. This allows you to be sure that the only updates are security updates, and the RHEL version doesn't change, possibly breaking compatibility with the software installed on it.

The key here is choosing the right RHEL repository. RHEL repositories are tied to either a specific major version, or a major and minor version combination, where a specific version might be "6.x", and a major and minor version might be "6.4". Using a "RHEL 6.4" repository means that the major and minor version remain fixed at 6.4, with the only updates being errata. Using a "RHEL 6.x" repository means that only the major version remains fixed, with the minor version being updated as the releases are made available. So a RHEL server subscribed to a "RHEL 6.x" repository will be upgraded to 6.1, 6.2, 6.3 and 6.4 as those releases are made.

So... if you want to have RHEL hosts fixed to a major and minor version, but be aware of errata as they're released, create a content view and select the repository with a fixed major and minor version. For example, a fixed major and minor repository for RHEL is "Red Hat Enterprise Linux 7 Server RPMs x86_64 7.X", while the repository with only the major version fixed is "Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server".

Please reply if you have any feedback on what I've written, or any further questions.

Russell,

The problem with this approach is that you will be syncing channel content multiple times, especially if you environment has multiple hosts with different minor release requirements. This is why the approach to sync latest available packages (single channel) and then generate channel/content views to restrict availability to content hosts is used.

I was also under the imperssion that an EUS subscription is required to access the minor version channels after a new minor version is released, is this still the case?

Great question Richard, there definitely looks to be a discrepancy there.

If you haven't already seen it, check out this page for the dates for errata in RHEL to match minor releases: https://access.redhat.com/articles/3078

Unfortunately, this page also lists 2013-02-21 for RHEL 6.4 (which you have used) so the minor discrepancies you are seeing are still unexplained.

Does your 6.4 ISO image md5sum match the ISO that is currently listed/available in the portal?

I was also under the imperssion that an EUS subscription
is required to access the minor version channels after
 a new minor version is released, is this still the case?

An EUS subscription provides access to high priority security & bugfix errata for that older minor release after it is no longer current. In Satellite 6, there are also repositories that contain 'everything from GA to "the day 6.4 ends"', and I believe that is what Russell was speaking to above. While those do exist, I don't believe they solve the problem that is listed in the OP. See Understanding Red Hat Content Delivery Network Repositories and their usage with Satellite 6 for a more detailed explanation of the type of repos available in the CDN and their expected use with Satellite 6.

Hi all,

Many thanks for the comments.

What I was initially doing was taking the RHEL 6Server repository and creating a timestamped Content View based on the Release date of the minor version. Eg, Red Hat KB 3078 suggested that the release date of RHEL 6.4 was 2013-02-21.

Looking at the timestamp of the RHEL 6.4 DVD ISO image, it's my assumption that Red Hat took a snapshot of the pre-RHEL 6.4 packages around 31-January-2013. They then go through the QA process before being released later on. If I create a content view of 6Server from 31-January-2013 I won't get the enhancements that were released to 6Server after that date. In this case, the CV won't pick up packages are on the 6.4 DVD. If we try and move the 6Server filter date forward (to 2013-02-21) we pick up these RHEL 6.4 updates but we also pick up other errata which were not included on the DVD image.

What I have now done is the following:

From Content -> Red Hat Repositories -> Kickstarts, selected and synchronised "Red Hat Enterprise Linux 6 Server Kickstart x86_64 6.4"

This creates a publicly accessible repo at:

http://SATELLITE/pulp/repos/ORGANISATION/Library/content/dist/rhel/server/6/6.4/x86_64/kickstart/

At this point, I can manually create an /etc/yum.repos.d/rhel64.repo file on my clients and point them at this URL. I could also import them into Satellite and associate them with an 'empty' content view. This would achieve the goal of having the servers in Satellite, but at least being able to identify what errata is outstanding. I could then add to the CV if I wanted particular security patches applying by adding the 6.4 or 6Server repo and adding a filter with the specific errata in question. I realise that depending on the errata selection, this may insist on an update from RHEL6.4 to a later version, but in all likelyhood we'll stick with the DVD image until our next server refresh cycle.

One thing that didn't work for me which I was hoping it would:

I created a Content View which uses the "Red Hat Enterprise Linux 6 Server Kickstart x86_64 6.4" repository with no filters and published it. It had the expected 3648 packages. I attached my RHEL 6.4 client to it, and adjusted the "product content" tab in Satellite to say "Red Hat Enterprise Linux 6 Server (Kickstart)" enabled.

However, I still don't see the Kickstart repo from Satellite being displayed:

[root@rhel64 ~]# yum repolist all Loaded plugins: package_upload, product-id, security, subscription-manager repo id repo name status rhel-source Red Hat Enterprise Linux 6Server - x86_64 - Source disabled rhel-source-beta Red Hat Enterprise Linux 6Server Beta - x86_64 - Source disabled repolist: 0

Is that to be expected? (I think I may have read somewhere that using kickstarts in content views was not supported/advised?)

Thanks again for the feedback!

Richard.

Also, Russell brings up a very valid point above, which I'll quote below:

Why do you want to "..create a Content View that matches
 the content of the GA DVD ISO image"? I ask because you 
said that you want to at least be aware of, and later apply, 
errata issued by Red Hat. The ISO images are a snapshot 
of packages at a point in time, so there seems to be a 
conflict between your requirement to be aware of errata, 
but have a content view match the contents of the ISO.

Installation media for Red Hat Enterprise Linux are effectively snapshots of packages, and the tool you are using (the content view filter for 'Errata by Date & Time') works on errata. They are in fact different.

This is why you are seeing additional packages when using a date of '2013-02-21'. Your content view includes all of the zero-day errata that comes with RHEL 6.4 (and all the errata released after the DVD ISO is created, but before 6.4's 'official' release). For many reasons (QE testing, delivery to hardware partners, etc), the RHEL ISOs are created long before GA of the next minor release. (And you've noted as much above.) Between the creation date of the ISO and the official release date of the next minor release, bugs are found, errata are issued are released.

Which brings us back to the original problem request of 'what is the use case?'

I can see a use case for 'I want all errata released with 6.4 but NOT 6.5' (and we can easily solve those), but I cannot see the use-case of 'I want 6.4 at GA' AND 'I want the ability to address errata'. In fact, the two use-cases are mutually exclusive with a single repo.

There is just no metadata included within Red Hat's errata that describes how to build an install CD/DVD. For what it's worth, even in the in the Satellite 5 days, we couldn't do this with errata alone. We shipped spacewalk-create-channel, which worked on packages with extra metadata which described which packages were part of the release. Note: this was a separate & distinct tool than spacewalk-clone-by-date, which worked on errata.

My recommendation would be to use the 6Server repo with a content-view filter as you originally did. My reasons for that are:

  • Red Hat Enterprise Linux has pretty stringent requirements for z-stream (between the minor releases) errata. Any errata released between 6.4 & 6.5 are going to be errata that you want as they usually are high priority bugs and/or security fixes. Does this mean that your CV doesn't exactly match the install ISO? Yes, it does. But I would assert that it is close enough to not matter.
  • If you require a bit more granularity, you can make your content view filter more selective, such as including security updates only (and not the bugfixes and enhancements)
  • Creating the yum .repo file that points to the kickstart repo over HTTP and then creating a content view with the 6Server repos heavily filtered, while it works, it is IMHO working against the workflows of the product. Especially if you use any of the additional RHEL repositories (like Optional, Extras, etc). Additionally, if there is a post 6.4 errata that you need to install, and it has dependencies on newer packages, you'll get them. (And I don't expect you to keep a spreadsheet of which package is dependent on what)

If your use case is 'give me RHEL 6.4 content' and nothing newer, use the 6.4 repos, optionally extending it with Extended Update Support

If your use case if 'give me RHEL content, that is relatively $CURRENT (where you define $CURRENT), use 6Server with content view filters.

I am personally a fan of the latter.

Future reading, Understanding Red Hat Content Delivery Network Repositories and their usage with Satellite 6

Hi Rich,

Many thanks for the detail - it's really helpful.

I understand the conflict you and Russell are highlighting for "I want 6.4 at GA" AND "I want the ability to address errata". What about if I drop the requirement on addressing new errata and instead want the following: I want to register my servers with Satellite so that I can use the subscription functionality and ensure our environment is licensed correctly. I want my server to be able to pick up packages from a 6.4 GA (DVD) repo (in case I did not install them at build time). Would that alter your recommendation above?

Part of the reason for the GA release is that our software vendors typically install from a particular image and don't have the zero-day errata applied to them. Whilst I'm strongly in favour of applying the latest patches, I'm also obliged to ensure we don't drift from the GA release across our estate.

Richard.

Richard,

Can you please clarify what you mean by the phrase "ensure we don't drift from the GA release across our estate." If your aim is to prevent the installation of packages released after a specific RHEL version's GA date, I think this presents some risk. In excluding the application of errata, the systems in questions are vulnerable to the risks identified in the errata. It would be highly unusual for a software vendor to support an application on condition that errata are NOT applied.

Hi again,

I was looking at Rich Jerrido's post where he suggested using the 6Server repository and then use the errata dates to provide a snapshot that was close to a specific GA release.

Is it the case that some RPMs are made available onto a GA release but don't have a corresponding errata? For example, consider the following package on the RHEL 6.4 DVD:

-r--r--r-- 109 root root 84864 Aug 17 2010 Packages/libIDL-0.8.13-2.1.el6.x86_64.rpm

The file was also pulled down onto my Satellite server when I sync 6Server, so I know that Satellite has it:

/var/lib/pulp/published/yum/master/yum_distributor/-Red_Hat_Enterprise_Linux_Server-Red_Hat_Enterprise_Linux_6_Server_RPMs_x86_64_6Server/1453364641.69/libIDL-0.8.13-2.1.el6.x86_64.rpm

However, looking in the Katello database, this package has no corresponding errata:

foreman=# select * from katello_erratum_packages where filename='libIDL-0.8.13-2.1.el6.x86_64.rpm'; id | erratum_id | nvrea | name | filename ----+------------+-------+------+---------- (0 rows)

As a result, my content view of the "Red Hat Enterprise Linux 6 Server RPMs x86_64" which includes a filter restricting it to all errata before 2013-02-21 doesn't pickup this package.

How do I change my filter on 6Server to include packages that were on the 6.4 DVD but without an errata ID?

Richard.

Hi again,

A quick response to my own post in case others find this information useful.

Originally to create my "6.4 GA" Content View, I was using an INCLUDE filter view "Red Hat Enterprise Linux 6 Server RPMs x86_64" with the following restrictions:

Include errata start date: 2005-Jan-01
Include errata end date: 2013-Feb-21

This gave me content with 6641 packages and 1672 errata.

I then did a separate, brand new version of the Content View using an EXCLUDE filter with the following restrictions:

Exclude errata start date: 2013-Feb-21

This gave me content with 10098 packages and 1672 errata.

If I use the EXCLUDE filter I now see the package libIDL-0.8.13-2.1.el6.x86_64.rpm on my client via the content view, which is positive.

However, running 'yum update' on my 6.4 (GA) client results in 96 'minor' updates being available. Example:

Installed Packages
Name        : sssd
Arch        : x86_64
Version     : 1.9.2
Release     : 82.el6
Repo        : installed
From repo   : anaconda-RedHatEnterpriseLinux-201301301459.x86_64

Available Packages
Name        : sssd
Arch        : x86_64
Version     : 1.9.2
Release     : 82.4.el6_4
Repo        : rhel-6-server-rpms

Out of interest, are people generally using INCLUDE or EXCLUDE filters when filtering errata based on timestamp?

Richard.

Richard,

There is an excellent and detailed article at [1] which describes in detail how Content View filters work. I would recommend using the EXCLUDE filter in your most recent example as the simplest configuration is easiest to understand and, if necessary troubleshoot.

When you read the article I've linked to, take note of the following: "When using "Filter: Erratum by Date", you're filtering on the errata release date and not the package date".

[1] https://access.redhat.com/solutions/1564953

All;

This is a good discussion. I recently ran into a similar issue myself. I have a need to restrict a set of systems to use RHEL7.3 packages (primarily kernel) and any updates thereto. This would match exactly with the minor release repositories that Mr. Jerrido described.

However, I can't figure out how to mirror a minor release repository simply with content views and filters. Mr. Jerrido alluded to the fact that it was easily achievable ("I can see a use case for 'I want all errata released with 6.4 but NOT 6.5' (and we can easily solve those)").

My approach is to restrict packages to dates before 7.4 was released (~July 31, 2017). However, the date filtering only works against errata. When I filter this way and compare the resulting package set against the actual 7.3 repository there are significantly less packages in my filtered repo. I assume this is because there are a number of packages released that are NOT relevant to an errata.

I saw the recommendation to use EXCLUDE filters instead of INCLUDE filters. However, while this would restrict me from applying 7.4-relevant errata I would likely still get 7.4-specific packages.

I want my resulting repo to look exactly like the 7.3 repo while utilizing only the 7Server base repository. Any specific help?

I've been testing all day and I am beginning to think there is no way to do this. I did the errata filter, which works well but then I found that there are baseline packages that are not included (e.g. c-ares, which is needed to install SSSD). I then added a package filter and specified to include all packages without associated errata. The issue here is that this includes some newer packages as well that then require other newer packages that may have been version-limited by the errata filter. It seems one would have to create specific package filters to include specific packages on an as-needed basis.

I don't understand why the recommendation is to use Content Filters to limit hosts to a specific minor version but there is not instruction on how to actually accomplish this. It seems the only way to get the minor version functionality is to actually sync the minor version repository.

Someone please let me know if I am missing something because this seems ridiculous to me.

Hi Lesley,

I ended up using an EXCLUDE filter based on date to create a repo that closely matched the GA release. From the example you've given, if you exclude errata beginning 31-July-2017 from the 7Server repo wouldn't you end up with your desired state - a repo of 7.3 packages? Which version of Satellite are you using?

Richard.

No, because not all packages are necessarily driven by errata. We could exclude the errata as you mentioned but we would implicitly include packages that were released after 7.4GA. When doing a yum update some of these packages will be slated to be updated to but failures will likely occur because those packages will have dependencies that will not necessarily exist in your repository.

I am using Satellite 6.2.10.

Lesley,

This has been an ongoing issue for a very long time and I have seen several attempts to resolve it as dependency resolution in EL7 packages is problematic (I believe more so than it was in 6.x).

I assume that the basic model you want to implement is a standard 'SOE' base install that is fully patched, and you then want to apply specific errata (eg. security errata) onto this base installation. You may also want to stay to a minor release, eg. '7.x'. This is a common approach I have seen with my customers (in fact, it is almost the universal standard). They want to have a standard platform and then only update the absolute minimum to meet patch/security compliance to avoid/limit potential regression.

Unfortunately this approach is fraught and it has been an issue in RHEL for quite some time. The 'z' channels or EUS channels provide this capability for minor releases if your customer wants to stay on a minor release, but 'z' channels are only supported for a limited time and they are also not created for later point releases (when the major version leaves full support).

Replicating this capability in older Satellite used to be achieved by using the 'clone-by-date' tool and specifying the dates outlined on the GA release pages for the minor releases. 'clone-by-date' also supported the ability to limit the errata to a specific errata type, eg 'security'. Unfortunately, clone-by-date had several issues and would often miss errata, and would also miss dependencies resulting in channels that had updates that couldn't be applied.

Other methods for cloning security errata often results in missed dependencies; this is an issue with the packages themselves. Unfortunately, tools like Satellite 6 require this depdency information in the packages to be absolutely correct, but there are regularly issues. An example is SSSD, the Samba packages and quite often x86_64/i686 variants of the same packages (things like devel packages). Even if the tool you are using to patch does dependency resolution, these above applications often miss dependent packages, breaking the depdendencies imported into a channel/view which breaks the patch process.

Just last week I pulled this method of patching from a CI process of a customer because every time an errata with failed depdendencies was released, it would break the CI/CD pipeline.

-edit- I outlined an example of the SSSD package dependency problem here: https://access.redhat.com/discussions/3177161#comment-1219621

My view is that Red Hat should not be allowing ISV's certify against minor releases. If major releases are indeed compatible across all minor iterations, the ISV's should only be able to certify against major versions to avoid this ongoing nightmare of holding back Red Hat updates for ISV demands (the most common reason I am asked to stay on minor releases). ie. ISV's should state "certified on EL7", not "certified on EL7.2". If there is a compatability issue or regression across minor releases it should be Red Hat's problem to solve as they offer the platform compatability/stability (it's what customers pay for) so there shouldn't be breaking change across minor release.

Pixel; Thanks for the detailed answer. I tend to agree with you on the compatibility across minor versions. In fact, when my coworkers from other specialties approach me about needing to be on some version 7.x I tell them that minor versions are (or should be) meaningless.

However, recently one of these groups started using a product that deploys a kernel module that the vendor states requires 7.2. It has however been working on 7.3. Sadly, it seems to break when they try to insert it into the latest kernel in 7.4.

Give that what are the use cases for baselining on a given minor version? It seems that it makes some sense if you are not going to make small, a la carte, changes to your content views.

The process I generally implement is build a base image off media (eg. 7.4) and then 'yum update' to latest on that image as part of the kickstart process to create the image/template.

This system was then traditionally subscribed to a channel/repo/(whatever you call it in your environment) that only exposed the security errata to the host and any time an admin etc. would update using 'yum update' it could only receive security errata and would never update minor version (we can get into lengthy discussion about what constitutes a minor version!.. ie. kernel security errata would have broken your example).

Because this method of limiting what is exposed to the clients introduces so many errors into the process (ie. this channel has missing dependencies), I have now moved several customers to the primary 'latest' channel that exposes all packages to the client system.. I have then added a shim/script in front of yum that limits admins from calling 'yum update' etc. without passing '--security'. This is working far more reliably as if any packages are required/missing they will be picked up through this primary channel. There is the ongoing risk that at any time an admin could subvert this process and update the server to the latest minor version with a standard 'yum update', but they would have to carry out several intentional steps to achieve this.

The reason we have moved to this model is the Red Hat tools just don't appear to reflect the reality, even though all documentation suggests they should. We investigated Satellite 6 at length (through several beta iterations) and could never achieve the basic goal of "full base platform, with only security patches applied after initial deployment", without constant fiddling/tweaking of content views.

Luckily the 'cattle' style model of deployment where base images are generated for every application/build deployment and patched on creation (with full automated regression testing etc.) is doing away with a lot of the tedium of ongoing patching, but I can appreciate that a lot of enterprises are a long way from his (if it's even something they plan to implement).

-edit-

I maintained a list of packages that caused breakages when cloning based on security errata. If they broke the build process more than once, I took note of them. I don't have specifics, just maintained the list for reference.
NetworkManager-* (missing dependency)
libstdc++-devel-* (multilib)
gcc-c++-* (multilib)
systemd-libs* (multilib)
sssd-* (missing dependency)

What I ended up doing, for my disconnected Satellites, was to use my connected instance to get a full package listing and updateinfo.xml from the RHEL7.3 repository. I then used this information to reconfigure my '7Server' repository only with 7.3 relevant packages and errata. I sync'd this repository and created a Content View (snapshot) with a date-based errata filter and also used a package filter with the option 'include all packages without errata' to capture all non-errata based packages.

I used the filters because my content view also contains the 'Satellite tools for RHEL7' repository which is already newer than RHEL7.4 GA and I wanted to ensure that packages from the Satellite tools repository don't try to require packages from the 7Server repository that are newer than available. It seems to work so far for my initial baseline builds.

I'll still have to work out how or whether we will apply newer errata to those systems. On a related note it appears that by utilizing an errata filter that applicable errata (released after the filter cutoff date) no longer show as applicable to systems affected by the filter. This will make it very difficult to figure out which errata truly are applicable.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.