lxd VS LXC

Please correct me if I'm wrong, but the post also links the "add Canonical CLA check #12665" [0], and my understanding is that "retain copyright" here is like a typical forum agreement where you going forward must agree to a perpetual worldwide unlimited license to Canonical that they can use as they please per [1]:

>In effect, you’re giving us a licence, but you still own the copyright — so you retain the right to modify your code and use it in other projects.

You explicitly do retain ownership, so you can then take that same code and contribute it elsewhere under any license you wish. The same author could contribute the same patch to both the LXD and the Incus fork. But some might object to being required to allow Canonical to specially license as they want.

So your characterization seems unfair, and then gets kind of nasty at the end:

>The author is pissed off because he can't build custom versions without redistributing the modifications

Incus is a full fork, and Canonical has apparently been taking changes back from it as well as is often the case with such forks where both sides get value from each other. It's perfectly understandable for some folks to be bummed if that's no longer the case, and there is nothing evil about the Apache2 license. There's plenty of history that in OSS going back to the beginning, no need for insinuations or attacks.

----

0: https://github.com/canonical/lxd/pull/12665/commits/eb5c773d...

1: https://ubuntu.com/legal/contributors

You could consider LXD which lets you easily run both containers and VMs: https://ubuntu.com/lxd

I hope this doesn't affect LXC negatively.

LXC and LXD share plenty of contributors.

https://github.com/lxc/lxc/graphs/contributors

https://github.com/canonical/lxd/graphs/contributors

I use an "unprivileged LXC container" setup on several Debian bullseye hosts. It works fantastic, and each LXC container feels like a real server.

Compare that to Docker's "one-container-one-process" philosophy, reinventing the wheel by awkwardly composing multiple containers.

[1] https://linuxcontainers.org/lxd/

The expected changes are: - https://github.com/lxc/lxd will now become https://github.com/canonical/lxd - https://linuxcontainers.org/lxd will disappear and be replaced with a mention directing users to https://ubuntu.com/lxd - The LXD YouTube channel will be handed over to the Canonical team - The LXD section on the LinuxContainers community forum will slowly be sunset in favor of the Ubuntu Discourse forum run by Canonical - The LXD CI infrastructure will be moved under Canonical’s care - Image building for Linux Containers will no longer be relying on systems provided by Canonical, limiting image building to x86_64 and aarch64.

I hope this doesn't affect LXC negatively.

LXC and LXD share plenty of contributors.

https://github.com/lxc/lxc/graphs/contributors

https://github.com/canonical/lxd/graphs/contributors

I use an "unprivileged LXC container" setup on several Debian bullseye hosts. It works fantastic, and each LXC container feels like a real server.

Compare that to Docker's "one-container-one-process" philosophy, reinventing the wheel by awkwardly composing multiple containers.

There is an issue with lxc as stated here: https://github.com/lxc/lxc/issues/4283 and https://github.com/Vanilla-OS/apx/issues/118

I'm currently attempting to enroll my Ubuntu (20.04) (Unprivileged) LXC hosts to my windows AD server but am having difficulty. I'm using SSSD and KRB5 to manage the user directory and authentication. Once joining the domain with realmd, all seems ok, I can use the id command, etc to lookup users and groups and the host appears in Windows Users and Computers. The issue I'm having is with authentication, I believe it to be related to this issue however I don't entirely understand the solution and can't seem to find much else on the matter (Note the method I'm using works fine on full VMs). Would anybody please be able to provide more clarity in layman's terms?

I don't recall having to do any uid/gid fixup last time I made an unprivileged container. I did have to prepare the unprivileged host user, of course, by reserving a range of subordinate uids/gids (/etc/sub?id) and configuring a virtual network interface limit (/etc/lxc/lxc-usernet).

To create the container, I did this:

lxc-create -t download -n -- -d debian -r bullseye -a amd64

Note that this runs the 'download' template, which (IIRC) is better suited to unprivileged containers than the 'debian' template is. The 'download' template will list its available distros if you do this:

lxc-create -t download -n -- --list

Note that some versions of lxc-create may fail with a keyserver error because sks-keyservers.net died somewhat recently. Workaround: DOWNLOAD_KEYSERVER=hkp://keyserver.ubuntu.com lxc-create

https://github.com/lxc/lxc/issues/3894

Found this issue and edited the config file of the lxc container:

and on this thread... an different approach is described

https://github.com/lxc/lxc/issues/1629#issuecomment-311379508