Production web servers should be kept secure, but some packages need a bleeding edge version.
Smart engineers will not have all system packages automatically upgrade. We don’t know new versions’ effect on the system. But you still want all packages to auto-upgrade in case there are critical security updates.
In RedHat 7, you can use yum-cron for the job of automatic security upgrades. Simply install it via yum install yum-cron and adjust its configuration file to include the proper update command. In /etc/yum/yum-cron.conf:
update_cmd = minimal-security-severity:Critical
Now enable the service and start it:
systemctl enable yum-cron
systemctl start yum-cron
This ensures that only critical security updates are applied.
However, if you use cloud-based services on your server, you want their client packages to be always the latest version. One shining example of this would be Nginx Amplify. It is recommended to always have the latest version of its agent installed.
Provided that we don’t want to auto-upgrade the whole system to bleeding versions just for one package, what could we do?
Surely, we could put something like this in cron:
@daily /usr/bin/yum --assumeyes --quiet --errorlevel=0 update nginx-amplify-agent
This is what I actually did at first. Even then, I wasn’t happy of this solution as I couldn’t leverage yum-cron for the job.
I was further less happy when I added another cron job of the same kind for another package. I started to get cron notifications about yum waiting to release its locks. Two jobs were fighting each other for the yum lock file:
Existing lock /var/run/yum.pid: another copy is running as pid 48048.
Perusing the yum configuration file, I came to a solution which I really love. Now I can automatically update specific packages while keeping the rest of the system auto-update only if they have critical security updates. This gives me a stable system which continuously works with cloud services like Nginx Amplify.
Let’s set Nginx Amplify to auto-update in a proper way.
Autoupdate Nginx Amplify
First, I assume you already have a .repo file for Amplify agent in your system. What we’re going to do is create a directory with .repo files of packages we want to auto-update for any kind of upgrades, secure or not:
mkdir /etc/yum.auto.repos.d
chmod 0755 /etc/yum.auto.repos.d
chown root:root /etc/yum.auto.repos.d
Now we will symlink our Nginx Amplify .repo file from the regular repos.d directory:
cd /etc/yum.auto.repos.d
ln -s /etc/yum.repos.d/nginx-amplify.repo
Next, create a yum-cron configuration file, which contains the magic ingredient for using only our yum.auto.repos.d directory for the job. This will ensure that other repositories will not be used.
nano /etc/yum/yum-cron-auto.conf
Put the following configuration inside:
[commands]
# We will always upgrade
update_cmd = default
# Whether a message should emitted when updates are available.
update_messages = yes
# Whether updates should be downloaded when they are available. Note
# that updates_messages must also be yes for updates to be downloaded.
download_updates = yes
# Whether updates should be applied when they are available. Note
# that both update_messages and download_updates must also be yes for
# the update to be applied
apply_updates = yes
# 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.
random_sleep = 0
[emitters]
# Name to use for this system in messages that are emitted. If
# system_name is None, the hostname will be used.
system_name = None
# 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
# The width, in characters, that messages that are emitted should be
# formatted to.
output_width = 80
[email]
# The address to send email messages from.
# NOTE: 'localhost' will be replaced with the value of system_name.
email_from = root
# List of addresses to send messages to.
email_to = root
# Name of the host to connect to to send email messages.
email_host = localhost
[groups]
# List of groups to update
group_list = None
# The types of group packages to install
group_package_types = mandatory, default
[base]
# This section overrides yum.conf
# Use this to filter Yum core messages
# -4: critical
# -3: critical+errors
# -2: critical+errors+warnings (default)
debuglevel = -2
# skip_broken = True
mdpolicy = group:main
# Uncomment to auto-import new gpg keys (dangerous)
# assumeyes = True
# Here comes the magic:
reposdir=/etc/yum.auto.repos.d
The final part of the whole setup would be to create the actual cron job which uses yum-cron. Create /etc/cron.daily/yum-auto.cron with the following contents and make it executable (chmod +x):
#!/bin/bash
# Only run if this flag is set. The flag is created by the yum-cron init
# script when the service is started -- this allows one to use chkconfig and
# the standard "service stop|start" commands to enable or disable yum-cron.
if [[ ! -f /var/lock/subsys/yum-cron ]]; then
exit 0
fi
# Action!
exec /usr/sbin/yum-cron /etc/yum/yum-cron-auto.conf
Our daily cron job uses yum-cron with the special configuration that we have created earlier. So yum will use only specific repositories for automatic package upgrades.
Welcome to the fresh and stable server and enjoy using latest Nginx Amplify agent.