This post shows how to setup the Incus UI
- expose the port 8443
- create the user certificate
- install the user certificate to Incus and your browser
- troubleshooting
- auxiliary explanations.
This post was written in response to a user’s question.
3 Likes
Hello Simos, thank you for writing this how-to. I do have a question. You mention replacing the /var/lib/incus/server.{crt,key} with properly-signed ones using ‘incus cluster update-certificate’ (minor typo: the article still says ‘lxc cluster update-certificate’) so that the browser does not complain about self-signed certificates. However, when I use that command it updates the /var/lib/incus/cluster.{crt,key} files on all nodes and does not touch the server.{crt,key} files.
Do you or anyone know if there is a different way to use a command to update the https TLS certificate in the server.{crt,key} files?
I think I didn’t fully read what you said in the article. You do mention that you use the cluster command to update it and I guess I assumed that would update the server file and you did not mention that there is a separate cluster file.
Unfortunately I don’t have my original self-signed certs but I am gathering that for a cluster you need the cert to have subject-alternate names for each cluster member? I ask because I notice that my remote clients are expecting the cert to cover the FQDN of each node. If they are all the same then a single cert needs to be valid for all the node names.
Thanks, I fixed the typo.
I have not tested the cluster setup and I merely conveyed what (I understood that) is said in this post, Possible to use a 'real' SSL certificate for LXD API rather than self-signed? - #2 by stgraber
I think that @stgraber can shed some light here.
Hi
I was just wondering and hope that my suggestion makes sense. When one installs Incus, the web ui should be installed automatically. Maybe just a cli command to enable/disable it. Or run it in a docker container, like the one I’m currently using: LXConsole. I sometimes struggle to get the Incus web ui up and running, so I ran to LXConsole. It just works.
Run the incus webui command on any distro which packages the UI. For the Zabbly packages, you do that through apt install incus-ui-canonical
I dont get why we dont have an official repo for ui for incus. Can anyone explain this?
Because there is no such thing as an official UI for Incus. There are many options but no official one.
The most common one is to run the LXD UI from Canonical on top of Incus with some modifications, that’s what the incus-ui-canonical package contains (and why it’s named that way).
Why not create a WEBUI of our own?
Because we’re not web developers and implementing a full web UI like the one we’re getting from Canonical takes a long time to do it right 
The LXD UI team at Canonical is a 2-3 people show and the current UI is the result of probably 3-4 years of work at this time.
So far none of the other options have really ticked the boxes we’d want to have for something we could consider an official UI, so far the LXD UI is the closest from a design / feature standpoint but obviously not something we’ll ever want to bless as official either.
1 Like
How to use manually compiled web UI static files
As someone having spent almost 3 months of my free time working on a webui from scratch, I can tell you it’s a pain to get right. As far as funding goes, I’m not able to work on it anymore, but if that can be covered, I’m happy to resume the work. So far, I have a Proxmoxy-feeling UI, but it would require a good 6 to 8 months of love to actually be usable.
1 Like
Is it open source? I want to give it a try
No, it’s not open source yet, and it doesn’t have the features that can be expected from a working Incus UI. This screenshot features some of the nice working bits and shamelessly hides all the things that don’t work
It will be published once it reaches an acceptable level of maturity, but I’m currently trying to get that work funded. Unfortunately, it is currently stalled, as the amount of work required is huge, and I’m not in a position where I can work on it pro bono.
I realize it was probably unfair of me to post a screenshot and basically say “you can’t get it”; still, I’d be really glad to see this project released next year.
1 Like
so far the LXD UI is the closest from a design / feature standpoint but obviously not something we’ll ever want to bless as official either.
Is there anything preventing the community to develop incus UI based on LXD UI? If not, what would be required to get it to the point where it can become official?
If it’s possible to fill in the task list for incus UI MVP it would probably be best to have community develop it, I don’t see why many wouldn’t be interested in contributing to it (instead of making their own versions like what bensmr did).
It can be done on some off branch until it’s MVP ready.
Absolutely nothing, except obviously lots of time.
Having the same feature set as the Canonical UI, because we don’t want to be replacing something that works with something of our own that’s not usable.
That’s a tough one, because replacing a product with another comes with the expectation that the latter does everything the former did, so… you already have the tasklist with what the Canonical UI offers.
Yeah, I’m not developing it for just myself, I started the work to have a clear idea of what’s needed to make it work, and most of all, the time it would require for a seasoned developer that has a good understanding of the Incus API. And even if the Canonical UI looks simple, the work behind it is damn huge. For the record, I’m currently waiting for funding approval right now (should take a few more months to have an answer), and if that works out, it will be an actual project on which people can contribute a few months later, once the ground work is done.
Keep in mind that it’s a pretty low-reward project, because the Canonical UI just works, and getting up to par takes time that most of community contributors prefer to put into the actual Incus software.
Thank you for spending your time answering this. I have a bit of a hard time following.
Does incus-ui-canonical fully use incus or does it stilly rely on LXD? If it still relies on LXD, did incus API diverge significantly enough for it to require a lot of effort to just update the endpoints?
If on the other hand existing incus UI replaced LXD with Incus, then it has the same feature set as Canonical UI which as you say qualify it to become official.
I would be grateful to get pointed out what I’m missing.
It is a fork of the LXD UI, ported to use the Incus API. Both APIs are quite similar, but API features that only exist in Incus aren’t really supported in the UI, it being “just” a rebased fork (which is updated regularly, integrating upstream features).
Alright, but it has the same feature set as the Canonical UI and it’s usable. There must be a different reason why it’s not official then. Does it have to implement all incus API features for it to be official?
Edit: Upon thinking about it, I think it’s pretty clear that if Incus to have it’s own UI it needs to support most of it’s use cases. It’s possible to start it off from LXD UI but the task might still be considerable and have to involve incus maintainers to work out, and maybe resources are better spent elsewhere.
Well, it depends. We (FuturFusion in this situation) wouldn’t do that as LXD UI is GPLv3 and we’d rather a new UI to be Apache 2.0 or BSD licensed. This therefore prevents us from using the LXD UI as a base, requiring a completely new project built from the ground up.