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

[Evgeni Golov]

Hi,

On Sun, Oct 30, 2016 at 07:06:42PM +0100, Dryden Personalis wrote:
> Evgeni Golov schreef op 30-10-2016 16:53:
> 
> > Given that we
> > 1) ship a config that works just fine by default (but does not have
> > networking at all)
> > 2) provide an easy way to enable DHCP on a bridge
> > do you think this report can be closed, or do you see any more room
> > for improvement here?
> 
> Thank you for responding. I was indeed mistaken about the default config.
> 
> There is a page on the wiki that mentions lxc-net and the option you
> mention.

You mean https://wiki.debian.org/LXC? Yeah. We should polish it a bit and
ship inside the lxc package, so that people don't have to go to the wiki.

> However. There is scarcely any documentation on it.

True, but that we can improve ;)

> lxc-net seems rather "oblique", you don't know what it is or what it does.

I am speaking about
% dpkg -L lxc |grep lxc-net
/etc/init.d/lxc-net
/lib/systemd/system/lxc-net.service
/usr/lib/x86_64-linux-gnu/lxc/lxc-net
(and so is the above wiki page)

> At some point I did check out https://github.com/CameronNemo/lxc-net but
> that was way after. It says it has been obsoleted by inclusing in LXC.

The version we ship is part of the upstream source at https://github.com/lxc/lxc/blob/master/config/init/common/lxc-net.in

> However when you look at the sources at that repo there is no indication of
> any DHCP.

The upstream script will launch a dnsmasq on the bridge.

> The scripts are (in that repo) also rather ... minimal. It is not the
> complete set of masquerading rules you'd need for a truly functioning
> system.

Please have a look at the right script ;)

> I certainly cannot find any documentation on lxc-net directly.
> 
> So I guess the improvement would be that your point (2) actually reaches
> people...

Let's fix the shipped docs, then :)

> The issue then remains that there are two classes of people:
> 
> - those with DHCP in the network who depend on the setting to be dhcp and
> who subsequently do not set a fixed IP address
> - those with no DHCP in the network and who do set a fixed IP address (in
> the container config).
> 
> It seems a clear separation of people due to the config, something that
> could be treated as a defining characteristic.
> 
> I don't know how LXC can change that but I only see 3 solutions:
> 
> - don't set it to DHCP which you say will offend the other half of the
> people and I guess for a general home computer that is logical but you'd be
> flabbergasted if your network-less (dhcp-less) computer system or network
> would hang for 15+ seconds or longer booting your computer the first time,
> right.
> 
> Any computer not on a dhcp network now hangs while booting? That's not good
> is it. You can only solve that in one of two ways:

My computers do not hang when booting? :)

> - create a shorter timeout for the dhcp thing (or don't wait for networking
> to come on before you give a login prompt).

as far as I remember that is what happening, networking is brought up in the background these days.

> - or, allow systemd to communicate more clearly that it is not gonna wait
> forever for ya.
> 
> But really the strange thing from a user point of view is that you configure
> the network in LXC and then *it doesn't work* because it is not evident that
> the inner container is going to use DHCP by default.

You can't configure the network on just one end of the "cable" ;)
Unless you do it on both ends properly, you end up with a broken config.

> But LXC doesn't determine the inner system. It could be anything right, not
> just Debian. It could be anything that does its networking in whatever way,
> so it is up to the (Debian) LXC people to determine that it should work with
> Debian, it's not like LXC can handle that it itself.
> 
> So the only solution comes down to providing that DHCP server by default (as
> LXC) instead of waiting for the user to select to use lxc-net for that.

And then people will complain that we define a bridge they do not use, because
their network is totally different (than mine, and yours).

> That is actually what you expect as a user. You expect LXC to do the DHCP
> thing when you configure the networking inside (the container config).
> 
> So I would assume that the answer would need to lie in having LXC start that
> DHCP server when you configure a fixed IP address and maybe that is not
> perfect but it follows the model of what needs to happen anyway:
> 
> * you define a static address ---> inner container config must be set to
> manual/static OR dhcp must exist.
> 
> * you don't define a static address ---> nothing needs to happen because
> DHCP will work or you expect yourself to already have it
> 
> So the biggest problem at this point is that the LXC inner container config
> as set in the external configuration file (for the container) is completely
> disjunct from any lxc-net business as far as the configuration model goes.

Right, because lxc-net (or any other bridge/dhcp/whatever setup) is systemwide.
Whereas containers are not.

> LXC-NET apparently evolved as a standalone thing and apparently it is still
> is this way.

No.

> But people do not want to use lxc-net if they can't see what it is going to
> do for them. I don't know ... I have never come across the scripts on my
> computer (VPS).

The people are free to use whatever setup they want. :)

> So I can only suggest this thing and these are the 3 solutions I mentioned,
> perhaps? :P.
> 
> 1. lxc-net must be better documented so that people do not set up networking
> without it (but some may still not want to use it)

agreed.

> 2. the dhcp "server" must be started instantly and automatically when a
> static IP address has been configured (and there could be another
> configuration flag to control that) and it should not be dependent on
> another (external) configuration file like /etc/default/lxc (which doens't
> even exist).

The file exists, in 2.0. It did not in 1.0 which is in Jessie.
Still, I dislike the idea of starting the bridge by default.

> And the third solution was to change the debian config to manual
> configuration so that it doesn't override the static IP setting of the
> container externally (the config of the container on the host).

Right, as it would then break dhcp setups.

> So if you say the 3rd option is unavailable (and it should be, I guess) that
> leaves:
> 
> * clear documentation that setting the network in LXC config file (for the
> container) is not enough.

yes

> * automatically starting DHCP on static config

no

> * make lxc-net more available, more accessible, and more transparent.

yes.
> 
> I *saw* the reference on the Debian Wiki:
> https://wiki.debian.org/LXC/SimpleBridge
> 
> However, the documentation is *so minimal* and the lxc-net service *doesn't
> exist*.
> 
> But hold on, you were mentioning 2.0? The Debian version in Jessie is
> 1.0.6-6+deb8u2.
> 
> That one in Stretch is 2.0.5-1... and LXC mentions that 1.1 has end of life
> (but 1.0 hasn't) but it seems they urge everyone to upgrade anyway?

1.0 and 2.0 are LTS releases, 1.1 was not, so that is EOL now.
Jessie shipped with 1.0, Stetch will come with 2.0.
You can have 2.0 in Jessie today via backports.

> My bug was against Jessie, I'm not sure I mentioned that. That means
> everyone in Jessie is going to keep stuck with this behaviour?

Yes, we are not touching Jessie at this point.
For critical updates? Yes. But not for a simplification of the networking setup.

Regards
Evgeni