[pkg-lxc-devel] Bug#835529: lxc: default debootstrap minimal install hangs waiting for dhcp

[Dryden Personalis]

Package: lxc
Version: 1:1.0.6-6+deb8u2
Severity: normal

Dear Maintainer,

As I was issuing my bug reports again....

Well.

Just a small issue but relevant because it determines the usability and user-friendliness of the package or Debian at least.

By default an LXC container will be started with the network settings in /var/lib/lxc/<host>/config. These settings are injected into the container when it starts.

A default minimal Debian installation however will have DHCP configured.

Now LXC doesn't provide a mimimal dhcp in itself which would be nice, but....

DHCP is not actually required to get the thing online. If you configure it to static, or even set it to manual, it will still work. You will have network, you just won't be able to reconfigure it or to bring it online again after you really kill it.

Now since the container is accessible by default from the root (/var) filesystem, all it takes to get this think working normally (for a start) is to perform "sed -i 's/dhcp/manual/' /var/lib/lxc/<host>/etc/network/interfaces" but if you don't notice you will be starting and restarting your container an endless number of times before you will venture into its network configuration because it is just not that important yet although it does hang your system by up to a minute.

So I would simply humbly suggest one of two things:

1) perform the sed action above in the /usr/share/lxc/templates/lxc-debian file.
2) allow lxc to be shipped with the most minimal of DHCP servers that is not even a standalone thing but that will at least respond to a request for the network that has already been configured in its host configuration file of /var/lib/lxc/<host>/config.

Of course this configuration is not there yet when the container is just installed.

But in both cases the container would start working as soon as the user makes that configuration.

The way it stands the only containers that presently really work are ones that are implemented on a network that already has dhcp and the container is allowed to access that external dhcp, which is not very likely for a minimal install. It would work on a home network, but not on a VPS. It is not very convenient to have to configure dnsmasq for just a single container. So in the end you end up either setting a static route, and host config, or you end up installing dnsmasq, or you set it to manual and just accept that you won't have the ability to restart networking by yourself. I feel it is a bad choice to set the default configuration for those who already have most of the "infrastructure" configured and make it easier for THEM, when they already know the system. Any new person will be baffled by the network taking 30-60 seconds to start, and then, in the end, when you realize it couldn't start, it is still configured (as per the LXC injection).

So I have been waiting at least 20 times one minute for no good reason.

Moreoever initially, because systemd does not give a timeout be default (but the init script or dhcp server does) you think that the system is going to hang (like so many times before). SystemD tells you there is no timeout. Heh, but there is, you just don't see it. So before even searching the web what was going on, I had already tried at least 3 different network configs (in the host config of /var/lib/lxc/<host>/config) before realizing the system wasn't bugged (all that much) and I just had to wait a minute even though it told me it would hang.

So many times SystemD does not have a timeout configured but it times out anyway, but you are put on the wrong foot in the meantime and make bad choices because of that.

You can say I probably wasted at least 2 hours because of this, because I kept changing my network config to see if it would work *this time*.

Eventually I searched the web and realized "Oh, this thing IS going to time out." Damn.

Anyway, that's just one experience from one person that is probably replicated a million times over for different people in different times and places and locations and habitats.

Got screwed over by bad defaults again.....

In any case, I'd hope that it could be made better for someone else. There is another bug with the debian installation, but I cannot really troubleshoot it, but I will post another bug for that.

Regards.



-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lxc depends on:
ii  init-system-helpers  1.22
ii  libapparmor1         2.9.0-3
ii  libc6                2.19-18+deb8u4
ii  libcap2              1:2.24-8
ii  libseccomp2          2.1.1-1
ii  libselinux1          2.3-2
ii  multiarch-support    2.19-18+deb8u4
ii  python3              3.4.2-2

Versions of packages lxc recommends:
ii  debootstrap  1.0.67
ii  openssl      1.0.1k-3+deb8u5
ii  rsync        3.1.1-3

Versions of packages lxc suggests:
pn  lua5.2  <none>

-- no debconf information