Is it possible to fork lxd-ui to incus-ui from GPLv3 license perspective?
Yeah, there wouldn’t be any legal issue there, obviously the fork would have to remain under GPLv3 but that’d be fine.
I don’t think any of us on the Incus team enjoy web development enough to go through the whole process of starting and maintaining a fork of the LXD UI, but that’s why I’m currently planning on just taking the LXD UI as it is, just do minimum rebranding through a couple of simple patches and then ship that through my package repository.
If someone wanted to invest a bunch of time and effort into maintaining a full fork, that’d obviously be fine too.
I’m available to maintain it
That Canonical LXD UI has now been packaged as incus-ui-canonical in my package repository.
A live demo of it is also available at Linux Containers - Incus - Try it online by clicking the Access a Web UI link after starting the session.
If you are actively developing/maintaining an Incus compatible web UI and would like to have it packaged in my repository, let me know or better yet, send a pull request!
4 Likes
I am very pleased that the LXD UI works with Incus, because this means that the Incus and LXD REST APIs are still mostly compatible. I hope it remains so. You had indicated here not to count on such compatibility and you specifically mentioned that “For the lxd-to-incus migration tool, we import both the incus and lxd clients in the same binary, specifically so we don’t rely on the incus client to talk to LXD or vice-versa.”
I would like to see more things being compatible between LXD and Incus. There may be other tools besides the LXD UI that could work in both products. I develop such a tool and I use it to launch LXD and Incus containers the same way. I resorted to writing my own API with the things that I need from each product, and implemented it for Incus and for LXD using their respective Go packages.
A central piece of the API is the Go package github.com/lxc/incus/shared/api for Incus and github.com/canonical/lxd/shared/api for LXD. I wish parts of this package could eventually be shared between the two projects and become a sort of common API (like the S3 API which is shared across many products).
Comparing api/instance.go between Incus and LXD, I see that they differ mostly in comments. The LXD version has comments that include “LXD” and “lxd”, while the Incus version has more generic terms:
// InstancePut represents the modifiable fields of an instance.
// InstancePut represents the modifiable fields of a LXD instance.
One more substantial difference is the deprecated LXD ContainerOnly field, that has been removed from Incus. This means that instance.go cannot currently be shared between the two products in Go. But the JSON representations of the instance.go types are still compatible between Incus and LXD. Is there, or can there be a specification of the API that both products can adhere to?
I did contact Canonical at the beginning of the Incus work to inquire about willingness to switch to the generic terms so that code could be more similar between both projects. I was told the request would need to be escalated and I have not heard anything since, so I wouldn’t hold my breathe about the likelihood of shared code/initiatives at this point.
LXD UI is a modern API client so it already was staying away from the bits of API that was removed in Incus, leaving the main differences to be around deprecated config keys and the like which was simple enough to patch in place. There are a few more differences around types for things like the server config (incus is map[string]string, lxd is map[string]any because of trust_password), but that kind of difference is invisible in javascript.
I would like to use it, though the way of CLI creating certificate and adding trust for that in a browser is not seriously an easy and perhaps less safe way of managing a whole lxd host/cluster.
Till a better authentication solution is provided, including a Role Based Access such as Openfga etc. I would consider it as a tool for a one-man show.
Incus 0.2 has OIDC without OpenFGA but Incus 0.3 which will be released very very soon does have OpenFGA support.
1 Like
Looking forward to it.
Finally, an authentication and RBA, with a broad compatibility.
Rather than generating a new cert, is it possible to put an LE certificate somewhere that the (Incus) UI will be able to use it? I looked through the Incus documents and those of, um, the original project and it wasn’t clear where. Or do you insist on a private cert, which I’d rather not do?
You can configure Incus itself to use Let’s Encrypt, see the acme server configuration options.
That would then get you a valid certificate for the web UI.
Yes, I saw that. Unfortunately my hosts are not open to the Internet inbound so I use DNS-01 to generate the LE certs.
If they’re clustered, you can use incus cluster update-certificate to replace the public facing cluster certificate across your cluster with a new one.
If they’re standalone, then you’d want to directly replace /var/lib/incus/server.crt and /var/lib/incus/server.key with your cert and then run systemctl restart incus to reload the API.
Great, thanks. I’ll give it a try.
I don’t cluster because with (UK) energy costs being what they are I bring hosts down when I’m not using them; and I find things that rely on a quorate don’t like that.
Yeah, indeed, you’d need a minimum of 2 systems up at all times.
Thanks, I did (finally …) do this but on first login Incus still wants me to create a new certificate. The (Firefox) browser says my cert is valid. Is this expected behaviour, ie I need to still create and import a browser cert even though I’m using a “proper” site certificate?
don’t mix ssl certificate and client trust certificate, first one used to protect connection between client and server, while second for authorization.
so yes, you need both of them, unless:
- some UI would support OpenConnect ID (OIDC) auth (+flow)
- you have OIDC provider self-hosted (like KeyCloak) or in cloud (Okta)
- incus were configured for OIDC
for me it looks like a pain in the… in the current state
Well, it’s confusing - since the TLS cert is supposed to establish the identity of the server; whereas auth is an entirely separate exercise, the IAP should give the browser a token. I don’t see why there is a need for a separate client cert, it doesn’t improve security in any way.