Ubuntu Server 18.04 – Installing security updates

How to use the Docker Compose command

Since I’ve mentioned updating packages several times, let’s have a formal conversation about it. Updated packages are made available for Ubuntu quite often, sometimes even daily. These updates mainly include the latest security updates, but may also include new features. Since Ubuntu 18.04 is an LTS release, security updates are much more common than feature updates. Installing the latest updates on your server is a very important practice, but, unfortunately, it’s not something that all administrators keep up on for various reasons.

When installed, security updates very rarely make many changes to your server, other than helping to keep it secure against the latest threats. However, it’s always possible that a security update that’s intended to fix a security issue ends up breaking something else. This is rare, but I’ve seen it happen. When it comes to production servers, it’s often difficult to keep them updated, since it may be catastrophic to your organization to introduce change within a server that’s responsible for a large portion of your profits. If a server goes down, it could be very costly. Then again, if your servers become compromised and your organization ends up the subject of a CNN hacking story, you’ll definitely wish you had kept your packages up-to-date!

The key to a happy data center is to test all updates before you install them. Many administrators will feature a system where updates will graduate from one environment into the next. For example, some may create virtual clones of their production servers, update them, and then see whether anything breaks. If nothing breaks, then those updates will be allowed on the production servers. In a clustered environment, an administrator may just update one of the production servers, see how it gets impacted, and then schedule a time to update the rest. In the case of workstations, I’ve seen policies where select users are chosen for security updates before they are uploaded to the rest of the population. I’m not necessarily suggesting you treat your users as guinea pigs, but everyone’s organization is different, and finding the right balance for installing updates is very important. Although these updates represent change, there’s a reason that Ubuntu’s developers went through the hassle of making them available. These updates fix issues, some of which are security concerns that are already being exploited as you read this.

To begin the process of installing security updates, the first step is to update your local repository index. As we’ve discussed before, the way to do so is to run sudo apt update. This will instruct your server to check all of its subscribed repositories to see whether any new packages were added or out-of-date packages removed. Then, you can start the actual process.

There are two commands you can use to update packages. You can run either sudo apt upgrade or sudo apt dist-upgrade.

The difference is that running apt upgrade will not remove any packages and is the safest to use. However, this command won’t pull down any new dependencies either. Basically, the apt upgrade command simply updates any packages on your server that have already been installed, without adding or removing anything. Since this command won’t install anything new, this also means your server will not have updated kernels installed either.

The apt dist-upgrade command will update absolutely everything available. It will make sure all packages on your server are updated, even if that means installing a new package as a dependency that wasn’t required before. If a package needs to be removed in order to satisfy a dependency, it will do that as well. If an updated kernel is available, it will be installed. If you use this command, just take a moment to look at the proposed changes before you agree to have it run, as it will allow you to confirm the changes during the process.

Generally speaking, the dist-upgrade variation should represent your end goal, but it’s not necessarily where you should start. Updated kernels are important, since your distribution’s kernel receives security updates just as any other package. All packages should be updated eventually, even if that means something is removed because it’s no longer needed or something new ends up getting installed.

When you start the process of updating, it will look similar to the following:

sudo apt upgrade
Updating packages on an Ubuntu server

Before the update process actually starts, you’ll be given an overview of what it wants to do. In my case, it wants to upgrade 9 packages. If you were to press Y and then Enter, the update process would begin. At this point, I’ll need to leave the Terminal window open, it’s actually dangerous to close it in the middle of the update process.

Assuming that this process finishes successfully, we can run the apt dist-upgrade command to update the rest; specifically, the packages that were held back because they would’ve installed new packages or removed existing ones. There weren’t any in my case, but in such a situation you may see text indicating that some upgrades were held back, which is normal with apt upgrade. At that point, you’ll run sudo apt dist-upgrade to install any remaining updates that didn’t get installed with the first command.

In regards to updating the kernel, this process deserves some additional discussion. Some distributions are very risky when it comes to updating the kernel. Arch Linux is an example of this, where only one kernel is installed at any one time. Therefore, when that kernel gets updated, you really need to reboot the machine so that it can use it properly (sometimes, various system components may have difficulty in the case where you have a pending reboot after installing a new kernel).

Ubuntu, on the other hand, handles kernel upgrades very efficiently. When you update a kernel in Ubuntu, it doesn’t replace the kernel your server is currently running on. Instead, it installs the updated kernel alongside your existing one. In fact, these kernels will continue to be stacked and none of them will be removed as new ones are installed. When new versions of the Ubuntu kernel are installed, the GRUB boot loader will be updated automatically to boot the new kernel the next time you perform a reboot. Until you do, you can continue to run on your current kernel for as long as you need to, and you shouldn’t notice any difference. The only real difference is the fact that you’re not taking advantage of the additional security patches of the new kernel until you reboot, which you can do during your next maintenance window. The reason this method of updating is great is because if you run into a problem where the new kernel doesn’t boot or has some sort of issue, you’ll have a chance to press Esc at the beginning of the boot process, where you’ll be able to choose the  Advanced options for Ubuntu option, which will bring you to a list of all of your installed kernels. Using this list, you can select between your previous (known, working) kernels and continue to use your server as you were before you updated the kernel. This is a valuable safety net!

 

After you update the packages on your server, you may want to restart services in order to take advantage of the new security updates. In the case of kernels, you would need to reboot your entire server in order to take advantage of kernel updates, but other updates don’t require a reboot. Instead, if you restart the associated service, you’ll generally be fine (if the update itself didn’t already trigger a restart of a service). For example, if your DNS service (bind9) was updated, you would only need to execute the following to restart the service:

sudo systemctl restart bind9

In addition to keeping packages up to date, it’s also important that you understand how to rollback an updated package in a situation where something went wrong. You can recover from such a situation by simply reinstalling an older version of a package manually. Previously downloaded packages are stored in the following directory:

/var/cache/apt/archives

There, you should find the actual packages that were downloaded as a part of your update process. In a case where you need to restore an updated package to a previously installed version, you can manually install a package with the dpkg command. Generally, the syntax will be similar to the following:

sudo dpkg -i /path/to/package.deb

To be more precise, you would use a command such as the following to reinstall a previously downloaded package, using an older Linux kernel as an example:

sudo dpkg -i /var/cache/apt/archives/linux-generic_4.15.0.7.8_amd64.deb

However, with the dpkg command, dependencies aren’t handled automatically, so if you are missing a package that your target package requires as a dependency, the package will still be installed, but you’ll have unresolved dependencies you’ll need to fix. You can try to resolve this situation with apt:

sudo apt -f install

The apt -f install command will attempt to fix your installed packages, looking for packages that are missing (but are required by an installed package), and will offer to install the missing dependencies for you. In the case where it cannot find a missing dependency, it will offer to remove the package that requires the missing packages if the situation cannot be worked out any other way.

Well, there you have it. At this point, you should be well on your way to not only installing packages, but keeping them updated as well.

Comments are closed.