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.