stgraber

12 ms·

1.
by stgraber 10mo ago
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
2.
by stgraber 10mo ago
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 stric
3.
by stgraber 10mo ago
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
4.
by stgraber 10mo ago
You can download the CLI client for Linux, Windows and MacOS from our Github releases: https://github.com/lxc/incus/releases/latest/ I've filed https://github.com/lxc/incus-os&#
5.
by stgraber 2y ago
The LXD UI is a separate project from LXD, it's at https://github.com/canonical/lxd-ui It's one of the UI options you can use on top of Incus and a rebranded version of it is what we're making available
6.
Incus 6.0 LTS has been released(discuss.linuxcontainers.org)
34 points by stgraber 2y ago|12 comments
7.
by stgraber 3y ago
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 possib
8.
by stgraber 3y ago
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
9.
by stgraber 3y ago
Yes it is indeed
10.
by stgraber 3y ago
https://linuxcontainers.org/incus/try-it/ give it a try :)
11.
by stgraber 3y ago
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 (t
12.
by stgraber 3y ago
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 (h
13.
by stgraber 3y ago
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 pre
14.
by stgraber 3y ago
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
15.
by stgraber 3y ago
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
16.
by stgraber 4y ago
LXD now has a lxd-user process which allows for automated restricted project generation providing a safe LXD environnement for non-admin users. https://youtu.be/6O0q3rSWr8A
17.
by stgraber 5y ago
TLDR for those who don't want to watch the video! 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 us
18.
by stgraber 6y ago
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
19.
by stgraber 6y ago
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 Fedo
20.
LTS release of system container and VM manager LXD(discuss.linuxcontainers.org)
3 points by stgraber 6y ago|0 comments
21.
by stgraber 7y ago
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
22.
LXD 3.15 has been released(discuss.linuxcontainers.org)
6 points by stgraber 7y ago|0 comments
23.
by stgraber 7y ago
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
24.
by stgraber 8y ago
Indeed, as an upstream project, maintaining packages in several distributions is extremely time consuming and near impossible when like us, you're doing monthly releases. We welcome distributions packaging LXD directly themselves and t
25.
by stgraber 8y ago
Note that Ubuntu 20.04 will be using the snap package, so we only really need to focus on one thing to validate for all distros. Users upgrading from 18.04 to 18.10 are already being automatically migrated over to the snap. We have 3 tracks
26.
by stgraber 8y ago
At this point, the only feature that I'm aware of which we have in the Ubuntu kernel and hasn't been merged upstream yet is support for overlayfs inside user namespaces. The other big one for a long time was fuse inside user names
27.
by stgraber 11y ago
It's not as the appc spec stands for "app container" and LXD doesn't run application containers but instead full system containers.
28.
Try LXD (Linux Containers) Online(linuxcontainers.org)
2 points by stgraber 11y ago|0 comments
29.
by stgraber 12y ago
Right and it seems unlikely that either license change happened with consent from all contributors up to that point, so as the project doesn't have a CLA and the copyright of the individual contributions remains with their original aut
30.
by stgraber 12y ago
Correct, a commercialization clause is clearly incompatible with the GPL as is mentioned in their FAQ: http://www.gnu.org/licenses/gpl-faq.html#NoMilitary So short of proper dual-licensing (which this isn't), that

More ›