People all over the world have become accustomed to software updates. Today, almost everyone uses a personal computer and owns a smartphone. Everyday, the words “an update is available” flashes across screens everywhere. Way too often, these updates are ignored. Personal experiences with buggy updates have scared day-to-day technology users into mistrusting updates when alerts come across their screen. Unknowingly to some, pushing off some of these updates may be put their devices at risk.
Linux system administrators deal with updates everyday as well. In the Linux world, these updates are often referred to as patches. This overview will cover what patching really means in the Linux world. Best practices will be covered as well. This includes how to patch via RPM, and how to schedule and prioritize patches. Finally, common issues that occur will be covered, and ways to handle those issues will be explored.
What is Patching?
One of the foundations of running a secure Linux system is keeping all of your software up to date. Patches should be checked for over a routine schedule, and updates should be pushed through accordingly. Patches can be applied either manually or automatically. If needed, patches can be uninstalled, as well.
Unprotected security holes are a constant threat to the safety of your network. Every day, new flaws are uncovered by people and programs with malicious intent. As these vulnerabilities are recognized, software developers release fixes, available via update. It’s imperative that these patches are applied to your system regularly to keep your system online and your data secured.
Patches are released for performance purposes as well. Over time, developers add features and streamline processes within their software. Updated software is posted to repositories, available for patching. Installing these patches will help to keep your system performing at its best and running efficiently.
How to Patch via RPM
The most effective way to install patches is via RPM, or RPM Package Manager. RPM is a free package management system available to all distributions of Linux. There are quite a few advantages of patching software via RPM. Biggest of all, RPM packages are verified for integrity using GPG and MD5 checksums. RPMs are most often hosted by central databases on the internet, referred to as RPM repositories.
Red Hat Enterprise Linux and Fedora-based Distribution Patching
The default RPM package manager for Red Hat and Fedora-based systems is yum (Yellowdog Updater, Modified).
To update the entire operating system, the following command can be used:
- yum update
In some cases, it may be best to install a specific package, rather than run an entire system update. To run an update on specific package, use the following command:
- yum update <package-name>
If you need to remove a package in its entirety, use this command:
- yum remove <package-name>
If a software package is found to be corrupted or compromised, and a patch is not yet available, it may be a good idea to remove it.
Debian-based Distribution Patching
Debian-based Linux distributions, such as Ubuntu, use APT as the default package manager. APT, or the Advanced Package Tool, uses the apt-get command to install, remove, and update packages.
To run an update on the entire system, use the following two commands:
- apt-get update - Syncs packages with sources. Verifies the right files will be installed
- apt-get upgrade - Downloads and installs updates across all software packages.
To update a current package, the following command can be used:
- apt-get install <package-name>
If the package isn’t installed - this command will install it. If the package is already installed, it will check for and install the latest update.
To remove an installed package, use the following command:
- apt-get remove <package-name>
Again, packages that are found to be not-trustworthy should be removed with this command until they can be confirmed.
Best Practices to Linux Patch Management
As with any system administration process, it’s important to have a good understanding of the best practices for patching your Linux system. Your patches should be applied according to a schedule, and patches should be prioritized and updated when appropriate. Patches should be applied from reputable sources, and administrators should be alerted when critical patches are released.
The best method to enforce abiding by these practices is to have a set Standard of Procedures for patching. This SOP should be in written form and shared with all of the system administrators. Here’s an overview of each of the building blocks best patching practices:
Schedule Your Patches Appropriately
You should have a set schedule of how often patches are looked for and run. If there is no schedule at all - critical updates may be missed, and important updates may be forgotten entirely. Additionally, checking for and installing patches everyday can be a waste of bandwidth, time, and resources.
In general, scheduling a weekly time to patch your systems is good practice. Events may arise in which hyper-critical security patch needs to be installed immediately. These patches should be installed immediately for the security of your system. In all other cases, try to stick to a schedule.
Separate Critical Patches from Performance-Based Updates
Some patches, such as patches related to security, should be installed immediately. Other patches should be allowed to mature a bit before installation. General software and system updates, as with any other piece of software, can have bugs and other issues. Waiting on the general public to stress-test this software a bit before you install it on your own system is a good idea.
A general rule would be to wait up to one month after non-essential software has been released before allowing patches to be installed on your Linux system. These patches should be installed as a part of your weekly patch schedule. As always, the critical security patches should be installed shortly after release to protect from vulnerabilities.
Update from RPM Repositories
It’s important to know that your patches are coming from reliable sources. Strictly enforcing a rule to only apply patches from RPM repositories is a good way to know that what you’re installing is safe. Software packages listed in reputable repositories can be trusted, and downloads are verified using MD5 checksums.
Set Up Notification Processes
Notifications can be scheduled so that when important security-related patches are released to the public, you know right away. The sooner you know that patches have been released, the sooner you can apply them to your system.
Red Hat offers an email subscription for security issue notification. To subscribe to the mailing list, visit this site:
The Debian-based Ubuntu distribution uses an RSS feed to send users security notices. To subscribe to the this RSS feed, read more here:
Developers of third-party programs should also offer notifications for security vulnerabilities. It’s good practice to be sure to be on all of these mailing lists as well.
Common Issues with Patches
Every so often, a software developer releases a patch that has a bug in it. While all software should be quality tested to verify that no bugs exist before releasing it - sometimes, things fall through the cracks. Here are things that can be done about a buggy update:
- To minimize these events, as discussed earlier, it's always a good idea to allow non-essential updates to mature before installing them on your system.
- Make sure that you have a good backup of your system. Backups should be run nightly. If an update causes instability throughout your system, rolling back to the latest update may be a good idea.
- If you are able to figure out which patch is causing your issues, you can try uninstalling the specific software package and installing a fresh copy.
Patches That Affect System Productivity
Running a software update during business hours can sometimes affect productivity. If you know in advance that this may happen with a certain update, it is good practice to wait to apply patches until non-business hours. This may mean late night or weekend work, but the investment in extra time will pay off.
Be sure to be available as the system is put back to work again following a patch application. If bugs or software changes are going to affect productivity, you should be prepared to respond immediately.
Major Software Changes
Most of the time, an applied patch only changes things “behind-the-scenes”. Occasionally, however, an applied patch will change the entire user-facing interface of a software package. Particularly large updates can cause confusion when trying to use the software following patch application.
To be prepared for major changes, system administrators should read through the release notes before applying patches. If the release notes indicate major changes, administrators should wait to apply this patch at a time that will have the softest impact. Additionally, a little internet research may reveal more information on software changes and an explanation on how to use the newest software.
Updated Software that Uses More Resources
When a software patch adds new features, an increased load is eventually put on server resources. Eventually, over time, you may see a system slow-down. The software that you are running may eventually be calling for more resources than was originally allocated when the system was first built.
Here are some ways to combat running out or resources:
- Run a resource inventory. Determine which resources are causing the bottleneck, and see if they can be upgraded.
- Have an upgrade plan. Over time, all systems need to be upgraded. Have a plan in place ahead of time for when the day comes.
- Consider virtualization. Computing resource management is a lot easier and more configurable when your servers are virtualized.
No matter how you combat it - it’s best to be prepared - no one should be caught by surprised by running out of resources.
Every Linux system administrator makes decisions about software patches weekly, if not more often. Administrators need to be knowledgeable about the best practices and common pitfalls of Linux patching. Having a Standard of Procedures for how to handle the patching process is essential for each Linux system.
These procedures should include scheduling patches appropriately, and understanding their priority. Notifications should be in place for when urgent patches are released. On top of all this, system administrators need to know for sure that patches are coming from reputable sources.
Plans need to be in place for how to handle update issues, such as buggy patches and ones that cause confusion due to changes in interface. Patches should be applied at times that don’t affect business production. Finally - plans should be in place for when patched software requires more resources than your system can provide.
System administrators who have a Standard of Procedures in place to take on these items will be prepared to handle each and every software patch that comes their way!