Creating a custom patch baseline (Linux)

To create a custom patch baseline for Linux managed nodes

1. Open the Amazon Systems Manager console at https://console.amazonaws.cn/systems-manager/.

2. In the navigation pane, choose Patch Manager.

   -or-

   If the Amazon Systems Manager home page opens first, choose the menu icon ( ) to open the navigation pane, and then choose Patch Manager.

3. Choose the Patch baselines tab, and then choose Create patch baseline.

   -or-

   If you are accessing Patch Manager for the first time in the current Amazon Web Services Region, choose Start with an overview, choose the Patch baselines tab, and then choose Create patch baseline.

4. For Name, enter a name for your new patch baseline, for example, MyRHELPatchBaseline.

5. (Optional) For Description, enter a description for this patch baseline.

6. For Operating system, choose an operating system, for example, Red Hat Enterprise Linux.

7. If you want to begin using this patch baseline as the default for the selected operating system as soon as you create it, check the box next to Set this patch baseline as the default patch baseline for operating system name instances.

   Note

   This option is available only if you first accessed Patch Manager before the patch policies release on December 22, 2022.

   For information about setting an existing patch baseline as the default, see Setting an existing patch baseline as the default.

8. In the Approval rules for operating-systems section, use the fields to create one or more auto-approval rules.

   • Products: The version of the operating systems the approval rule applies to, such as RedhatEnterpriseLinux7.4. The default selection is All.

   • Classification: The type of patches the approval rule applies to, such as Security or Enhancement. The default selection is All.

     Tip

     You can configure a patch baseline to control whether minor version upgrades for Linux are installed, such as RHEL 7.8. Minor version upgrades can be installed automatically by Patch Manager provided that the update is available in the appropriate repository.

     For Linux operating systems, minor version upgrades aren't classified consistently. They can be classified as bug fixes or security updates, or not classified, even within the same kernel version. Here are a few options for controlling whether a patch baseline installs them.

     • Option 1: The broadest approval rule to ensure minor version upgrades are installed when available is to specify Classification as All (*) and choose the Include nonsecurity updates option.

     • Option 2: To ensure patches for an operating system version are installed, you can use a wildcard (*) to specify its kernel format in the Patch exceptions section of the baseline. For example, the kernel format for RHEL 7.* is kernel-3.10.0-*.el7.x86_64.

       Enter kernel-3.10.0-*.el7.x86_64 in the Approved patches list in your patch baseline to ensure all patches, including minor version upgrades, are applied to your RHEL 7.* managed nodes. (If you know the exact package name of a minor version patch, you can enter that instead.)

     • Option 3: You can have the most control over which patches are applied to your managed nodes, including minor version upgrades, by using the InstallOverrideList parameter in the AWS-RunPatchBaseline document. For more information, see About the AWS-RunPatchBaseline SSM document.

   • Severity: The severity value of patches the rule is to apply to, such as Critical. The default selection is All.

   • Auto-approval: The method for selecting patches for automatic approval.

     Note

     Because it's not possible to reliably determine the release dates of update packages for Ubuntu Server, the auto-approval options aren't supported for this operating system.

     • Approve patches after a specified number of days: The number of days for Patch Manager to wait after a patch is released or last updated before a patch is automatically approved. You can enter any integer from zero (0) to 360. For most scenarios, we recommend waiting no more than 100 days.

     • Approve patches released up to a specific date: The patch release date for which Patch Manager automatically applies all patches released or updated on or before that date. For example, if you specify July 7, 2023, no patches released or last updated on or after July 8, 2023, are installed automatically.

   • (Optional) Compliance reporting: The severity level you want to assign to patches approved by the baseline, such as Critical or High.

     Note

     If you specify a compliance reporting level and the patch state of any approved patch is reported as Missing, then the patch baseline's overall reported compliance severity is the severity level you specified.

   • Include non-security updates: Select the check box to install nonsecurity Linux operating system patches made available in the source repository, in addition to the security-related patches.

     Note

     For SUSE Linux Enterprise Server, (SLES) it isn't necessary to select the check box because patches for security and nonsecurity issues are installed by default on SLES managed nodes. For more information, see the content for SLES in How security patches are selected.

   For more information about working with approval rules in a custom patch baseline, see About custom baselines.

9. If you want to explicitly approve any patches in addition to those meeting your approval rules, do the following in the Patch exceptions section:

   • For Approved patches, enter a comma-separated list of the patches you want to approve.

     Note

     For information about accepted formats for lists of approved patches and rejected patches, see About package name formats for approved and rejected patch lists.

   • (Optional) For Approved patches compliance level, assign a compliance level to the patches in the list.

   • If any approved patches you specify aren't related to security, select the Include non-security updates check box for these patches to be installed on your Linux operating system as well.

10. If you want to explicitly reject any patches that otherwise meet your approval rules, do the following in the Patch exceptions section:

    • For Rejected patches, enter a comma-separated list of the patches you want to reject.

      Note

      For information about accepted formats for lists of approved patches and rejected patches, see About package name formats for approved and rejected patch lists.

    • For Rejected patches action, select the action for Patch Manager to take on patches included in the Rejected patches list.

      • Allow as dependency: A package in the Rejected patches list is installed only if it's a dependency of another package. It's considered compliant with the patch baseline and its status is reported as InstalledOther. This is the default action if no option is specified.

      • Block: Packages in the Rejected patches list, and packages that include them as dependencies, aren't installed by Patch Manager under any circumstances. If a package was installed before it was added to the Rejected patches list, or is installed outside of Patch Manager afterward, it's considered noncompliant with the patch baseline and its status is reported as InstalledRejected.

11. (Optional) If you want to specify alternative patch repositories for different versions of an operating system, such as AmazonLinux2016.03 and AmazonLinux2017.09, do the following for each product in the Patch sources section:

    • In Name, enter a name to help you identify the source configuration.

    • In Product, select the version of the operating systems the patch source repository is for, such as RedhatEnterpriseLinux7.4.

    • In Configuration, enter the value of the yum repository configuration to use in the following format:

      [main]
      name=MyCustomRepository
      baseurl=https://my-custom-repository
      enabled=1

      Tip

      For information about other options available for your yum repository configuration, see dnf.conf(5).

      Choose Add another source to specify a source repository for each additional operating system version, up to a maximum of 20.

      For more information about alternative source patch repositories, see How to specify an alternative patch source repository (Linux).

12. (Optional) For Manage tags, apply one or more tag key name/value pairs to the patch baseline.

    Tags are optional metadata that you assign to a resource. Tags allow you to categorize a resource in different ways, such as by purpose, owner, or environment. For example, you might want to tag a patch baseline to identify the severity level of patches it specifies, the operating system family it applies to, and the environment type. In this case, you could specify tags similar to the following key name/value pairs:

    • Key=PatchSeverity,Value=Critical

    • Key=OS,Value=RHEL

    • Key=Environment,Value=Production

13. Choose Create patch baseline.