In this video, we will discuss the basics of patching and software management with Red Hat Satellite. Satellite helps you to define and manage a Standard Operating Environment, or SOE. Building an SOE includes two key things: defining your builds, your workloads, and your applications that run on Red Hat and figuring out how to best manage and integrate those apps in your organization by looking at the enterprise as a whole from the workloads, to the people who manage them, to your patching methodologies. That way when it is time to build out new servers you have the tools and the processes in place to quickly create those environments.

In turn, this enables you to quickly respond to security vulnerabilities such as Heartbleed and ShellShock. Once you have your SOE built, it is really easy for you just to take and quickly patch those environments and keep them up to date. This, in turn, helps you comply with your organization's security policies. Security gets a lot easier when you know exactly what is on your system and what systems need to be patched.

And finally, Satellite makes it really easy to not only deploy Red Hat software, but pretty much any third-party software.Once you add a product into Satellite, Satellite owns that content and keeps track of it. 

Now we will jump into our demo environment and will show you how to patch existing systems, as well as how to create a custom product and leverage that within Satellite. We will start by looking at the hosts that we already have in our environment. We will then apply a patch to one host, and then we will look at how to apply patches to many hosts. I will start by going Hosts > Content Hosts. When we see a list of Content Hosts, notice in the Installable Updates column that there are several different categories of updates that are available. We have Security, Bug Fixes, Enhancements and Package Updates.

We are going to start by looking at the most important, which is your Security Updates. I am going to click right on the host itself, where you can see more details about the hosts. Then notice we have the same section in the upper right under Installable Errata. I will click on the Security category. And it will show me a list of security errata that are available. To get more details, click on any errata that you like. It is going to show you all the information such as your Description, your Solution, and the Packages that are affected.

I will go back to the Errata list and you can select one or more of the errata that you want to apply and simply click Apply Selected. Confirm that you want to apply it, and in a matter of moments, your errata is applied to your host. That is really simple for one host, but obviously you do not want to go on every host one at a time like this so let’s take a look at how you would apply an errata to a group of hosts.

We go to Content > Errata and note under the Content Host Counts column we have a list of how many hosts are applicable as well as installable. So, if I click on this errata, I can see in the Content Hosts view that it affects four of my five hosts. I will go back to the Errata list and to apply, simply select one or more errata then click Apply Errata. Select the hosts that you want to apply it on, click Next and Confirm.

Again, in a matter of moments your errata is applied to your hosts and to confirm this you can go to Monitor > Tasks and you can see the details of where the errata has been applied. So, hopefully you can see how this would be really easy if you have something like Heartbleed or ShellShock, you can quickly identify which hosts are affected by the errata and apply them to those hosts.

Next let’s look at a third-party piece of software and how we would create that within Satellite. To add a custom piece of software into Satellite we are going to use the EPEL repository. We have a Knowledgebase entry on how to do this within Satellite, so essentially, I am just going to follow the steps within this knowledgebase. I am pointing it out for your reference. I am not going to follow it line by line.

Since the EPEL software package uses GPG, the first thing we need to do is add a content credential into Satellite. Select Content > Content Credentials. I don’t currently have any created so I am going to click Create Content Credential. We will name this EPEL. It is a GPG Key and the key itself is located on the Fedora page. I will paste that key right into the page and click Save. 

Next thing we are going to do is create a Product. It is under Content > Products. As you can see, we already have a variety of products that are listed here that are Red Hat products but now we are going to create our own third-party custom product. We will again call this EPEL. We will point it out at our EPEL GPG Key, and you can provide any Description that you like. Click Save. That’s created our product as a category but we still need to create a repository to associate this with.

So, I will click New Repository. This is the EPEL_REPO, it’s yum software. I am going to restrict that to the x86 architecture. In my Upstream URL, I have open here my browser, and my GPG Key is EPEL. A lot of this other information is there because depending on the piece of custom content that you are adding, you may or you may not need to provide those items. I am going to unclick Verify SSL, and then click Save.

So, I have not provided any software, uploaded any package, but it did provide a URL where that content can be synchronized. So, the next step is to sync the repository. Select the box and click Sync Now. This will take a few minutes but thanks to the magic of video it has been sped up for you. As you can see we got a success message which means we have synced the repository from the non-Red Hat software into our Satellite environment. If I return to the products page I can see the EPEL_REPO with a success and the content of that repository.

So, that gets the software into Satellite, how do we get that out to your hosts? We do that using a concept that we call content views. The content view is a managed selection of content that contains one or more repositories. To create a content view we go to Content > Content Views. As you can see, we already have a couple of views that have been created. But we will create a new view that has our EPEL repository. We call this EPEL. I am not going to select the composite view or the auto publish at this time. I will click Save. And under Yum Content I am going to add the EPEL_REPO so that’s the only thing that is contained within this repository. I could absolutely add more content if I wanted. Notice the Publish New Version button at the top. If I wanted to go ahead and publish this content view and make it available to hosts, that’s how I would do it. But I am not going to do it quite yet. I am going to return to the Content Views page and I am going to create a second view.

This time I will create what is known as a composite content view. I am going to create a view that has both the content from RHEL as well as the content from EPEL. That way when I send that content view out to a host it will get all of the content from both of these content views. That is known as a Composite View and I will select the Auto Publish button. That way when a content view, either the RHEL or the EPEL content view is updated, it will automatically publish this composite content view. So, click Save. I am going to include EPEL and RHEL7 content views into my composite content view.

Again, I am not going to publish the view at this time, I am going to return to my Content Views. Notice that EPEL is not yet published and RHEL+EPEL is also not yet published. So, if I return to my EPEL repository and I click Publish New Version, I can enter any sort of Description that I want. It already has Version 1.0 so as I make changes to this repository it will increment the version number. I will click Save. And this will start the process of publishing and promoting the content view.

So, I successfully published version 1.0 of the EPEL repository into my library environment. Satellite also has the concept of life cycle environments so this is currently in the library but as I move along and test this out I can move it into a Q and A type environment, or a development environment, or a production environment. And I can continually promote these different content views into matching life cycle environments.

If I return back to the main Content Views page, I had published the EPEL repository but note that the RHEL+EPEL also was successfully published. That is because this composite content view had auto publish enabled. So, that handles getting the content into Satellite, adding the content to a content view, but now let’s make it available to our hosts.

We will do that by going Hosts > Content Hosts then I can select one of these hosts. Then notice under the Content View currently it is set to RHEL7. I can edit that and change it to the RHEL+EPEL content view that we just created, so that assign the appropriate content view. But to sync the packages, we go to Packages > Actions then select Update All Packages. 

And that process applied all of the packages from the RHEL content view as well as from the EPEL content view. So, you can see with added a whole bunch of new packages to this host, both Red Hat and non-Red Hat.

As a recap of this video, we started by patching a single host, just adding one errata to that host. We then showed how to go on to the errata section, find a particular errata, figure out what hosts that errata applies to, and apply that errata to all of the applicable hosts. We then created a new product pointed at a repository for EPEL, synced that repository of non-Red Hat software into Satellite, created a content view as well as a composite content view to make that content available to hosts. Then we updated all the packages. So, this package now has both RHEL as well as non-RHEL software managed through Satellite. That concludes this section. See you in the next video.