Managing Red Hat Satellite | Content

Satellite 6.4
Red Hat Satellite

Lifecycle Environments | Content Views | Activation Keys

In our previous post, we discussed how to attach Red Hat entitlements, set up initial repositories, sync our content and set up a daily sync plan. This will give you the basics you need for managing Red Hat Satellite Servers, however in most cases we want to expand upon the features that Satellite provides by utilizing lifecycle environments, content views, and activation keys. So, let us get started with Lifecycle Environments.

Initial GUI when logging into Satellite 6.4

Lifecycle Environments

So what exactly is a lifecycle environment?

Application life cycles are divided into life cycle environments, which represent each stage of the application life cycle. Life cycle environments are linked to form an environment path. You can promote content along the environment path to the next life cycle environment when required. For example, if development ends on a particular version of an application, you can promote this version to the testing environment and start development on the next version.

Red Hat

We add a lifecycle to our environment by going to Content > Lifecycle Environments.

The various options within the Content menu in Satellite.

Creating the lifecycle environment

On a new Satellite server, you will only see Library in your Lifecycle path. By default, this is created, and all hosts registered to Satellite will have access to it. Smaller environments may be able to get away with keeping it this way, however, it is recommended to build out an environment based on your own development lifecycle. For example: DEV > QA > PROD. To get started, just click on Create Environment Path.

Creating a Lifecycle Environment.

You will begin by adding your first environment in which you wish to promote content through. Generally, this is a TEST or DEV environment. You will send your new ERATTA, REPOS, and the like first into DEV, in which servers that are in this DEV lifecycle can then best tested with these patches, and software that is installed. Once everything checks out you know it is safe to promote to the next lifecycle, which could be QA, or end PROD in some environments. You are then assured you will not have adverse effects from a patch cycle in PROD as it was previously tested while in DEV and even QA.

Adding configuration details to the enviornment

Continuing on in our example, we fill in the details of our environment. Whatever makes sense for your organization. Once you are done, click on Save.

Adding the details for your lifecycle environment.

You will then see your first lifecycle, it currently holds 0 content views and content hosts. Those will be added later.

Newly created lifecycle environment.

Finish your lifecycle path by repeating the previous steps, adding QA, and PROD.

All the lifecycle paths are now created. DEV > QA > PROD” class=”wp-image-2127″/></figure>



<h3 class=Content Views

Content views are managed selections of content, which contain one or more repositories (yum, puppet, or containers) with optional filtering. These filters can be either inclusive or exclusive, and tailor a system view of content for life cycle management. They are used to customize content to be made available to client systems.

Red Hat

Our next step in managing Red Hat Satellite is with content views. One example of why you would use a content view is with patching different types of RHEL Servers. You may not want a file server to have access to packages that are required for a web server. You may need to have higher versions of PHP, Python or such on your web server, so you will have Red Hat Software Collections or third-party repositories to have specific versions of PHP on your web server. By adding those repositories to a specific content view, which is then attached to an activation key you can have these packages visible to just your web server, while your file server or database server would have their own role specific repositories.

To create a content view, just go to Content > Content Views > Create New View.

Creating a Content View in Satellite 6.4

Naming the content view

Give it a name, I like prefixing things within Satellite with CV or AK (content view, or activation key). This way you notice what it is at a glance by the prefix. Fill in the remainder of the information, and then click on Save.

Details of the content view.

Adding yum content to your view

Next, you will need to attach yum content to your view. We only have RHEL 7 and Satellite Tools. As both are needed for a base RHEL server, we will add both to our content view. In a production environment you will likely have many other products, just choose the ones that are required for this view, which you plan to attach to specific servers. Once you have them selected, click on Add Repositories.

Adding yum content to the content view.

Once added you need to publish your content to the appropriate lifecycle environment. At the least, you will need to publish to library. Generally, though you will continue to your first lifecycle, in our case DEV. It is good practice to add a description as to what you are doing and why. Once you are ready, click on Save.

Try to give a description to your content view promotions.

Initial content view publish

It will take time, especially the more repositories you have in the content view, for the initial publish into library. Just be patient.

Content view during initial publishing.

Content view ready to promote

Once it is finished, you will see the initial environment, as well as how many packages, and errata are available in your content view. This is helpful when publishing future content view revisions, as this number will change with each itteration as your daily sync will download new packages and errata over time. To gain access to those new packages after this initial publish, you will need to republish your content view again, and move it through the lifecycle enviornment.

Content view is now ready with all packages available.

We finish by promoting our content view one more time, this time into DEV. With an initial publish, you will usually push it all the way into Prod, as if you don’t the production servers will not have any content to install.

Promoting the content view into the DEV lifecycle.

Activation Keys

Activation keys define selected properties of content hosts. You can use activation keys during content host registration to improve the speed, simplicity and consistency of the process. Activation can specify:

– Associated subscriptions and subscription attach behavior.
– Available products and repositories.
– A life cycle environment and a content view.
– Host collection membership.

Red Hat

Activation Keys will make managing a Red Hat Satellite server more efficitent. To create an activation key, we go to Content > Activation Keys > Create Activation Key.

Creating an Activation Key in Satellite 6.4

Naming conventions for Activation Keys

Name the key (I like prefixing, so AK-) based on the role of servers you will be registering with that AK. If they are simple RHEL servers, give them a name such as I have. However, you can customize them further by naming them Web Servers, Database Servers, etc. Just so it is clear what they will be registering so you can connect them to the appropriate server while registering. You also need to choose what environment that server will be placed in. In this example, I want RHEL 7 Servers that will be in the DEV lifecycle. I guess a better naming convention would have been AK-RHEL7-DEV-Servers. When you are finished, just click on Save.

Details of the Activation Key, and what lifecycle it will be connected to.

Setting the release version of RHEL

By default, the release version let us blank. Which you can keep it as, or you can set the release version based on what products you have attached. In my case, as I used the main RHEL7 repository, I can set the servers for 7Server, which will allow my servers to upgrade to each z stream of 7 as it comes out. It will, however, hold them at 7 and not allow them to upgrade to 8. Which in reality it would be unable to do without the RHEL 8 repos attached to the content view/activation key combination.

Setting the release version of Red Hat Server in the activation key.

Entitlements

Next, we need to attach our entitlements to this AK, this will hand out the required number for each server that uses this activation key. So, select the subscription tab, choose the Add sub tab, then choose the entitlements that are needed. Then choose Add Selected.

Adding the entitlements to your activation key.

Finally we need to choose which repositories are enabled or disabled by default when a server is registered via the Activation Key. By deafult, Satellite Tools is disabled. Choose Satellite Tools, then Select Actions, here we can choose Override to Enabled. If you wish to disable a repository by default, you can set it to override to disable.

Enabling Satellite tools within the activation key.

How to use your activation key

You will see the results below. And that about does it. We now have a lifecycle enviornment, a content view, and an activation key. We are ready to register our first server into our enviornment. This will be discussed in our next article. To use the activation key, you will see the synatax of it in the Details tab.

# subscription-manager register --org="ACME" --activationkey="AK-RHEL7-Servers"
The finished activation key, ready to register new RHEL servers.

What’s next?

Our next article will cover registering an already built or manually installed RHEL server into our Satellite environment. Later we will cover provisioning. I hope this acticle has helped in understanding further how to manage a Red Hat Satellite server.

Share

Ivan Windon

Ivan Windon is a Site Reliability Engineer at IBM. Ivan is actively engaged in Cloud Technologies with AWS, Google, and Azure. Ivan has extensive experience with Linux and Windows administration, DNS, Networking, IDM, and Security. In his free time, he enjoys being with his wife and two children. The family enjoys hiking, and traveling when able. His favorite locations are Yosemite NPS, and San Francisco, California.

You may also like...

1 Response

  1. denzel baker says:

    Hello Ivan,

    I hope you’re doing well

    Thanks for the post, I have some questions please :

    I still don’t understand the Entitlements part:
    Next, we need to attach our entitlements to this AK, this will hand out the required number for each server that uses this activation key. So, select the subscription tab, choose the Add sub tab, then choose the entitlements that are needed. Then choose Add Selected.

    Because I found it in every tutorial about Foreman/Satellite Activation_Key for CentOS/Red Hat.
    Example in CLI:
    hammer subscription list –organization myorg.lan

    hammer activation-key add-subscription –organization myorg.lan –name ‘CentOS8_Key’ \
    –quantity ‘1’ –subscription-id 1

    Why we have to do those steps ?
    If we don’t do that. the Activation Key could not be used for registering client to Foreman/Satellite ? Or we could use it but if we open the redhat.repo file, it will be blank (without any repo) or something else ?

    And what does the option –quantity ‘1’ mean ?
    Does this mean that we can register one client only even if we used this option during Activation Key creation : –unlimited-hosts or something else ?

    2nd question: Let’s say that we have Products, Repos, CV, AK and everything is configured, but after a while we decide to add another repo :

    After doing all th necessary steps and adding a repo to a CV and publish/promote it, how it will appear on already registered client (normally added to redhat.repo file in every client machine) (should we reexecute subscription-manager or something else ?)

    Thanks in advance !

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: