Discussion:
[lxc-users] LXC 3.0.0: Packaging Changes To Be Aware Of
Christian Brauner
2018-04-07 14:54:07 UTC
Permalink
Hey everyone,

LX{C,FS,D} upstream here. :)

I'm sorry to ping you all at once in this mail and I seriously hope I only
added actual package maintainers for LXC based projects in their respective
distros to this mail. If not I'm genuinely sorry to have banged on your door
(or rather inbox) on a Saturday!

A few days ago we released LXC [1] and LXD [2] 3.0.0 which are going to be our
next LTS releases receiving support from upstream for 5 years until 2023.

LXC 3.0.0 not just introduces a lot of changes and improvements on all fronts
in general but will also likely require changes in packaging. These changes are
what I'd like to inform you about because we really don't want you all to run
into pointless confusion and problems.

The distros I think should be reached by this mail are:

Alpine
ArchLinux
Debian
Fedora
Gentoo
NixOS
openSUSE
OpenWrt

Please, if anyone of you know other packagers in other distros that are not
derivatives of the above please forward this mail. Don't leave fellow
maintainers hanging. :)

Here is a list of what we consider will most likely affect you as packagers:

1. **Important** the lxc-templates have been moved out of the main LXC tree
into a separate repository
https://github.com/lxc/lxc-templates

This means that without this separate package LXC will now only come with
the following templates:

lxc-busybox
lxc-download
lxc-local
lxc-oci

2. **Important** distrobuilder is the new way of creating machine/system
container images
The templates have been replaced by a new project called "distrobuilder"
[5]. It aims to be a very simple Go project focussed on letting you easily
build full system container images by either using the official cloud image
if one is provided by the distro or by using the respective distro's
recommended tooling (e.g. debootstrap for Debian or pacman for ArchLinux).
It aims to be declarative, using the same set of options for all
distributions while having extensive validation code to ensure everything
that's downloaded is properly validated.

**Warning: Advertisement** please consider packaging distrobuilder.
https://github.com/lxc/distrobuilder

A more lengthy justification can be found at:
https://brauner.github.io/2018/02/27/lxc-removes-legacy-template-build-system.html

3. The python3 bindings have been moved out of the main LXC tree and are
maintained in a separate Github repo under the LXC namespace.
https://github.com/lxc/python3-lxc

This means that the

--with-python

configure flag should be dropped.

A more lengthy justification can be found at:
https://brauner.github.io/2018/02/27/lxc-removes-legacy-template-build-system.html

4. The lua bindings have been moved out of the main LXC tree and are
maintained in a separate Github repo under the LXC namespace.
https://github.com/lxc/lua-lxc

This means that the

--with-lua

configure flag should be dropped.

A more lengthy justification can be found at:
https://brauner.github.io/2018/02/27/lxc-removes-legacy-template-build-system.html

5. **Important** the pam_cgfs.so pam module has moved from the LXCFS tree into
the LXC tree
https://github.com/lxc/lxc/blob/master/src/lxc/pam/pam_cgfs.c

This means that in order to compile the pam module with LXC you should pass:

--enable-pam

and

--with-pamdir=PAM_PATH

when compiling LXC.
In case you don't know what the pam module is for it is used to allow
unprivileged cgroup management for fully unprivileged containers. It
useful for all container runtimes (e.g. openSUSE is shipping and
using it). For a slightly deeper look at it I suggest you read [3].

6. Removeal of legacy cgroup drivers
This includes the cgmanager driver. Which also implies that

This means that the

--with-cgmanager

configure flag should be dropped. The cgmanager package can likely also be
dropped unless you maintain a package for our 1.0 stable branch!

A more lengthy justification can be found at:
https://brauner.github.io/2018/02/20/lxc-removes-legacy-cgroup-drivers.html

7. All legacy configuration keys have been removed.
With LXC 2.1.0 we started to print warning when legacy configuration keys
were used in the container config and started yelling at people that we will
remove legacy configuration keys in LXC 3.0.0. This is now reality.
lxc-update-config
/usr/bin/lxc-update-config -h|--help [-c|--config]
config: the container configuration to update

which will automatically replace legacy configuration keys with their new
counterparts. If the upgrade fails it will have left a *.backup file in the
same directory where the config file was and it can simply be restored.

Please make sure your users know about this update script. Fwiw, [4]
provides a list of all removed legacy configuration keys and their new
counterparts.

8. **Warning: Advertisement** for any distro on here that does not already
package LXCFS which has been around for a long time they should consider it.
It provides a *runtime agnostic* way of partially virtualizing /proc through
a minimal multi-threaded fuse filesystem.
These mocked files can be overmounted over their /proc counterparts in the
container.
https://github.com/lxc/lxcfs

For a thorough overview over what has changed please see:
https://discuss.linuxcontainers.org/t/lxc-3-0-0-has-been-released

Thank you all for packaging LXC, LXCFS, and LXD!
The LXC team

[1]: https://discuss.linuxcontainers.org/t/lxc-3-0-0-has-been-released
[2]: https://discuss.linuxcontainers.org/t/lxd-3-0-0-has-been-released
[3]: https://brauner.github.io/2018/02/28/lxc-includes-cgroup-pam-module.html
[4]: Legacy Key | New Key | Comments
-------------------------------------|-------------------------------|---------
lxc.aa_profile | lxc.apparmor.profile |
lxc.aa_allow_incomplete | lxc.apparmor.allow_incomplete |
lxc.console | lxc.console.path |
lxc.devttydir | lxc.tty.dir |
lxc.haltsignal | lxc.signal.halt |
lxc.id_map | lxc.idmap |
lxc.init_cmd | lxc.init.cmd |
lxc.init_gid | lxc.init.gid |
lxc.init_uid | lxc.init.uid |
lxc.kmsg | - | removed
lxc.limit | lxc.prlimit |
lxc.logfile | lxc.log.file |
lxc.loglevel | lxc.log.level |
lxc.mount | lxc.mount.fstab |
lxc.network | lxc.net |
lxc.network. | lxc.net.[i]. |
lxc.network.flags | lxc.net.[i].flags |
lxc.network.hwaddr | lxc.net.[i].hwaddr |
lxc.network.ipv4 | lxc.net.[i].ipv4.address |
lxc.network.ipv4.gateway | lxc.net.[i].ipv4.gateway |
lxc.network.ipv6 | lxc.net.[i].ipv6.address |
lxc.network.ipv6.gateway | lxc.net.[i].ipv6.gateway |
lxc.network.link | lxc.net.[i].link |
lxc.network.macvlan.mode | lxc.net.[i].macvlan.mode |
lxc.network.mtu | lxc.net.[i].mtu |
lxc.network.name | lxc.net.[i].name |
lxc.network.script.down | lxc.net.[i].script.down |
lxc.network.script.up | lxc.net.[i].script.up |
lxc.network.type | lxc.net.[i].type |
lxc.network.veth.pair | lxc.net.[i].veth.pair |
lxc.network.vlan.id | lxc.net.[i].vlan.id |
lxc.pivotdir | - | removed
lxc.pts | lxc.pty.max |
lxc.rebootsignal | lxc.signal.reboot |
lxc.rootfs | lxc.rootfs.path |
lxc.se_context | lxc.selinux.context |
lxc.seccomp | lxc.seccomp.profile |
lxc.stopsignal | lxc.signal.stop |
lxc.syslog | lxc.log.syslog |
lxc.tty | lxc.tty.max |
lxc.utsname | lxc.uts.name |

[5]: https://github.com/lxc/distrobuilder
Mihamina RAKOTOMANDIMBY
2018-04-07 19:11:58 UTC
Permalink
Post by Christian Brauner
2. **Important** distrobuilder is the new way of creating machine/system
container images
The templates have been replaced by a new project called "distrobuilder"
[5]. It aims to be a very simple Go project focussed on letting you easily
build full system container images by either using the official cloud image
if one is provided by the distro or by using the respective distro's
recommended tooling (e.g. debootstrap for Debian or pacman for ArchLinux).
It aims to be declarative, using the same set of options for all
distributions while having extensive validation code to ensure everything
that's downloaded is properly validated.
**Warning: Advertisement** please consider packaging distrobuilder.
https://github.com/lxc/distrobuilder
https://brauner.github.io/2018/02/27/lxc-removes-legacy-template-build-system.html
Hello,

I'm looking for some tutorial of using the image built with distrobuilder.

After having build the image: how to start it with lxc-start?
--
--
*Mihamina RAKOTOMANDIMBY
Tél: +261 32 11 635 03
Calendar: http://mihamina.rktmb.org/p/calendar.html

/DevOps, Linux, Jira, Confluence, PHP, Java/ *
Christian Brauner
2018-04-09 11:32:53 UTC
Permalink
Post by Mihamina RAKOTOMANDIMBY
Post by Christian Brauner
2. **Important** distrobuilder is the new way of creating machine/system
container images
The templates have been replaced by a new project called "distrobuilder"
[5]. It aims to be a very simple Go project focussed on letting you easily
build full system container images by either using the official cloud image
if one is provided by the distro or by using the respective distro's
recommended tooling (e.g. debootstrap for Debian or pacman for ArchLinux).
It aims to be declarative, using the same set of options for all
distributions while having extensive validation code to ensure everything
that's downloaded is properly validated.
**Warning: Advertisement** please consider packaging distrobuilder.
https://github.com/lxc/distrobuilder
https://brauner.github.io/2018/02/27/lxc-removes-legacy-template-build-system.html
Hello,
I'm looking for some tutorial of using the image built with distrobuilder.
After having build the image: how to start it with lxc-start?
lxc-create -n <container-name> -t local -- --metadata /path/to/meta.tar.xz --fstree /path/to/rootfs.tar.xz
lxc-start -n <container-name>

Also see:
https://asciinema.org/a/165783

Christian
Adrian Pepper
2018-07-17 20:11:43 UTC
Permalink
This message devolved from a different query which is implied here together
with its answer. Perhaps this result will save some other people some time.
I just discovered a stupid user (lxc administrator) trick.
Suppose you have an lxc setup you are migrating from Ubuntu 16.04 to 18.04.
(Going from lxc 2.0(2.0.8) to 3.0(3.0.1)).
(Doing a fresh install of Ubuntu 18.04 and modifying to match).
If under Ubuntu 18.04 you install the "lxc" package, but not the
"lxc-templates" package, then, even after "lxc-update-config",
some of your lxc config files will fail because of...
(for example)
lxc.include = /usr/share/lxc/config/ubuntu.common.conf
As an even stupider user trick, things seem to superficially work properly
if you simply remove the "ubuntu." from the config file, leaving
lxc.include = /usr/share/lxc/config/common.conf
It turns out /usr/share/lxc/config/ubuntu.common.conf (and many others)
are provided under Ubuntu by the "lxc-templates" package.
Hmm. Could lxc-update-config (be changed to) remark upon the need for
the lxc-templates package? Or maybe just make a general observation
that the include file does not exist? ("Something is wrong")
While waiting for the above message to actually appear, I thought of a
perhaps better set of comments on the same thing. As a follow-up to
Christian Brauner's packaging change announcement.

I eventually wonder (below) if "lxc" could once again have "lxc-templates"
as a dependency, even though "lxc-utils" does[should] not. Since "lxc"
is now branded as a transitional package => lxc-utils.


Adrian Pepper
Subject: [lxc-users] LXC 3.0.0: Packaging Changes To Be Aware Of
Hey everyone,
LX{C,FS,D} upstream here. :)
[...]
1. **Important** the lxc-templates have been moved out of the main LXC tree
into a separate repository
https://github.com/lxc/lxc-templates
This means that without this separate package LXC will now only come with
lxc-busybox
lxc-download
lxc-local
lxc-oci
The templates had been in a separate "lxc-templates" package also in
Ubuntu 16.04.
But "lxc-templates" had been a dependency of the "lxc" package and
was therefore dragged in automatically.

But with the change indicated in the quoted announcement, it no longer
gets so dragged in.

But an unmentioned associated effect of not dragging in lxc-templates
is that most of the files
/usr/share/lxc/config/*.conf
are no longer put in place.

So "lxc-templates" must be installed not only to use the templates
to generate new containers. It must be installed if you are going
bring forward containers from Ubuntu 16.04 (lxc 2.0), which had been
generated using templates.

"lxc-update-config" works without complaint on containers whose config
includes, for example

lxc.include = /usr/share/lxc/config/ubuntu.common.conf

But the containers still fail afterwards because the include is not
satisfied. (They fail, that is, until "lxc-templates" is installed).

(Assume here that a common way of producing an upgraded host system,
e.g. Ubuntu 18.04 versus 16.04, is to produce a new minimal 18.04
system and then apply all recorded "apt install" commands corresponding
to actual desired packages (yes, modifications are sometimes needed,
but...). The old 16.04 system need not have explicitly done "apt
install lxc-templates" and so that could be overlooked in 18.04).

Since "lxc" is now branded as a transitional package => lxc-utils,
could "lxc" have lxc-templates as a dependency, even though lxc-utils
will not?


Adrian Pepper
***@uwaterloo.ca
Christian Brauner
2018-07-20 09:09:11 UTC
Permalink
Post by Adrian Pepper
This message devolved from a different query which is implied here together
with its answer. Perhaps this result will save some other people some time.
I just discovered a stupid user (lxc administrator) trick.
Suppose you have an lxc setup you are migrating from Ubuntu 16.04 to 18.04.
(Going from lxc 2.0(2.0.8) to 3.0(3.0.1)).
(Doing a fresh install of Ubuntu 18.04 and modifying to match).
If under Ubuntu 18.04 you install the "lxc" package, but not the
"lxc-templates" package, then, even after "lxc-update-config",
some of your lxc config files will fail because of...
(for example)
lxc.include = /usr/share/lxc/config/ubuntu.common.conf
As an even stupider user trick, things seem to superficially work properly
if you simply remove the "ubuntu." from the config file, leaving
lxc.include = /usr/share/lxc/config/common.conf
It turns out /usr/share/lxc/config/ubuntu.common.conf (and many others)
are provided under Ubuntu by the "lxc-templates" package.
Hmm. Could lxc-update-config (be changed to) remark upon the need for
the lxc-templates package? Or maybe just make a general observation
that the include file does not exist? ("Something is wrong")
While waiting for the above message to actually appear, I thought of a
perhaps better set of comments on the same thing. As a follow-up to
Christian Brauner's packaging change announcement.
I eventually wonder (below) if "lxc" could once again have "lxc-templates"
as a dependency, even though "lxc-utils" does[should] not. Since "lxc"
is now branded as a transitional package => lxc-utils.
That's a packaging call that Stéphane needs to make.
Post by Adrian Pepper
Adrian Pepper
Subject: [lxc-users] LXC 3.0.0: Packaging Changes To Be Aware Of
Hey everyone,
LX{C,FS,D} upstream here. :)
[...]
1. **Important** the lxc-templates have been moved out of the main LXC tree
into a separate repository
https://github.com/lxc/lxc-templates
This means that without this separate package LXC will now only come with
lxc-busybox
lxc-download
lxc-local
lxc-oci
The templates had been in a separate "lxc-templates" package also in
Ubuntu 16.04.
But "lxc-templates" had been a dependency of the "lxc" package and
was therefore dragged in automatically.
But with the change indicated in the quoted announcement, it no longer
gets so dragged in.
But an unmentioned associated effect of not dragging in lxc-templates
is that most of the files
/usr/share/lxc/config/*.conf
are no longer put in place.
So "lxc-templates" must be installed not only to use the templates
to generate new containers. It must be installed if you are going
bring forward containers from Ubuntu 16.04 (lxc 2.0), which had been
generated using templates.
"lxc-update-config" works without complaint on containers whose config
includes, for example
lxc.include = /usr/share/lxc/config/ubuntu.common.conf
But the containers still fail afterwards because the include is not
satisfied. (They fail, that is, until "lxc-templates" is installed).
(Assume here that a common way of producing an upgraded host system,
e.g. Ubuntu 18.04 versus 16.04, is to produce a new minimal 18.04
system and then apply all recorded "apt install" commands corresponding
to actual desired packages (yes, modifications are sometimes needed,
but...). The old 16.04 system need not have explicitly done "apt
install lxc-templates" and so that could be overlooked in 18.04).
Since "lxc" is now branded as a transitional package => lxc-utils,
could "lxc" have lxc-templates as a dependency, even though lxc-utils
will not?
Adrian Pepper
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users
Stéphane Graber
2018-07-20 12:57:09 UTC
Permalink
Post by Adrian Pepper
This message devolved from a different query which is implied here together
with its answer. Perhaps this result will save some other people some time.
I just discovered a stupid user (lxc administrator) trick.
Suppose you have an lxc setup you are migrating from Ubuntu 16.04 to 18.04.
(Going from lxc 2.0(2.0.8) to 3.0(3.0.1)).
(Doing a fresh install of Ubuntu 18.04 and modifying to match).
If under Ubuntu 18.04 you install the "lxc" package, but not the
"lxc-templates" package, then, even after "lxc-update-config",
some of your lxc config files will fail because of...
(for example)
lxc.include = /usr/share/lxc/config/ubuntu.common.conf
As an even stupider user trick, things seem to superficially work properly
if you simply remove the "ubuntu." from the config file, leaving
lxc.include = /usr/share/lxc/config/common.conf
It turns out /usr/share/lxc/config/ubuntu.common.conf (and many others)
are provided under Ubuntu by the "lxc-templates" package.
Hmm. Could lxc-update-config (be changed to) remark upon the need for
the lxc-templates package? Or maybe just make a general observation
that the include file does not exist? ("Something is wrong")
While waiting for the above message to actually appear, I thought of a
perhaps better set of comments on the same thing. As a follow-up to
Christian Brauner's packaging change announcement.
I eventually wonder (below) if "lxc" could once again have "lxc-templates"
as a dependency, even though "lxc-utils" does[should] not. Since "lxc"
is now branded as a transitional package => lxc-utils.
That's a packaging call that Stéphane needs to make.
No it won't as that'd require Canonical to provide LTS (5 years) support
on lxc-templates which we very much don't want to do.
Post by Adrian Pepper
Adrian Pepper
Subject: [lxc-users] LXC 3.0.0: Packaging Changes To Be Aware Of
Hey everyone,
LX{C,FS,D} upstream here. :)
[...]
1. **Important** the lxc-templates have been moved out of the main LXC tree
into a separate repository
https://github.com/lxc/lxc-templates
This means that without this separate package LXC will now only come with
lxc-busybox
lxc-download
lxc-local
lxc-oci
The templates had been in a separate "lxc-templates" package also in
Ubuntu 16.04.
But "lxc-templates" had been a dependency of the "lxc" package and
was therefore dragged in automatically.
But with the change indicated in the quoted announcement, it no longer
gets so dragged in.
But an unmentioned associated effect of not dragging in lxc-templates
is that most of the files
/usr/share/lxc/config/*.conf
are no longer put in place.
So "lxc-templates" must be installed not only to use the templates
to generate new containers. It must be installed if you are going
bring forward containers from Ubuntu 16.04 (lxc 2.0), which had been
generated using templates.
"lxc-update-config" works without complaint on containers whose config
includes, for example
lxc.include = /usr/share/lxc/config/ubuntu.common.conf
But the containers still fail afterwards because the include is not
satisfied. (They fail, that is, until "lxc-templates" is installed).
(Assume here that a common way of producing an upgraded host system,
e.g. Ubuntu 18.04 versus 16.04, is to produce a new minimal 18.04
system and then apply all recorded "apt install" commands corresponding
to actual desired packages (yes, modifications are sometimes needed,
but...). The old 16.04 system need not have explicitly done "apt
install lxc-templates" and so that could be overlooked in 18.04).
Since "lxc" is now branded as a transitional package => lxc-utils,
could "lxc" have lxc-templates as a dependency, even though lxc-utils
will not?
Adrian Pepper
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
Loading...