mirror of
https://pagure.io/fedora-docs/quick-docs.git
synced 2024-10-18 17:26:29 +00:00
a41da0d4ee
Without the single quotes, the command may not work depending on the files in the current directory.
303 lines
12 KiB
Text
303 lines
12 KiB
Text
= Automatic Updates
|
||
Ben Cotton; Petr Bokoc; Jean-Baptiste Holcroft
|
||
:revnumber: all
|
||
:revdate: 2022
|
||
:category: Administration
|
||
:tags: How-to, DNF, Updates
|
||
//:imagesdir: ./images
|
||
|
||
|
||
You must decide whether to use automatic xref:dnf.adoc[DNF]
|
||
updates on each of your machines. There are a number of arguments both
|
||
for and against automatic updates to consider. However, there is no
|
||
single answer to this question: it is up to the system administrator or
|
||
owner of each machine to decide whether automatic updates are desirable
|
||
or not for that machine. One of the things which makes one a good system
|
||
administrator is the ability to evaluate the facts and other people's
|
||
suggestions, and then decide for oneself what one should do.
|
||
|
||
A general rule that applies in most cases is as follows:
|
||
|
||
_If the machine is a critical server, for which unplanned downtime of a
|
||
service on the machine can not be tolerated, then you should not use
|
||
automatic updates. Otherwise, you *may* choose to use them._
|
||
|
||
Even the general rule above has exceptions, or can be worked around.
|
||
Some issues might be resolved through a special setup on your part. For
|
||
example, you could create your own DNF repository on a local server,
|
||
and only put in tested or trusted updates. Then use the automatic
|
||
updates from only your own repository. Such setups, while perhaps more
|
||
difficult to set up and maintain, can remove a large amount of risk
|
||
otherwise inherent in automatic updates.
|
||
|
||
[[how-are-automatic-updates-done]]
|
||
== How are automatic updates done?
|
||
|
||
You can use a service to automatically download and install any new
|
||
updates (for example security updates).
|
||
|
||
The https://dnf.readthedocs.org/en/latest/automatic.html[dnf-automatic]
|
||
RPM package as a link:dnf[DNF] component provides a service which is
|
||
started automatically.
|
||
|
||
[[install-and-settings-of-dnf-automatic]]
|
||
=== Install and settings of dnf-automatic
|
||
|
||
On a fresh install of Fedora 22 with default options, the dnf-automatic
|
||
RPM is not installed. The first command below installs this RPM:
|
||
|
||
[source,bash]
|
||
----
|
||
sudo dnf install dnf-automatic
|
||
----
|
||
|
||
By default, dnf-automatic runs from the configurations in the `/etc/dnf/automatic.conf` file. These configurations only download, but do not apply any of the packages. In order to change or add any configurations, open the `.conf` file as the root user (or using `sudo`) from a terminal window.
|
||
|
||
[source,bash]
|
||
----
|
||
env EDITOR='gedit -w' sudoedit /etc/dnf/automatic.conf
|
||
----
|
||
|
||
Detailed description of dnf-automatic settings is provided on the
|
||
https://dnf.readthedocs.org/en/latest/automatic.html[dnf-automatic] page.
|
||
|
||
[[run-dnf-automatic]]
|
||
=== Run dnf-automatic
|
||
|
||
Once you are finished with the configuration, execute:
|
||
|
||
[source,bash]
|
||
----
|
||
systemctl enable --now dnf-automatic.timer
|
||
----
|
||
|
||
to enable and start the `systemd` timer.
|
||
|
||
Check status of `dnf-automatic`:
|
||
|
||
[source,bash]
|
||
----
|
||
systemctl list-timers 'dnf-*'
|
||
----
|
||
|
||
[[changes-as-of-fedora-26]]
|
||
=== Changes as of Fedora 26
|
||
|
||
As of Fedora 26 there are now three timers that control dnf-automatic.
|
||
|
||
* `dnf-automatic-download.timer` - Only download
|
||
* `dnf-automatic-install.timer` - Download and install
|
||
* `dnf-automatic-notifyonly.timer` - Only notify via configured emitters
|
||
in `/etc/dnf/automatic.conf`
|
||
|
||
You can still use `download_updates` and `apply_updates` settings from
|
||
inside `/etc/dnf/automatic.conf`.
|
||
|
||
[[can-we-trust-dnf-updates]]
|
||
== Can we trust DNF updates?
|
||
|
||
Dnf in Fedora has the GPG key checking enabled by default.
|
||
Assuming that you have imported the correct GPG keys, and still have
|
||
`gpgcheck=1` in your `/etc/dnf/dnf.conf`, then we can at least assume that
|
||
any automatically installed updates were not corrupted or modified from
|
||
their original state. Using the GPG key checks, there is no way for an
|
||
attacker to generate packages that your system will accept as valid
|
||
(unless they have a copy of the *private* key corresponding to one you
|
||
installed) and any data corruption during download would be caught.
|
||
|
||
However, the question would also apply to the question of update
|
||
quality. Will the installation of the package cause problems on your
|
||
system? This we can not answer. Each package goes through a QA process,
|
||
and is assumed to be problem free. But, problems happen, and QA can not
|
||
test all possible cases. It is always possible that any update may cause
|
||
problems during or after installation.
|
||
|
||
[[why-use-automatic-updates]]
|
||
== Why use automatic updates?
|
||
|
||
The main advantage of automating the updates is that machines are likely
|
||
to get updated more quickly, more often, and more uniformly than if the
|
||
updates are done manually. We see too many compromised machines on the
|
||
internet which would have been safe if the latest updates where
|
||
installed in a timely way.
|
||
|
||
So while you should still be cautious with any automated update
|
||
solution, in particular on production systems, it is definitely worth
|
||
considering, at least in some situations.
|
||
|
||
[[reasons-for-using-automatic-updates]]
|
||
=== Reasons FOR using automatic updates
|
||
|
||
While no one can determine for you if your machine is a good candidate
|
||
for automatic updates, there are several things which tend to make a
|
||
machine a better candidate for automatic updates.
|
||
|
||
Some things which might make your machine a good candidate for automatic
|
||
updates are:
|
||
|
||
* You are unlikely to apply updates manually for whatever reason(s).
|
||
* The machine is not critical and occasional unplanned downtime is
|
||
acceptable.
|
||
* You can live without remote access to the machine until you can get to
|
||
its physical location to resolve problems.
|
||
* You do not have any irreplaceable data on the machine, or have proper
|
||
backups of such data.
|
||
|
||
If all the above apply to your machine(s), then automatic updates may
|
||
be your best option to help secure your machine. If not all the above
|
||
apply, then you will need to weigh the risks and decide for yourself if
|
||
automatic updates are the best way to proceed.
|
||
|
||
[[reasons-against-using-automatic-updates]]
|
||
=== Reasons AGAINST using automatic updates
|
||
|
||
While no one can determine for you if your machine is a bad candidate
|
||
for automatic updates, there are several things which tend to make a
|
||
machine a worse candidate for automatic updates.
|
||
|
||
Some things which might make your machine be a bad candidate for
|
||
automatic updates are:
|
||
|
||
* It provides a critical service that you don't want to risk having
|
||
unscheduled downtime.
|
||
* You installed custom software, compiled software from source, or use
|
||
third party software that has strict package version requirements.
|
||
* You installed a custom kernel, custom kernel modules, third party
|
||
kernel modules, or have a third party application that depends on kernel
|
||
versions (this may not be a problem if you exclude kernel updates, which
|
||
is the default in Fedora `dnf.conf` files). (See also
|
||
https://bugzilla.redhat.com/show_bug.cgi?id=870790[bug #870790] - you
|
||
may need to modify the base section to add
|
||
`exclude=kernel*`.)
|
||
* Your environment requires meticulous change-control procedures.
|
||
* You update from other third party DNF repositories besides Fedora
|
||
(core, extras, legacy), repositories which may conflict in versioning
|
||
schemes for the same packages.
|
||
|
||
There are also some other reasons why installing automatic updates
|
||
without testing may be a bad idea. A few such reasons are:
|
||
|
||
* The need to back up your configuration files before an update. Even
|
||
the best package spec files can have mistakes. If you have modified a
|
||
file which is not flagged as a configuration file, then you might lose
|
||
your configuration changes. Or an update may have a different format of
|
||
configuration file, requiring a manual reconfiguration. It is often best
|
||
to back up your configuration files before doing updates on critical
|
||
packages such as mail, web, or database server packages.
|
||
* Unwanted side effects. Some packages can create annoying side effects,
|
||
particularly ones which have cron jobs. Updates to base packages like
|
||
openssl, openldap, sql servers, etc. can have an effect on many other
|
||
seemingly unrelated packages.
|
||
* Bugs. Many packages contain buggy software or installation scripts.
|
||
The update may create problems during or after installation. Even cosmetic bugs, like those found in previous Mozilla updates causing the user's icons to be removed or break, can be annoying or problematic.
|
||
* Automatic updates may not complete the entire process needed to make the system secure. For example, DNF can install a kernel update, but until the machine is rebooted (which DNF will not do automatically) the new changes won't take effect.
|
||
The same may apply to restarting daemons. This can leave the user feeling that he is secure when he is not.
|
||
|
||
|
||
[[best-practices-when-using-automatic-updates]]
|
||
== Best practices when using automatic updates
|
||
|
||
If you decide to use automatic updates, you should at least do a few
|
||
things to make sure you are up-to-date.
|
||
|
||
Check for package updates which have been automatically performed, and
|
||
note if they need further (manual) intervention. You can monitor what
|
||
DNF has updated via its log file (usually `/var/log/dnf.log`).
|
||
|
||
You can monitor updates availability automatically by email after
|
||
modifying the dnf-automatic configuration file (usually `/etc/dnf/automatic.conf`).
|
||
|
||
[source,bash]
|
||
----
|
||
[emitters]
|
||
emit_via = email
|
||
|
||
[email]
|
||
# The address to send email messages from.
|
||
email_from = root@localhost.com
|
||
|
||
# List of addresses to send messages to.
|
||
email_to = root
|
||
|
||
# Name of the host to connect to to send email messages.
|
||
email_host = localhost
|
||
----
|
||
|
||
You would replace root with an actual email address to which you want the
|
||
report sent, and localhost with an actual address of a SMTP server. This
|
||
change will mean that after dnf-automatic runs, it will email you
|
||
information about available updates, a log about downloaded
|
||
packages, or installed updates according to settings in `automatic.conf`.
|
||
|
||
[[alternative-methods]]
|
||
== Alternative methods
|
||
|
||
As an alternative to dnf-automatic,
|
||
https://github.com/rackerlabs/auter[auter] can be used. This operates in
|
||
a similar way to dnf-automatic, but provides more flexibility in scheduling,
|
||
and some additional options including running custom scripts before or
|
||
after updates, and automatic reboots. This comes at the expense of
|
||
more complexity to configure.
|
||
|
||
[source,bash]
|
||
----
|
||
sudo dnf install auter
|
||
----
|
||
|
||
You should then edit the configuration. Descriptions of the options are contained in the
|
||
conf file `/etc/auter/auter.conf`.
|
||
|
||
Auter is not scheduled by default. Add a schedule for `--prep` (if you
|
||
want to pre-download updates) and `--apply` (install updates). The
|
||
installed cron job which you can see in `/etc/cron.d/auter` contains lots of examples.
|
||
|
||
To make auter run immediately without waiting for the cron job to run,
|
||
for example for testing or debugging, you can simply run it from the
|
||
command line:
|
||
|
||
[source,bash]
|
||
----
|
||
auter --apply
|
||
----
|
||
|
||
If you want to disable auter from running, including from any cron job:
|
||
|
||
[source,bash]
|
||
----
|
||
auter --disable
|
||
----
|
||
|
||
[[alternatives-to-automatic-updates]]
|
||
== Alternatives to automatic updates
|
||
|
||
[[notifications]]
|
||
=== Notifications
|
||
|
||
Instead of automatic updates, dnf-automatic can only download new
|
||
updates and can alert you via email of available updates which you
|
||
could then install manually. This can be set by editing of `/etc/dnf/automatic.conf` file.
|
||
|
||
[[scheduling-updates]]
|
||
=== Scheduling updates
|
||
|
||
Another common problem is having automatic updates run when it isn't
|
||
desired (holidays, weekends, vacations, etc). If there are times that no
|
||
one will be around to fix any problem arising from the updates, it
|
||
may be best to avoid doing updates on those days.
|
||
|
||
This problem can be fixed by modification of the timer of dnf-automatic
|
||
using the description on the
|
||
xref:understanding-and-administering-systemd.adoc[Understanding and administering systemd]
|
||
page.
|
||
|
||
[[other-methods-of-protection]]
|
||
=== Other methods of protection
|
||
|
||
Yet another thing to consider if not using automatic updates is to
|
||
provide your machine with some other forms of protection to help defend it of
|
||
any attacks that might occur before updates are in place. This might
|
||
include an external firewall, a host-based firewall (like iptables,
|
||
ipchains, and/or tcp wrappers), not performing dangerous tasks on the
|
||
computer (like browsing the web, reading e-mail, etc.), and monitoring
|
||
the system for intrusions (with system log checkers, IDS systems,
|
||
authentication or login monitoring, etc).
|