71 lines
2.3 KiB
ReStructuredText
71 lines
2.3 KiB
ReStructuredText
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.
|