Content Lifecycle Management Examples

This section contains some common examples of how you can use content lifecycle management. Use these examples to build your own personalized implementation.

1. Creating a Project for a Monthly Patch Cycle

An example project for a monthly patch cycle consists of:

  • Creating a By Date filter

  • Adding the filter to the project

  • Applying the filter to a new project build

  • Excluding a patch from the project

  • Including a patch in the project

1.1. Creating a By Date filter

The By Date filter excludes all patches released after a specified date. This filter is useful for your content lifecycle projects that follow a monthly patch cycle.

Procedure: Creating the By Date Filter

  1. In the Uyuni Web UI, navigate to Content Lifecycle  Filters and click Create Filter.

  2. In the Filter Name field, type a name for your filter. For example, Exclude patches by date.

  3. In the Filter Type field, select Patch (Issue date).

  4. In the Matcher field, later or equal is autoselected.

  5. Select the date and time.

  6. Click Save.

1.2. Adding the Filter to the Project

Procedure: Adding a Filter to a Project

  1. In the Uyuni Web UI, navigate to Content Lifecycle  Projects and select a project from the list.

  2. Click Attach/Detach Filters link to see all available filters

  3. Select the new Exclude patches by date filter.

  4. Click Save.

1.3. Applying the Filter to a New Project Build

The new filter is added to your filter list, but it still needs to be applied to the project. To apply the filter you need to build the first environment.

Procedure: Using the Filter

  1. Click Build to build the first environment.

  2. OPTIONAL: Add a message. You can use messages to help track the build history.

  3. Check that the filter has worked correctly by using the new channels on a test server.

  4. Click Promote to move the content to the next environment. The build takes longer if you have a large number of filters, or they are very complex.

1.4. Excluding a Patch from the Project

Tests may help you discover issues. When an issue is found, exclude the problem patch released before the by date filter.

Procedure: Excluding a Patch

  1. In the Uyuni Web UI, navigate to Content Lifecycle  Filters and click Create Filter.

  2. In the Filter Name field, enter a name for the filter. For example, Exclude openjdk patch.

  3. In the Filter Type field, select Patch (Advisory Name).

  4. In the Matcher field, select equals.

  5. In the Advisory Name field, type a name for the advisory. For example, SUSE-15-2019-1807.

  6. Click Save.

  7. Navigate to Content Lifecycle  Projects and select your project.

  8. Click Attach/Detach Filters link, select Exclude openjdk patch, and click Save.

When you rebuild the project with the Build button, the new filter is used together with the by date filter we added before.

1.5. Including a Patch in the Project

In this example, you have received a security alert. An important security patch was released several days after the first of the month you are currently working on. The name of the new patch is SUSE-15-2019-2071. You need to include this new patch into your environment.

The Allow filters rule overrides the exclude function of the Deny filter rule. For more information, see Content Lifecycle Management.
Procedure: Including a Patch in a Project

  1. In the Uyuni Web UI, navigate to Content Lifecycle  Filters and click Create Filter.

  2. In the Filter Name field, type a name for the filter. For example, Include kernel security fix.

  3. In the Filter Type field, select Patch (Advisory Name).

  4. In the Matcher field, select equals.

  5. In the Advisory Name field, type SUSE-15-2019-2071, and check Allow.

  6. Click Save to store the filter.

  7. Navigate to Content Lifecycle  Projects and select your project from the list.

  8. Click Attach/Detach Filters, and select Include kernel security patch.

  9. Click Save.

  10. Click Build to rebuild the environment.

2. Update an Existing Monthly Patch Cycle

When a monthly patch cycle is complete, you can update the patch cycle for the next month.

Procedure: Updating a Monthly Patch Cycle

  1. In the by date field, change the date of the filter to the next month. Alternatively, create a new filter and change the assignment to the project.

  2. Check if the exclude filter for SUSE-15-2019-1807 can be detached from the project. There may be a new patch available to fix this issue.

  3. Detach the allow filter you added previously. The patch is included by default.

  4. Rebuild the project to create a new environment with patches for the next month.

3. Enhance a Project with Live Patching

This section covers setting up filters to create environments for live patching.

When you are preparing to use live patching, there are some important considerations

  • Only ever use one kernel version on your systems. The live patching packages are installed with a specific kernel.

  • Live patching updates are shipped as one patch.

  • Each kernel patch that begins a new series of live patching kernels displays the required reboot flag. These kernel patches come with live patching tools. When you have installed them, you need to reboot the system at least once before the next year.

  • Only install live patch updates that match the installed kernel version.

  • Live patches are provided as stand-alone patches. You must exclude all regular kernel patches with higher kernel version than the currently installed one.

3.1. Exclude Packages with a Higher Kernel Version

In this example you update your systems with the SUSE-15-2019-1244 patch. This patch contains kernel-default-4.12.14-150.17.1-x86_64.

You need to exclude all patches which contain a higher version of kernel-default.

Procedure: Excluding Packages with a Higher Kernel Version

  1. In the Uyuni Web UI, navigate to Content Lifecycle  Filters, and click Create Filter.

  2. In the Filter Name field, type a name for your filter. For example, Exclude kernel greater than 4.12.14-150.17.1.

  3. In the Filter Type field, select Patch (Contains Package).

  4. In the Matcher field, select version greater than.

  5. In the Package Name field, type kernel-default.

  6. Leave the the Epoch field empty.

  7. In the Version field, type 4.12.14.

  8. In the Release field, type 150.17.1.

  9. Click Save to store the filter.

  10. Navigate to Content Lifecycle  Projects and select your project.

  11. Click Attach/Detach Filters.

  12. Select Exclude kernel greater than 4.12.14-150.17.1, and click Save.

When you click Build, a new environment is created. The new environment contains all the kernel patches up to the version you installed.

All kernel patches with higher kernel versions are removed. Live patching kernels remain available as long as they are not the first in a series.

This procedure can be automated using a filter template. For more information on how to apply a live patching filter template, see administration:content-lifecycle.adoc#filter-templates.

4. Switch to a New Kernel Version for Live Patching

Live Patching for a specific kernel version is only available for one year. After one year you must update the kernel on your systems. Execute these environment changes:

Procedure: Switch to a New Kernel Version

  1. Decide which kernel version to upgrade to. For example: 4.12.14-150.32.1

  2. Create a new kernel version Filter.

  3. Detach the previous filter Exclude kernel greater than 4.12.14-150.17.1 and attach the new filter.

Click Build to rebuild the environment. The new environment contains all kernel patches up to the new kernel version you selected. Systems using these channels have the kernel update available for installation. You need to reboot systems after they have performed the upgrade. The new kernel remains valid for one year. All packages installed during the year match the current live patching kernel filter.

5. AppStream Filters

In a content lifecycle management project, you can use the AppStream filter to transform modular repositories into regular repositories. It does this by keeping the packages in the repository and stripping away the module metadata. The resulting repository can be used in Uyuni in the same way as a regular repository.

AppStream repositories are natively supported throughout the Web UI.

Therefore, this process is not mandatory to work with AppStream repositories.

The AppStream filter selects a single module stream to be included in the target repository. You can add multiple filters to select multiple module streams.

If you do not use an AppStream filter in your CLM project, the module metadata in the modular sources remains intact, and the target repositories contain the same module metadata. As long as at least one AppStream filter is enabled in the CLM project, all target repositories are transformed into regular repositories.

In some cases, you might wish to build regular repositories without having to include packages from any module. To do so, add an AppStream filter using the matcher none (disable modularity). This will disable all the modules in the target repository. This is especially useful for Red Hat Enterprise Linux 9 clients, where the default versions of most modules are already included in the AppStream repository as regular packages.

To use the AppStream filter, you need a CLM project with a modular repository such as Red Hat Enterprise Linux AppStreams. Ensure that you included the module you need as a source before you begin.

Procedure: Using AppStream Filters

  1. In the Uyuni Web UI, navigate to your Red Hat Enterprise Linux 8 or 9 CLM project. Ensure that you have included the AppStream channels for your project.

  2. Click Create Filter and use these parameters:

    • In the Filter Name field, type a name for the new filter.

    • In the Filter Type field, select Module (Stream).

    • In the Matcher field, select equals.

    • In the Module Name field, type a module name. For example, postgresql.

    • In the Stream field, type the name of the desired stream. For example, 10. If you leave this field blank, the default stream for the module is selected.

  3. Click Save to create the new filter.

  4. Navigate to Content Lifecycle  Projects and select your project.

  5. Click Attach/Detach Filters, select your new AppStream filter, and click Save.

You can use the browse function in the Create/Edit Filter form to select a module from a list of available module streams for a modular channel.

Procedure: Browsing Available Module Streams

  1. In the Uyuni Web UI, navigate to your Red Hat Enterprise Linux 8 or 9 CLM project. Ensure that you have included the AppStream channels for your project.

  2. Click Create Filter and use these parameters:

    • In the Filter Name field, type a name for the new filter.

    • In the Filter Type field, select Module (Stream).

    • In the Matcher field, select equals.

  3. Click Browse available modules to see all modular channels.

  4. Select a channel to browse the modules and streams:

    • In the Module Name field, start typing a module name to search, or select from the list.

    • In the Stream field, start typing a stream name to search, or select from the list.

Channel selection is only for browsing modules. The selected channel is not be saved with the filter, and does not affect the CLM process in any way.

You can create additional AppStream filters for any other module stream to be included in the target repository. Any module streams that the selected stream depends on is automatically included.

Be careful not to specify conflicting, incompatible, or missing module streams. For example, selecting two streams from the same module is invalid.
Procedure: Disabling Modularity

  1. In the Uyuni Web UI, navigate to your Red Hat Enterprise Linux 8 or 9 CLM project. Ensure that you have included the AppStream channels for your project.

  2. Click Create Filter and use these parameters:

    • In the Filter Name field, type a name for the new filter.

    • In the Filter Type field, select Module (Stream).

    • In the Matcher field, select none (disable modularity).

  3. Click Save to create the new filter.

  4. Navigate to Content Lifecycle  Projects and select your project.

  5. Click Attach/Detach Filters, select your new AppStream filter, and click Save.

This will effectively remove the module metadata from the target repository, excluding any package that belongs to a module.

When you build your CLM project using the Build button in the Web UI, the target repository is a regular repository without any modules, that contains packages from the selected module streams.

Disabling modularity altogether in Red Hat Enterprise Linux 8 projects might result in a faulty environment as some modules are essential for healthy operation in Red Hat Enterprise Linux 8.