Skip to content

Feature: System Updates for dnf, yum, apt hosts

andreasn edited this page May 3, 2017 · 42 revisions

Summary

Cockpit provides a "Software Updates" page for Atomic/OSTree. Extend it for "classic" yum/dnf/apt based operating systems: Show available changes, provide button for applying outstanding updates, and allow the user to enable automatic updates.

Stories

User stories:

Roy administrates his company's mail server. He normally applies updates once a week, but today he reads on IT news about an urgent Postfix security issue.

Moss administers his team's internal file server. He wants to cut down on the amount of time he spends on manually doing software updates on the server.

Workflows:

Roy logs in to Cockpit and sees that there is a Postfix update available referring to that CVE, so he sends out an announcement about a short planned downtime, the applies the update and reboots the server. He verifies that the mail server comes back online.

Moss logs in to the server via Cockpit. He enables automatic installation of updates. Every few months some update causes connection errors as a reboot is required, then Moss does that manually.

Scope

Operating systems supported by Cockpit have some standard mechanism to manually or automatically apply updates and describe the changes in available updates. They usuall allow some configurability, such as whether to only download or to actually apply updates automatically, whether to apply them during runtime or shutdown, and the interval at which this happens. Cockpit should just provide a simple interface to this existing mechanism and not try and invent any logic of its own. It should only support the most common use cases and its UI and complexity should be comparable to the existing "Software Updates" page for OSTree.

Phase 1 provides showing the availability of updates, describing them to the extent possible, and provide a button to apply them, together with a live logtail of the update output. This can be quite complex and packages often show custom error messages, so Cockpit should not try and interpret them, but just show the output verbatim.

Phase 2 provides a simple check box to enable daily automatic updates, (to be discussed, check if all backends support this) possibly with a choice between applying them during runtime (default) or at shutdown.

Cockpit's currently supported operating systems use one out of four package managers for which this needs to be implemented: dnf (Fedora), yum (Centos/RHEL 7), apt (Debian/Ubuntu), and ostree (Atomic).

OS interfaces: View changes and manual application

dnf:

Human-readable and structured description of available updates can be seen with

# dnf updateinfo info
===============================================================================
kernel-4.10.13-200.fc25
===============================================================================
Update ID : FEDORA-2017-17d1c05236
Type : security
Updated : 2017-05-01 14:13:41
Bugs : 1445207 - CVE-2017-7477 kernel: net: Heap overflow in skb_to_sgvec in macsec.c
: 1446566 - CVE-2016-9604 kernel: security: The built-in keyrings for security tokens can be joined as a session and then modified by the root user [fedora-all]
: 1445208 - CVE-2017-7477 kernel: net: Heap overflow in skb_to_sgvec in macsec.c [fedora-all]
: 1389433 - CVE-2016-9604 kernel: security: The built-in keyrings for security tokens can be joined as a session and then modified by the root user
Description : The 4.10.13 stable update contains a number of important fixes across the tree.

This should at least be broken into individual packages (list with expanders for details) and get line wrapped. This can be refined to recognize bug and CVE references and turn them into proper links.

Updates are applied with dnf -y update.

yum:

yum-plugin-changelog only displays the raw RPM spec changelogs, and only as part of yum update. So this needs to be run with --assumeno to not actually apply the update, and the changelog sections need to be parsed out of the other output:

# yum install -y yum-plugin-changelog
# yum --changelog update
Loaded plugins: auto-update-debuginfo, changelog, fastestmirror, product-id,
              : search-disabled-repos, subscription-manager
[...]
Resolving Dependencies
--> Running transaction check
---> Package NetworkManager.x86_64 1:1.4.0-17.el7_3 will be updated
[...]
--> Finished Dependency Resolution

Changes in packages about to be updated:

ChangeLog for: 1:NetworkManager-1.4.0-19.el7_3.x86_64,
             : 1:NetworkManager-libnm-1.4.0-19.el7_3.x86_64,
             : 1:NetworkManager-team-1.4.0-19.el7_3.x86_64,
             : 1:NetworkManager-tui-1.4.0-19.el7_3.x86_64
* Wed Mar 29 08:00:00 2017 Beniamino Galvani <bgalvani@redhat.com> - 1:1.4.0-19
- core: alyways force a sync of the default route (rh#1431268)

* Mon Mar 27 08:00:00 2017 Beniamino Galvani <bgalvani@redhat.com> - 1:1.4.0-18
- manager: ensure proper disposal of unrealized devices (rh#1433303)
[...]
Dependencies Resolved

================================================================================
 Package                  Arch   Version                   Repository      Size
================================================================================
Installing:
 kernel                   x86_64 3.10.0-514.16.1.el7       updates         37 M
[...]

Updates are applied with yum -y update.

apt:

The standard mechanism is apt-listchanges, but this is currently tightly integrated with apt-get dist-upgrade, i. e. it displays the changes after downloading the updates and before applying them. There is currently no good way to only display changes without actually installing them ("dry run"). For that reason, Ubuntu's update-manager has its own logic for downloading the changelogs from http://changelogs.ubuntu.com/ and displaying the relevant part. But this package is not available in Debian.

TODO: research some better solution here

As a first step, apt-get -qq update; apt list --upgradable will at least provide the number, names, and versions of packages for which updates are available.

Updates are applied with apt-get -y dist-upgrade.

ostree:

Already implemented, to the degree possible (there are no individual package changelogs):

Screenshot of Software Updates on Atomic

OS interfaces: Automatic application

Reference for dnf/yum: https://fedoraproject.org/wiki/AutoUpdates

dnf:

Enable automatic download of updates:

dnf install dnf-automatic
systemctl enable --now dnf-automatic.timer

Enable automatic application of updates by setting apply_updates = yes in /etc/dnf/automatic.conf. Parse the value to get the current mode.

yum:

Enable automatic download of updates:

yum install -y yum-cron
systemctl enable yum-cron && systemctl start yum-cron

(The service unit only creates the flag file that gates the cron job.)

Enable automatic application of updates by setting apply_updates = yes in etc/yum/yum-cron.conf. Parse the value to get the current mode.

apt:

Enable automatic download of updates:

apt-get install -y unattended-upgrades

Enable automatic application of updates:

echo 'APT::Periodic::Unattended-Upgrade 7;' > /etc/apt/apt.conf.d/51-enable-unattended-upgrades

Check current status with:

apt-config shell UnattendedUpgradeInterval APT::Periodic::Unattended-Upgrade

Empty or UnattendedUpgradeInterval='0': not enabled; when running the above command it will say UnattendedUpgradeInterval='7'

ostree:

There is no documented official way in the documentation (projectatomic or wiki). Also, Atomic is meant to be rebooted after installing a new image. To be discussed: It may be too intrusive to reboot unannounced in the background. If an admin wants this functionality, Cockpit could install a cron job that does atomic host upgrade and shutdown -r +5m if a newer image got downloaded.

Prior art

UI Design

Clone this wiki locally