Configuration¶
This document provides the configuration options for the Livepatch Server for both Juju charm and snap deployments.
Note
The configuration below applies to the Livepatch Server operator charms and Server snap. For reactive charm deployments — or if your deployment configuration differs from the options below — see the migration guide from reactive charm to operator charm.
Setting configuration¶
Configuration methods differ depending on whether the Livepatch Server is deployed with Juju and charms, or as a standalone snap.
Default and example values are available on the respective machine charm and K8s charm configuration pages.
Juju¶
The configuration keys in the table below map directly to the options exposed by the Livepatch charms, unless otherwise noted.
Assuming the Livepatch Server has been deployed with the alias livepatch, apply configuration changes with:
juju config livepatch <key>=<value>
# Example: enable basic authentication
juju config livepatch auth.basic.enabled=true
See the Juju CLI configuration documentation for all available methods of applying configuration.
Snap¶
The configuration keys in the table below map directly to the values accepted by the Livepatch Server snap. Prepend lp. to all keys when setting snap configuration.
Apply configuration changes with:
sudo snap set canonical-livepatch-server lp.<key>=<value>
# Example: enable basic authentication
sudo snap set canonical-livepatch-server lp.auth.basic.enabled=true
Configuration options¶
The following sections describe the available configuration values.
Server configuration¶
Name |
Description |
Values |
|---|---|---|
|
Log level for the server. |
|
|
Whether to redirect patch download requests to the URL specified in |
|
|
Template URL for redirecting clients for patch downloads. Example: |
|
|
Listen address for the server. |
|
|
Maximum number of API requests to serve concurrently. |
|
|
Queue limit. Approximately equals |
|
|
In multi-server deployments, determines whether this unit is the leader. Not available for charmed deployments. |
|
|
Enable configuration blocks specific to Canonical’s hosted Livepatch configuration. |
|
Admin authentication¶
The following values configure authentication to the server’s admin endpoints. Ubuntu SSO authentication has been removed; only Basic Auth is supported. The auth.sso.* keys below are retained for legacy configuration/migration reference and are ignored by the server.
Basic Auth configuration accepts a comma-separated list of users. See the admin tool setup guide for details.
Basic Auth passwords must be bcrypt hashed.
Name |
Description |
Values |
|---|---|---|
|
Enable Basic Auth. |
|
|
Comma-separated list of user objects. |
|
Ubuntu SSO authentication (removed)¶
Note
Ubuntu SSO authentication has been removed. Use Basic Auth instead.
Name |
Description |
Values |
|---|---|---|
|
Enable Ubuntu SSO authentication. |
|
|
SSO authentication configuration listing authorised teams. |
|
|
URL for SSO authentication. |
|
|
Public key for the authentication server. Accepts a file path or an inline key. |
|
Ubuntu Pro¶
The following values configure how the server interacts with the Ubuntu Pro backend (also referred to as the contracts server) for client authentication. These are relevant for Canonical’s hosted Livepatch Server and airgapped deployments.
Name |
Description |
Values |
|---|---|---|
|
Whether to connect to the contracts service. |
|
|
URL of the contracts server. |
|
|
Basic Auth username for the contracts service. |
|
|
Basic Auth password for the contracts service. |
|
Database¶
The following values configure how the server interacts with its PostgreSQL database.
Name |
Description |
Values |
|---|---|---|
|
PostgreSQL connection string. Unavailable for charmed deployments (handled through Juju relations). |
|
|
Maximum number of connections in the pool. |
|
|
Maximum lifetime of a database connection. |
|
|
Maximum memory in MB available for each query operation. |
|
InfluxDB¶
The following values configure how the server interacts with InfluxDB for sending aggregated KPIs.
Name |
Description |
Values |
|---|---|---|
|
Whether to enable InfluxDB KPI reporting (hosted). |
|
|
URL of the InfluxDB server. |
|
|
Authentication token for InfluxDB. |
|
|
InfluxDB bucket to use. |
|
|
Bucket for sending patch ping data, for example under a different retention policy. If empty, defaults to the value of |
|
|
InfluxDB organisation containing the bucket. |
|
TimescaleDB¶
The following values configure how the server interacts with its TimescaleDB instance for storing time-series patch ping metrics. TimescaleDB runs as a PostgreSQL extension on a dedicated PostgreSQL instance, separate from the main database. TimescaleDB can be enabled alongside or as a replacement for InfluxDB for KPI metrics.
Name |
Description |
Values |
|---|---|---|
|
Whether to enable the TimescaleDB store for KPI metrics. |
|
|
Connection string for the TimescaleDB PostgreSQL instance. |
|
|
Maximum number of connections in the pool (1–1000). |
|
|
Maximum lifetime of a connection before it is recycled. |
|
|
Maximum memory in MB available for each query operation. |
|
|
Duration the store waits before flushing buffered writes. Defaults to 1 minute if unset. |
|
Patch storage¶
The following values configure how the server manages patch storage. See the patch storage how-to guide for details.
Name |
Description |
Values |
|---|---|---|
|
Storage backend type for on-premises patch synchronisation. |
|
|
Directory path for filesystem storage. |
|
|
Swift account username. |
|
|
Swift API key. |
|
|
Swift authentication URL. |
|
|
Swift domain. |
|
|
Swift tenant. |
|
|
Swift container bucket. |
|
|
Swift region. |
|
|
PostgreSQL connection string. Can be left blank in charmed deployments to use Juju relations. |
|
|
S3 bucket for storing patches. |
|
|
S3 endpoint URL. |
|
|
AWS region for S3. |
|
|
Whether to use secure transfers. |
|
|
AWS access key. |
|
|
AWS secret key. |
|
Patch cache¶
The following values configure the server’s patch cache.
Name |
Description |
Values |
|---|---|---|
|
Whether to enable patch caching for faster delivery. |
|
|
Time-to-live for cached patches. |
|
|
Maximum size of the patch cache. |
|
Patch sync¶
The following values configure how the server synchronises patches from an upstream server.
Name |
Description |
Values |
|---|---|---|
|
Whether patch synchronisation is enabled. |
|
|
Unit ID. Not available in charmed deployments. |
|
|
Minimum kernel version to download patches for, in |
|
|
Comma-separated list of kernel architectures to download patches for. |
|
|
Comma-separated list of kernel flavours to download patches for. |
|
|
Automatic synchronisation interval (for example |
|
|
Strategy for reporting machine counts: |
|
|
Whether to send machine reports during synchronisation. |
|
|
Token for authenticating with an upstream Livepatch Server. |
|
|
URL of the upstream server to pull patches from. |
|
|
Whether to synchronise tiers from the upstream server. |
|
|
Whether to use a proxy when synchronising patches. |
|
|
HTTP proxy URL. |
|
|
HTTPS proxy URL. |
|
|
Comma-separated list of addresses to bypass the proxy. |
|
Blocklist cache¶
The following values configure the server’s patch blocklist cache.
Name |
Description |
Values |
|---|---|---|
|
Whether to enable the blocklist cache. |
|
|
Interval for refreshing the blocklist cache. |
|
KPI reports¶
The following values configure how the server sends KPI reports. KPI reports require InfluxDB to be configured. KPIs include aggregated information on client machines such as client version and patch status.
Name |
Description |
Values |
|---|---|---|
|
Whether to enable KPI reporting. |
|
|
Interval for submitting KPI reports. |
|
Machine reports¶
The following values configure the server’s machine report behaviour. Machine reports are stored in PostgreSQL and capture information when clients check in.
Name |
Description |
Values |
|---|---|---|
|
Whether to enable machine reporting to PostgreSQL. Reports are stored in the server’s PostgreSQL database. |
|
|
Number of days to retain machine reports. |
|
|
Maximum number of rows to delete per cleanup operation. |
|
|
Interval for running report cleanup operations. |
|
Cloud delay (deprecated)¶
The following values configure the server’s cloud delay behaviour.
Note
The cloud delay feature is deprecated. Use the patch-delay and cutoff-date configuration options on the Livepatch Client instead.
Name |
Description |
Values |
|---|---|---|
|
Whether to delay patch releases to clients based on their cloud, region, or availability zone. |
|
|
Default delay in hours for clouds, regions, or availability zones without a specified delay. |
|