[systemd-devel] networkd: Support setting mtu / mac address by interface name

[William Kennington]

In regards to the OS and syntax, this is NixOS. NixOS uses its own
expression language to configure the entire system, including the network
stack. If a user wanted to configure their system's networking stack, they
would modify the networking.* set of options in their
/etc/nixos/configuration.nix. Currently this is done with a set of
generated scripts run as systemd services with device based dependencies.
Ideally this would be directly translated to networkd syntax.

For example, a user might have this snippet as part of their config for
statically configuring one of their ethernet interfaces:

networking.interfaces."enp4s0" = {
  macAddress = "de:ad:be:eef:ca:fe";
  mtu = 9000;
  ip4 = [
    { address = "10.0.0.2"; prefixLength = 24; }
    { address = "10.0.0.3"; prefixLength = 24; }
  ];
};

For link configuration, we are currently generating a
network-link-<ifname>.service which sets the mac address and mtu using
iproute2:
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces.nix#L691-L713

The networking options are all defined in:
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces.nix

Our current translator to networkd is:
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces-systemd.nix


Of course, the problem with just using kernel names is that our use case
assumes that the interface was already renamed by udev. Therefore, our
matching must be based on the post-udev name if it is to be backward
compatible. Ultimately it might be best to continue using our set of
scripts coupled with udev generated systemd device units, given our use
cases.

On Thu, Dec 4, 2014 at 9:53 AM, Tom Gundersen <teg at jklm.no> wrote:

> On Thu, Dec 4, 2014 at 4:11 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > On Thu, 04.12.14 11:20, Tom Gundersen (teg at jklm.no) wrote:
> >
> >> > I mean, most of the times .link files are
> >> > used to choose the name depending on other fields, but I think in all
> >> > cases where the name is chosen at creation time of an interface (like
> >> > for example for veth links), it should be Ok to match links based on
> >> > the name they already have?
> >>
> >> So this we could do (i.e., allow name matches if and only if the name
> >> is set at creation time). Though, if the name is set at creation time,
> >> shouldn't also all the other properties have been?
> >
> > In nspawn we create veth links, and I *really* *really* don't want to
> > add tons of options there to set the MTU or suchlike. Setting these
> > properties really should be done within networkd I think.
> >
> > I think it would be really useful if we could match on the container's
> > veth links by name, so that a .link file for it could be equally
> > expressive as the .network file already is.
> >
> >> Moreover, if we
> >> give people this feature I'm pretty sure we'll get lots of people
> >> expecting it to work also for any other sort of name and getting
> >> confused when it doesn't.
> >
> > Well, this is something we can fix by documentation, no?
> >
> > Or maybe name the match option differently, maybe OriginalName= or
> > KernelName= or so, and then only matching interfaces where you know
> > that the name was selected by userspace in the first place?
>
> I like the idea of OriginalName, much less likely to get people
> confused. I now implemented that, with the restriction that we cannot
> match on renamed names. For now I left it open to match on ethX style
> names, as people in principle could do sensible things like
> "OriginalName=eth*" or even "OriginalName=eth0" when we know there is
> only one interface.
>
> One thing to consider would be to disallow renaming from a .link file
> where the OriginalName was used to match. That way we don't have the
> somewhat odd situation that a .link file can only be applied once (we
> do not remember the original name, so cannot match on that the second
> time around, as that would be a mess)...
>
> Testing and feedback welcome. Does this solve your problem William?
>
> Cheers,
>
> Tom
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20141204/d24bba15/attachment.html>