Patching nodes

After configuring patch management, you can start applying patches to nodes. The patch_server task enables simply applying patches, while the group_patching plan performs health checks before and after patches are applied.

Patch nodes

Use the patch_server task to apply patches to nodes. You can limit patches to security or non-security updates, Windows or *nix nodes, or a specific patch group.

Before you begin
Ensure you have permission to run the pe_patch::patch_server task.
  1. On the Patches page, in the Apply patches section, use the filters to specify which patches to apply to which nodes.
    Note: Filters use and logic. This means that if you select Security updates and Windows, the results include security patches for Windows nodes, not all security patches and all Windows patches.
  2. Select Run > Task.
    The Run a task page appears with patching information pre-filled for the pe_patch::patch_server task.
  3. Optional: In the Job details field, provide a description of the task run. This text appears on the Tasks page.
  4. Optional: Under Task parameters, add optional parameters to the task. See Patching task parameters for a full list of available parameters.
    Note: You must click Add parameter for each optional parameter-value pair you add to the task.
  5. Optional: If you want to schedule the task to run later, under Schedule, select Later and choose a time.
  6. Select Run task to apply patches.
Results
To check the status of the task, look for it on the Tasks page. You can filter the results to view only pe_patch tasks.
Note: When using patch management to update core packages that affect the networking stack, the task run might look like it failed due to the PXP agent on the node losing connection with the primary server. However, the task still completes successfully. You can confirm by checking the pe_patch fact to verify the relevant packages were updated.

Patching task parameters

The pe_patch::patch_server task applies patches to nodes. When you patch nodes in the console, most of the information for the patch_server task is prefilled on the Run a task page, but you can add additional parameters to the task before you run it.

timeout
Indicates how much time elapses before the task run times out.
Accepted values: Any positive integer, in seconds.
Default: 3600
security_only
Indicates whether to apply only security patches.
Accepted values: true, false
Default: false
yum_params
Indicates additional parameters to include in YUM commands, such as including or excluding repositories.
Accepted values: String
Default: undef
dpkg_params
Indicates additional parameters to include in apt-get commands.
Accepted values: String
Default: undef
zypper_params
Indicates additional parameters to include in Zypper commands.
Accepted values: String
Default: undef
clean_cache
Indicates if YUM or dpkg caches are cleaned at the start of the task.
Accepted values: true, false
Default: false
reboot
Indicates if and when nodes reboot during the task run.
Note: If the node group you're patching has a reboot_override value specified, that value overrides any reboot parameter you specify in task runs.
Accepted values:
  • always — The node always reboots during the task run, even if no patches are required.
  • never (or false) — The node never reboots during the task run, even if patches are applied.
  • patched (or true) — The node reboots if patches are applied.
  • smart — Use the OS supplied tools, like needs_restarting on RHEL or a pending reboot check on Windows, to determine if a reboot is required.
Default: never

Patch nodes with built-in health checks

Use the group_patching plan to patch nodes with pre- and post-patching health checks. The plan verifies that Puppet is configured and running correctly on target nodes, patches the nodes, waits for any reboots, and then runs Puppet on the nodes to verify that they're still operational.

Before you begin
Ensure you have permission to run the pe_patch::group_patching plan.
  1. In the console, in the Orchestration section, select Plans and then click Run a plan.
  2. Specify plan details:
    • Code environment — Select the environment where you installed the module containing the plan you want to run. For example, production.
    • Job description — Provide an optional description of the plan run.
    • Plan — Select pe_patch::group_patching.
  3. In the Plan parameters section, specify the patch_group that you want to base running the plan on, and optionally add other patching plan parameters.
    Note: The patch_group parameter is defined in the pe_patch class for node groups under patch management. For details, see Specify patching parameters.
  4. Optional: In the Schedule section, specify if you want the plan to run at a later date and time.
  5. Click Run job.
Results
To check the status of the plan, look for it on the Plans page.
Note: When using patch management to update core packages that affect the networking stack, the task run might look like it failed due to the PXP agent on the node losing connection with the primary server. However, the task still completes successfully. You can confirm by checking the pe_patch fact to verify the relevant packages were updated.

Patching plan parameters

The pe_patch::group_patching plan verifies that Puppet is configured and running correctly on target nodes, patches the nodes, waits for any reboots, and then runs Puppet on the nodes to verify that they're still operational.

By default, the plan includes a health check which considers "healthy" any nodes on which:
  • The Puppet service is enabled and running
  • Noop mode and cached catalogs are not enabled
  • The run interval is 30 minutes
You can modify plan behavior with several types of optional parameters:
  • Patching options let you control how patching itself is applied, including adding an optional string to arguments passed to your package provider.
  • Health check options control when a pre-patching health check and a post-patching Puppet run occurs.
    Tip: The health_check_* parameters apply patches only to nodes that match values you specify. For example, if you change health_check_service_running to false, the pre-patching health check marks nodes on which the Puppet service is running as "unhealthy" and skips patching them.
  • Reboot options control when a post-patching reboot occurs, and let you specify a script to execute after patching.
Patching options
patch_group
Specifies the patch_group, as defined in the pe_patch class parameter, that you want to base running the plan on.
Accepted values: String
patch_task_timeout
Indicates how much time elapses before the task run times out.
Accepted values: Any positive integer, in seconds.
Default: 3600
security_only
Indicates whether to apply only security patches.
Accepted values: true, false
Default: false
yum_params
Indicates additional parameters to include in YUM commands, such as including or excluding repositories.
Accepted values: String
Default: undef
dpkg_params
Indicates additional parameters to include in apt-get commands.
Accepted values: String
Default: undef
zypper_params
Indicates additional parameters to include in Zypper commands.
Accepted values: String
Default: undef
clean_cache
Indicates if YUM or dpkg caches are cleaned at the start of the task.
Accepted values: true, false
Default: false
sequential_patching
Indicates if nodes in the specified patch group are patched, rebooted, and the post-reboot script run one a time rather than all at once.
Accepted values: true, false
Default: false
Health check options
run_health_check
Indicates whether to do a pre-patching health check and a post-patching Puppet run.
Accepted values: true, false
Default: true
health_check_noop
Verifies the noop setting during pre-patching health checks.
Accepted values: true, false
Default: false
health_check_runinterval
Verifies the runinterval setting during pre-patching health checks.
Accepted values: Any positive integer, in seconds.
Default: 1800 (equivalent to the default Puppet run interval of 30 minutes)
health_check_service_running
Verifies whether the Puppet service is running during pre-patching health checks.
Accepted values: true, false
Default: true
health_check_service_enabled
Verifies whether the Puppet service is enabled during pre-patching health checks.
Accepted values: true, false
Default: true
health_check_use_cached_catalog
Verifies the use_cached_catalog setting during pre-patching health checks.
Accepted values: true, false
Default: false
Reboot options
reboot
Indicates if and when nodes reboot during the plan run.
Note: If the node group you're patching has a reboot_override value specified, that value overrides any reboot parameter you specify in plan runs.
Accepted values:
  • always — The node always reboots during the plan run, even if no patches are required.
  • never — The node never reboots during the plan run, even if patches are applied.
  • patched — The node reboots if patches are applied.
  • smart — Use the OS supplied tools, like needs_restarting on RHEL or a pending reboot check on Windows, to determine if a reboot is required.
Default: patched
reboot_wait_time
Indicates how long to wait for nodes to reboot before running a post-patching health check.
Accepted values: Any positive integer, in seconds.
Default: 600
post_reboot_scriptpath
The full path to an executable script or binary on the target node to be run after reboot and before the final Puppet run.
Accepted values: File path
Default: undef