If you administer your own server(s), sooner or later you face this problem: you have to reboot the operating system, but the machine provides an important service that you can’t interrupt.
But why reboot in the first place? Everything seems to be working fine after an apt-get upgrade command. However, things are not always as they seem. Even though the system happily continues to run after every upgrade, not forcing a reboot like Windows does, it might still need one.
For example, when a vulnerability in the core of the system (kernel) is discovered, it is patched and pushed to your server as a new package. After you install the patched kernel, some files are written to disk, but it’s still the old kernel that’s running the show, since it is the one loaded into memory (RAM).
This means your server is still vulnerable to the security holes previously discovered. Other processes, daemons, and services can be reloaded without restarting the operating system. However, the kernel sits at the heart of the system and can only be reloaded at the next boot.
Also read: How to Add Users in Ubuntu Server
Ubuntu Livepatch solves this by allowing you to close kernel security holes without restarting. This way, you can avoid or delay reboots for weeks or months without compromising security.
The core idea behind live patching is simple: when a function is vulnerable, rewrite it, eliminate flaw, and load new function somewhere into memory. When the function is called, instead of running the code in the kernel, redirect the call to use the rewritten code.
But, as with most things that seem to work simply, the implementation and technical details are not so simple.
How to Set Up Livepatch on Ubuntu
Go to this page and create your Ubuntu One account. (Or just log in if you already have it.) Check your email and click on the account confirmation link afterwards. Next, visit the Canonical Livepatch Service page. Select that you are an “Ubuntu user,” and click on the button to generate your token. The next page will show you the exact commands you have to enter on your server. After the first command, enter
sudo snap install canonical-livepatch
Wait a few seconds until the snap package is fully installed. When it’s done, you will get a result similar to what you can see in the following picture.
Finally, with the last command from Canonical’s page,
sudo canonical-livepatch enable #PASTE_YOUR_TOKEN_HERE
the service becomes active and will automatically apply security patches to your kernel, whenever necessary, with no input required on your part.
Install Snap Daemon If Necessary
On some rare occasions, the first command in the previous section might fail, with the following error message: -bash: /usr/bin/snap: No such file or directory. In this case it means your server provider has an Ubuntu operating system image that doesn’t include the snap daemon service by default. Install it with:
sudo apt update && sudo apt install snapd
Now run the two commands from the previous section again.
Also read: 5 Useful Patches to Improve Your dwm Experience
Keeping Your Server Updated
Livepatch will apply all necessary security updates to your kernel. However, you should still upgrade the rest of your system on a regular basis with a command like:
sudo apt update && sudo apt upgrade
You should do this weekly, or even more often, if you can. Important system packages might prompt you that they need to be restarted to apply the latest security fixes.
These are usually graceful restarts, meaning they don’t disrupt any service in the process. For example, in this case, the SSH daemon was restarted without interrupting the active SSH session.
In other situations, you could restart services yourself to make sure that the new, patched code is reloaded and security fixes are applied. For example, if you notice that the nginx package has been upgraded, you can run
systemctl restart nginx.service
to reload the nginx daemon into memory. Otherwise, even though a package is upgraded, it might still run with the old, vulnerable code, putting your server at risk to known attacks. Some package upgrades do this for you, but others don’t. That’s why it’s a good habit to pay attention to what “apt upgrade” does and restart some services, if necessary. You can also look at the logs to see if this has been done automatically.
Conclusion
As you can see, Canonical has made it rather easy to implement this on a server. As far as the kernel is concerned, there’s no maintenance work required on your part. The only thing you can do is run
canonical-livepatch status
from time to time to check on things.
Our latest tutorials delivered straight to your inbox
