Changes between Initial Version and Version 1 of unattended-upgrades

Jan 15, 2017, 9:05:04 PM (5 years ago)
Jamie McClelland



  • unattended-upgrades

    v1 v1  
     1= Unattended Upgrades =
     3May First/People Link keeps servers up to date using [ unattended upgrades], meaning that most software packages are upgraded automatically as new releases are made via Debian.
     5== Phase in ==
     7We are phasing in this policy. During the initial phase, the default setting will use the default settings of the unattended upgrades package - namely, only security packages from Debian will be upgraded.
     9In the second phase, we will expand this to all Debian packages except backports.
     11== Configuration ==
     13Unattended backups are configured on a per-server basis via the server's .pp file in puppet.
     15Here's a sample default:
     18  class { "mayfirst::m_unattended_upgrades":
     19    uu_upgrade_email => $parent
     20  }
     23The $parent variable is pulled in from the top of the file where the email address of the server's parent should be identified. This email address will receive a message if there are any errors during the upgrade.
     25This configuration will only upgrade security packages during the initial phase, and later will be expanded to include all Debian packages except backports. This default can be changed by passing in a new `$uu_origin_patterns` variable. Some examples include:
     28uu_origin_patterns => "origin=*"  # Upgrade everything from any repo
     29uu_origin_patterns => "a=stable" # Only upgrade from stable archive
     32In addition, you can specify packages that should ''not'' be upgraded with:
     35uu_package_blacklist => [ "freeswitch*", "certbot" ]
     38(Note - wildcards are possible. Also, pinning is respected.)
     40== Notes ==
     42As parent, you can take steps to retain control over the upgrade process. Some steps you may consider:
     44 * In the server $purpose string, provide explicit directions to other team members about when and how you want help (e.g. Hands off, never touch please).
     45 * Comment out the unattended upgrades entirely and leave a comment explaining why and under what circumstances you are ok with another team member upgrading a package (e.g. only upgrade under critical security vulnerability)
     46 * Adding packages to the black list (implies that you don't want other admins upgrading them). Commenting is useful here so we know why
     47 *