Keeping the Linux systems updated

Spend some time perusing the Common Vulnerabilities and Exposures database, and you'll soon see why it's so important to keep your systems updated. Yes, indeed, you'll even find that there have been security flaws with our beloved Linux, as shown in the following screenshot:

Updating a Linux system only requires one or two simple commands, and it's generally faster and less painful than updating a Windows system.

You can find the Common Vulnerabilities and Exposures database here:

https://cve.mitre.org/.

All of you conscientious, dedicated Linux administrators will definitely want to become familiar with this site.

Updating Debian-based systems

Let's take a look at how to update Debian-based systems:

1. On Debian and its many children, including Ubuntu, run two commands, as shown here:

sudo apt update
sudo apt dist-upgrade

2. Occasionally, you'll also need to remove some old packages that are no longer needed. How will you know? Easy. When you log in to the system, a message will appear on the command line. To remove these old packages, just run the following command:

sudo apt auto-remove

Next, we will configure auto updates for Ubuntu.

Configuring auto updates for Ubuntu

A new feature of Ubuntu 18.04 LTS that wasn't in Ubuntu 16.04 LTS is that you can configure it to automatically install security updates. You can see that here on the installer screen:

I must confess, though, that I have mixed feelings about this. I mean, it's nice that the security updates get installed without me having to do anything, but a lot of those updates require that the system be rebooted before they can take effect. By default, Ubuntu systems don't automatically reboot after an update is installed. If you keep it that way, you'll see a message about it when you log in to the system. But if you prefer, you can set Ubuntu to automatically reboot after it automatically updates itself. Here's how to do this:

1. Go into the /etc/apt/apt.conf.d directory and open the 50unattended-upgrades file in your favorite text editor. In the vicinity of line 68, you'll see a line that says the following:

//Unattended-Upgrade::Automatic-Reboot "false";

2. Uncomment the line by removing the leading slashes, and change false to true, like so:

Unattended-Upgrade::Automatic-Reboot "true";

3. With this new configuration, Ubuntu will now reboot itself immediately after the automatic update process has completed. If you'd rather have the machine reboot at a specific time, scroll down to about line 73, where you'll see this line of code:

//Unattended-Upgrade::Automatic-Reboot-Time "02:00";

4. Since this line is commented out with its pair of leading slashes, it currently has no effect. To have the machine reboot at 2:00 A.M., just uncomment this line. To have it reboot at, say, 10:00 P.M., uncomment the line and change the time to 22:00, like so:

Unattended-Upgrade::Automatic-Reboot-Time "22:00";

Of course, there's that old, basic precept that thou shalt not install system updates on a production system without first testing them on a test system. Any operating system vendor can occasionally supply you with problematic updates, and that has included Ubuntu. (I know what you're saying: Preach it, Donnie.) Ubuntu's automatic update feature is in direct opposition to that basic precept. If automatic updates have been enabled, disabling them is quite easy, if you choose to do so:

1. To disable automatic updates, just go into the /etc/apt/apt.conf.d directory and open the 20auto-upgrades file in your favorite text editor. What you'll see is this:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

2. Change the parameter for that second line to 0, so that the file will now look like this:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "0";

Now, the system will still check for updates and show a message at the login screen when any are available, but it won't automatically install them. And of course, it should go without saying that you need to check your systems on a regular basis to see if updates are available. If you do prefer to leave automatic updates enabled, be sure to either enable automatic rebooting or to log in to the system at least a couple of times a week to see if it needs to be rebooted.

3. If you want to see if there are any security-related updates available, but don't want to see any non-security updates, use the unattended-upgrade command, like so:

sudo unattended-upgrade --dry-run -d

4. To manually install the security-related updates without installing non-security updates, just run the following line of code:

sudo unattended-upgrade -d

If you're running some form of desktop Ubuntu on a workstation that gets shut down after every use, you can enable the automatic updates if you like, but there's no need to enable automatic reboots.

Also, if you're running a non-Ubuntu flavor of Debian, which would include Raspbian for the Raspberry Pi, you can give it the same functionality as Ubuntu by installing the unattended-upgrades package. Just run the following line of code:

sudo apt install unattended-upgrades

You can also use the apt command to install only the security updates, but it would require piping the apt output into a convoluted set of text filters in order to mask the non-security updates. Using the unattended-upgrade command is much easier.

I said before that we should always test updates on a test system before we install them on a production system, and that certainly does hold true for corporate servers. But what do we do when we have a whole bunch of IoT devices that we need to keep updated, especially if these devices are all over the place out in the field and in consumer devices?

In the wonderful world of IoT, the ARM CPU versions of Ubuntu, Raspbian, and Debian are the most popular Linux distros for use on the various Pi devices, including the ubiquitous Raspberry Pi. If you have lots of IoT devices in the field and in consumer devices, you might not have direct control over them once they've been deployed or sold. They still need to be kept updated, so setting up unattended updates with automatic rebooting would certainly be advantageous. But keep in mind that in the world of IoT, we have to be concerned about safety as well as security. So, for example, if you have devices that are set up as some sort of critical, safety-related industrial controller, then you most likely don't want the device to automatically reboot after doing automatic updates. But if you're a television vendor who installs Linux on smart televisions, then definitely set them up to automatically update and to automatically reboot themselves after an update.

Updating Red Hat 7-based systems

With Red Hat-based systems, which include CentOS and Oracle Linux, there's no automatic update mechanism that you can set up during installation. So, with the default configuration, you'll need to perform updates yourself:

1. To update a Red Hat 7-based system, just run this one command:

sudo yum upgrade

2. Sometimes, you might just want to see if there are any security-related updates that are ready to be installed. Do that by running the following command:

sudo yum updateinfo list updates security

3. If any security updates are available, you'll see them at the end of the command output. On the system that I just tested, there was only one security update available, which looks like this:

FEDORA-EPEL-2019-d661b588d2 Low/Sec. nagios-common-4.4.3-1.el7.x86_64

updateinfo list done

4. If the only thing you want to install is just the security updates, run the following command:

sudo yum upgrade --security

5. Now, let's say that you need a CentOS system to automatically update itself. You're in luck because there's a package for that. Install and enable it, and start it by running the following commands:

sudo yum install yum-cron

sudo systemctl enable --now yum-cron

6. To configure it, go into the /etc/yum directory, and edit the yum-cron.conf file. At the top of the file, you'll see this:

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

This lists the various types of upgrades we can do. The last line shows that we're set to update everything.

7. Let's say that you only want security updates to get applied automatically. Just change the last line to the following:

update_cmd = security

8. On lines 15 and 20, you'll see this line:

download_updates = yes
apply_updates = no

This indicates that by default, yum-cron is only set to automatically download updates, but not to install them.

9. If you want the updates to get automatically installed, change the apply_updates parameter to yes.

Note that unlike Ubuntu, there's no setting to make the system automatically reboot itself after an update.

10. Finally, let's look at the mail settings for yum-cron, which you'll find on lines 48 through 57 of the yum-cron.conf file, as shown here:

[email]
# The address to send email messages from.
# NOTE: 'localhost' will be replaced with the value of system_name.
email_from = root@localhost

# List of addresses to send messages to.
email_to = root

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

As you can see, the email_to = line is set to send messages to the root user account. If you want to receive messages at your own account, just change it here.

11. To see the messages, you'll need to install a mail reader program, if one isn't already installed. (It hasn't been installed if you chose Minimal installation when you installed the operating system.) Your best bet is to install mutt, like so:

sudo yum install mutt

12. When you open mutt and look at a message, you'll see something like this:

13. As with all operating systems, certain updates will require that the system be restarted. And how do you know when the system needs to be restarted? With the needs-restarting command, of course. First, though, you need to make sure that needs-restarting is installed on your system. Do that with the following line of code:

sudo yum install yum-utils

Once the package is installed, there are three ways to use needs-restarting. If you just run the command without any option switches, you'll see the services that need to be restarted and the packages that require you to reboot the machine. You can also use the -s or -r options, as shown here:

Command	Explanation
sudo needs-restarting	This shows the services that need to be restarted, and the reasons why the system might need to be rebooted.
sudo needs-restarting -s	This only shows the services that need to be restarted.
sudo needs-restarting -r	This only shows the reasons why the system needs to be rebooted.

Next, we will be updating Red Hat 8-based systems.

Updating Red Hat 8-based systems

The old yum utility has been around for practically forever, and it's been a good, hard-working utility. But it does have its occasional quirks, and at times it can be excruciatingly slow. But not to worry. Our heroes at Red Hat have finally done something about that, by replacing yum with dnf. Now, dnf has been tested on the Fedora distro for the past few years, and it's now a part of the RHEL 8 family. So, when you work with your CentOS 8 virtual machines, you'll use dnf instead of yum. Let's see how to do this:

1. For the most part, you use dnf the same way that you'd use yum, with the same arguments and options. For example, to do a system upgrade, just run the following command:

sudo dnf upgrade

2. The main functional difference between yum and dnf is that dnf has a different automatic update mechanism. Instead of installing the yum-cron package, you'll now install the dnf-automatic package, like so:

sudo dnf install dnf-automatic

3. In the /etc/dnf directory, you'll see the automatic.conf file, which you'll configure the same way as you did the yum-cron.conf file for CentOS 7. Instead of working as a cron job, as the old yum-cron did, dnf-automatic works with a systemd timer. When you first install dnf-automatic, the timer is disabled. Enable it and start it by running the following line of code:

sudo systemctl enable --now dnf-automatic.timer

4. Verify that it's running by typing the following line of code:

sudo systemctl status dnf-automatic.timer

5. If it started successfully, you should see something like this:

[donnie@redhat-8 ~]$ sudo systemctl status dnf-automatic.timer
 dnf-automatic.timer - dnf-automatic timer
   Loaded: loaded (/usr/lib/systemd/system/dnf-automatic.timer; enabled; vendor preset: disabled)
   Active: active (waiting) since Sun 2019-07-07 19:17:14 EDT; 13s ago
  Trigger: Sun 2019-07-07 19:54:49 EDT; 37min left

Jul 07 19:17:14 redhat-8 systemd[1]: Started dnf-automatic timer.
[donnie@redhat-8 ~]$

For more details about dnf-automatic, type the following command:

man dnf-automatic

And that's all there is to it.

Automatic updating sounds like a good thing, right? Well, it is in some circumstances. On my own personal Linux workstations, I always like to turn it off. That's because it drives me crazy whenever I want to install a package, and the machine tells me that I have to wait until the update process finishes. In an enterprise, it might also be desirable to disable automatic updates, so that administrators can have more control over the update process.

There are special considerations about doing updates in an enterprise environment. Let's look at them next.

Managing updates in an enterprise

When you first install any Linux distro, it will be configured to access its own package repositories. This allows the user to install any software package or install updates directly from these normal distro repositories. This is great for home or small business use, but not so great for the enterprise.

In an enterprise setting, there are two additional considerations:

• You want to restrict what packages the end users are allowed to install.
• You always want to test updates on a separate test network before allowing them to be installed on a production network.

For these reasons, enterprises will often set up their own repository servers that only have approved packages and approved updates. All other machines on the network will be configured to pull their packages and updates from them, rather than from the normal distro repository. (We won't go into how to set up on-premises repository servers here, because that's a topic better suited for a Linux administration book.)

Ubuntu has always been one of the more innovative Linux distros, but it's also had more than its fair share of quality-control problems. In its early days, there was at least one Ubuntu update that completely broke the operating system, requiring the user to re-install the operating system. So, yeah, in any mission-critical environment, test those updates before putting them into production.

I think that that's about it for our introductory chapter. Let's wrap things up in a summary, shall we?