Satellite 6 Content View Based on GA Releases such as 6.4, 6.6, 6.7 etc
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.
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
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.
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.
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.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
