Content Management Guide

Content management in the context of Red Hat Satellite 6 means a work flow that provides a sustainable repository for multiple content types. For Red Hat content, Red Hat Satellite 6 also uses subscription information so that it knows what content is available to a user. This means Red Hat Satellite 6 uses components to manage the following:

The application life cycle is a concept central to Red Hat Satellite 6’s content management functions. The application life cycle defines how a particular system and its software look at a particular stage. For example, an application life cycle might be simple; you might only have a development stage and production stage. In this case the application life cycle might look like this:

However, a more complex application life cycle might have further stages, such as a phase for testing or a beta release. This adds extra stages to the application life cycle:

Ultimately, the stages in an application life cycle depend on your organization and its software development methods. However, Red Hat Satellite 6 provides methods to customize each application life cycle stage so that it suits your specifications.

Each stage in the application life cycle is called an environment in Red Hat Satellite 6. Each environment uses a specific collection of content. Red Hat Satellite 6 defines these content collections as a Content View. Each Content View acts as a filter where we can define what repositories, packages, and Puppet modules to include in a particular environment. This provides a method for you to define specific sets of content to designate to each environment.

The concept of the application life cycle depends on a certain level of progression. For example, environments in the early stages of an application life cycle might use newer and pre-release packages for development and testing of new features. Likewise, environments in the later stages might use only stable packages to suit production-level software. If the packages in development pass testing, you can promote the development Content View across the application life cycle so that it becomes the Content View for the production environment. This ensures that your application life cycle progresses with the development of your application.

Figure 1.1. The Red Hat Satellite 6 Application Life Cycle

Red Hat Satellite 6 manages different content types. This includes:

This guide uses an example scenario to demonstrate Red Hat Satellite 6’s features. In this scenario, a software development company called ACME recently installed Red Hat Satellite 6 and its system administrators want to start importing and managing Red Hat content. The end goal for ACME is to:

This guide only focuses on content management. Further features, such as host provisioning, environment architecture, and Satellite Server management, are covered in other guides in the Red Hat Satellite 6 series.

This guide provides both steps for using either the Red Hat Satellite 6 Web UI or its CLI tool (hammer). Use either depending on your preferred method of interacting with Red Hat Satellite 6. If using the CLI and do not want to include authentication details each time you enter a hammer command, create a CLI configuration file for the local user:

# mkdir ~/.hammer
# cat > .hammer/cli_config.yml <<EOF
:foreman:
    :host: 'https://satellite.example.com/'
    :username: 'admin'
    :password: 'p@55w0rd!'

EOF

Some CLI commands can use the --async option to perform certain tasks asynchronously. For example, you can synchronize content and publish Content Views as a asynchronous task rather than monitoring it. This guide omits the --async so that users can monitor progress of tasks to completion. If including the --async option for certain tasks, ensure the task completes before moving on to the next task.

Red Hat Satellite 6 hosts repositories for RPM and Puppet content, including content synchronized with Red Hat’s Content Delivery Network and your own custom repositories. Such repositories grow in size over time. This means you must estimate adequate size requirements to suit your environment and scale future requirements accordingly.

Red Hat Satellite 6 stores and manages repository content in /var/lib/pulp. It is recommended to mount this directory onto a large local partition that you can scale. For example, use Logical Volume Manager (LVM) to create this partition.

Red Hat Satellite 6 synchronize and stores packages from Red Hat’s Content Delivery Network. This includes repositories for Red Hat Enterprise Linux and other Red Hat software. The recommended storage requirements for Red Hat content are as follows:

During Production Phase 1 of a major Red Hat Enterprise Linux version:

After Production Phase 1 of a major Red Hat Enterprise Linux version:

For more information about Red Hat Production Phases, see "Red Hat Enterprise Linux Life Cycle".

Red Hat Satellite 6 provides users with the ability to create Content Views. Content Views act as a snapshot of a user-defined content collection at a particular point in time. This provides a means to create customized content collections from preexisting repositories.

Each unit of content in a Content View uses a symbolic link to the Definitive Media Library stored in the /var/lib/pulp/content directory. In addition, each repository in a Content View contains metadata about the content belonging to the Content View. This means a Content View using a minimal number of packages uses a small amount of storage. However, the storage size adds up when you use multiple Content Views and a large number of packages per view.

For example, a Content View using the Red Hat Enterprise Linux 7 RPMs repository might contain over 7000 packages. In terms of disk space, this might only result in less than 100MB of symbolic links. However, take into account the following:

To help reduce the amount of storage that Content Views consume, use the following recommendations:

Red Hat Satellite 6 also uses the following databases for its content management components:

In this chapter, we explored the base concept of content management in the context of Red Hat Satellite 6. This includes defining phases of the Red Hat Satellite 6 application life cycle and the different types of content that Red Hat Satellite 6 manages. This chapter also defined the scope of our example scenario and provided storage requirements to suit your content management needs.

The next chapter looks at creating organizations to store content.

Click New Organization.

A creation wizard appears with three sections:

After completing your organization creation, click Submit.

# hammer organization create \
--name "ACME" \
--label "ACME" \
--description "Our example organization for managing content."

This creates your first organization.

Before managing content in Red Hat Satellite 6, we must set the context. A context defines which organization to use for our content.

# hammer subscription list --organization "ACME"

This sets the context for each interaction through the CLI.

You can view an organization’s repository content using a browser or using the API if you have a debug certificate for that organization. The previous section describes creating and downloading the certificate which is in the X.509 format. To use a browser you must first convert the X.509 certificate to a format your browser supports and then import the certificate. The curl utility only requires extracting the certificate and key into separate files.

This chapter showed how to create new organizations, create organization debug certificates, remove organizations, and set an organization as our context for content management.

The next chapter explores how Red Hat Satellite 6 imports your subscriptions into your organization. After the subscriptions are imported, so you can start managing Red Hat content.

You can have more than one allocation in a Satellite Server if you want to manage more than one organization. Satellite 6 requires a single allocation for each organization configured in Satellite. The advantage of this is that since each organization maintains completely separate subscriptions, you can support multiple organizations each with their own Red Hat accounts.

You can access your subscription information on the Red Hat Customer Portal. You can also assign subscriptions for use in on-premise management applications, such as Red Hat Satellite, using subscription allocations.

The following procedure explains how to add subscriptions to an allocation.

When you have added subscriptions to the allocation, export the manifest file.

While viewing a subscription allocation that has at least one subscription, you can export a manifest in either of two places:

When the manifest is exported, the Customer Portal encodes the selected subscription certificates and creates a .zip archive. This is the Subscription Manifest, which can be uploaded into the Satellite Server.

Both the Red Hat Satellite 6 Web UI and CLI provide methods for importing the manifest.

[user@client ~]$ scp ~/manifest_file.zip root@satellite.example.com:~/.

Then enter the following command to import it:

[root@satellite ~]# hammer subscription upload \
--file ~/manifest_file.zip \
--organization "organization_name"

After a few minutes, the CLI reports a successful manifest import.

Every time that you change a subscription allocation, you must refresh the manifest to reflect these changes. For example, you must refresh the manifest if you take any of the following actions:

You can updated the manifest in Satellite in one of the three following ways:

[root@satellite ~]# hammer subscription upload \
--file ~/manifest_file.zip \
--organization "organization_name"

Using Activation Keys is the recommended way to attach subscriptions to content hosts during provisioning. However, an Activation key cannot update an existing host. If you need to attach new or additional subscriptions, such as future-dated subscriptions, to one host, follow the method below. If you need to update multiple hosts, see Section 3.8, “Bulk Updating Content Hosts' Subscriptions”. For more information on Activation keys, see Chapter 8, Managing Activation Keys.

However, you are not required to attach Smart Management subscriptions to each content host. Smart Management subscriptions cannot attach automatically to content hosts in Satellite because they are not associated with any product certificates. Adding a Smart Management subscription to a content host does not provide any content or repository access. If you want, you can add a smart management subscription to a manifest for your own recording or tracking purposes.

The methods described here are intended for post installation changes to multiple content hosts at the same time. You can use the web UI and the filter function to select the content hosts to be changed, or use the Hammer command-line tool’s CSV file export function, edit the configuration settings in the CSV file, and upload the changes.

This chapter showed how to use a Subscription Allocation and Manifest to take subscription information from the Red Hat Customer Portal and import it into our Satellite Server.

The next chapter looks at how to start importing content, specifically Red Hat’s RPM repositories.

A DML is a repository that stores and protects the definitive, authorized versions of software and configurations. In other words, the DML acts as a master version of any content imported into Satellite. This includes Red Hat content, such as RPM files, kickstart trees, and ISO images. As mentioned in Section 1.1, “Overview of Red Hat Satellite 6 Content Management”, Red Hat Satellite 6 stores and manages content in a DML.

In Satellite, we use the concept of a Product as an organizational unit to group multiple repositories together. Such repository collections are analogous to the concept of real life products. For example, if we view Red Hat Enterprise Linux Server as a Product in Satellite, the repositories for that product might consist of different versions (6.0, 6.1, 7.0), different architectures (i386, x86_64, s390x, arm), and different add-ons (Optional repositories, Supplementary repositories, Virt V2V tools). This unifies all related repositories within the DML. Using Products ensures repositories that depend on each other are synchronized together. For Red Hat repositories, products are created automatically after enabling the repository.

In this chapter, our aim is to start creating our DML using Red Hat content. To do this, we synchronize our DML with Red Hat’s Products and their repositories.

When you select which repositories form the DML, Satellite Server synchronizes its own repositories with the repositories on the Red Hat CDN. This ensures that Satellite Server retains an exact copy of Red Hat’s repositories as a part of its DML. Satellite Server fetches this repository information and stores it on Satellite Server’s file system. After an initial synchronization, you can create a synchronization plan that checks to ensure the repositories in the DML is up to date with the CDN’s repositories.

It is possible to perform an initial synchronization using ISO images. See Appendix C, Importing Content ISOs into a Connected Satellite for more information on using Content ISOs. For locations with bandwidth limitations, using an On Demand or Background download policy as described below might be quicker than downloading and importing Content ISOs.

Red Hat Satellite provides multiple download policies for synchronizing RPM content. For example, you might aim to save time and only download the content metadata while deferring the actual content download for later.

Satellite Server offers the following policies:

The latter two policies act as a Lazy Synchronization feature because they save time synchronizing content. The lazy sync feature must only be used for yum repositories. The packages can be added to Content Views and promoted to life cycle environments as normal.

Capsule Server offers the following policies:

These policies are not available if a Capsule was installed or updated with --enable-foreman-proxy-plugin-pulp set to false.

The first step in selecting the repositories to synchronize is to identify the product that contains the repository, then enable that repository based on release version and base architecture.

The relationship between products and specific repositories is connected through a cascading hierarchy. Select a product and this opens a list of repository sets for that product. Select a repository set and this opens a list of repositories that you can enable. For our scenario, select Red Hat Enterprise Linux Server, then Red Hat Enterprise Linux 7 Server (RPMs), then enable Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server. This enables the latest RPM files for Red Hat Enterprise Linux 7.

# hammer product list --organization "ACME"

List the repository set for the product:

# hammer repository-set list \
--product "Red Hat Enterprise Linux Server" \
--organization "ACME"

This displays the repositories in the product’s repository set, including their name and ID number. Enable the repository using either the name or ID number. Also include the release version (7Server) and base architecture (x86_64). For example:

# hammer repository-set enable \
--name "Red Hat Enterprise Linux 7 Server (RPMs)" \
--releasever "7Server" \
--basearch "x86_64" \
--product "Red Hat Enterprise Linux Server" \
--organization "ACME"

For this scenario, use either the Web UI or the CLI to enable the following repositories for ACME:

These repositories provide some initial content for our scenario’s DML. You can select more repositories based upon your needs.

We have enabled specific repositories to form our initial DML. Now we synchronize the repositories with the Red Hat CDN’s repositories.

# hammer product synchronize \
--name "Red Hat Enterprise Linux Server" \
--organization "ACME"

You can also synchronize each repository individually. List all repositories in the product, then synchronize using the ID number for the corresponding repositories. For example:

# hammer repository list \
--product "Red Hat Enterprise Linux Server" \
--organization "ACME"
# hammer repository synchronize \
--name "Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server" \
--product "Red Hat Enterprise Linux Server" \
--organization "ACME"

The synchronization duration depends on the size of each repository and the speed of your network connection. The following table provides estimates of how long it would take to synchronize content, depending on the available Internet bandwidth:

A manual synchronization is often required for the initial content import into the DML. However, it is recommended to create a synchronization plan to ensure that our DML updates on a regular basis.

A synchronization plan checks and updates the content in your DML at a regularly scheduled date and time. Red Hat Satellite 6 provides users with the ability to create a synchronization plan and assign products to it.

Click Save to create a plan. The plan details page displays along with two tabs for Details and Products.

Now add your products. Click the Products tab, then click Add. Select the Red Hat Enterprise Linux Server product and click Add Selected.

# hammer sync-plan create \
--name "Red Hat Products 2" \
--description "Example Plan for ACME's Red Hat Products" \
--interval daily \
--sync-date "2016-02-01 01:00:00" \
--enabled true \
--organization "ACME"

Then assign the Red Hat Enterprise Linux Server product to it:

# hammer product set-sync-plan \
--name "Red Hat Enterprise Linux Server" \
--sync-plan "Red Hat Products" \
--organization "ACME"

Now Satellite Server checks its DML content against the Red Hat CDN on a daily basis and keeps its Red Hat repositories up to date.

This chapter showed how to import Red Hat content into ACME’s Satellite Server and keep it up to date through synchronization plans.

The next chapter explores a importing custom content into Satellite Server’s DML. This process is similar to importing Red Hat content except we create and manage custom products.

In Section 4.2, “Using Products and Repositories in Satellite”, we explored the concept of a Product in Red Hat Satellite 6 and how it is used to group repositories together. Red Hat Satellite 6 also provides the ability to create custom Products so you can add multiple related repositories. Both Red Hat content and custom content in Red Hat Satellite 6 share some similarities:

In this chapter, we aim to create a product that contains two related repositories: an RPM repository containing RPM content and a Puppet repository for modules to configure the RPM content.

For more information about creating and packaging RPMs, see the RPM Packaging Guide in the Red Hat Enterprise Linux documentation.

In our scenario, ACME is aiming to develop a product called Exampleware, which is a web-based application that requires a PostgreSQL database. ACME might aim to use production-level Exampleware in the field using PostgreSQL from the Red Hat Enterprise Linux repositories but test Exampleware with newer versions of PostgreSQL. For this situation, let’s create a custom product for PostgreSQL so that we can synchronize the newer versions.

When you have entered this information, click Save.

# hammer product create \
--name "PostgreSQL" \
--sync-plan "Example Plan" \
--description "Content from PostgreSQL repositories" \
--organization "ACME"

This creates a new product where we can create our own custom repositories and synchronize their content.

Before we create a custom product, we might need to create a custom GPG key. This is used to provide a certain level of security for RPM transactions with the PostgreSQL repository.

First download a copy of the version specific repository package to your client system. In our case, we download pgdg-redhat95:

[user@client ~]$ wget http://yum.postgresql.org/9.5/redhat/rhel-7-x86_64/pgdg-redhat95-9.5-2.noarch.rpm

Extract the RPM file without installing it:

[user@client ~]$ rpm2cpio pgdg-redhat95-9.5-2.noarch.rpm | cpio -idmv

The GPG key is located relative to the extraction at etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG-95.

[user@client ~]$ scp ~/etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG-95 root@satellite.example.com:~/.

Upload the GPG key to Satellite:

[root@satellite ~]# hammer gpg create \
--key ~/RPM-GPG-KEY-PGDG-95 \
--name "PostgreSQL 9.5" \
--organization "ACME"

Now we have a GPG key we can associate with our repository.

Normally, a production-level server would use the version of PostgreSQL included with Red Hat Enterprise Linux for stability purposes. However, ACME’s developers might aim to test Exampleware with a more recent version of PostgreSQL. In this instance, they can create a custom repository for a newer version of PostgreSQL.

Click Save to save this repository entry.

The repository uses the synchronization plan to periodically keep it up to date. However, let’s perform an initial synchronization. Select the PostgreSQL 9.5 repository and click Sync Now. This starts a task to synchronize our repository with the external PostgreSQL repository.

# hammer repository create \
--name "PostgreSQL 9.5" \
--content-type "yum" \
--publish-via-http true \
--url http://yum.postgresql.org/9.5/redhat/rhel-7-x86_64/ \
--gpg-key "PostgreSQL 9.5" \
--product "PostgreSQL" \
--organization "ACME"

Then synchronize the repository:

# hammer repository synchronize \
--name "PostgreSQL 9.5" \
--product "PostgreSQL" \
--organization "ACME"

Now we have a synchronized copy of PostgreSQL 9.5. Let’s take this a step further and include a Puppet module to configure a PostgreSQL server.

Custom products can also include repositories for Puppet modules. This provides a method to incorporate state configuration of hosts.

First, let’s create a repository for our PostgreSQL product.

Click Save to save this repository entry.

# hammer repository create \
--name "PostgreSQL Puppet Modules" \
--content-type "puppet" \
--product "PostgreSQL" \
--organization "ACME"

Now we have a custom repository for our Puppet modules. Let’s add one now.

For this scenario, we manually import a Puppet module for configuring PostgreSQL.

Download this module from the Puppet Forge site (https://forge.puppetlabs.com/puppetlabs/postgresql). Open the page in your browser and click download latest tar.gz to save to your local file system.

Navigate to the Upload Puppet Module section, click Browse, select the PostgreSQL Puppet Module we downloaded previously, and click Upload. After a few seconds, Satellite Server reports Content successfully uploaded.

[user@client ~]$ scp ~/puppet_module.tar.gz root@satellite.example.com:~/.

Import the Puppet module to the PostgreSQL Puppet Modules repository:

[root@satellite ~]# hammer repository upload-content \
--path ~/puppet_module.tar.gz \
--name "PostgreSQL Puppet Modules" \
--product "PostgreSQL" \
--organization "ACME"

Now we have a custom repository that contains both RPM content and a Puppet module to install and configure a server using the RPM content.

In addition to creating a repository of uploaded Puppet modules, Satellite Server can synchronize a complete Puppet module repository. In this example, Satellite Server synchronizes the entire Puppet Forge repository.

When you have entered this information, click Save.

After creating our custom product, the repositories screen appears. Click Create Repository, which displays a form for a new repository. Enter the following details:

Click Save to save this repository entry.

Select the Puppet Forge Modules repository and click Sync Now. This imports all modules from Puppet Forge into Satellite Server.

# hammer product create \
--name "Puppet Forge" \
--sync-plan "Example Plan" \
--description "All modules from Puppet Forge" \
--organization "ACME"

Create the Puppet Forge repository:

# hammer repository create \
--name "Puppet Forge Modules" \
--content-type "puppet" \
--product "Puppet Forge" \
--organization "ACME" \
--url http://forge.puppetlabs.com/

Synchronize the repository:

# hammer repository synchronize \
--name "Puppet Forge Modules" \
--product "Puppet Forge" \
--organization "ACME"

Red Hat Satellite 6 includes a utility called pulp-puppet-module-builder, which you can install on other systems from the pulp-puppet-tools RPM. This tool checks out a Git repository, builds all the modules, and publishes them in a structure that Satellite 6 can synchronize. One common method is to run the utility on Satellite Server itself, publish to a local directory, and synchronize against that directory. For example:

# mkdir /modules
# chmod 755 /modules
# pulp-puppet-module-builder \
--output-dir=/modules \
--url=git@mygitserver.com:mymodules.git \
--branch=develop

This checks out the develop branch of the Git repository from git@mygitserver.com:mymodules.git and publishes it to /modules. Add this directory as the URL (file:///modules) for a new repository on Satellite Server. For example:

# hammer repository create \
--name "Modules from Git" \
--content-type "puppet" \
--product "MyProduct" \
--organization "ACME" \
--url file:///modules

# mkdir /var/www/html/modules/
# chmod 755 /var/www/html/modules/
# pulp-puppet-module-builder \
--output-dir=/var/www/html/modules/ \
--url=git@mygitserver.com:mymodules.git \
--branch=develop

Custom products in Red Hat Satellite can also include repositories for custom file types. This provides a generic method to incorporate arbitrary files in a Product. Applications range from distributing SSH keys and source code files to larger files such as virtual machine images and ISO files.

You can upload files to the repository or synchronize it from an upstream Satellite Server. When you add files to a custom file type repository, you can use the normal Satellite management functions such as adding a specific version to a Content View to provide version control and making the repository of files available on various Capsule Servers. Clients must download the files over HTTP or HTTPS using curl -O.

A file type repository in Satellite Server can be created only in a custom product, but you can create an independent file type repository in a directory on the system where Satellite is installed, or on a remote HTTP server, and then synchronize the contents of that directory into Satellite. This method is useful when you have multiple files to add to a Satellite repository.

This example creates a Product My File Product, and then creates a file type repository My Files within that product. For more information about file type repositories outside of Satellite, see Appendix E, Creating a Remote File Type Repository.

# hammer repository upload-content \
--product "My File Product" \
--name "My Files" \
--organization "ACME" \
--path example_file

The --path option can indicate a file, a directory of files, or a glob expression of files. Globs must be escaped by single or double quotes.

You can download files to a client over HTTPS using curl -O, and optionally over HTTP if the Publish via HTTP repository option is selected.

You can create a custom file type repository, from a directory of files, external to Satellite Server using the pulp-manifest command. You can then synchronize the files into Satellite Server. When you add files to a file type repository, you can work with the files as with any other repository.

This procedure describes configuring a repository in a directory on the base system where Satellite is installed. To create a file type repository in a directory on a remote server, see Appendix E, Creating a Remote File Type Repository.

This chapter demonstrated how to create custom repositories for non-Red Hat content. This includes RPM files, Puppet modules, and custom file types.

At this point we have all our base content imported into our Satellite Server’s DML. This means we can start using it in our application life cycle.

The next chapter looks at developing an application life cycle to match the development and production process of ACME.

As we discussed, the application life cycle defines how systems appear at a certain stage. However, the actual application life cycle depends on your organization and how it structures a particular production chain.

For example, an email server might only require a simple application life cycle where you have a production-level server for real world use and a test server for trying out the latest mail server packages. When the test server passes the initial phase, we can set the production-level server to use the new packages.

Another example might be an development life cycle for a software product. You might aim to develop a new piece of software in a development environment, have it tested in a quality assurance environment, pre-release it as a beta, then release it as a production-level application.

Each application life cycle uses a set of stages called environments. Each environment act as a particular state for our systems. Each environment also follows on from a previous environment, creating a chain of environments that becomes our application life cycle. Each application life cycle starts with an initial Library, which acts as a central source in our Definitive Media Library (DML). The Library environment contains all of the content we previously synchronized in our previous chapters. From this point, we create additional environments that link starting from the Library environment.

For our scenario, we aim to create simple application life cycle for developing and releasing ACME’s Exampleware. We use the Library environment as our initial environment, then chain an additional three environments in this order: Development, Testing, and Production.

Click New Environment Path to start a new application life cycle. A form appears for adding a new environment to Library. Enter Development for the Name and the Label automatically completes. Enter Environment for ACME’s Development Team for the Description. Click Save.

We return to the environments listing. A new table appears with our Development environment. This new table represents our new application life cycle. Now we add the rest of the environments to the application life cycle.

Click Add New Environment just above the new table. This time, enter Testing for Name and Environment for ACME’s Quality Engineering Team for the Description. Click Save.

Finally, click Add New Environment again. Enter Production for Name and Environment for ACME’s Product Releases for the Description. Click Save.

The final application life cycle appears as a table with our three environments: Development, Testing, and Production.

# hammer lifecycle-environment create \
--name "Development" \
--description "Environment for ACME's Development Team" \
--prior "Library" \
--organization "ACME"
# hammer lifecycle-environment create \
--name "Testing" \
--description "Environment for ACME's Quality Engineering Team" \
--prior "Development" \
--organization "ACME"
# hammer lifecycle-environment create \
--name "Production" \
--description "Environment for ACME's Product Releases" \
--prior "Testing" \
--organization "ACME"

View your chain with the hammer lifecycle-environment paths command:

# hammer lifecycle-environment paths --organization "ACME"
-----------------------------------------------
LIFECYCLE PATH
-----------------------------------------------
Library >> Development >> Testing >> Production
-----------------------------------------------

The following is an optional step for environments that use Capsule Servers to provision content.

If your Capsule Server has content functionality enabled, you must add an environment. Adding an environment enables Capsule Server to synchronize content from Satellite Server and provide content to host systems.

Capsule Server is configurable using Hammer CLI on Satellite Server, or through the web UI.

Click Edit.

Select Env in the Life Cycle Environments tab.

To synchronize capsule’s content, click the Synchronize button in the Overview tab.

Select one of two options:

# hammer capsule list

Using the ID, verify the details of your Capsule Server:

# hammer capsule info --id capsule_id_number

Verify the life cycle environments available and note the environment ID:

# hammer capsule content available-lifecycle-environments \
--id capsule_id_number

Available life cycle environments are available for Capsule Server, but not currently attached.

Add the life cycle environment to your Capsule Server:

# hammer capsule content add-lifecycle-environment \
--id capsule_id_number --environment-id environment_id_number

Repeat for each life cycle environment you want to add to Capsule Server.

To synchronize all content from your Satellite Server environment to Capsule Server, enter the following command:

# hammer capsule content synchronize --id capsule_id_number

To synchronize a specific life cycle environment from your Satellite Server to Capsule Server, enter the following command:

# hammer capsule content synchronize --id external_capsule_id_number \
--environment-id environment_id_number

For more information on working with Life Cycle Environments, see Life Cycle Environments in the Architecture Guide.

Content moves from one environment to the next in an application life cycle chain. This is a process called promotion. Promotion is an important concept to understand because it is the basis for managing content across an application life cycle.

For our scenario, let’s say that ACME’s Exampleware is in full development and production. ACME packages their Exampleware content into a RPM file, which becomes part of a separate product. In this situation, ACME might have version 1.0 of Exampleware released, which means exampleware-1.0-0.noarch.rpm is in the Production environment.

ACME wants to release a patch for Exampleware, so they start development on version 1.1 of Exampleware. In this instance, the environments in the application life cycle would contain the following version of Exampleware:

After completing development on the patch, ACME promotes the RPM to the Testing environment so ACME’s Quality Engineering team can review the patch. The application life cycle then contains the following package versions in each environment:

While the Quality Engineering team reviews the patch, the Development team starts work on Exampleware 2.0. This results in the following application life cycle:

The Quality Engineering team completes their review of the patch. Now Exampleware 1.1 is ready for release. ACME promotes 1.1 to the Production environment:

The Development team completes their work on Exampleware 2.0 and promotes it to the Testing environment:

Finally, the Quality Engineering team reviews the package. After a successful review, we promote the package to the Production environment:

This example demonstrates the mapping of ACME’s development process into a Red Hat Satellite 6 application life cycle. Each environment contains a set of systems registered to Red Hat Satellite 6. These systems only have access to repositories relevant to their environment. When we promote packages from one environment to the next, the target environment’s repositories receive new package versions. As a result, each system in the target environment can update to the new package versions.

Another concept we explore in the next chapter is Content Views. A Content View is essentially a collection of content gathered and filtered from the Library and published in its own repository. The Red Hat and custom repositories we synchronized previously act as source content, while the Content Views customize exactly how the end repositories appear. Content Views contain packages and Satellite Server promotes Content Views across environments in the application life cycle. An environment might use one Content View (Version 1.0) but then might receive a new version of the Content View (Version 1.1). The repositories from Version 1.0 are replaced with the repositories for Version 1.1, which might include a new version of the Exampleware RPMs.

If a newly created Red Hat Satellite Capsule Server has content functionality enabled, the Capsule Server needs an environment added to enable it to synchronize content from Satellite Server and provide content to host systems.

After you have created a Content View and an environment path consisting of two or more life cycle environments, you can promote the Content View from one environment to the next as required. This means that the most recent version of the Content View that exists in a specified environment is promoted, or copied, to the next environment in the life cycle environment path.

You can promote a Content View to any environment where that version does not exist. The system automatically suggests the next environment in the life cycle environment path, but you can override this and promote to a different environment if required.

This procedure describes how to remove a life cycle environment from Red Hat Satellite.

There are multiple reasons to remove life cycle environments from Capsule Server. For example:

This chapter returned to the concept of the application life cycle and how it applied to Red Hat Satellite 6’s content management. This chapter also explored how Red Hat Satellite 6 promoted content across the environments in the application life cycle.

The next chapter discusses Content Views and how they are used to create custom filtered repositories from our existing DML.

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:

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:

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:

A standard Content View is a single Content View that can be associated with a single host.

# hammer repository list --organization "ACME"

# hammer content-view create \
--name "Base" \
--description "Base operating system" \
--repository-ids 1,2 \
--organization "ACME"

# hammer content-view publish \
--name "Base" \
--description "Initial content view for our operating system" \
--organization "ACME"

# hammer repository list --organization "ACME"

# hammer content-view create \
--name "Database" --description "PostgreSQL Database" \
--repository-ids 4 \
--organization "ACME"

# hammer content-view publish \
--name "Database" \
--description "Initial RPMs and Puppet module for database" \
--organization "ACME"

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:

The company might develop four individual Content Views:

The company can then create two Composite Content Views. One with a PostgreSQL database:

And one with MariaDB:

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.

# hammer content-view version list \
--full-results true \
--organization "ACME"

# 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"

# hammer content-view publish \
--name "Stack" \
--description "Initial version of Stack" \
--organization "ACME"

# 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"

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:

There are also four types of content to filter:

Let’s look at some examples of using content filters.

Filter:

Filter:

Filter 1:

Filter 2:

For another example of how content filters work, see the following article: "How do content filters work in Satellite 6"

[ ] Security
[X] Enhancement
[X] Bugfix

# 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"

# 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"

# hammer content-view publish \
--name "Base" \
--description "Adding errata filter" \
--organization "ACME"

# 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"

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.

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.

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

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

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

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

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

[root@atomic_client ~]# wget http://satellite.example.com/pub/katello-rhsm-consumer

[root@atomic_client ~]# chmod +x katello-rhsm-consumer

[root@atomic_client ~]# ./katello-rhsm-consumer

[root@atomic_client ~]# subscription-manager register

This chapter explain how to use Content Views to customize your own repositories from existing content in the DML. This includes:

The next chapter discusses activation keys and how systems use them to register and access content from application life cycle environments.

With activation keys you can define how the content host is subscribed during registration. The subscription behavior defined by the activation key depends on two factors:

Based on the above factors, there are three possible scenarios for subscribing with activation keys:

The activation keys are used for registration. This includes:

You can test the activation key we created. Register an existing Red Hat Enterprise Linux 7 system to Satellite Server.

First, download the consumer RPM for your Satellite Server. This is usually located in the pub directory on the host’s web server. For example, for a Satellite Server with the host name satellite.example.com, enter the following command on the client to register:

# rpm -Uvh http://satellite.example.com/pub/katello-ca-consumer-latest.noarch.rpm

This RPM installs the necessary certificates for accessing repositories on Satellite Server and configures Red Hat Subscription Manager to use the server’s URL.

Next, run Red Hat Subscription Manager on the client:

# subscription-manager register --activationkey="development-stack" \
--org="ACME"
The system has been registered with id: 744fb31c-c983-00f5-ca14-bddd0f711353

Check Satellite Server to confirm the registration.

# hammer host list --organization "ACME"

# yum install katello-agent

You can use multiple activation keys when registering a content host. This allows you to create activation keys for specific subscription sets and then combine them according to content host requirements. For example, the following command registers a content host to the ACME organization with both VDC and OpenShift subscriptions:

# subscription-manager register --org="ACME" \
--activationkey="ak-VDC,ak-OpenShift"

If there are conflicting settings in activation keys, the rightmost key takes precedence.

You can change the subscriptions associated with an Activation Key using the web UI or using the Hammer command-line tool. The Hammer CLI method requires downloading a CSV file, making changes to the Activation Key settings, and then uploading the changed CSV file.

Note that changes to an Activation Key applies only to machines provisioned after the change. To update subscriptions on existing content hosts, see Section 3.8, “Bulk Updating Content Hosts' Subscriptions”.

When auto-attach is enabled on an activation key and there are subscriptions associated with the key, the subscription management service selects and attaches the best-matched associated subscriptions based on a set of criteria like currently-installed products, architecture, and preferences like service level.

You can enable auto-attach and have no subscriptions associated with the key. This type of key is commonly used to register virtual machines when you do not want the virtual machine to consume a RHEL subscription but to inherit a RHEL Virtual Data Center (VDC) subscription from the hypervisor.

Auto-attach is enabled by default. Disable the option if you want to force attach all subscriptions associated with the activation key.

# hammer activation-key update --name "development-stack" \
--organization "ACME" --auto-attach true

An activation key can be configured to define a default service level for the new host created with the activation key. Setting a default service level selects only the matching subscriptions to be attached to the host. For example, if the default service level on an activation key is set to Premium, only subscriptions with premium service levels are attached to the host upon registration.

# hammer activation-key update --name "development-stack" \
--organization "ACME" --service-level premium

This chapter discussed activation keys, demonstrated how to create them, and how systems register to a Satellite Server with them.

The next chapter explores errata management, including how to apply errata to a system.

Red Hat Satellite 6 provides various methods to manage and apply errata. As discussed in Section 7.4, “Content Filters”, we can use Content Views and content filters to limit errata. Such filters include:

As an example, we can create a content filter to exclude errata after a certain date. This ensures our production systems in the application life cycle are kept up to date to a certain point. Then we can modify the filter’s start date to introduce new errata into our testing environment. This is so we can test the compatibility of new packages into our application life cycle.

For instructions on creating a content filter, see Section 7.4.1, “Creating a Content Filter”.

When a Content View contains errata, we can apply it to our systems. Each system registered to your Red Hat Satellite 6 includes an errata management screen where you can apply multiple errata to the system. In addition, Red Hat Satellite 6 contains an errata management feature where you can search, review, and apply errata to multiple systems.

The following procedure describes how to view and filter the available errata and how to display metadata of the selected advisory.

For this procedure, we aim to apply some errata to a system. This procedure follows on from Section 8.2, “Using Activation Keys” and assumes you registered a test Red Hat Enterprise Linux 7 system to your Satellite Server. In this example, we aim to apply the following erratum:

Errata ID:   RHSA-2016:0008
Title:       Moderate: openssl security update
Type:        security
Severity:    Moderate
Issued:      2016-01-07
Updated:     2016-01-07
Description: OpenSSL is a toolkit that implements the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols, as well as a full-strength, general purpose cryptography library.

Let’s apply errata for OpenSSL. Navigate to the search bar and enter title ~ openssl. This searches for any errata with openssl in the title. Select the RHSA-2016:0008 errata and click Apply Selected. A confirmation message appears. Click Apply.

Satellite Server starts a task to update all packages associated with the selected errata. When the task completes, Satellite Server lists the packages updated and their new versions in the Details section. For example:

1:openssl-1.0.1e-51.el7_2.2.x86_64
1:openssl-libs-1.0.1e-51.el7_2.2.x86_64

Log in to the client system and confirm the errata updates:

[root@client ~]# yum list openssl openssl-libs

# hammer host errata list \
--host client.example.com \
--search "title ~ openssl" \
--organization "ACME"

Apply the most recent erratum to the client system. Identify the erratum to apply using the Errata ID:

# hammer host errata apply \
--host client.danssat.net \
--errata-ids RHSA-2016:0008 \
--organization "ACME"

Log in to the client system and confirm the errata updates:

[root@client ~]# yum list openssl openssl-libs

The Red Hat Satellite 6 Web UI provides an errata management tool to help review and apply errata to multiple systems. For this example, we use the same erratum (RHSA-2016:0008) from Section 9.3, “Applying Errata to Individual Systems”.

Let’s apply a single OpenSSL errata to our systems through this tool. Navigate to the search field and enter title ~ openssl. This shows all errata relating to OpenSSL. Although this includes bug fixes and enhancements, note that Satellite Server cannot install these errata to our test system due to the filter we created in Section 7.4.1, “Creating a Content Filter”.

Click on the most recent OpenSSL errata. In our example, this is RHSA-2016:0008.

The Details screen for this erratum appears and provides a description of what the erratum resolves.

Navigate to the Content Hosts subtab. This displays a list of all applicable systems for this errata. We select Only show content hosts where the errata is currently installable in the host’s Lifecycle Environment to limit this list to systems that can actually install the errata.

Select our test system and click Apply to Hosts. A confirmation screen appears regarding the errata installation. Click Confirm.

Satellite Server starts a task to update the erratum’s packages for each selected system. When the task completes, log in to the client system and confirm the errata updates:

[root@client ~]# yum list openssl openssl-libs

List all OpenSSL errata:

# hammer erratum list --search "title ~ openssl" --organization "ACME"

Search again, restricting the list to installable errata:

# hammer erratum list \
--errata-restrict-installable true \
--search "title ~ openssl" --organization "ACME"

Find out details about this errata:

# hammer erratum info --id RHSA-2016:0008

List the systems that this erratum is applicable:

# hammer host list \
--search "applicable_errata = RHSA-2016:0008" \
--organization "ACME"

Apply the errata to a single system:

# hammer host errata apply \
--host client.example.com \
--errata-ids RHSA-2016:0008

Enter the following command for each client system and replace --host with the name of the system for each execution.

# for HOST in `hammer \
--csv --csv-separator "|" host list \
--search "applicable_errata = RHSA-2016:0008" \
--organization "ACME" | tail -n+2 | awk \
-F "|" '{ print $2 }'` ; do echo \
"== Applying to $HOST ==" ; hammer host errata apply \
--host $HOST --errata-ids RHSA-2016:0008 ; done

This command identifies all hosts with RHSA-2016:0008 as an applicable erratum and then applies the erratum to each host.

Log in to the client system and confirm the errata updates:

[root@client ~]# yum list openssl openssl-libs

You can configure email notifications for Satellite users as described in Configuring Email Notifications in Administering Red Hat Satellite. Users can receive a summary of applicable and installable errata, notifications on Content View promotion or after synchronizing a repository.

This chapter provided some guidelines on how Red Hat Satellite 6 manage errata and applies them to systems.

The next chapter explores container management in Red Hat Satellite 6.

The Red Hat Container Catalog provides a set of container images that you can import into your Satellite Server. The process for importing this content differs to how we enable repositories for Red Hat content. The process is:

Click Save.

After creating the custom product, the product’s repositories screen appears. Click Create Repository, which displays a form for a new repository. Enter the following details:

Click Save. We return to the product’s repository screen with our new repository listed. Select it and click Sync Now to start the synchronization process. After a few minutes, Satellite Server completes the synchronization. Click Manage Docker Manifests to list the available manifests. From the list, you can optionally remove any manifests that are not required.

# hammer product create \
--name "Red Hat Container Catalog" \
--sync-plan "Example Plan" \
--description "Red Hat Container Catalog content" \
--organization "ACME"

Create the repository for the container images:

# hammer repository create \
--name "RHEL7" \
--content-type "docker" \
--url "http://registry.access.redhat.com/" \
--docker-upstream-name "rhel7" \
--product "Red Hat Container Catalog" \
--organization "ACME"

Then synchronize the repository:

# hammer repository synchronize \
--name "RHEL7" \
--product "Red Hat Container Catalog" \
--organization "ACME"

Now we have a synchronized set of container images.

In addition to importing container images from Red Hat Container Catalog, Red Hat Satellite 6 can also import content from other image registries, such as community-based or internal registries. The process for importing from third-party registries is the similar to importing images from the Red Hat Container Catalog:

The following procedure demonstrates how to accomplish this using the official Fedora images from the DockerHub registry (https://registry.hub.docker.com).

Click Save.

After creating the custom product for Fedora, the product’s repositories screen appears. Click Create Repository, which displays a form for a new repository. Enter the following details:

Click Save. We return to the product’s repository screen with our new repository listed. Select it and click Sync Now to start the synchronization process. After a few minutes, Satellite Server completes the synchronization. Click Manage Docker Manifests to list the available manifests. From the list, you can optionally remove any manifests that are not required.

# hammer product create \
--name "Fedora" \
--sync-plan "Example Plan" \
--description "Fedora content" \
--organization "ACME"

Create the repository for the container images:

# hammer repository create \
--name "Fedora/SSH" \
--content-type "docker" \
--url "https://registry.hub.docker.com" \
--docker-upstream-name "fedora/ssh" \
--product "Fedora" \
--organization "ACME"

Then synchronize the repository:

# hammer repository synchronize \
--name "Fedora/SSH" \
--product "Fedora" \
--organization "ACME"

Now we have a synchronized set of container images.

Use Content Views to manage container images across the application life cycle. This process uses the same publication and promotion method that RPMs and Puppet modules use.

Click Save to complete.

This creates a new Content View entry. Navigate to the Docker Content subtab, then click Add. Select the container repository for our Red Hat Enterprise Linux 7 Server image. Click Add Repository. This adds the container images from this repository 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 container image and click Save.

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

You can also click Promote to promote this Content View across environments in the application life cycle.

# hammer repository list --organization "ACME"

For our example, the container rhel7 repository uses 8 for its IDs. Create the Content View and add the repository:

# hammer content-view create \
--name "Containers" \
--description "Container image for Red Hat Enterprise Linux 7" \
--repository-ids 8 \
--organization "ACME"

Now publish the view:

# hammer content-view publish \
--name "Containers" \
--description "Initial content view for our container image" \
--organization "ACME"

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

Some of the container images use Docker tags to identify version numbers and basic information about each version.

# hammer docker tag info --id 218 --organization "ACME"

View a Docker tag using the tag ID:

# hammer docker tag info --id 218

This chapter provided a basic overview of managing container image content in Red Hat Satellite 6, including how to create your own registry and how to manage container images across the application life cycle.

The next chapter examines how to manage OSTree content.

In Satellite Server 6.3, OSTree management tools are enabled by default. If required, to ensure that they are enabled, enter the following command:

# satellite-installer --katello-enable-ostree=true

Red Hat’s CDN provides OSTree Content for you to select and synchronize.

Navigate to Content > Products and click on the Red Hat Enterprise Linux Atomic Host. This product now includes a repository for our Red Hat Enterprise Linux Atomic Host Trees branch set. Select this repository and click Sync Now.

After a few minutes, Satellite Server completes the import of all images relating to the rhel7 repository.

# hammer repository-set list \
--product "Red Hat Enterprise Linux Atomic Host" \
--organization "ACME" | grep "ostree"

Enable the ostree repository for Red Hat Enterprise Linux Atomic Host. In our example, the ID for this repository is 3822:

# hammer repository-set enable \
--product "Red Hat Enterprise Linux Atomic Host" \
--name "Red Hat Enterprise Linux Atomic Host (Trees)" \
--organization "ACME"

Find and synchronize the repository in our product. In our example, the ID for our version of the repository is 5:

# hammer repository list \
--product "Red Hat Enterprise Linux Atomic Host" \
--organization "ACME"
# hammer repository synchronize \
--name "Red Hat Enterprise Linux Atomic Host Trees" \
--product "Red Hat Enterprise Linux Atomic Host" \
--organization "ACME"

In addition to importing OSTree content from Red Hat’s CDN, Red Hat Satellite 6 also imports content from other sources. This requires a published HTTP location for the OSTree to import.

Click Save.

After creating the custom product for Fedora, the product’s repositories screen appears. Click Create Repository, which displays a form for a new repository. Enter the following details:

Click Save. We return to the product’s repository screen with our new repository listed. Select it and click Sync Now to start the synchronization process. After the a few minutes, Satellite Server completes the synchronization.

# hammer product create \
--name "OSTree Content" \
--sync-plan "Example Plan" \
--description "OSTree Content" \
--organization "ACME"

Create the repository for the OSTree:

# hammer repository create \
--name "Custom OSTree" \
--content-type "ostree" \
--url "http://www.example.com/rpm-ostree/" \
--product "OSTree Content" \
--organization "ACME"

Then synchronize the repository:

# hammer repository synchronize \
--name "Custom OStree" \
--product "OSTree Content" \
--organization "ACME"

Now we have a synchronized set of OSTree branches.

Use Content Views to manage OSTree branches across the application life cycle. This process uses the same publication and promotion method that RPMs and Puppet modules use.

Click Save to complete.

This creates a new Content View entry. Navigate to the OSTree Content subtab, then click Add. Select the OSTree repository for our Red Hat Enterprise Linux Atomic Host Trees. Click Add Repository. This adds the OSTree content from this repository 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 OSTree and click Save.

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

You can also click Promote to promote this Content View across environments in the application life cycle.

# hammer repository list --organization "ACME"

For our example, the OSTree repository uses 5 for its IDs. Create the Content View and add the repository:

# hammer content-view create \
--name "OSTree" \
--description "OSTree for Red Hat Enterprise Linux Atomic Host" \
--repository-ids 5 \
--organization "ACME"

Now publish the view:

# hammer content-view publish \
--name "OSTree" \
--description "Initial content view for our OSTree" \
--organization "ACME"

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

This chapter provided a basic overview of managing OSTree content in Red Hat Satellite 6, including how to import and synchronize your OSTree content from Red Hat and custom sources. This chapter also showed how to manage this content across the application life cycle.

The next chapter examines how to manage ISO files.

The Red Hat Content Delivery Network provides ISO images for certain products. The process for importing this content is similar to how we enable repositories for RPM content.

Navigate to Content > Products and click on Red Hat Enterprise Linux Server. The repository screen for this product appears. This product now includes a repository for our ISO image set. Select this repository and click Sync Now.

After a few minutes, Satellite Server completes the import of all chosen images.

# hammer repository-set list \
--product "Red Hat Enterprise Linux Server" \
--organization "ACME" | grep "file"

Enable the file repository for Red Hat Enterprise Linux 7.2 Server ISO:

# hammer repository-set enable \
--product "Red Hat Enterprise Linux Server" \
--name "Red Hat Enterprise Linux 7 Server (ISOs)" \
--releasever 7.2 \
--basearch x86_64 \
--organization "ACME"

Find and synchronize the repository in our product. In our example, the ID for our version of the repository is 40:

# hammer repository list \
--product "Red Hat Enterprise Linux Server" \
--organization "ACME"
# hammer repository synchronize \
--name "Red Hat Enterprise Linux 7 Server ISOs x86_64 7.2" \
--product "Red Hat Enterprise Linux Server" \
--organization "ACME"

This section provides a method to manually import ISO content and other files to Satellite Server. For this example, we upload a file called bootdisk.iso to Satellite Server. The process is similar to uploading custom Puppet modules:

Click Save.

After creating the custom product for our ISOs, the product’s repositories screen appears. Click Create Repository, which displays a form for a new repository. Enter the following details:

Click Save. We return to the product’s repository screen with our new Bootdisk repository listed. Click on the Bootdisk repository.

Navigate to the Upload File section and click Browse. Select the ISO file (bootdisk.iso in our example) and click Upload. After a few seconds, Satellite Server reports Content successfully uploaded.

# hammer product create \
--name "Custom ISOs" \
--sync-plan "Example Plan" \
--description "Custom ISO collection" \
--organization "ACME"

Create the repository:

# hammer repository create \
--name "Bootdisk" \
--content-type "file" \
--product "Custom ISOs" \
--organization "ACME"

Upload the ISO file to the repository:

# hammer repository upload-content \
--path ~/bootdisk.iso \
--name "Bootdisk" \
--product "Custom ISOs" \
--organization "ACME"

Now we have a custom repository that contains an ISO image.

Open Vulnerability and Assessment Language (OVAL) files contain information about public security content. Red Hat Satellite 6 uses OVAL files as part of its SCAP auditing process. Red Hat also provides a repository (https://www.redhat.com/security/data/oval/) that contains multiple OVAL files. Satellite Server can synchronize this repository so that you have local access to files for SCAP auditing.

Click Save.

After creating the custom product for our OVAL files, the product’s repositories screen appears. Click Create Repository, which displays a form for a new repository. Enter the following details:

Click Save. We return to the product’s repository screen with our new repository listed. Select this repository and click Sync Now.

# hammer product create \
--name "OVAL Files" \
--sync-plan "Example Plan" \
--description "OVAL file collections" \
--organization "ACME"

Create the OVAL repository:

# hammer repository create \
--name "Red Hat OVAL Files" \
--content-type "file" \
--product "OVAL Files" \
--publish-via-http true \
--url https://www.redhat.com/security/data/oval/ \
--organization "ACME"

Then synchronize the OVAL repository:

# hammer repository synchronize \
--name "Red Hat OVAL Files" \
--product "OVAL Files" \
--organization "ACME"

On a test Red Hat Enterprise Linux 7 system, install the openscap-scanner package, which contains the oscap tool:

# yum install openscap-scanner

Download a copy of the Red Hat Enterprise Linux 7 OVAL file from Satellite Server.

# cd /tmp
# wget http://satellite.example.com/pulp/isos/ACME-OVAL_Files-Red_Hat_OVAL_Files/Red_Hat_Enterprise_Linux_7.xml

Scan the test Red Hat Enterprise Linux 7 machine for vulnerabilities with the oscap tool:

# oscap oval eval \
--results results.xml \
--report report.html ./Red_Hat_Enterprise_Linux_7.xml

This performs the evaluation and generates an OVAL report with information on whether each definition is compliant or not.

This chapter provided a basic overview of managing ISOs and file content in Red Hat Satellite 6.

The next chapter examines completing the content management process.

This guide presented an end-to-end scenario involving a fictional company called ACME. Through this scenario, this guide has demonstrated how to achieve the following:

Satellite Server in our scenario now contains content managed across an application life cycle. Now we can provision systems in specific environments. Let’s look at how this happens when provisioning bare metal systems.

# hammer medium list --organization "your_organization"

# hammer template dump --name subscription_manager_registration

<%= snippet "subscription_manager_registration" %>