Package_Management

The role configures basic package management settings and implements the update modes "ansible" and "user". Regardless the update mode, different unattended-upgrade modes

can be activated with the help of the package_management_autoinstall_updates variable. The general consensus is that if the update mode ansible is set, the upgrades are pushed by us and if the

update mode user is set, the user is upgrades on its own. All the different combinations will be shown below.

General

Details for the file "98keep_modified_config_files"

This file defines how apt will handle modified configuration files. The following two settings are set:

  • force-confdef = if a package has a default action for config files, use this default action
  • force-confold = if a package has no default action for config files, always keep modified config files

Details for the file "needrestart.conf"

The only change in this file is the setting "$nrconf{restart}". As default this is set to "l" (listing only) to prevent needrestart from interfering with the update process.

Update modes and usage explained

This role implements update modes. There are currently two different update modes (ansible & user). The update mode ansible is the default and if nothing else is configured in the inventory file,

there will be no unattended-upgrades and all the update/upgrades will be pushed by us. If the update mode is changed to user then the file responsible for unattended-upgrades will be copied to

the target machine. As mentioned above in the purpose of this role, regardless of the update mode, unattended-upgrades can be activated. Which means the unattended-upgrades without defining the package_management_autoinstall_updates

variable will not be activated in the udpate mode user or ansible.

Here are all the possible options for update modes.

Update mode ansible:

  • No unattended-upgrades
  • Security upgrades only
  • without mailreporting
  • with mailreporting
  • Feature upgrades only
  • without mailreporting
  • with mailreporting

Update mode user:

  • No unattended-upgrades
  • Security upgrades only
  • without mailreporting
  • with mailreporting
  • Feature upgrades only
  • without mailreporting
  • with mailreporting

When unattended-upgrades are activated with the package_management_autoinstall_updates variable, a option for mailreporting is available.

There are two options for mailreporting. The first one is called only-on-error, which is the default. This means that there will only be mailreporting if something goes wrong with the unattended-upgrades.

The second one is called on-change, as the name suggests, this option will report on every change the unattended-upgrades make.

How can I change the update mode?

The update mode can be changed by setting the following variable from ansible to user in the inventory file:

package_management_update_mode: user

How can I change what unattended-upgrades will be done?

You can define that only security upgrades should be done in the respective update mode by setting the following variable in the inventory File:

package_management_autoinstall_updates: sec_updates

You can define that Feature upgrades should be done in the respective update mode by setting the following variable in the inventory File:

package_management_autoinstall_updates: feature_updates

How can I define an e-mail address for mailreporting?

You are able to define an e-mail address for mailreporting by defining the following variable in the inventory file:

package_management_user_mode_mail: example@ethz.ch

How can I change the mailreporting mode?

You are able to change the mailreporting mode from only-on-error to on-change by setting the following variable in the inventory file:

package_management_user_mode_mail: on-change

Here is an example of a inventory File regarding the update modes:

package_management_conf: true
package_management_update_mode: user
package_management_autoinstall_updates: sec_updates
package_management_autoinstall_updates_mail: example@ethz.ch
package_management_autoinstall_updates_mailreport: on-change

In this example, unattended-upgrades are activated and only security upgrades will be done.

The mailreport variables are defined that there will be a notification on each change the unattended-upgrades are doing. I would leave this default to only-on-error.

If you have any questions regarding the update modes, feel free to contact niels.dill@id.ethz.ch

Dependencies

Role Dependencies

Package Dependencies

Role Variables

Name Type Default value Purpose Comment Role
package_management_conf Boolean false If true, the role is activated and will be applied - noble_package_management
package_management_install_base_packages Boolean false If true, the task for base_package installation is activated and will be applied - noble_package_management
package_management_allow_release_upgrades String "never" Defines if OS release upgrades are possible Variable is used in the template "release-upgrade.j2" Possible settings are: never, normal, lts noble_package_management
package_management_update_mode String "ansible" If this variable stays default, the consensus is that the upgrades are done by us remotly if this variable is set to "user", the file 50unattended-upgrades will be copied to the target host and the consensus is that the upgrades are done by the user itself/auto updates Possible settings are: ansible (default), user noble_package_management
package_management_autoinstall_updates String false If this variable stays default, even if the update mode is set to user, where the 50unattended-upgrades file is copied to the target host, no unattended-upgrades will be done. If this variable is set to "sec_updates", unattended-upgrades will be done regardless of the update mode, but only security upgrades. If this variable is set to "feature_updates", unattended-upgrades will be done regardless of the update mode. With this option all packages on the target host will be upgrades if any update is available. This option is not quite suited for every host so keep that in mind. Possible settings are: false (default), sec_updates, feature_updates noble_package_management
package_management_autoinstall_updates_mail String false If this variable stays default, in the 50unattended-upgrades file the mail address for reporting will not be set if this variable is set with an E-Mail address then there will be reporting to this address - noble_package_management
package_management_autoinstall_updates_mailreport String "only-on-error" If this variable stays default, there will only be mailreporting if there is an error with the
unattended-upgrades if this variable is set to on-change, there will be mailreporting on every change the unattended-upgrades make Possible settings are: only-on-error (default), on-change noble_package_management
support_contact String empty Contains the support contact Standard variable from inventory multirole
package_management_needrestart String "l" Defines the behavior of needrestart after an update Possible settings are: "l" = list only, "i" = interactive, a prompt will be shown after the update, "a" = automatic noble_package_management
packages String htop,nload,ncdu,vim,fish the base packages - noble_package_management

Example Playbook

Including an example of how to use your role (for instance, with variables passed in as parameters) is always nice for users too:

- hosts: servers
  roles:
     - { role: username.rolename, x: 42 }

License

BSD

Author Information

Maintainer: Urs Blumentritt Niels Dill

Support-Contact: s4d-linux-support@id.ethz.ch