Creating a patch catalog for CentOS or OL ULN



Related BMC Communities article

BMC Customers using Automation for Patching use cases depend on OS vendors for Patches and metadata. To view a document that tracks the service status of the different OS Vendors as known to BMC Support, see the following BMC Communities document:

OS Patching Vendor Health Dashboard

The patch catalog is used to maintain and work with the patch repository through the TrueSight Server Automation console. For both online and offline repositories, you create a patch catalog using the TrueSight Server Automation console. Patches are added to the catalog as depot objects according to filters defined for the catalog.

This topic describes how to set up a patch catalog for CentOS or OL ULN and includes the following sections:

Prerequisites for the catalog

Ensure that the following prerequisites are met:

  • You must pre-install the following packages on the server that hosts the patch repository:
    • reposync (part of the yum-utils rpm) 
    • createrepo
    • python-urlgrabber
    • bzip2
    • (For OL ULN) yum or dnf
  • If you plan to use a Proxy server for the CentOS or OL ULN patch catalog in TrueSight Server Automation, review the Proxy Server options described in Global-Configuration-parameter-list.

Creating a patch catalog

Do the following:

  1. Log in to the system where TrueSight Server Automation is installed.
  2. On the TrueSight Server Automation console, right-click a folder in the Depot, and select New > Patch catalog > Generic RPM Linux Patch Catalog.
  3. Provide information for the patch catalog as described in the following table:

    Panel section

    Description

    General

    Enter a Name for the patch catalog and a Description of its contents. Then, browse to the directory where you want to store the catalog.

    CentOS or OL ULN Catalog options

    Defines a number of options including locations (such as the location of the source files and the repository), as well as filters and whether local copies of the files are created on the target server or downloaded directly during deployment.

    Catalog Mode

    Select one of two options:
    • Source from Vendor (Online Mode): Use this mode when the Application Server is installed on a server with Internet access.
    • Source from Disk Repository (Offline Mode): Use this mode in a secured environment where you can download the patch on a server (with Internet access) that is located outside the secure environment.

    Repository Options

    Enter the following information:
    • Payload Source Location (NSH path)
      (Offline Only) Location of the existing metadata and payload files. Metadata files stored in this location are copied to the catalog automatically. Payload files are not copied to the catalog.
    • Repository Location (NSH Path)
      The NSH path of the patch repository location. Ensure that sufficient free space is available at this location. Repositories typically contain many files, usually totaling gigabytes of data.
      Click here to see the platforms supported for storing your repository
    When specifying a host within an NSH path, you can use either the host name or the IP address (IPv4 or IPv6).

    Filters

    Filters limit the amount of information in the catalog.There is no upper limit to the number of filter combinations you can make but there must be at least one. Only RPMs that match the combinations you define (and their dependent RPMs) are added to the catalog.
    ImportantYou cannot create a catalog with multiple filters for the same combination of operating system and architecture.
    You can define filters while creating or editing the catalog.Do the following:
    1. Click Add Filter and select from the following:
      • Online Mode
        Field
        Description
        Channel
        Select a channel from the list. The operating system (OS) and architecture are selected automatically.
        repos/child channels
        Select a repository or child channel from the list.
      • Offline Mode
        Select a channel from the list. The operating system (OS) and architecture are selected automatically.
    2. Save the changes.

  4. Provide information for the patch catalog options as described in the following table:

    Tab

    Description

    Depot Object Options

    Network URL Type for Payload Deployment

    • (default) Copy to agent at staging: The Application Server copies patch payloads to a staging directory on the target server during the Deploy Job staging phase.
    • Agent mounts source for direct use at deployment (no local copy): A Deploy Job instructs the agent on a target server to: mount the device specified in the URl and deploy patch payloads directly to the agent. The Deploy Job does not copy patch payloads to a staging area on the agent, so the job does not create any local copies of the patches on target servers.

    Network URL for Payload Deployment

    The value entered here depends on your selection in the Network URL Type for Payload Deployment box:

    • If you select Copy to agent at staging, do not enter a value. The value is populated automatically based on the repository location.
    • If you select Agent mounts source for direct use at deployment (no local copy), enter the NFS-accessible path to the location of the payload.
      If you specify the host in this path as an IPv6 address, enclose the IPv6 address in square brackets.

    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.

    Max Deport Object Work Items to Process in Parallel

    Maximum number of work items that can be performed in parallel.

    Default Notifications

    The Default Notifications panel provides options for defining 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.

    Default notifications can take the form of emails or SNMP traps. 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. Default notifications are sent when you run a job immediately (that is, you do not schedule the job) or a scheduled job completes but you have not set up email or SNMP notifications for that scheduled occurrence.

    Job Run Notifications

    Field

    Description

    Send email to

    Lists email addresses of the accounts to notify when a job completes with the status that you specify. Separate multiple email addresses with semicolons, such as sysadmin@bmc.com;sysmgr@bmc.com. After entering email address information, select the statuses that cause an email to be generated. The statuses can be Success, Failed, or Aborted.

    Send SNMP trap to

    Provides name or IP address of the server to notify when the job completes. After entering server information, select the statuses that should cause an SNMP trap to be generated. The statuses can be Success, Failed, or Aborted.

    TrueSight Server Automation provides a management information base (MIB) that describes its SNMP trap structure. You can use this MIB to create scripts that integrate traps into your trap collection system. The MIB is located on the Application Server host computer at installDirectory/Share/BladeLogic.mib.

    Schedules

    The Schedules panel lets you 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.

    When scheduling a job, you can perform any of the following tasks:

    • Scheduling a job that executes immediately — To schedule a job that executes immediately, select Execute job now.
    • Scheduling a job — The Schedule tab lets you schedule a job so it can run one time, recur hourly, daily, weekly, or monthly, or recur at some arbitrary interval. For more information, see Patch-catalog-Scheduling.
    • Defining job notifications — The Job Notifications tab lets you set up notifications that are generated when a scheduled job runs. For more information, see Patch-catalog-Scheduled-Job-Notifications.

    Catalog Update Job Properties

    The Properties panel provides a list of properties automatically assigned to the job being created. In this list, you can modify the value of any properties that are defined as editable.

    For any property that has a check in the Editable column, select the property and click in the Value column.

    • To set a property value back to its default value, click Reset to Default Value g_V95_reset_icon.gif.
      The value of the property is reset to the value it inherits from a built-in property class. The Value Source column shows the property class from which the value is inherited.
    • Depending on the type of property you are editing, you can take different actions to set a new value, such as entering an alphanumeric string, choosing from an enumerated list, or selecting a date.
      To insert a parameter into the value, enter the value, bracketed with double question mark delimiters (for example, ??MYPARAMETER??) or click Select Property g_V95_SelectPropertyIcon.gif.

    Results

    View the job run results.

  5. Click Finish
    A patch catalog is stored in the appropriate Depot folder.

Editing the additional options

  1. In the Depot folder, right-click the CentOS catalog that you created.
  2. Select Open.
  3. Set or update any information for the patch catalog options.
  4. Save the changes.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*