Walkthrough: Setting up and managing an online patch catalog for Linux

This topic walks you through the process of setting up a patch catalog for a Red Hat Linux. It also explains how to set up a smart group that automatically selects a subset of the patches in the patch catalog.

This topic includes the following sections:

The video at right demonstrates the process of setting up a patch catalog for Linux.

https://youtu.be/fLkd8eJBEoQ

Introduction

This topic is intended for system administrators who are tasked with managing patches. The goal of this topic is to demonstrate how to organize patch information by setting up a central location for storing metadata about a type of patch. BladeLogic calls these locations patch catalogs. By creating patch catalogs customized to your needs, it becomes easier to select the patches you want to evaluate on servers throughout your data center.

What is a patch catalog?

A patch catalog provides a place to store metadata about patches and the patch payloads themselves. Patch catalogs can be designed for specific needs. For example, a patch catalog can be used for a particular operating system, such as Red Hat Linux 6.0. With well designed patch catalogs, it is easier to select the patches that are used when evaluating the patch configuration of designated servers.

After you have created a patch catalog, you can create patch catalog smart groups, which can be dynamically populated with patches from the patch catalog that meet certain criteria. This smart group can be used as a filter during a Patching Job to determine whether patches in the group are missing on target servers.

What does this walkthrough show?

This walkthrough shows how to use the TrueSight Server Automation Patch Catalog wizard to create a job that obtains patches from the Red Hat network.

The job sets up notifications for the administrator in charge of Linux patching if the Patch Catalog job should fail. The job is scheduled to run monthly to obtain the latest patches.

This walkthrough also shows how to set up a patch smart group that automatically selects patches from the patch group that are critical security advisories.

What do I need to do before I get started?

Ensure that you complete the following pre-requisite steps prior to creating a patch catalog for Linux platforms:

For this walkthrough, you need various authorizations. You can log in and perform these tasks as BLAdmin, the TrueSight Server Automation superuser, but BMC recommends a more restrictive approach to granting authorizations. Ideally, you should set up a role that is granted only the authorizations needed for patch management. To learn how to restrict access, see Walkthrough: Restricting permissions for a patching administrator.
You must know which server you want to use as a patch repository.

For RHEL 7

For Red Hat Enterprise Linux 7, you must also:

Ensure that the following packages are pre-installed on the server that hosts the patch repository:
- reposync (part of the yum-utils rpm) - For RHEL 7, you perform RHEL patching using the more advanced CDN (reposync) interface.
- createrepo
- python-urlgrabber
Have an account with the Red Hat Network from which you can obtain patch data.
Obtain the required certificates.

See Creating a patch catalog for Red Hat Enterprise Linux for the detailed steps.

As CDN is supported for TrueSight Server Automation 8.9.02 and later, this note is applicable for all RHEL filters.

How to set and manage a patch catalog for UNIX

	Step	Example screen
1	Log on as BLAdmin or preferably as PatchingUser. PatchingUser is the user account that was set up in Walkthrough: Restricting permissions for a patching administrator. Expand the Depot folder and navigate to a subfolder where you want to create a patch catalog. Right-click the subfolder and select New > Patch Catalog > Red Hat Linux Patch Catalog. The New Patch Catalog panel opens. For Name, enter a name for the patch catalog you are creating. For example, enter `Red Hat 6 x86_64`. Under Catalog Mode, make sure Source From Vendor (Online Mode) is selected. Working in online mode obtains patch data directly from the Red Hat Network. Under Red Hat Network Credentials, enter a user name and password that has been granted access to the Red Hat Network. These fields may be completed dynamically if your organization has globally configured patch access. Note: The Red Hat Network (RHN) mode has been deprecated in TrueSight Server Automation 8.9.02, you do not have to enter credentials in the new CDN mode, which is used by default while creating a Red Hat Patch catalog. TrueSight Server Automation 8.9.02 and later versions do not require input of credentials. For Repository Location (NSH Path), enter a location on a Linux platform where patch information can be stored. This location must have ample free space–typically many gigabytes. Enter the location using a Network Shell-style path.	For 8.9.00 and 8.9.01 For 8.9.02 and later
2	Click Add Filter and make the following settings on the Add Red Hat Filter dialog box. Select RHN (xmlrpc). Note: The Red Hat Network (RHN) mode has been deprecated in TrueSight Server Automation 8.9.02. The new CDN mode is used by default while creating a Red Hat Patch catalog. TrueSight Server Automation 8.9.02 and later versions do not require input of credentials. For Channel, select a channel from the list provided. Select By Errata Type. Leave all the sub-options selected. Click OK. The filter is then added to the new patch catalog.	For 8.9.00 and 8.9.01 For 8.9.02 and later
3	Optionally, you can schedule a job to execute immediately, schedule a job at a specific time in the future, schedule a job on a recurring basis, and define notifications that are issued when a job runs. Scheduling is not essential because you can also trigger a Catalog Update Job manually. In production environments, however, BMC recommends that you schedule the job to ensure that a catalog always has the most recent patches. In this example, we set up the job to run immediately and also to run on the first Tuesday of every month afterwards. Click Job Options. Click Schedules. Select Execute job now to indicate the job should run as soon as you save the window. Click New Schedule and define the a job schedule. In this example, we want to schedule it to update Tuesday mornings. You may want to use a different time, day, or even update less often. Click Monthly. Select First and Tuesday. Enter a time, such as 08:00.
4	Updating the patch catalog is an important task, so if there's a problem, someone will want to know about it. For email notifications to be sent, a mail server must be configured for the Application Server. This step is only required if you want to receive a notification email when this job runs. Click Scheduled Job Notifications. Select Send email to. Enter an email address of someone to be notified if this job fails. Separate multiple email addresses with semicolons, such as `sysadmin@bmc.com;sysmgr@bmc.com`. Check one or more statuses that will generate an email, for example, Failed. Select Send SNMP trap to. When a job completes, an SNMP trap is sent to a specified server, where it can be read using software that receives and interprets SNMP traps. Enter a server name or IP address. Check one or more options, for example, Failed. Click OK.
5	Optionally, you can define default notifications that are generated when a job completes. If you have set up notifications for a particular scheduled job, those notifications are generated instead of default notifications. Click Job Run Notifications. Select Send email to. Enter an email address of someone to be notified if this job fails. Separate multiple email addresses with semicolons, such as `sysadmin@bmc.com;sysmgr@bmc.com`. Check one or more statuses that will generate an email, for example, Failed. Select Send SNMP trap to. When a job completes, an SNMP trap is sent to a specified server, where it can be read using software that receives and interprets SNMP traps. Enter a server name or IP address. Check one or more options, for example, Failed.
6	Click Depot Object Options. Make sure that Network URL Type for Payload Deployment is set to Copy To Agent At Staging. This setting means TrueSight Server Automation copies patch payloads from the patch repository to a staging directory on the target server when you are deploying patches. For Network URL for Payload Deployment, enter a location on a Linux platform where the payload deployment information can be stored. This location must have ample free space–typically many gigabytes. Enter the location using a Network Shell-style path. For RBAC Policy, browse to and select a predefined ACL Policy. Permissions defined by the ACL Policy are assigned to all Depot objects created in the catalog. For Max Depot Object Work Items to process in parallel, you can set the maximum number of work items that can be performed in parallel. The default is 15.
7	You can specify a list of properties automatically assigned to a job. In this list, you can modify the value of any properties that are defined as editable. Click Job Properties. Select a property and click to edit the value.
8	You can add individual permissions to a job. You can also set permissions by adding ACL templates or ACL policies. ACLs control access to all objects, including the sharing of objects between roles. Click Permissions. Under Access Control List, add a new authorized role or delete a role as needed. Under ACL Policies, add a new group policy or replace the ACL with selected policies as needed. Click OK to save your changes and close the window.
9	Click Finish. The Patch Catalog Job starts running. You can watch its progress on the Tasks in Progress pane.
10	When the job completes, you can use the Depot folder and navigate to the location where you created the patch catalog. You selected this location in the first step. Right-click the catalog, and select Open. The pane at right show the definition of the patch catalog job. Click the Results tab. A green check indicates the job ran successfully.
11	Create a patch smart group for security patches. Right-click the patch catalog you just created and select New > Patch Catalog Smart Group. A wizard for creating smart groups opens. For Name, enter a name for the patch catalog smart group, such as `Production Patch Policy`. In the list of conditions, take the following steps: In the first column, select Redhat Errata. In the second column, select ERRATA_TYPE In the third column, select equals. In the fourth column, select Security Advisory. Taken together, the row should read "Any Redhat Errata where ERRATA_TYPE equals Security Advisory." In the fifth column, select AND. Click Apply Changes . Click Add New Condition . Double-click the row representing the new condition and enter the following information: In the first column, select Redhat Errata. In the second column, select ERRATA_SEVERITY. In the third column, select equals. In the fourth column, select Critical. Taken together, the row should read "Any Redhat Errata where ERRATA_SEVERITY equals Critical." Click Apply Changes. Click Finish. A new smart group collects all Red Hat patches that are critical security advisories.

Wrapping it up

Congratulations. You have set up a job that creates a patch catalog for Red Hat Linux 6. The job will run monthly and obtain the latest patches from the Red Hat Network. If the job fails for any reason, an email notification is sent You have also learned how to create a patch catalog smart group so you can easily group all patches that are critical security advisories.

Where to go from here

Now that you have a serviceable patch catalog it is time to use it to test your Linux servers for patch compliance. See Walkthrough: Basic Red Hat Linux patch analysis.