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.
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 |
| For 8.9.00 and 8.9.01 For 8.9.02 and later |
2 |
| 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.
| |
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.
| |
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.
| |
6 |
| |
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.
| |
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.
| |
9 | Click Finish. | |
10 |
| |
11 | Create a patch smart group for security patches.
|
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.
Comments