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

Reply via email to