Optional Ubuntu Landscape connector, plus native package management

[Jemo121]

I went looking for anything about Canonical's Landscape in OpenUEM and found nothing, no issue, PR, discussion or docs page. So I'm raising it here first. Opening an issue would assume you want this, and I don't know that yet.

Landscape covers some of the same ground as OpenUEM on Ubuntu and Debian machines: inventory, installed packages, what updates are pending. It also reports things OpenUEM has no way to know, like whether a machine is attached to Ubuntu Pro and whether ESM or Livepatch are active, because that information only comes from Canonical.

The practical problem is for people already running Landscape for that reporting. Moving to OpenUEM means either dropping Landscape and losing the Pro status, or running both and keeping two inventories that will eventually disagree about patch level. Most people pick the second, and then nobody can say which system is authoritative when it matters.

What I'd suggest, in order:

First, package management that doesn't depend on any of this. OpenUEM should be able to install, update and remove apt and dnf packages on its own. That's already in the roadmap and I've opened an issue on the agent side for it (open-uem/openuem-agent#211). It's the part I care about most and it doesn't need Landscape to exist.

Second, and only if you think it's worth having, a Landscape connector that's off unless someone turns it on. Read-only to start with: pull the computer list and package data from the Landscape API, show it against the matching endpoint in the console with the source labelled, and expose Pro attachment, ESM and Livepatch state as inventory fields. No write path in a first version, so no triggering package operations through Landscape and nothing where Landscape overrides data OpenUEM collected itself.

The order matters to me. If a connector ever became the normal way people manage packages on Ubuntu, OpenUEM would have handed off a core part of what it does to a vendor tool.

Things I don't know:

Whether you want this at all. It's an integration with one company's product for one family of distributions, and "we're staying distro neutral" is a fair answer. I'd sooner hear it now.

How endpoints would be matched. Both systems have their own identity for the same machine and matching on hostname breaks the first time someone renames one. Is there already a pattern in OpenUEM for storing an external system's ID against an endpoint?

Where it would run. A worker that talks to the Landscape API and publishes over NATS looks closer to how the rest of the project is built than having the console make the calls, but you'd know better than me.

Credentials. It needs a Landscape API key stored server side. The Authentication entity already encrypts the OIDC cookie key, so I assume that's the pattern to copy.

Whether anyone else wants it. An integration nobody uses is just maintenance. If this is only useful to me then it shouldn't be built, and a few replies here would tell us more than my guessing would.

For context, I've been reading through the codebase on my own time. I have no connection to Canonical and nobody is waiting on this. I'm happy to do the work if it's something you want, and if you had to choose, the package management issue is the more useful of the two.