os_patching: This manifest sets up a script and cron job to populate theos_patchingfact.
clean_cache: Clean patch caches (yum/dpkg) via a taskpatch_server: Carry out OS patching on the server, optionally including a reboot and/or only applying security related updatesrefresh_fact: Force a refresh of the os_patching fact cache via a task
os_patching::patch_after_healthcheck: An example plan that uses the puppet health check module to perform a pre-check on the nodes you're planning to patch. If the nodes pass the check, they get patched
This manifest sets up a script and cron job to populate
the os_patching fact.
assign node to 'Week3' patching window, force a reboot and create a blackout window for the end of the year
class { 'os_patching':
patch_window => 'Week3',
reboot_override => 'always',
blackout_windows => { 'End of year change freeze':
{
'start': '2018-12-15T00:00:00+10:00',
'end': '2019-01-15T23:59:59+10:00',
}
},
}class profiles::soe::patching (
$patch_window = undef,
$blackout_windows = undef,
$reboot_override = undef,
){
# Pull any blackout windows out of hiera
$hiera_blackout_windows = lookup('profiles::soe::patching::blackout_windows',Hash,hash,{})
# Merge the blackout windows from the parameter and hiera
$full_blackout_windows = $hiera_blackout_windows + $blackout_windows
# Call the os_patching class to set everything up
class { 'os_patching':
patch_window => $patch_window,
reboot_override => $reboot_override,
blackout_windows => $full_blackout_windows,
}
}{"End of year change freeze": {"start": "2018-12-15T00:00:00+10:00", "end": "2019-01-15T23:59:59+10:00"}}puppet task run os_patching::patch_server --params '{"reboot": "smart"}' --targets centos.example.comclass { 'os_patching':
ensure => absent,
}The following parameters are available in the os_patching class:
puppet_binarypatch_data_ownerpatch_data_grouppatch_cron_usermanage_yum_utilsblock_patching_on_warningsyum_utilsfact_uploadapt_autoremovemanage_delta_rpmdelta_rpmmanage_yum_plugin_securityyum_plugin_securityreboot_overridepatch_windowpre_patching_commandpatch_cron_hourpatch_cron_monthpatch_cron_monthdaypatch_cron_weekdaypatch_cron_minwindows_update_hourwindows_update_interval_minsensurefact_modeblackout_windows
Data type: Stdlib::Absolutepath
Location of the Puppet binary
Data type: String
User name for the owner of the patch data
Data type: String
Group name for the owner of the patch data
Data type: String
User who runs the cron job
Data type: Boolean
Should the yum_utils package be managed by this module on RedHat family nodes?
If true, use the parameter yum_utils to determine how it should be manged
Data type: Boolean
If there are warnings present in the os_patching fact, should the patching task run?
If true the run will abort and take no action
If false the run will continue and attempt to patch (default)
Data type: Enum['installed', 'absent', 'purged', 'held', 'latest']
If managed, what should the yum_utils package set to?
Data type: Boolean
Should puppet fact upload be run after any changes to the fact cache files?
Data type: Boolean
Should apt-get autoremove be run during reboot?
Data type: Boolean
Should the deltarpm package be managed by this module on RedHat family nodes?
If true, use the parameter delta_rpm to determine how it should be manged
Data type: Enum['installed', 'absent', 'purged', 'held', 'latest']
If managed, what should the delta_rpm package set to?
Data type: Boolean
Should the yum_plugin_security package be managed by this module on RedHat family nodes?
If true, use the parameter yum_plugin_security to determine how it should be manged
Data type: Enum['installed', 'absent', 'purged', 'held', 'latest']
If managed, what should the yum_plugin_security package set to?
Data type: Optional[Variant[Boolean, Enum['always', 'never', 'patched', 'smart', 'default']]]
Controls on a node level if a reboot should/should not be done after patching. This overrides the setting in the task
Data type: Optional[String]
A freeform text entry used to allocate a node to a specific patch window (Optional)
Default value: undef
Data type: Optional[Stdlib::Absolutepath]
The full path of the command to run prior to running patching. Can be used to run customised workflows such as gracefully shutting down applications. The entry must be a single absolute filename with no arguments or parameters.
Data type: Variant[Enum['absent'], Integer[0,23]]
The hour(s) for the cron job to run (defaults to absent, which means '*' in cron)
Data type: Variant[Enum['absent'], Integer[1,12]]
The month(s) for the cron job to run (defaults to absent, which means '*' in cron)
Data type: Variant[Enum['absent'], Integer[1,31]]
The monthday(s) for the cron job to run (defaults to absent, which means '*' in cron)
Data type: Variant[Enum['absent'], Integer[0,7]]
The weekday(s) for the cron job to run (defaults to absent, which means '*' in cron)
Data type: Integer[0,59]
The min(s) for the cron job to run (defaults to a random number between 0 and 59)
Default value: fqdn_rand(59)
Data type: Integer[0,23]
Control the hour on which windows nodes check for updates
Data type: Integer
Control how often windows updates for updates
Data type: Enum['present', 'absent']
present to install scripts, cronjobs, files, etc, absent to cleanup a system that previously hosted us
Data type: Stdlib::Filemode
Data type: Optional[Hash]
Options:
- :title
String: Name of the blackout window - :start
String: Start of the blackout window (ISO8601 format) - :end
String: End of the blackout window (ISO8601 format)
Default value: undef
Clean patch caches (yum/dpkg) via a task
Supports noop? false
Carry out OS patching on the server, optionally including a reboot and/or only applying security related updates
Supports noop? false
Data type: Optional[String]
Any additional parameters to include in the yum upgrade command (such as including/excluding repos)
Data type: Optional[String]
Any additional parameters to include in the dpkg command
Data type: Optional[String]
Any additional parameters to include in the zypper update command
Data type: Optional[Variant[Boolean, Enum['always', 'never', 'patched', 'smart']]]
Should the server reboot after patching has been applied? (Defaults to 'never')
Data type: Optional[Integer]
How many seconds should we wait until timing out the patch run? (Defaults to 3600 seconds)
Data type: Optional[Boolean]
Limit patches to those tagged as security related? (Defaults to false)
Data type: Optional[Boolean]
Should the yum/dpkg caches be cleaned at the start of the task? (Defaults to false)
Force a refresh of the os_patching fact cache via a task
Supports noop? false
An example plan that uses the puppet health check module to perform a pre-check on the nodes you're planning to patch. If the nodes pass the check, they get patched
The following parameters are available in the os_patching::patch_after_healthcheck plan:
Data type: TargetSpec
Data type: Optional[Boolean]
Default value: false
Data type: Optional[Integer]
Default value: 1800