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 | - | jammy_package_management |
| package_management_install_base_packages | Boolean | false | If true, the task for base_package installation is activated and will be applied | - | jammy_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 | jammy_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 | jammy_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 | jammy_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 | - | jammy_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 | jammy_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 | jammy_package_management |
| packages | String | htop,nload,ncdu,vim,fish | the base packages | - | jammy_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