Chapter 7. Creating 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 the 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 the Satellite Server updates and publishes the packages. For example, let’s say the we use a content view that contains our Exampleware package:

 DevelopmentTestingProduction

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 will regenerate and then contain the exampleware-1.1-0.noarch.rpm package:

 DevelopmentTestingProduction

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.

This chapter shows how to create different types of content views and apply various filters to them.

7.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 option deselected.

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. The 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.

The 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:

IDName

1

Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server

2

Red Hat Satellite Tools 6.2 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"

The Satellite Server creates the new version of the view and publishes it to the Library environment.

7.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 option deselected.

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. Scroll to the postgresql module and click Select a Version.

Scroll 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.

The 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:

IDName

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"

The Satellite Server creates the new version of the view and publishes it to the Library environment.

7.3. Promoting a Content View

The 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.

Note

Non-administrator users require two permissions to promote a content view to an environment:

  1. promote_or_remove_content_views
  2. 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

Make sure you’re still on the Versions screen for the Database content view. In the versions table, scroll 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 once more. 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.4. Defining 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 choose 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 choose 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.
Note

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.
Important

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 should 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 deselect 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 make sure 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 deselect 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 make sure 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.5. 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 will be 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.

Note

You can also choose 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.6. Defining 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.

Important

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, the Satellite Server reports an error.

7.7. 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.8. Registering Systems to Environments and their Content Views

With content views in place, we can register systems to these environments and views.

7.8.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 satellite6.example.com, run the following command on the client to register:

[root@client ~]# rpm -Uvh http://satellite6.example.com/pub/katello-ca-consumer-latest.noarch.rpm

Run the following command to view a list of environments and their content views on the Satellite Server:

[root@client ~]# subscription-manager environments --org "acme"

Register the client system to an environment and content view on the Satellite Server:

[root@client ~]# subscription-manager register --org "acme" --environment "Development/Stack"
Note

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.8.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 the 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
Note

Because Atomic is functionally an appliance, we do not recommend that you try to install katello-agent on it.

7.9. 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 the 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.