This site requires JavaScript to be enabled
Welcome Guest|
Recent searches
IE BUMPER
KB0017285

Linux Automatic Patching Overview

Number of views : 8
Article Number : KB0017285
Published on : 2020-03-30
Last modified : 2020-03-30 21:37:18
Knowledge Base : ESM External

What is it?

The ESM team offers automatic patching for Linux hosts similar to automatic patching provided for Windows hosts. There is now the option of having Red Hat Enterprise Linux (RHEL) hosts automatically patched monthly according to a regular patching schedule.

What is the Schedule?

In accordance with software development cycle best practices, Maintenance Windows are divided into weeks-of-the-month based on each host's production environment, with patches becoming available on the following days: Dev hosts are patched starting the 1st of every month, Test hosts starting the 8th of every month, Qual starting the 15th of every month, and Prod starting the 22nd of every month.

The day of the week and time the maintenance windows take place are both customizable.  Patching maintenance windows are available every day of the week except Friday. The available maintenance windows are:

  • 6:00pm-10:00pm
  • 8:00pm-12:00am
  • 10:00pm-2:00am
  • 12:00am-4:00am
  • 2:00am-6:00am
  • 4:00am-8:00am
  • 6:00am-10:00am
  • 8:00am-12:00pm

Benefits

This approach to automatic patching offers many benefits over manual patching:

  • Reduced CostsHosts enrolled in patch automation no longer require manual patching, saving time and money.
  • Flexibility: One can chose from any one of eight maintenance windows on any day of the week (except Friday.) Additionally, environments with multiple hosts can be patched all-at-once, or one-at-a-time in separate windows.
  • Less Downtime: Because patching is fully automated, service restarts and host reboots can take place during off-hours, reducing potential customer impact.
  • Customization: The automated maintenance workflow allows for fine-tuning of the patching process. For example, custom scripts to start/stop services can be run, specific software repositories can be enabled/disabled, and post-reboot verification scripts can be run, at multiple points within the overall process.

Workflow

What are the steps that occur during automatic patching:

  • VM Snapshot: Hosts are placed into Maintenance mode in Zenoss Monitoring to suppress alerting, and a snapshot is taken of the host (if a VM).
  • Pre-Patch Tasks: Any tasks that need to take place before software patching. By default, the only task here is clearing the yum cache.
  • Yum update: Software is patched. All packages are updated with only official RedHat and ESM managed repositories. Packages can be excluded and special repositories enabled or disabled as desired.
  • Post-Patch, Pre-Reboot Tasks: Any tasks that need to occur after patching, but before rebooting, take place at this time. For hosts leveraging Puppet for configuration management, Puppet runs occur at this time to achieve the desired host state.
  • Host is Rebooted
  • Post-Reboot Tasks: By default, nothing happens after reboot.  Any scripts needed to verify or restart services can take place at this time. (Services that restart automatically at reboot will continue to do so and need not be specified here.)  Zenoss Monitoring is taken out of Maintenance mode at this time.

Preparing For Enrollment: Information Needed for Each Host

Configuration can be set individually per host enrolled or across multiple hosts within a service.

  • What time each host should be patched (see maintenance windows above)
  • Do any special scripts need to be run? They can be run before patchingafter patching, and/or after reboot.
  • Are there any custom yum directives? For example, do any special repositories need to be toggled or packages locked to a specific version? By default, only official RedHat and ESM managed repositories are enabled and all packages are upgraded to the latest version.

 

Permalink: utss/KAhome.do?number=KB0017285

Thank You! Your feedback has been submitted.

Feedback