How To Enable automatic updates in Centos 7 and RHEL 7

Install yum-cron

The package that allows us to do automatic updates via yum is yum-cron, to do this just open a terminal as root and run the command:

yum -y install yum-cron

This will install the yum-cron package, now it’s time to configure it, the default configuration file it’s /etc/yum/yum-cron.conf.

Configure yum-cron for auto-update

In the first part of the file you’ll find these options (these are the defaults):

#  What kind of update to use:
# default                            = yum upgrade
# security                           = yum --security upgrade
# security-severity:Critical         = yum --sec-severity=Critical upgrade
# minimal                            = yum --bugfix upgrade-minimal
# minimal-security                   = yum --security upgrade-minimal
# minimal-security-severity:Critical =  --sec-severity=Critical upgrade-minimal
update_cmd = default

# Whether a message should be emitted when updates are available,
# were downloaded, or applied.
update_messages = yes

# Whether updates should be downloaded when they are available.
download_updates = yes

# Whether updates should be applied when they are available.  Note
# that download_updates must also be yes for the update to be applied.
apply_updates = no

# Maximum amout of time to randomly sleep, in minutes.  The program
# will sleep for a random amount of time between 0 and random_sleep
# minutes before running.  This is useful for e.g. staggering the
# times that multiple systems will access update servers.  If
# random_sleep is 0 or negative, the program will run immediately.
# 6*60 = 360
random_sleep = 360

In my opinion the first it’s the most interesting, while on rhel/centos 6 we were unable to choose which kind of update do in automatic we are plenty of options in rhel/centos 7.

As you can see the default it’s to upgrade all your packages, the same you’d obtain with the command yum upgrade, but there are also other options and now you can decide to just do security upgrade or even just the most critical security, this add a lot of flexibility and options.

As example you can now do full upgrades on your development machines and just the minimum to stay security safe on your production servers, this make sense and it’s good to be finally able to specify this.

How to have an output of the results

There are 2 setup that you can tweak to get feedbacks from this procedure:

1) As first option you can decide to send messages to standard output or via email with the option emit_via

# How to send messages.  Valid options are stdio and email.  If
# emit_via includes stdio, messages will be sent to stdout; this is useful
# to have cron send the messages.  If emit_via includes email, this
# program will send email itself according to the configured options.
# If emit_via is None or left blank, no messages will be sent.
emit_via = stdio

2) If you choose to send the output via email you have some option available to set the most common options for an email:

[email]
# The address to send email messages from.
email_from = root@localhost

# List of addresses to send messages to.
email_to = 

# Name of the host to connect to to send email messages.
email_host = localhost

Verify that the service is running

Once installed the service should be enabled by default, but to be sure you can verify it with the commandsystemctl status yum-cron.service that should give an output similar to this one:

# /bin/systemctl status yum-cron.service yum-cron.service - Run automatic yum updates as a cron job Loaded: loaded (/usr/lib/systemd/system/yum-cron.service; enabled) Active: active (exited) since sab 2014-08-09 00:37:16 CEST; 16h ago Process: 830 ExecStart=/bin/touch /var/lock/subsys/yum-cron (code=exited, status=0/SUCCESS) Main PID: 830 (code=exited, status=0/SUCCESS) CGroup: /system.slice/yum-cron.service

If you see that the service is stopped you can start it with the command

systemctl start yum-cron.service

Conclusions

By default this package is not present and so, unless you have a tight schedule and care of updating your servers, I strongly suggest to install and enable it, and keep the most “wide” upgrade option that should not break your services.
As example I’ve a server with apache and php, I know the application and everything is installed from the repositories, I’m “quiet” sure that a full upgrade of the system will not broke anything and so I’ve choose to keep the default option and upgrade all the packages.

On the other way on systems where I don’t know well the applications, or something is installed from the sources I’d keep the automatic upgrades only for security reasons.