Categories: BlogCanonicalUbuntu

Managing Livepatch on-prem

Ubuntu Livepatch is the service and the software that enables organizations to quickly patch vulnerabilities on the Linux kernel. It enables uninterrupted service while reducing fire drills during high and critical severity kernel vulnerabilities. With Ubuntu Livepatch on-prem we enhance our service to enable enterprises manage on private or public cloud their livepatched systems.

In this post, we will introduce Ubuntu Livepatch on-prem and look into how it can be deployed for your organization, as well as answer some of the most commonly asked questions.

On-prem kernel livepatching

Complex enterprise environments often follow policies that require a gradual roll-out of updates to reduce risk, or have high-security isolated environments that need to be updated. Livepatch on-prem allows an organization to define a roll-out policy and remain in full control of which machines will get updated and when. The Livepatch on-prem server is a middle-man service that regularly syncs with the Ubuntu Livepatch service to gather the latest kernel livepatches. It then deploys the patches gradually in as many stages as required, following the organizational policy.

How to deploy Livepatch on-prem

The service is easily deployable with juju on any environment from the public cloud of your choice to a private cloud using the model-driven juju framework. Once deployed it connects to the Ubuntu Livepatch service with an Ubuntu Advantage token, and can be configured to perform patch deployment according to a predefined set of policies.

How to manage livepatches

The deployment of the livepatches is performed in multiple tiers. The systems on the first tier receive the available patches unconditionally. The next tiers serve as promotion tiers where patches are promoted by the administrator. That approach allows for a risk-based deployment that keeps the most important systems as the last tier, as well as for cohort deployment where clusters of systems are patched gradually to keep the expected availability. The livepatch client systems are associated with a tier by assigning them the corresponding token for that tier, a token issued by the on-prem server.

Let’s take an example. An administrator can configure an incoming tier –let’s call it Tier 1– where livepatches get applied as they come from the Ubuntu Livepatch service, and a promotion tier –Tier 2– that the administrator can promote patches to once the criteria she set for promotion are met. That simple scenario is depicted graphically below.

Deployment on tier 1
Deployment on tier 2

That simple association of a livepatch client to a tier allows for complex policy definitions and scenarios to deploy.

How many clients can an on-prem server handle?

The server can handle thousands of clients in a single CPU core system, and it requires access to storage space of a few gigabytes, to store the patches. There are multiple supported storage backends, such as the local filesystem, OpenStack Object Storage (Swift), S3, minio or postgresql. You can find more detailed instructions on deploying and configuring livepatch on-prem on our website.

How can I access Livepatch on-prem?

Livepatch on-prem is available with an Ubuntu Advantage subscription.

Where can I find more information about livepatch on-prem?

The complete documentation of Livepatch on-prem service is available on Ubuntu Livepatch website.

Conclusion

Livepatch on-prem enables your organization to follow its own roll-out policies while taking advantage of Livepatching across your portfolio. Livepatching not only improves your infrastructure’s security posture but greatly reduces downtime and unplanned maintenance windows due to high and critical severity kernel vulnerabilities. If you would like to know more about Livepatch on-prem and how it could be implemented for you, get in touch!

Ubuntu Server Admin

Recent Posts

Predict, compare, and reduce costs with our S3 cost calculator

Previously I have written about how useful public cloud storage can be when starting a…

1 day ago

One Thread to Poll Them All: How a Single Pipe Made WaterDrop 50% Faster

This is Part 2 of the "Karafka to Async Journey" series. Part 1 covered WaterDrop's…

1 day ago

A year of documentation-driven development

For many software teams, documentation is written after features are built and design decisions have…

2 days ago

Announcing FIPS 140-3 for Ubuntu Core22

With the release of the FIPS 140-3 certified cryptographic modules for Ubuntu 22.04 LTS, Canonical…

3 days ago

The foundations of software: open source libraries and their maintainers

Open source libraries are repositories of code that developers can use and, depending on the…

6 days ago

From inspiration to impact: design students from Regent’s University London explore open design for their dissertation projects

Last year, we had the opportunity to speak at Regent’s UX Conference (Regent’s University London’s…

1 week ago