gitea-pages/admin-guide/software/updates.rst

Updates

There are two major aspects to software updates on PSI Linux systems:

1. The configured repositories.
2. The Update policy

Generally the assumption is that /etc/yum.conf points the system at repositories which, for each package, contain the version of that package which should be installed on the system, and possibly older versions. This way, a simple yum update would always bring a system to the desired state, even though it is not recommended to actually run yum update directly (see below).

The policy answers the following questions:

1. When should updates be installed?
2. Which types of updates should be installed? I.e. security fixes, security and bug fixes, or all updates?
3. When should the system reboot? I.e. always (offline updates, recommended), only when there is a new kernel, or never?
4. For how long can updates be pending before an alert is triggered?

Policy

Parameters: - timing (never, timespec) - severity - reboot behaviour (always, only if necessary (kernel update or needs-restarting), never)

Example of fully automatic updates with mandatory reboots:

update::schedule: Thu, 02:00 -- 04:00
update::severity: 'security'
update::reboot: 'always'

Example of manually triggered, full updates with reboots if necessary:

update::schedule: 'never'
update::severity: 'all'
update::reboot: 'if-necessary'

Procedure

Updates should be performed by starting the psi-update service. Using this service instead of running yum directly has a number of benefits:

1. All update-related log output can be retrieved from the journal easily using journalctl -u psi-update.service.
2. The service will take into account the update policy even when in manual mode, e.g. it will only install the desired types of updates.
3. The service will automatically notify monitoring systems if a reboot is necessary, avoiding false positives.
4. It will take of any cleanup actions necessary. E.g. Splunk, a commercial logging product requires to accept its license again after updates (by running something like splunk --accept-license).

Monitoring

There will be a separate mechanism, e.g. a Nagios check, to alert on systems that are not compliant with their update policy.