Yeah, most enterprise deployments of Incus use OIDC for authentication and then OpenFGA for authorization with permissions typically synchronized with something like AD/Entra.
TLS certs remain used for some role account type stuff and as a break glass type of access for when OIDC is unavailable and there's an emergency. A nice characteristic of TLS certificates is that they can be generated safely in a HSM which you can then dump into a safe, works well in the corporate world, much better than passwords for this kind of thing.
It's very very different between the UI and Incus itself :)
The Incus teams are low level system engineers who develop in Go or C.
The UI is a pile of typescript which none of us really want to understand/touch any more than strictly needed.
The Incus UI is a soft fork (really just a small overlay) on top of the LXD UI to adjust for the API differences between LXD and Incus and for fixing the few big gripes we had with the LXD UI. Because both projects are under the same license, we can actually just follow what happen in LXD UI and pull in code from it.
Incus is a very different beast. The whole reason the project had to be started is because of Canonical's series of changes which eventually led to a re-licensing of LXD to AGPLv3. With Incus remaining Apache 2.0, none of us can even look at the LXD code without risking being "tainted". We cannot import any code from LXD since that license change and we never have. However LXD has no problem with importing Apache 2.0 code into an AGPLv3 codebase, which they have quite actively been doing.
In short Incus is a hard fork of LXD, we don't look at any LXD code or even at their issues or release announcements (mostly because it's not useful for those two). That means that everything that happened in Incus since December 2023 has been completely independent of LXD.
The Incus UI is a soft fork of the LXD UI, it's rebased every time they push a new version out and our goal is to keep the delta as small as possible as it's something we want to spend as little time on as we possibly can. It's also why we always package it as "incus-ui-canonical" to make it very clear as to what it is.
There are also other UIs out there that could be used, sadly last I checked none came close to the feature coverage of the LXD UI or they had dependency on external components (database, active web servers, ...) whereas what we want is a UI that's just a static javascript bundle which then hits our REST API like any other client.
It's indeed still open source, but was moved from Apache 2.0 to AGPLv3 and from not having any requirements to contributions to requiring all contributors sign a CLA.
So it's definitely still open source, but the changes they made allows them to still look and import any change from Incus that they wish, whilst preventing us from looking at any LXD code without risk of tainting ourselves...
Of course following the move and going AGPLv3 would solve the project contribution issue.
In fact it'd back Canonical into an interesting corner as Incus would be allowed to freely take LXD changes, but the opposite would not be possible unless they let go of the CLA.
It certainly would put Incus in a great situation, if it wasn't for the fact that we think keeping the Apache2 license is the right thing to do. The Go packages provided by Incus are used in hundreds of other codebases, a switch to AGPLv3 would cause those codebases to have to follow which would only lead to reduced adoption for Incus and a lot of pain in the Go ecosystem as a whole.
And then there is the fact that many large companies, including some that have been relying on LXD in the past, have policies specifically against the consumption of AGPL code. One prime example of that would be Google, which last I checked make up more than 50% of the LXD user base thanks to LXD being used on Chromebooks for the Linux shell feature.
Overall, the thing I hate most with this change is that it's going to make what was otherwise a pretty cordial relationship between the two projects now turn into a very stressful one where we need to basically be careful not to look at each other's stuff...
It may seem that LXD and Incus were straight up competitors, but in reality, we were doing behind the scenes debugging together, sending each others' link to pull requests and specifications, ... this effectively all ends today and it's a shame.
They changed COPYING from Apache2 to APGLv3 without introducing any SPDX headers or similar to denote what is Apache2 and what isn't. So yes, while AGPLv3 is compatible with Apache2, it doesn't grant anyone the right to relicense code.
Anyone is allowed to take my Apache2 code and do what they wish with it so long as it remains Apache2, you can't just go and replace the license text from one license to another and call it good, that code is still Apache2.
Anyone is welcome to use my code in a proprietary piece of code, indeed the Apache2 license allows it.
What it doesn't allow is for my code to be re-licensed to AGPLv3 nor can they grant themselves a license to do whatever they want (their CLA).
So indeed they could keep importing Incus bugfixes and new features into LXD, but that code would need to have an exception carved out in their current contribution requirements as the code would not come from an author that has signed the Canonical CLA nor would it be under the AGPLv3 license.
They would also need adequate tracking of this so they don't accidentally assume that the code belongs to them and that they can re-license it as they wish for other projects. Also anyone who stumbles onto that code in the LXD codebase should be properly informed that they can include that code in a non-AGPLv3 project as that bit of code is Apache2, not AGPLv3.
It is used for Crostini. Specifically, ChromeOS uses corssvm to run a virtual machine in which it runs LXD and then creates containers inside of that VM through it.
Google has sent the occasional bugfix, usually for pretty complex issues (hard to hit race and the like) but weren't involved in project maintenance or even very actively talking to us. We'd usually bump into the Crostini folks at conferences once or twice a year and just talk over dinner.
The LXD project had over 300 contributors over the years which while not up to par with insanely large projects like Kubernetes or Linux is still pretty respectable.
So achieving similar level of contributions to a fork would already be pretty nice. It's hard to predict the community reception of the fork though and whether that will lead to more contributions than has been seen in the past when the project was backed by Canonical or if there being two active codebases will result in a reduced set of contributors to both.
It doesn't. The LXD team does make and support the snap, but LXD itself doesn't depend on it at all.
The majority of LXD users are actually on ChromeOS which is Gentoo based and uses a LXD ebuild package. Debian has a native .deb package too, so does ArchLinux, Alpine, OpenSUSE and a few others.
LXD however does need some special code to handle being run as a snap, that part can become a bit annoying to account for and test at times.
As mentioned, this isn't my fork, it's a fork made by Aleksa who's been the long time LXD packager for OpenSUSE as well as someone very involved within the container space, both userspace (runc, umoci, containerd, ...) and in the Linux kernel space.
I've just been helping out getting it to actually be functional and providing a bit of a laundry list of things I'd do differently should I be starting LXD from scratch now, which a fork like this now makes possible.
We've started building daily images of some Linux distributions' desktop environments. Those run using LXD VMs and get you functional desktop environment already setup with user account and all. No install or setup needed, great to try other distros.
Currently got Arch and Ubuntu available, Fedora should follow soon, then we'll go based on demand.
LXD works fine on WSL2 as unlike WSL1 you're now getting a full Linux kernel.
The main issue left is that WSL2 doesn't start your normal init system and so makes it harder to run a daemon... You end up having to manually start it every time which is a bit annoying.
But my understanding is that Microsoft is actively working on this and that we should have the normal init system run in some way in the near future.
There are quite a few Linux distributions with native packages in their main repository, that includes ArchLinux, Alpine, Gentoo and OpenSUSE for those that I'm aware of with active package maintainers. There also are packages for Fedora/CentOS/RHEL through maintained COPR repositories and I'm sure I'm forgetting some distros.
Go can be a bit annoying to package in general and LXD was made a bit harder by also having a stack of C libraries for some bits, though with 4.6 we kicked out the need for a custom sqlite and for a coroutine library, so on the C side, outside of the C library, it's down to liblxc, libraft and libdqlite making it a bit easier to package.
For distributions that have a policy of splitting every single Go package into their own source packages (as is the case with Debian), our recommendation is to stick to the LTS release of LXD which only gets released every 2 years and where the bugfix releases don't normally alter dependencies.
The normal feature releases come out every month and those just aren't a good fit when it may take you more than a month to get any new dependency packaged independently first...
Anyway, as an upstream, we are very happy to work with packagers to get native packages in as many distribution as possible.
We do maintain the snap package ourselves and certainly do enjoy it as an upstream since it gives us very large distribution and release coverage with a single package.
That being said, at the end of the day, all we care about is that our users get to run an up to date, secure, LXD. How they get is doesn't really matter to us as an upstream :)
And it's maybe interesting to point out that the majority of our userbase these days are on Chromebooks, effectively using the Gentoo ebuild package of LXD!
NFS currently cannot be used inside a user namespace.
There are patches floating around (similar to the work we did to allow FUSE) but they haven't made it upstream yet and my understanding is that there is some tricky corner cases on NFSv3 which still need to be sorted (NFSv4 was easier due to already having uid mapping capabilities).
The LXC and LXD repositories are under https://github.com/lxc which is a different Github organization with a much much smaller set of members (17 currently) than CanonicalLtd.
We require 2FA for all accounts under the lxc organization and only grant the access that's actually needed by those contributors. So while it's not impossible that one of our members' credentials may get compromised, especially when considering the use of access token, current access is as restricted as you would expect for those repositories.
It's also worth noting that because of Git's own design, even should one of those accounts get compromised, it would be fairly simple to spot and revert any changes that may have occurred.
TLS certs remain used for some role account type stuff and as a break glass type of access for when OIDC is unavailable and there's an emergency. A nice characteristic of TLS certificates is that they can be generated safely in a HSM which you can then dump into a safe, works well in the corporate world, much better than passwords for this kind of thing.