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.
