"merged" admin-guide

2021-05-05 14:24:27 +02:00
parent 296ecb3f26
commit c488e8de62
182 changed files with 17246 additions and 5 deletions
@@ -0,0 +1,70 @@
+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.