2017-10-26 21:20:01 +00:00
|
|
|
|
= AutoUpdates
|
|
|
|
|
|
2019-03-20 22:42:41 +00:00
|
|
|
|
include::{partialsdir}/unreviewed-message.adoc[]
|
2017-10-26 21:20:01 +00:00
|
|
|
|
|
|
|
|
|
[[automatic-updates]]
|
|
|
|
|
Automatic Updates
|
|
|
|
|
-----------------
|
|
|
|
|
|
2019-03-22 15:20:33 +00:00
|
|
|
|
You must decide whether to use automatic xref:dnf.adoc[DNF]
|
2017-10-26 21:20:01 +00:00
|
|
|
|
updates on each of your machines. There are a number of arguments both
|
|
|
|
|
for and against automatic updates to consider. However, there is no
|
2020-10-05 05:42:36 +00:00
|
|
|
|
single answer to this question: it is up to the system administrator or
|
2017-10-26 21:20:01 +00:00
|
|
|
|
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 onesself 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|yum repository on a local server,
|
|
|
|
|
and only put in it tested or trusted updates. Then use the automatic
|
|
|
|
|
updates from only your own repository. Such setups, while perhaps more
|
|
|
|
|
difficult to setup 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).
|
|
|
|
|
|
|
|
|
|
[[fedora-22-or-later-versions]]
|
|
|
|
|
Fedora 22 or later versions
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
|
|
|
|
The http://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.
|
|
|
|
|
|
|
|
|
|
....
|
|
|
|
|
dnf install dnf-automatic
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
Though, you have to change a configuration file. In order to do this,
|
|
|
|
|
run as the root user (or become root via su -) from a terminal window.
|
|
|
|
|
|
|
|
|
|
....
|
|
|
|
|
env EDITOR='gedit -w' sudoedit /etc/dnf/automatic.conf
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
Detailed description of dnf-automatic settings is provided on
|
|
|
|
|
http://dnf.readthedocs.org/en/latest/automatic.html[dnf-automatic] page.
|
|
|
|
|
|
|
|
|
|
[[run-dnf-automatic]]
|
|
|
|
|
Run dnf-automatic
|
|
|
|
|
+++++++++++++++++
|
|
|
|
|
|
|
|
|
|
Once you are finished with configuration, execute:
|
|
|
|
|
|
|
|
|
|
`systemctl enable dnf-automatic.timer && systemctl start dnf-automatic.timer`
|
|
|
|
|
|
|
|
|
|
to enable and start the systemd timer.
|
|
|
|
|
|
|
|
|
|
Check status of dnf-automatic:
|
|
|
|
|
|
|
|
|
|
`# 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.
|
|
|
|
|
|
2020-10-05 05:42:36 +00:00
|
|
|
|
* `dnf-automatic-download.timer` - Only download
|
|
|
|
|
* `dnf-automatic-install.timer` - Download and install
|
|
|
|
|
* `dnf-automatic-notifyonly.timer` - Only notify via configured emitters
|
2020-04-18 21:27:08 +00:00
|
|
|
|
in _/etc/dnf/automatic.conf_
|
2017-10-26 21:20:01 +00:00
|
|
|
|
|
|
|
|
|
You can still use _download_updates_ and _apply_updates_ settings from
|
|
|
|
|
inside _/etc/dnf/automatic.conf_.
|
|
|
|
|
|
|
|
|
|
[[fedora-21-or-earlier-versions]]
|
|
|
|
|
Fedora 21 or earlier versions
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
|
|
|
|
The yum-cron RPM package provides a service which is started
|
|
|
|
|
automatically. Though, you have to change a configuration file. In order
|
|
|
|
|
to do this, run as the root user (or become root via su -) from a
|
|
|
|
|
terminal window. On a fresh install of Fedora 20 with default options
|
|
|
|
|
the yum-cron RPM is not installed, the first command below installs this
|
|
|
|
|
RPM.
|
|
|
|
|
|
|
|
|
|
....
|
|
|
|
|
yum install -y yum-cron
|
|
|
|
|
env EDITOR='gedit -w' sudoedit /etc/yum/yum-cron.conf"
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
and enter your password. After, change the line
|
|
|
|
|
|
|
|
|
|
....
|
|
|
|
|
apply_updates = no
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
to
|
|
|
|
|
|
|
|
|
|
....
|
|
|
|
|
apply_updates = yes
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
Save the file. You are now done. Yum-cron updates your system every time
|
|
|
|
|
when there are new updates available.
|
|
|
|
|
|
|
|
|
|
[[can-we-trust-dnf-or-yum-updates]]
|
|
|
|
|
Can we trust dnf or yum updates?
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
Dnf and Yum in Fedora has the GPG key checking enabled by default.
|
|
|
|
|
Assuming that you have imported the correct GPG keys, and still have
|
2020-10-05 05:42:36 +00:00
|
|
|
|
gpgcheck=1 in your `/etc/dnf/dnf.conf` for dnf or `/etc/yum.conf` for yum, then we can at least assume that
|
2017-10-26 21:20:01 +00:00
|
|
|
|
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 they
|
|
|
|
|
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
|
2020-04-18 21:27:08 +00:00
|
|
|
|
acceptable.
|
2017-10-26 21:20:01 +00:00
|
|
|
|
* You can live without remote access to the machine until you can get to
|
2020-04-18 21:27:08 +00:00
|
|
|
|
its physical location to resolve problems.
|
2017-10-26 21:20:01 +00:00
|
|
|
|
* You do not have any irreplaceable data on the machine, or have proper
|
2020-04-18 21:27:08 +00:00
|
|
|
|
backups of such data.
|
2017-10-26 21:20:01 +00:00
|
|
|
|
|
|
|
|
|
If all of the above apply to your machine(s), then automatic updates may
|
|
|
|
|
be your best option to help secure your machine. If not all of 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
|
2020-04-18 21:27:08 +00:00
|
|
|
|
unscheduled downtime.
|
2017-10-26 21:20:01 +00:00
|
|
|
|
* You installed custom software, compiled software from source, or use
|
2020-04-18 21:27:08 +00:00
|
|
|
|
third party software that has strict package version requirements.
|
2017-10-26 21:20:01 +00:00
|
|
|
|
* You installed a custom kernel, custom kernel modules, third party
|
2020-04-18 21:27:08 +00:00
|
|
|
|
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 or yum.conf files). (But see also
|
|
|
|
|
https://bugzilla.redhat.com/show_bug.cgi?id=870790[bug #870790] - you
|
2020-10-05 05:42:36 +00:00
|
|
|
|
may need to modify `/etc/dnf/automatic.conf` in Fedora 22 or later versions in base section to add
|
|
|
|
|
exclude=kernel*. or in Fedora 21 or earlier versions `/etc/yum/yum-cron.conf` to
|
2020-04-18 21:27:08 +00:00
|
|
|
|
exclude=kernel*.)
|
2017-10-26 21:20:01 +00:00
|
|
|
|
* Your enviroment requires meticulous change-control procedures.
|
|
|
|
|
* You update from other third party yum|dnf repositories besides Fedora
|
2020-10-05 05:42:36 +00:00
|
|
|
|
(core, extras, legacy) repositories which may conflict in versioning
|
2020-04-18 21:27:08 +00:00
|
|
|
|
schemes for the same packages.
|
2017-10-26 21:20:01 +00:00
|
|
|
|
|
|
|
|
|
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
|
2020-04-18 21:27:08 +00:00
|
|
|
|
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 backup your configuration files before doing updates on critical
|
|
|
|
|
packages such as mail, web, or database server packages.
|
2017-10-26 21:20:01 +00:00
|
|
|
|
* Unwanted side effects. Some packages can create annoying side effects,
|
2020-04-18 21:27:08 +00:00
|
|
|
|
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.
|
2017-10-26 21:20:01 +00:00
|
|
|
|
* Bugs. Many packages contain buggy software or installation scripts.
|
2020-04-18 21:27:08 +00:00
|
|
|
|
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.
|
2017-10-26 21:20:01 +00:00
|
|
|
|
* Automatic updates may not complete the entire process needed to make
|
2020-04-18 21:27:08 +00:00
|
|
|
|
the system secure. For example, dnf or yum can install a kernel update,
|
|
|
|
|
but until the machine is rebooted (which dnf or yum 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.
|
2017-10-26 21:20:01 +00:00
|
|
|
|
|
|
|
|
|
[[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
|
2020-10-05 05:42:36 +00:00
|
|
|
|
dnf or yum has updated via its log file (usually or `/var/log/dnf.log` or `/var/log/yum.log`).
|
2017-10-26 21:20:01 +00:00
|
|
|
|
|
|
|
|
|
[[fedora-22-or-later-versions-1]]
|
|
|
|
|
Fedora 22 or later versions
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
|
|
|
|
You can monitor updates availability automatically by email after
|
2020-10-05 05:42:36 +00:00
|
|
|
|
modifying dnf-automatic configuration file (usually `/etc/dnf/automatic.conf`).
|
2017-10-26 21:20:01 +00:00
|
|
|
|
|
|
|
|
|
....
|
|
|
|
|
[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 a actual email address to which you want to
|
|
|
|
|
report sent, and localhost with a actual address of SMTP server. This
|
|
|
|
|
change will mean that after dnf-automatic runs, it will email you
|
|
|
|
|
information you about available updates, or log about downloaded
|
2020-10-05 05:42:36 +00:00
|
|
|
|
packages, or installed updates according to settings in `automatic.conf`.
|
2017-10-26 21:20:01 +00:00
|
|
|
|
|
|
|
|
|
[[fedora-21-or-earlier-versions-1]]
|
|
|
|
|
Fedora 21 or earlier versions
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
|
|
|
|
You can monitor this automatically by email by modifying the cron job to
|
|
|
|
|
mail you the last part of the log file. For example, edit
|
2020-10-05 05:42:36 +00:00
|
|
|
|
`/etc/cron.daily/yum.cron` so that it looks like the following:
|
2017-10-26 21:20:01 +00:00
|
|
|
|
|
|
|
|
|
....
|
|
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
if [ -f /var/lock/subsys/yum ] ; then
|
|
|
|
|
/usr/bin/yum -R 10 -e 0 -d 0 -y update yum
|
|
|
|
|
/usr/bin/yum -R 120 -e 0 -d 0 -y update
|
|
|
|
|
/usr/bin/tail /var/log/yum.log | /bin/mail -s yum-report youremail@yourdmain
|
|
|
|
|
fi
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
You would replace youremail@yourdomain with a actual email address to
|
|
|
|
|
which you want to report sent. This change will mean that after yum runs
|
|
|
|
|
every night, it will email you the tail end of the log file showing what
|
|
|
|
|
happened. (Note this assumes you have a working mail setup on your
|
|
|
|
|
machine.)
|
|
|
|
|
|
|
|
|
|
[[alternative-methods]]
|
|
|
|
|
Alternative methods
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
As an alternative to dnf-automatic or yum-cron,
|
|
|
|
|
https://github.com/rackerlabs/auter[auter] can be used. This operates in
|
|
|
|
|
a similar way to yum-cron, but provides more flexibility in scheduling,
|
|
|
|
|
and some additional options including running custom scripts before or
|
2020-10-05 05:42:36 +00:00
|
|
|
|
after updates, and automatic reboots. This comes at the expense of
|
2017-10-26 21:20:01 +00:00
|
|
|
|
more complexity to configure.
|
|
|
|
|
|
|
|
|
|
....
|
|
|
|
|
dnf install auter
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
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 contains lots of examples:
|
|
|
|
|
|
|
|
|
|
....
|
|
|
|
|
/etc/cron.d/auter
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
|
|
....
|
|
|
|
|
auter --apply
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
If you want to disable auter from running, including from any cron job:
|
|
|
|
|
|
|
|
|
|
....
|
|
|
|
|
auter --disable
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
[[alternatives-to-automatic-updates]]
|
|
|
|
|
Alternatives to automatic updates
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
[[notifications]]
|
|
|
|
|
Notifications
|
|
|
|
|
^^^^^^^^^^^^^
|
|
|
|
|
|
|
|
|
|
[[fedora-22-or-later-versions-2]]
|
|
|
|
|
Fedora 22 or later versions
|
|
|
|
|
+++++++++++++++++++++++++++
|
|
|
|
|
|
|
|
|
|
Instead of automatic updates, dnf-automatic can only download new
|
|
|
|
|
updates and can alert your via email of available updates which you
|
2020-10-05 05:42:36 +00:00
|
|
|
|
could then install manually. It can be set by editing of `/etc/dnf/automatic.conf` file.
|
2017-10-26 21:20:01 +00:00
|
|
|
|
|
|
|
|
|
[[fedora-21-or-earlier-versions-2]]
|
|
|
|
|
Fedora 21 or earlier versions
|
|
|
|
|
+++++++++++++++++++++++++++++
|
|
|
|
|
|
|
|
|
|
Instead of automatic updates yum can alert your via email of available
|
|
|
|
|
updates which you could then install manually. You could accomplish such
|
|
|
|
|
a setup with a cron job such as that listed below. Simply put this in
|
2020-10-05 05:42:36 +00:00
|
|
|
|
`/etc/cron.daily` with a suitable filename (such as
|
|
|
|
|
`yum-check-updates.cron`).
|
2017-10-26 21:20:01 +00:00
|
|
|
|
|
|
|
|
|
....
|
|
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
/usr/bin/yum check-update 2>&1 | /bin/mail -s "yum check-update output" root
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
You can of course change the email address it sends to, etc. to meet
|
|
|
|
|
your own needs.
|
|
|
|
|
|
|
|
|
|
[[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 the from the updates, it
|
|
|
|
|
may be best to avoid doing updates on those days.
|
|
|
|
|
|
|
|
|
|
[[fedora-22-or-later-versions-3]]
|
|
|
|
|
Fedora 22 or later versions
|
|
|
|
|
+++++++++++++++++++++++++++
|
|
|
|
|
|
|
|
|
|
This problem can be fixed by modification of the timer of dnf-automatic
|
|
|
|
|
using the description on
|
|
|
|
|
https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units[Use
|
|
|
|
|
Systemctl] page.
|
|
|
|
|
|
|
|
|
|
[[fedora-21-or-earlier-versions-3]]
|
|
|
|
|
Fedora 21 or earlier versions
|
|
|
|
|
+++++++++++++++++++++++++++++
|
|
|
|
|
|
|
|
|
|
One method is to use a crontab entry instead of the
|
2020-10-05 05:42:36 +00:00
|
|
|
|
`/etc/cron.daily/yum.conf` provided by default. For example, to only run
|
2017-10-26 21:20:01 +00:00
|
|
|
|
updates from Monday through Friday mornings (avoiding weekends), you
|
|
|
|
|
might use a crontab entry such as the following:
|
|
|
|
|
|
|
|
|
|
....
|
|
|
|
|
0 7 * * 1-5 /usr/bin/yum -y update
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
If you need more control over when it runs, you could create a file
|
2020-10-05 05:42:36 +00:00
|
|
|
|
called, for example, `/usr/local/etc/no-yum-update.conf`, which contains a
|
2017-10-26 21:20:01 +00:00
|
|
|
|
list of dates not to update on. What dates go in this file is up to you
|
|
|
|
|
to decide (vacations, holidays, etc). The dates would be in the format
|
|
|
|
|
YYYY-MM-DD (e.g. 2005-03-31). Then create a
|
2020-10-05 05:42:36 +00:00
|
|
|
|
`/etc/cron.daily/yum-update.cron` script something like the following:
|
2017-10-26 21:20:01 +00:00
|
|
|
|
|
|
|
|
|
....
|
|
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
today=$(date +%Y-%m-%d)
|
|
|
|
|
|
|
|
|
|
while read banned; do
|
|
|
|
|
[ "$today" == "$banned" ] && exit 0
|
|
|
|
|
done < /usr/local/etc/no-yum-update.conf
|
|
|
|
|
yum -y update
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
[[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
|
|
|
|
|
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 instrusions (with system log checkers, IDS systems,
|
|
|
|
|
authentication or login monitoring, etc).
|
|
|
|
|
|
|
|
|
|
'''''
|
|
|
|
|
|
|
|
|
|
Category:Documentation
|
|
|
|
|
'''
|
|
|
|
|
|
|
|
|
|
See a typo, something missing or out of date, or anything else which can be
|
2017-11-10 15:16:19 +00:00
|
|
|
|
improved? Edit this document at https://pagure.io/fedora-docs/quick-docs.
|