How to setup Livepatch on-prem server administration tool

Security Livepatch
#1

To perform operations such as promoting patches to tiers and issuing tokens for machines to attach to the livepatch server, an administration tool is provided as a snap:

$ sudo snap install canonical-livepatch-server-admin

For ease of use, it’s recommended to alias the admin command:

$ sudo snap alias canonical-livepatch-server-admin.livepatch-admin livepatch-admin

Authentication

There are two ways for the livepatch administration tool to authenticate with the livepatch server:

  • Ubuntu SSO
  • Username/password

Password authentication

To configure password authentication, username/password hash pairs will need to be generated using the htpasswd tool available in the apache2-utils package:

$ htpasswd -bnBC 10 <username> <password>
username:$2y$10$74ZpDgHaxnUQo.AJZk1cMuSRfef5oK5xq5o/GLbUH/Bbw6W2bmctm

Multiple such pairs can be provided as a comma-separated list:

$ juju config livepatch auth_basic_users="<user1>:<password1,<user2>:<password2>"

When logging in with the client, the username and password will need to be provided:

$ export LIVEPATCH_URL={haproxy url}

$ livepatch-admin login --auth <username>:<password>

Ubuntu SSO authentication

Ubuntu SSO authentication utilizes membership in public launchpad groups to gate access. The launchpad groups that will have administrator privileges are specified using charmed operator configuration:

$ juju config livepatch auth_lp_teams='https://launchpad.net/~<team>'

Multiple teams can be specified as a comma-separated list.

When logging in, user interaction will be necessary:

$ export LIVEPATCH_URL={haproxy url}

$ livepatch-admin login

To login please visit http://127.0.0.1:44035
1 Like
Livepatch On-Prem Server How-to Guides
Getting started with Livepatch On-Prem and Microk8s
How to deploy Livepatch on-prem
Livepatch Documentation
#2
#3
#4

I’m having trouble promoting patches.
Regardless of authentication method, including deliberately malformed credentials (same exit code, no output or error message), I get this from attempting to promote a patch with livepatch-admin:
Error: failed to associate patch with tier: Put /v1/admin/tiers/beta/92.1: cannot unmarshal parameters: cannot unmarshal into field LimitedRelease: unexpected content type “”; want application/json; content: “”

If I were to recreate the request in curl to debug my issue, what fields is the server expecting?

This is installed via charm, running on the same controller as Landscape on-prem, is haproxy getting in the way?

Is there any way to get more feedback from the livepatch-admin login command?

#5

Hi @ghill,

Apologies for the delay in replying.

If the below doesn’t help could you please post your bug here, this is the official tracker for on-prem bugs and will make it easier to track.

It’ll be helpful to know what charm revision of the livepatch-server you are running and the Snap revision of the admin-tool.

I think you might simply need a newer version of the admin-tool Snap. A sudo snap refresh canonical-livepatch-server-admin. Failing that, you can install the Snap from the candidate channel which has a newer version, which can be done with sudo snap refresh canonical-livepatch-server-admin --channel=latest/candidate

1 Like
#6

Thank you @kian-parvin, you are correct, refreshing the canonical-livepatch-server-admin snap to latest/candidate is what resolved the issue for me.
The new supported-kernels feature looks promising, though I needed to then refresh the server for the new schema.

Quick followup question, if nothing is entered into sync reports, does that mean there are no issues and no patches found? There does not seem to be a “successfully contacted server, no new patches found” entry, and my last entry is from May 17th.

Thanks again.

#7

Glad that resolved things! For clarity, the supported-kernels table is intended purely as a way for the server to communicate to client machines whether their kernel is supported. This list is maintained by Canonical since we create the patches and the data from the hosted server is synced to the on-prem instances for them to communicate to their downstream clients.

As for your question, yes that should indicate that things are okay. You can view all the sync reports if you add the --all flag so that any syncs that didn’t return anything will also be shown. More details are available with livepatch-admin sync reports --help. And if you want to see what patches you currently have stored you can use livepatch-admin storage patches.

I recommend adding the --help flag to commands to get more info where needed.
Hope that helps!

#8

Thank you, Kian. I’ve been using the --help flag to build a TUI tool.
It seems that supported-kernels --help page reuses the text from the tiers --help page.

Just to confirm, there is no way to limit synced patches by kernel version? I will never be deploying, for example, kernel 5.4.0-99, or any other 5.4 kernel. Should I be looking into manual downloads and using the livepatch-admin storage refresh option instead?

Exploring it a little, and following the existing examples of supported kernels, I’ve got clients reporting that their kernel isn’t supported. What is the client looking at when determining which kernel version/architecture/OS codename/flavour to match up against? As far as I can tell with lsb_release and uname, this should be a match.

However, if I’m understanding you correctly, the supported-kernels list cannot be controlled in an airgapped on-prem instance, since it gets overwritten from upstream?

Thanks

#9

Ah that’s very cool! Definitely share that with a post in this discourse channel or elsewhere when you feel it’s ready. Would be great to use and see.
Thanks for the note on the help page, we’ll take a look at that.

That’s correct, there is no way to filter by kernel version currently but this is something we’re adding at the moment. There is the ability to limit sync to only certain kernel “flavors” however. That option can be configured as described here. Manually downloading would work but all the other patches would be downloaded during the next sync unless you disable the automatic sync which is not advisable as you’d have to then always make sure you’re keeping up with new patches using another mechanism.

Clients report their

  • codename(e.g. Foca)
  • architecture(e.g. amd64)
  • flavour(e.g. -generic)
  • kernel-version

And that is used to determine the “support status”. Just fyi, we’ve seen another scenario this week that seems to indicate a bug that the sync of supported kernels from the upstream down to on-prem servers is not working and we are investigating that. The supported message however doesn’t prevent clients from receiving patches, it’s purely informational.

And as for your last question, correct, this list gets overwritten from upstream as there’s no value in users writing to the list.