Creating a patch catalog for SuSE Linux

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 types of repositories, online and offline, you create a patch catalog through 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 SuSE Linux, and includes the following sections:

Step 1: Review prerequisites for the catalog
Step 2: Create the patch catalog
Editing the options
Where to go from here

Step 1: Review prerequisites for the catalog

Review the following prerequisites for creating patch catalogs for SuSE.

You must pre-install the following packages on the server that hosts the patch repository:
- createrepo
- python-urlgrabber
Ensure that security policies on the repository server do not block the download of the catalog.

Ensure that the system you will use for the patch repository is supported by TrueSight Server Automation.

Click here to see the platforms supported for storing your repository

Patch catalog

Supported platforms for storing patch repositories

Windows

Windows or Unix

AIX

Any AIX server

Notes:

If you are downloading patches using the SUMA option, ensure that you have the SUMA utility installed on your repository server.
We recommend using the latest SUMA download option instead of the Fixget download option.
Before you use the SUMA download option, ensure that the repository server is running an AIX system.

Red Hat Enterprise Linux (RHEL) using the CDN interface

Red Hat Enterprise Linux 6¹, 7, 8 or 9

SuSE Linux 15

To patch SuSE 15 targets, you can use any of the following patch repositories:

SuSE 11¹ or 12 system configured with Subscription Management Tool (SMT).
SuSE 15 system configured with Repository Mirroring Tool (RMT).

SuSE Linux 12

SuSE Linux with SMT installed.

Note:To patch SuSE 12 targets, ensure that the SuSE patch repository server is configured with SMT.

The following table lists the versions that are installed with SMT out-of-the-box, as well as the versions on which SMT must be manually installed.

Repository server version	SMT installation
SuSE 11 SP3¹ SuSE 11 SP4¹ SuSE 12 Note: SuSE recommends upgrading SuSE 12 to SuSE 12 SP1 to avoid dependency issues.	Not configured with SMT out of the box. You must manually install and configure SMT (version 11 SP3) on the repository server before you create a SuSE patch catalog.
SuSE 12 SP1 or later service pack of SuSE 12 (recommended)	SMT is shipped out-of-the-box with the operating system.

Warning: BMC strongly recommends using Zypper when creating a patching job for a patch catalog that was created using the Subscription Management Tool (SMT). For more information, see Zypper patching tool.

SuSE Linux 11¹

SuSE Linux 12 and 15

SuSE Linux with createrepo and python-urlgrabber installed.

Oracle Enterprise Linux (Public repository)

Any supported RPM-based Linux with createrepo and python-urlgrabber installed

Oracle Enterprise Linux (OL ULN repository)

For Oracle Enterprise Linux 7.x, use a patch repository created on the system that runs Oracle Enterprise Linux 7.x. Similarly, for Oracle Enterprise Linux 8.x, use the patch repository created on the system that runs Oracle Enterprise Linux 8.x.

Solaris

Windows or Unix

Note: If you are using Solaris 11 patches, you can only use a Solaris 11 server for storing the patch repository.

Ubuntu

Windows or Unix

Debian

Windows or Unix

Amazon Linux

For Amazon Linux 2, use a patch repository created on the system that runs Amazon Linux 2.

Rocky Linux

For Rocky Linux, use a patch repository created on the system that runs Rocky Linux.

Cent OS

For CentOS 7, use a patch repository created on the system that runs CentOS 7. Similarly, for CentOS 8, use the patch repository created on the system that runs CentOS 8. Ensure that createrepo and python-urlgrabber are installed on the CentOS system.

Fujitsu Solaris

Windows or Linux

HP-UX

An HP-UX patch repository must reside either directly on the HP-UX (SWA) Server or in a directory that the SWA Server considers to be a local share.

Note that if you are using an offline downloader, you can run the offline downloader on any Windows or Linux machine, but the HP-UX patch repository must still reside on the HP-UX (SWA) Server.

¹Support for this platform is deprecated. For the complete list of deprecated platforms, see Deprecated-and-discontinued-features.

Subscription Management Tool (SMT) is installed and configured on the SuSE patch repository server. Ensure that you are registered with the SUSE Customer Center (SCC).

The smt.conf file in /etc is configured to provide smtUser with read/write/execute permissions at the repository location.
Note: The mirroring of the repositories is managed automatically by TrueSight Server Automation.

Click here to expand information about which SuSE versions are installed with SMT out-of-the-box

See the following table for information about which versions are installed with SMT out-of-the-box, and on which versions SMT must be manually installed.

Repository server version	SMT installation
SuSE 11 SP3 SuSE 11 SP4 SuSE 12 Note: SuSE recommends upgrading SuSE 12 to SuSE 12 SP1 to avoid dependency issues.	Not configured with SMT out of the box. You must manually install and configure SMT (version 11 SP3) on the repository server before you create a SuSE patch catalog.
SuSE 12 SP1 or later (recommended)	SMT is shipped out-of-the-box with the operating system.

If you are using a SuSE 15 server for storing SuSE patches, ensure that the Repository Mirroring Tool (RMT) is installed and configured on the server.

Step 2: Create the patch catalog

Right-click a folder in the Depot and select New > Patch catalog > SuSE Linux Patch Catalog.
The New Patch Catalog dialog panel opens.

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 folder in which you want to store the catalog.

SuSE Linux Catalog options

Define options such as locations (location of the source files, the repository, the signature file, and so on) 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 if the TrueSight Server Automation Application Server is installed on a server with Internet access.
Source from Disk Repository (Offline Mode): Use this mode in a secured environment where download occurs on a server, with Internet access, outside of the environment.

Repository Options

Enter the following information:

Field

Description

Payload Source Location (NSH Path)

(Offline mode only) Location of the XML files generated by the downloader and the corresponding payload files.
Metadata files stored in this location are copied to the catalog automatically. Payload files are not copied to the catalog.
To support sourcing of vendor-supplied media, run the BMC Patch Downloader utility using the -createRepo option. This option creates the repository with the necessary metadata file. Then identify the source location here.

Repository Location (NSH Path)

NSH path to the patch repository. This location can be on a Linux platform (Red Hat, SUSE or Oracle Enterprise Linux). However BMC strongly recommends that this location be on a SUSE platform, because some SUSE-specific patches need to be stored only on a SUSE repository server.

Also, ensure that the repository server has ample free space. Repositories typically contain many files, usually totaling gigabytes of data.

Important

When specifying a host within an NSH path, you can use either the host name of the IP address (IPv4 or IPv6).

Filters

Filters limit the amount of information brought into the catalog. Use this procedure to re-create the same filters defined in the configuration file used by the Patch Downloader utility. You can define a filter during catalog creation or later, when editing the catalog.

There is no upper limit to the number of filter combinations you can create, but you must create at least one. Only those RPMs that match the combinations that you define (and their dependent RPMs) are added to the catalog.

To begin, you click Add Filter (as shown in the following figure), and then you provide values for the following options:

OS Flavor: Select the combination operating system and architecture from the list provided.
OS: The operating system, based on your selection in the OS Flavor box, is supplied automatically in a read-only box.
Architecture: The architecture, based on your selected in the OS Flavor box, is supplied automatically in a read-only box.
OS Level: The operating system level of the files to be downloaded.

(Online Only) In Online mode, the SUSE filter XML file contains the following URLs for a combination of OS and Architecture: Online, Updates, and Pool. Depending on which updates need to be downloaded, select one or more of the following options:

Update: The latest updates for the specified OS level. If you select the Updates option, you must ensure that your target is at the OS level for which you require the updates. For example, if you select the Update option for SUSE Linux Enterprise 10 SP1, you must upgrade your target to SUSE Linux Enterprise 10 SP1 before applying the updates.
Online: Updates from the previous OS level to the specified OS level. You must use the Online option only when you want to bring your target from the existing OS level to the next OS level. For example, you must use the Online option if you want to bring your target from SUSE Linux Enterprise 10 SP2 to SUSE Linux Enterprise 10 SP3.
Pool: All the updates until the specified OS level. For an OS-Architecture combination, if you require the updates from an OS level to the next or the latest OS level, you must use the Pool option. For example, you must use the Pool option if you want to bring your target from SUSE Linux Enterprise 10 SP1 to SUSE Linux Enterprise 10 SP4.
Important
The Pool option includes the updates provided in the Online option, so selecting the Online option and the Pool option together is not required.

(Optional) On the Patch Global Configuration tab, you may also specify the SUSE override filters list file by performing the following steps:

Import the file into the Depot workspace
Point to this Depot path on the Patch Global Configuration tab.
The drop-down list for Service Packs in the SUSE Linux Catalog tab displays only the service packs specified in the SUSE filters list file.

In the bottom right corner, select Job options. (You can also edit the catalog at a later time to set these options).

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

Tab

Description

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.

Job Run 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.

Depot Object Options

Network URL Type for Payload Deployment

(default) Copy to agent at staging: The TrueSight Server Automation 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 chose Copy to agent at staging, do not enter a value here. The value is autopopulated based on the repository location.
If you chose 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.

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 .
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 .

Permissions

Using the Permissions panel, you can add individual permissions to an object. You can also set permissions by adding ACL templates or ACL policies. The Permissions list is an access control list (ACL) granting roles access to any objects created in the system, such as depot objects. ACLs control access to all objects, including the sharing of objects between roles. For more information, see the following table:

Task	Description
Adding an authorization	An authorization grants permission to a role to perform a certain type of action on this object. To add authorization to this object, click Add Entry in the Access Control List area. Then use the Add New Entry dialog box to specify the role and authorization you want to add.
Adding an ACL template	An ACL template is a group of predefined authorizations granted to roles. Using an ACL template, you can add a group of authorizations to the object. To add an ACL template to the object, click Use ACL Template in the Access Control List area. Then use the Select ACL Template dialog box to specify an ACL template that you want to add to this object. To set the contents of the selected ACL templates so that they replace all entries in the access control list, select Replace ACL with selected templates. If you do not select this option, the contents of the selected ACL templates are appended to existing entries in the access control list.
Adding an ACL policy	An ACL policy is a group of authorizations that can be applied to this object but can be managed from one location. To add an ACL policy to this object, click Use ACL Policy in the ACL Policies area. Then use the Select ACL Policy dialog box to specify an ACL policy that you want to add to the object. To set the contents of the selected ACL policies so they replace all entries in the access control list, select Replace ACL with selected policies. If you do not select this option, the contents of the selected ACL policies are appended to existing entries in the access control list.