| |
@@ -1,254 +1,124 @@
|
| |
- = AutoUpdates
|
| |
-
|
| |
- [[automatic-updates]]
|
| |
- Automatic Updates
|
| |
- -----------------
|
| |
-
|
| |
- 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 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.
|
| |
+ = Enabling 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).
|
| |
+ You can use automatic xref:dnf.adoc[DNF] updates to keep your machines up to date without manual intervention.
|
| |
+ There are a number of arguments both for and against automatic updates to consider.
|
| |
|
| |
- [[fedora-22-or-later-versions]]
|
| |
- Fedora 22 or later versions
|
| |
- ^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
| |
+ The general rule that applies in most cases is as follows:
|
| |
|
| |
- 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.
|
| |
+ _If the machine is a server for which unplanned downtime of a service on the machine can not be tolerated, automatic updates should not be used.
|
| |
+ Otherwise, you *may* choose to use them._
|
| |
|
| |
- [[install-and-settings-of-dnf-automatic]]
|
| |
- Install and settings of dnf-automatic
|
| |
- +++++++++++++++++++++++++++++++++++++
|
| |
+ [[can-we-trust-dnf-or-yum-updates]]
|
| |
+ == Can we trust DNF or Yum updates?
|
| |
|
| |
- 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 and Yum in Fedora both have GPG key checking enabled by default.
|
| |
+ Assuming you have imported the correct GPG keys (and have `gpgcheck=1` in `/etc/dnf/dnf.conf` for DNF or `/etc/yum.conf` for Yum) then we can safely assume that the automatically installed updates were genuine.
|
| |
+ This also applies to non-Fedora third-party repositories.
|
| |
+ Please consult the documentation for any non-Fedora repositories for more details.
|
| |
|
| |
- ....
|
| |
- dnf install dnf-automatic
|
| |
- ....
|
| |
+ [[why-use-automatic-updates]]
|
| |
+ == Why use automatic updates?
|
| |
|
| |
- 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.
|
| |
+ The main advantage of automating updates is that machines are likely to get updated more often, more regularly, and more uniformly than if the updates are done manually.
|
| |
|
| |
- ....
|
| |
- env EDITOR='gedit -w' sudoedit /etc/dnf/automatic.conf
|
| |
- ....
|
| |
+ Some things which might make your machine a good candidate for automatic updates are:
|
| |
|
| |
- Detailed description of dnf-automatic settings is provided on
|
| |
- http://dnf.readthedocs.org/en/latest/automatic.html[dnf-automatic] page.
|
| |
+ * 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 have backups of data on the machine (or the data on the machine is not important enough and can be lost).
|
| |
|
| |
- [[run-dnf-automatic]]
|
| |
- Run dnf-automatic
|
| |
- +++++++++++++++++
|
| |
+ 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.
|
| |
|
| |
- Once you are finished with configuration, execute:
|
| |
+ [[why-not-use-automatic-updates]]
|
| |
+ == Why NOT use automatic updates?
|
| |
|
| |
- `systemctl enable dnf-automatic.timer && systemctl start dnf-automatic.timer`
|
| |
|
| |
- to enable and start the systemd timer.
|
| |
+ Some things which might make your machine be a bad candidate for automatic updates are:
|
| |
|
| |
- Check status of dnf-automatic:
|
| |
+ * It provides a service that you don't want to risk having unscheduled downtime for.
|
| |
+ * 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.
|
| |
+ ** You may need to modify in Fedora 22 or later versions in base section to add `exclude=kernel*`, or in Fedora 21 or earlier versions to `exclude=kernel*`.
|
| |
+ * Your environment requires meticulous change-control procedures.
|
| |
+ * You update from other third party Yum or DNF repositories besides Fedora (core, extras, legacy ) repositories which may conflict in versioning schemes for the same packages.
|
| |
|
| |
- `# systemctl list-timers *dnf-*`
|
| |
+ There are also some other reasons why installing automatic updates without testing may be a bad idea.
|
| |
+ A few such reasons are:
|
| |
|
| |
- [[changes-as-of-fedora-26]]
|
| |
- Changes as of Fedora 26
|
| |
+ * The need to back up your configuration files before an update.
|
| |
+ ** If you have modified a file which is not flagged as a configuration file, then you might lose your configuration changes.
|
| |
+ ** An update may have a different format of configuration file, requiring a manual reconfiguration.
|
| |
|
| |
- As of Fedora 26 there are now three timers that control dnf-automatic.
|
| |
+ * 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.
|
| |
|
| |
- * `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_
|
| |
+ * Automatic updates may not complete the entire process needed to make 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---leaving the system insecure.
|
| |
|
| |
- 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
|
| |
- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
| |
+ [[how-are-automatic-updates-done]]
|
| |
+ == How are automatic updates done?
|
| |
|
| |
- 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.
|
| |
+ You can use a service to automatically download and install new updates (for example, security updates).
|
| |
+ The http://dnf.readthedocs.org/en/latest/automatic.html[dnf-automatic] RPM package as a xref:dnf.adoc[DNF] component provides a service which is started automatically.
|
| |
|
| |
- ....
|
| |
- yum install -y yum-cron
|
| |
- env EDITOR='gedit -w' sudoedit /etc/yum/yum-cron.conf"
|
| |
- ....
|
| |
+ [[install-and-settings-of-dnf-automatic]]
|
| |
+ === Install and settings of dnf-automatic
|
| |
|
| |
- and enter your password. After, change the line
|
| |
+ On a fresh install of Fedora 22 or later, the dnf-automatic package is not installed.
|
| |
+ The command below installs this RPM.
|
| |
|
| |
....
|
| |
- apply_updates = no
|
| |
+ sudo dnf install dnf-automatic
|
| |
....
|
| |
|
| |
- to
|
| |
+ By default, the dnf-automation runs from the configurations in `/etc/dnf/automation.conf` file.
|
| |
+ These configurations only download, but do not apply updates.
|
| |
+ In order to change or add any configurations, open the `.conf` file as the root user from a terminal window.
|
| |
|
| |
....
|
| |
- apply_updates = yes
|
| |
+ env EDITOR='gedit -w' sudoedit /etc/dnf/automatic.conf
|
| |
....
|
| |
|
| |
- 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
|
| |
- gpgcheck=1 in your `/etc/dnf/dnf.conf` for dnf or `/etc/yum.conf` for yum, 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.
|
| |
+ Detailed description of dnf-automatic settings is provided on
|
| |
+ http://dnf.readthedocs.org/en/latest/automatic.html[dnf-automatic] page.
|
| |
|
| |
- [[why-use-automatic-updates]]
|
| |
- Why use Automatic updates?
|
| |
- ~~~~~~~~~~~~~~~~~~~~~~~~~~
|
| |
+ [[run-dnf-automatic]]
|
| |
+ === Run dnf-automatic
|
| |
|
| |
- 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.
|
| |
+ Once you are finished with configuration, execute:
|
| |
|
| |
- 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.
|
| |
+ ....
|
| |
+ sudo systemctl enable dnf-automatic.timer && sudo systemctl start dnf-automatic.timer
|
| |
+ ....
|
| |
|
| |
- [[reasons-for-using-automatic-updates]]
|
| |
- Reasons FOR using automatic updates
|
| |
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
| |
+ to enable and start the systemd timer.
|
| |
+ Check status of dnf-automatic:
|
| |
|
| |
- 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.
|
| |
+ ....
|
| |
+ sudo systemctl list-timers dnf-*
|
| |
+ ....
|
| |
|
| |
- 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 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
|
| |
- 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 or yum.conf files). (But see also
|
| |
- https://bugzilla.redhat.com/show_bug.cgi?id=870790[bug #870790] - you
|
| |
- 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
|
| |
- exclude=kernel*.)
|
| |
- * Your enviroment requires meticulous change-control procedures.
|
| |
- * You update from other third party yum|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 backup 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 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.
|
| |
+ As of Fedora 26, there are now three timers that can be enabled to control dnf-automatic:
|
| |
|
| |
- [[best-practices-when-using-automatic-updates]]
|
| |
- Best practices when using automatic updates
|
| |
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
| |
+ * `dnf-automatic-download.timer` - for downloading only,
|
| |
+ * `dnf-automatic-install.timer` - for downloading and installing,
|
| |
+ * `dnf-automatic-notifyonly.timer` - for notifications via configured emitters in `/etc/dnf/automatic.conf`.
|
| |
|
| |
- If you decide to use automatic updates, you should at least do a few
|
| |
- things to make sure you are up-to-date.
|
| |
+ You can still use `download_updates` and `apply_updates` settings from inside `/etc/dnf/automatic.conf`.
|
| |
|
| |
- Check for package updates which have been automatically performed, and
|
| |
- note if they need further (manual) intervention. You can monitor what
|
| |
- dnf or yum has updated via its log file (usually or `/var/log/dnf.log` or `/var/log/yum.log`).
|
| |
+ [[best-practices-when-using-automatic-updates]]
|
| |
+ === Best practices when using automatic updates
|
| |
|
| |
- [[fedora-22-or-later-versions-1]]
|
| |
- Fedora 22 or later versions
|
| |
- ^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
| |
+ If you decide to use automatic updates, you should at least do a few things to make sure you are up to date.
|
| |
|
| |
- You can monitor updates availability automatically by email after
|
| |
- modifying dnf-automatic configuration file (usually `/etc/dnf/automatic.conf`).
|
| |
+ * Check for package updates which have been automatically performed, and note if they need further manual intervention.
|
| |
+ * You can monitor what DNF or Yum has updated via its log file.
|
| |
+ * You can monitor updates availability automatically by email after modifying dnf-automatic configuration file.
|
| |
|
| |
....
|
| |
[emitters]
|
| |
@@ -265,181 +135,34 @@
|
| |
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
|
| |
- packages, or installed updates according to settings in `automatic.conf`.
|
| |
-
|
| |
- [[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
|
| |
- `/etc/cron.daily/yum.cron` so that it looks like the following:
|
| |
-
|
| |
- ....
|
| |
- #!/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.)
|
| |
+ You would replace `root` with a actual email address to which you want the report sent, and `localhost` with an actual address of SMTP server.
|
| |
+ This change will mean that after dnf-automatic runs, it will email you information about available updates, or logs about downloaded packages, or installed updates according to settings in the configuration file.
|
| |
|
| |
[[alternative-methods]]
|
| |
- 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
|
| |
- after updates, and automatic reboots. This comes at the expense of
|
| |
- more complexity to configure.
|
| |
+ 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 after updates, and automatic reboots.
|
| |
|
| |
....
|
| |
- dnf install auter
|
| |
+ sudo dnf install auter
|
| |
....
|
| |
|
| |
- Edit the configuration. Descriptions of the options are contained in the
|
| |
- conf file:
|
| |
+ Edit the configuration `/etc/auter/auter.conf`.
|
| |
+ Descriptions of the options are documented in the conf file:
|
| |
|
| |
- ....
|
| |
- /etc/auter/auter.conf
|
| |
- ....
|
| |
+ Auter is not scheduled to run by default.
|
| |
+ Add a schedule for `--prep` (to pre-download updates) and `--apply` (to install the updates).
|
| |
+ The installed cron job at `/etc/cron.d/auter` contains lots of examples:
|
| |
|
| |
- 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:
|
| |
+ 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:
|
| |
+ 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
|
| |
- could then install manually. It can be set by editing of `/etc/dnf/automatic.conf` file.
|
| |
-
|
| |
- [[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
|
| |
- `/etc/cron.daily` with a suitable filename (such as
|
| |
- `yum-check-updates.cron`).
|
| |
-
|
| |
- ....
|
| |
- #!/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
|
| |
- `/etc/cron.daily/yum.conf` provided by default. For example, to only run
|
| |
- 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
|
| |
- called, for example, `/usr/local/etc/no-yum-update.conf`, which contains a
|
| |
- 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
|
| |
- `/etc/cron.daily/yum-update.cron` script something like the following:
|
| |
-
|
| |
- ....
|
| |
- #!/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
|
| |
- improved? Edit this document at https://pagure.io/fedora-docs/quick-docs.
|
| |
t0xic0der commented 3 years ago
https://pagure.io/fedora-docs/quick-docs/pull-request/306#_2__8: Not to assume folks have multiple machines from the get-go, we should add a "Should you have multiple Fedora installations" in front.