Lennart Poettering <lenn...@poettering.net> writes: > On Tue, 21.04.15 10:58, Spencer Baugh (sba...@catern.com) wrote: > >> > The MAC address is currently generated as hash value from the >> > container name, it hence should be completely stable already as long >> > as you keep using the same name for the container? >> >> Well, generally I want to know what MAC/IP address a machine/container >> will receive in advance of actually starting it. I could start it once >> and immediately stop it to see and record what MAC address is generated >> for a given name, or copy the code to generate the MAC address out of >> nspawn.c, but neither of those seem like good options. > > Sidenote: if this is about having stable names to refer to containers, > note that nss-mycontainers adds those automatically. If enabled, then > all local container names will be resolvable, automatically. It's > often hence unnecessary to have fixed IP addresses for this at all.
It is about stable names, but I believe those names need to be usable from off the host. >> >> I am interested in using networkd to do these things, but at the moment >> >> it doesn't seem to have the required level of power. >> > >> > what do you mean precisely with this? >> >> I mean that instead of writing another service (probably a shell script) >> to set up the interface on the host, using the PrivateNetwork= and >> JoinsNamespaceOf= trick, instead have networkd set up the interface on >> the host inside a network namespace and use the same kind of trick. > > Well, I mean how useful would this actually be? THis would only work > for static configuration, everything more complex requires a daemon > watching the interface continously and that's really hard to do for a > set of network interfaces in a different network namespace. All that I want to do is configuration that can be done at the time of first creating the interface - like setting the MAC address. That is all the script that I am using at the moment does, everything else is done by networkd. > Also, trivial static IP configuration is seldom sufficient, you at > least need to also provide DNS configuration, and if you don't use > DHCP or something similar then you need to configure that inside the > container anyway. But if you do that you might as well configure the > static IP addresses in it too, so what is gained by doing this from a > networkd outside of the cotnainer? > >> Or am I misunderstanding the role of networkd? It seems like if I am >> writing a service that represents "the network interface and namespace >> for this container", I am doing something that networkd should >> ultimately do. > > Sure, absolutely. But our idea so far was that networkd should run > inside the container to configure the container's network, and on the > host to configure the host's network, but not to cross this boundary > and have the host networkd configure the container's network. Hmm, yes, but I think the problem is the configuration done at interface-creation-time. It seems to me that that configuration currently does not fit naturally in either the host networkd or the container networkd. >> "Set up the interface" here just means "create the interface with a >> specific MAC address", of course. > > Well, of course, we could beef up systemd-nspawn and allow it to take > configurable IP or MAC addresses on the command line, and then it > would become a second networkd, and we already have one of those... Yes, but what else can configure the interfaces at creation time? _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel