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

[Dryden Personalis]

Evgeni Golov schreef op 30-10-2016 19:44:

> 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.

The issue is that it is rather *hard* to use documentation from a 
console (or any Linux system) out of the root filesystem. You can go 
there but it takes some effort to find that documentation (there is no 
easy system that will get you there right away).

This documentation is typically not in the "man" system but info is 
hardly usable by people and so you are left with the files in 
/usr/share/doc but that is hard to reach for most people most of the 
time, I think.

That's why I think most people actually use a browser to access this 
information (not only for man, which you would typically do local) but 
also really for wiki style documentation you want it to be online.

Ideally you would have it differently but that is just the way it 
goes...

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

Ok. I have to install the version from stretch to check it.

> The upstream script will launch a dnsmasq on the bridge.

I just want to say here that in principle dnsmasq woudln't *need* to be 
systemwide.


> Please have a look at the right script ;)

Yaya. Will do.

>> 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? :)

I think my Debian 7 system doesn't either but then I don't know why the 
debootstrap version of Jessie takes so long. Maybe I just didn't realize 
any delays. Oh that system is Jessie now.... < delete previous text > I 
have no clue if it delays or used to delay after installation. The 
upgrade broke networking regardless because the removal of an "auto" 
line in my interfaces ;-).

Beside the point.

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

Actually SystemD messages stall while it is waiting for "Raise network 
interfaces".

It says "Starting Raise Network Interfaces.... [ no timeout ]" or 
something of the kind.

> 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.

I know. But. I am going to say that "bridge" and "dnsmasq" (or similar) 
are not exactly the same thing.

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

I know but my *conception* was that it would have an internal thing that 
would be so simple that it would only respond to *one* computer (the 
container) and give off just *one* IP address.

Even though dnsmasq is very simple (to use) it is still a full-fledged 
dhcp server.

What you expected (what I expected) was something so simple that it 
would only be capable of responding to that single request from the 
inner container. I don't know how complicated it would be to write 
something like that or extract something like that from something 
existing. That was just my conception.

LXC-NET creates a bridge, .. I guess I am mistaken? ... LXC creates an 
internal interface as the endpoint of the peer thing. That is by default 
that random name you get. Oh I guess you need a bridge to begin with to 
start any dns... dhcp server on it.

I don't really at this point know the internals and mechanics of how the 
bridge you specify is used by LXC, sorry. I had assumed that you would 
be able to provide DHCPD on just the peer interface alone.

So I don't know how the peer interface is connected to the bridge by 
LXC.

Oh right... the peer interface is added to the bridge... obviously :p.


>> 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.

Right however if you have the static IP of the container configured in 
the /var/lib/lxc/<name>/config file then *THAT* IP would not be 
systemwide and the DHCP server could be configured to only respond to 
that address with that information.

You could basically automatically start a dnsmasq with only the required 
information: the MAC address of your container and a line for that IP 
address with the MAC, ie. some dhcp-host line.

> 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.

Yes I was only on about the DHCP. The bridge, namely, is something you 
have to explicitly set in the LXC config (for the container) so you are 
already doing that. You are already aware of that need. The only thing 
that is missing is that tiny little DHCP that will make it work right 
off the bat ;-).

>> * clear documentation that setting the network in LXC config file (for 
>> the
>> container) is not enough.
> 
> yes

I will see if I can write some documentation on the wiki tonight.