Chapter 7. Managing Content Views
This chapter shows how to create different types of Content Views and apply various filters to them.
7.1. Understanding Content Views
Red Hat Satellite 6 uses Content Views to create customized repositories from the core repositories in your Definitive Media Library (DML). It achieves this through defining which repositories to use and then applying certain filters to the content. These filters include both package filters, package group filters, and errata filters. We use Content Views as a method to define which software versions a particular environment uses. As mentioned in the previous chapter, a Production environment might use a Content View containing older package versions, while a Development environment might use a Content View containing newer package versions.
Each Content View creates a set of repositories across each environment, which Satellite Server stores and manages. When we promote a Content View from one environment to the next environment in the application life cycle, the respective repository on Satellite Server updates and publishes the packages. For example, let’s say that we use a Content View that contains our Exampleware package:
| Development | Testing | Production | |
|---|---|---|---|
| Content View Version and Contents | Version 2 - exampleware-1.1-0.noarch.rpm | Version 1 - exampleware-1.0-0.noarch.rpm | Version 1 - exampleware-1.0-0.noarch.rpm |
The repositories for Testing and Production contain the exampleware-1.0-0.noarch.rpm package. If we promote Version 2 of the Content View from Development to Testing, the repository for Testing regenerates and then contains the exampleware-1.1-0.noarch.rpm package:
| Development | Testing | Production | |
|---|---|---|---|
| Content View Version and Contents | Version 2 - exampleware-1.1-0.noarch.rpm | Version 2 - exampleware-1.1-0.noarch.rpm | Version 1 - exampleware-1.0-0.noarch.rpm |
This ensures systems are designated to a specific environment but receive updates when that environment uses a new version of the Content View.
The general workflow for creating Content Views for filtering and snapshotting is as follows:
- Create a Content View.
- Add the repository and the Puppet modules that you want to the Content View.
- Optionally create one or more Filters to fine tune the content of the Content View.
- Publish the Content View.
- Attach the Content Host to the Content View.
- Optionally promote the Content View to another environment.
If a repository is not associated with the Content View, the file /etc/yum.repos.d/redhat.repo remains empty and systems registered to it cannot receive updates.
Systems can only be associated with a single Content View. To associate a system with multiple Content Views, create a composite Content View. For more information, see Section 7.3.1, “Creating a Composite Content View”.
7.2. Standard Content Views
A standard Content View is a single Content View that can be associated with a single host.
7.2.1. Creating a Simple Content View
For this example, we’ll create a simple Content View using just two repositories and no filters. The repositories to include are the Red Hat Enterprise Linux repository and the Satellite Tools repository. Note that this Content View contains all RPMs for Red Hat Enterprise Linux and takes several minutes to publish.
For Web UI Users
Navigate to Content > Content Views and click Create New View. This displays a form for View Details. Enter the following information:
-
Name - The plain text name for the view. Enter
Base. - Label - An internal ID for the view. Red Hat Satellite 6 automatically completes this field based on what you have entered for Name.
-
Description - A plain text description of the view. Enter
Base operating system. - Composite View? - Defines whether to use a Composite Content View. Leave this check box clear.
Click Save to complete.
This creates a new Content View entry and now you can add repositories to it. Select the repositories for Red Hat Enterprise Linux 7 Server RPMs (not the Kickstart RPMs) and Red Hat Satellite Tools. Click Add Repository. This adds all packages from these repositories to the Content View.
Our Content View is ready to publish. Navigate to Versions and click Publish New Version. Satellite Server provides some details about the new version (Version 1) and allows you to enter a Description for the version, which is useful to logging changes for new content versions. Enter Initial content view for our operating system and click Save.
Satellite Server creates the new version of the view and publishes it to the Library environment.
For CLI Users
Obtain a list of repository IDs:
# hammer repository list --organization "ACME"
For our example, the two repositories we require are using 1 and 2 for their IDs:
| ID | Name |
|---|---|
| 1 | Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server |
| 2 | Red Hat Satellite Tools 6.3 for RHEL 7 Server RPMs x86_64 |
Create the Content View and add repositories:
# hammer content-view create \ --name "Base" \ --description "Base operating system" \ --repository-ids 1,2 \ --organization "ACME"
Now publish the view:
# hammer content-view publish \ --name "Base" \ --description "Initial content view for our operating system" \ --organization "ACME"
Satellite Server creates the new version of the view and publishes it to the Library environment.
7.2.2. Creating a Content View with a Puppet Module
For this example, we’ll create another Content View using one repository and no filters. The repository to include is the PostgreSQL repository.
For Web UI Users
Navigate to Content > Content Views and click Create New View. This displays a form for View Details. Enter the following information:
-
Name - The plain text name for the view. Enter
Database. - Label - An internal ID for the view. Red Hat Satellite 6 automatically completes this field based on what you have entered for Name.
-
Description - A plain text description of the view. Enter
PostgreSQL Database. - Composite View? - Defines whether to use a Composite Content View. Leave this check box clear.
Click Save to complete.
This creates a new Content View entry. Select the repositories for PostgreSQL and click Add Repository. This adds all packages from the PostgreSQL repository to the Content View.
Navigate to Puppet Modules. Click Add New Module. This shows all our imported Puppet modules. Navigate to the postgresql module and click Select a Version.
Navigate to the entry for Use Latest and click Select Version in the Actions column.
The Puppet module is now added to the Content View. Let’s publish a new version.
Navigate to Versions and click Publish New Version. Enter Initial RPMs and Puppet module for database in the Description and click Save.
Satellite Server creates the new version of the view and publishes it to the Library environment.
For CLI Users
Obtain a list of repository IDs:
# hammer repository list --organization "ACME"
We only require the PostgreSQL RPM repository, not the Puppet module repository. In our example, we use the 4 for the ID of the PostgreSQL RPMs:
| ID | Name |
|---|---|
| 4 | PostgreSQL 9.5 |
Create the Content View and add repositories:
# hammer content-view create \ --name "Database" --description "PostgreSQL Database" \ --repository-ids 4 \ --organization "ACME"
Now publish the view:
# hammer content-view publish \ --name "Database" \ --description "Initial RPMs and Puppet module for database" \ --organization "ACME"
Satellite Server creates the new version of the view and publishes it to the Library environment.
7.3. Composite Content Views
A Composite Content View combines the content from several Content Views. For example, you might have separate Content Views to manage a base OS and an application individually. A Composite Content View allows you to merge the contents of both Content Views into a new repository. The repositories for the original Content Views still exist but a new repository now exists for the combined content.
As a use case scenario, a company might aim to develop an application that supports different database servers. The general application stack appears as:
| Exampleware Stack |
|---|
| Application |
| Database |
| Operating System |
The company might develop four individual Content Views:
- Red Hat Enterprise Linux (Operating System)
- PostgreSQL (Database)
- MariaDB (Database)
- Exampleware (Application)
The company can then create two Composite Content Views. One with a PostgreSQL database:
| Composite Content View 1 - Exampleware on PostgreSQL |
|---|
| Exampleware (Application) |
| PostgreSQL (Database) |
| Red Hat Enterprise Linux (Operating System) |
And one with MariaDB:
| Composite Content View 2 - Exampleware on MariaDB |
|---|
| Exampleware (Application) |
| MariaDB (Database) |
| Red Hat Enterprise Linux (Operating System) |
Each individual Content View is then managed and published separately. When we create a new version of the application stack, we publish a new version of the Composite Content Views.
Composite Content Views do not allow more than one of each repository. For example, if you attempt to include two Content Views using the same repository in a Composite Content View, Satellite Server reports an error.
7.3.1. Creating a Composite Content View
Let’s create a Content View for ACME that combines our two existing Content Views.
For Web UI Users
Navigate to Content > Content Views and click Create New View. Provide the following details for the view:
-
Name -
Stack -
Description -
A stack that includes a base operating system and a database - Composite View? - Selected
The Content View listing for the Composite Content View appears. Select both the Base and Database Content Views. Also, the Base Content View contains two versions, which means we need to select a version. Select Version 2, which contains the errata filter. After selecting the Content Views and their versions, click Add Content Views.
Click Publish New Version to publish the Composite Content View. Enter Initial version of Stack for Description and click Save.
When the publication completes, notice that the Content column reports the total package, errata, and Puppet module count for all included Content Views.
Now Promote the Composite Content View across all environments: Development, Testing, Production.
As you can see, Composite Content Views are published and promoted across application life cycle environments similar to regular Content Views.
For CLI Users
Before we create the Composite Content Views, we need the version IDs for our existing Content Views:
# hammer content-view version list \ --full-results true \ --organization "ACME"
For our scenario, the Database v1.0 version ID is 5 and the Base v2.0 version ID is 6. Create a new Composite Content View called Stack and include the version IDs with the --component-ids option:
# hammer content-view create \ --composite \ --name "Stack" \ --description "A stack that includes a base operating system and a database" \ --component-ids 4,14 \ --organization "ACME"
Publish the Composite Content View:
# hammer content-view publish \ --name "Stack" \ --description "Initial version of Stack" \ --organization "ACME"
Promote the Composite Content View across all environments:
# hammer content-view version promote \ --content-view "Stack" \ --version 1 \ --to-lifecycle-environment "Development" \ --organization "ACME" # hammer content-view version promote \ --content-view "Stack" \ --version 1 \ --to-lifecycle-environment "Testing" \ --organization "ACME" # hammer content-view version promote \ --content-view "Stack" \ --version 1 \ --to-lifecycle-environment "Production" \ --organization "ACME"
7.4. Content Filters
Content Views also use filters to include or restrict certain RPM content. Without these filters, a Content View includes everything from selected repositories.
Content filters are either one of the following types:
- Include - Defines the content to include in the view. This filter’s behavior follows a pattern where you start with no content, then select which content to add from the selected repositories. Use this filter to combine multiple content items.
- Exclude - Defines the content to exclude in the view. This filter’s behavior follows a pattern where you start with all content from selected repositories, then select which content to remove. Use this filter when you want to use most of a particular content repository but exclude certain packages, such as blacklisted packages. The filter uses all content in the repository except for the content you select.
If using a combination of Include and Exclude filters, publishing a Content View triggers the Include filters first, then the exclude filters. In this situation, select which content to include, then which content to exclude from the inclusive subset.
There are also four types of content to filter:
- Package - Filter packages based on their name and version number.
- Package Group - Select which package groups to add to the filter. The list of package groups is based on the repositories added to the Content View.
- Erratum (by ID) - Select which specific errata to add to the filter. The list of Errata is based on the repositories added to the Content View.
- Erratum (by Date and Type) - Select a issued or updated date range and errata type (Bugfix, Enhancement, or Security) to add to the filter.
Filters do not resolve any dependencies of the packages listed in the filters. Ensure to add package dependencies to the filter. This might require some level of testing to determine what dependencies are required.
Let’s look at some examples of using content filters.
Example 1
Create a repository with the base Red Hat Enterprise Linux packages. This filter requires a Red Hat Enterprise Linux repository added to the Content View.
Filter:
- Inclusion Type: Include
- Content Type: Package Group
- Filter: Select only the Base package group
Example 2
Create a repository that excludes all errata, except for security updates, after a certain date. This is useful if your aim to perform system updates on a regularly scheduled basis with the exception of critical security updates, which must be applied immediately. This filter requires a Red Hat Enterprise Linux repository added to the Content View.
Filter:
- Inclusion Type: Exclude
- Content Type: Erratum (by Date and Type)
- Filter: Select only the Bugfix and Enhancement errata types, and clear the Security errata type. Set the Date Type to Updated On. Set the Start Date to the date you want to restrict errata. Leave the End Date blank to ensure any new non-security errata is filtered.
Example 3
A combination of Example 1 and Example 2 where we only require the Base OS packages but want to filter out recent bug fix and enhancement errata. This requires two filters attached to the same Content View. The Content View processes the Include filter first, then the Exclude filter.
Filter 1:
- Inclusion Type: Include
- Content Type: Package Group
- Filter: Select only the Base package group
Filter 2:
- Inclusion Type: Exclude
- Content Type: Erratum (by Date and Type)
- Filter: Select only the Bugfix and Enhancement errata types, and clear the Security errata type. Set the Date Type to Updated On. Set the Start Date to the date you want to restrict errata. Leave the End Date blank to ensure any new non-security errata is filtered.
For another example of how content filters work, see the following article: "How do content filters work in Satellite 6"
7.4.1. Creating a Content Filter
For our scenario, we aim to create a content filter that restricts errata items after a certain date for ACME’s base operating system.
For Web UI Users
Navigate to Content > Content Views and select the Base Content View. Navigate to Yum Content > Filters and click New Filter. Enter the following details for your filter:
-
Name -
Errata Filter - Content Type - Erratum - Date and Type
- Inclusion Type - Exclude
-
Description -
Exclude errata items from the last year, with the exception of security updates
Click Save.
The Erratum Date Range screen appears, which allows you to select the errata type to filter and the date range. Select only Enhancement and Bugfix:
[ ] Security [X] Enhancement [X] Bugfix
For the Date Type, select either Issued On (the issued date of the erratum) or Updated On (the date of the erratum’s last update). If the erratum has not been updated after the creation date, then the Issued On and Updated On date are the same for that erratum. Note that Issued On just means that the errata items are filtered based on the issued date. The filter does not exclude any updates that have been made to that erratum.
For the Start Date, select today’s date from one year ago.
For the End Date, leave this field blank.
Click Save.
You can also select which specific repositories use this filter. Select the Affected repositories tab to select these repositories. For this example, there is only one repository to use in our filter.
Our filter is complete. Click Publish New Version to publish the resulting repository. For the Version Details enter Adding errata filter in the Description. Click Save.
When the Content View completes publication, notice the Content column reports a reduced number of packages and errata (except Security errata) from the initial repository. This means the filter successfully excluded the all non-security errata from the last year.
Promote this Content View across all environments: Development, Testing, Production.
For CLI Users
Add a filter to the Content View. Use the --inclusion false option to set the filter to an Exclude filter:
# hammer content-view filter create \ --name "Errata Filter" \ --type erratum --content-view "Base" \ --description "Exclude errata items from the last year, with the exception of security updates" \ --inclusion false \ --organization "ACME"
Add a rule to the filter:
# hammer content-view filter rule create \ --content-view "Base" \ --content-view-filter "Errata Filter" \ --start-date "2015-01-01" \ --types enhancement,bugfix \ --date-type updated \ --organization "ACME"
Publish the Content View:
# hammer content-view publish \ --name "Base" \ --description "Adding errata filter" \ --organization "ACME"
Promote the view across all environments:
# hammer content-view version promote \ --content-view "Base" \ --version 1 \ --to-lifecycle-environment "Development" \ --organization "ACME" # hammer content-view version promote \ --content-view "Base" \ --version 1 \ --to-lifecycle-environment "Testing" \ --organization "ACME" # hammer content-view version promote \ --content-view "Base" \ --version 1 \ --to-lifecycle-environment "Production" \ --organization "ACME"
7.5. Promoting a Content View
Satellite Server has published two Content Views and the repositories are now available to the Library environment. Let’s promote one of these Content Views so the repository appears available to the other environments.
Non-administrator users require two permissions to promote a Content View to an environment:
-
promote_or_remove_content_views -
promote_or_remove_content_views_to_environment.
The promote_or_remove_content_views permission restricts which Content Views a user is allowed to promote.
The promote_or_remove_content_views_to_environment permission restricts the environments to which a user is allowed to promote Content Views.
These permissions make it possible to designate that certain users are permitted to promote certain Content Views to certain environments, but not to other environments. For example, these permissions can be used to limit a user so that they are permitted to promote to test environments, but not to production environments. This provides a kind of multi-level authentication.
Both permissions must be assigned to a user to allow them to promote Content Views.
For Web UI Users
Ensure you are on the Versions screen for the Database Content View. In the versions table, navigate to Version 1.0 of our view and click Promote in the Actions column. A new screen appears where you can select the target environment. Select the Development environment and click Promote Version. After a few minutes, the promotion completes.
Click on the Promote button again. This time select the Testing environment and click Promote Version.
Finally click on the Promote button again. Select the Production environment and click Promote Version.
Now the repository for the Content View appears in all environments.
For CLI Users
Promote the Content View using the hammer content-view version promote each time:
# hammer content-view version promote \ --content-view "Database" \ --version 1 \ --to-lifecycle-environment "Development" \ --organization "ACME" # hammer content-view version promote \ --content-view "Database" \ --version 1 \ --to-lifecycle-environment "Testing" \ --organization "ACME" # hammer content-view version promote \ --content-view "Database" \ --version 1 \ --to-lifecycle-environment "Production" \ --organization "ACME"
Now the database content is available in all environments.
7.6. Registering Systems to Environments and their Content Views
With Content Views in place, we can register systems to these environments and views.
7.6.1. Registering a RHEL System with Subscription Manager
First, log into a test Red Hat Enterprise Linux 7 client system as the root user and download the consumer RPM for your Satellite Server. This is located in the pub directory on the host. For example, for a Satellite Server with the host name satellite.example.com, enter the following command on the client to register:
[root@client ~]# rpm -Uvh http://satellite.example.com/pub/katello-ca-consumer-latest.noarch.rpm
Enter the following command to view a list of environments and their Content Views on Satellite Server:
[root@client ~]# subscription-manager environments --org="acme"
Register the client system to an environment and Content View on Satellite Server:
[root@client ~]# subscription-manager register --org="acme" --environment="Development/Stack"
The client system asks for the user name and password for a Satellite Server user that belongs to the ACME organization. As an alternative, you can use an activation key to register a system, which is discussed in Chapter 8, Managing Activation Keys.
The client system now uses the published repositories from the Stack Content View in the Development environment.
7.6.2. Registering an Atomic Host with Subscription Manager
The following procedure explains how to register an Atomic Host with Subscription Manager.
Retrieve katello-rhsm-consumer from Satellite server:
[root@atomic_client ~]# wget http://satellite.example.com/pub/katello-rhsm-consumer
Change the mode of katello-rhsm-consumer in order to make it executable:
[root@atomic_client ~]# chmod +x katello-rhsm-consumer
Run katello-rhsm-consumer:
[root@atomic_client ~]# ./katello-rhsm-consumer
Register with Red Hat Subscription Manager:
[root@atomic_client ~]# subscription-manager register
Because Atomic is functionally an appliance, we do not recommend that you try to install katello-agent on it.
7.7. Chapter Summary
This chapter explain how to use Content Views to customize your own repositories from existing content in the DML. This includes:
- Creating basic Content Views with RPMs
- Creating Content Views with RPMs and Puppet modules
- Using content filters to include and exclude RPM content
- Combining several Content Views into a Composite Content View
- Registering systems to Satellite Server and consuming content from a specific Content Views
The next chapter discusses activation keys and how systems use them to register and access content from application life cycle environments.
