Enabling automatic updates in Centos 7 and RHEL 7
In previous posts we’ve seen how to Enable automatic security update in Debian/Ubuntu and in Red hat enterprise or Centos 6, recently I’ve started to work with the new Red Hat Enterprise 7 and I’ve noticed that there are some interesting changes in the way this system can be set to auto update.
An example ?
In Red Hat/Centos 6 you could not set which kind of update you’d like to do, so you could just decide to update for any kind of update (feature,bug or security) or nothing at all, this has changed and now we can fine grain which kind of updates we want to do on our servers.
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:
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 command systemctl status yum-cron.service
that should give an output similar to this one:
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.