Changes between Initial Version and Version 1 of unattended-upgrades

Timestamp:

Jan 16, 2017, 2:05:04 AM (7 years ago)

Author:

Jamie McClelland

Comment:

--

unattended-upgrades

@@ +1 @@
+= Unattended Upgrades =
+
+May First/People Link keeps servers up to date using [https://wiki.debian.org/UnattendedUpgrades unattended upgrades], meaning that most software packages are upgraded automatically as new releases are made via Debian.
+
+== Phase in ==
+
+We 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.
+
+In the second phase, we will expand this to all Debian packages except backports.
+
+== Configuration ==
+
+Unattended backups are configured on a per-server basis via the server's .pp file in puppet.
+
+Here's a sample default:
+
+{{{
+  class { "mayfirst::m_unattended_upgrades":
+    uu_upgrade_email => $parent
+  }
+}}}
+
+The $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.
+
+This 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:
+
+{{{
+uu_origin_patterns => "origin=*"  # Upgrade everything from any repo
+uu_origin_patterns => "a=stable" # Only upgrade from stable archive
+}}}
+
+In addition, you can specify packages that should ''not'' be upgraded with:
+
+{{{
+uu_package_blacklist => [ "freeswitch*", "certbot" ]
+}}}
+
+(Note - wildcards are possible. Also, pinning is respected.)
+
+== Notes ==
+
+As parent, you can take steps to retain control over the upgrade process. Some steps you may consider:
+
+ * 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).
+ * 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)
+ * Adding packages to the black list (implies that you don't want other admins upgrading them). Commenting is useful here so we know why
+ * 
+