[lfs-dev] Use systemd to configure network interfaces

Sebastian Plotz sebastian-plotz at web.de
Mon Apr 14 21:57:51 PDT 2014


Am 15.04.2014 05:37, schrieb Bryan Kadzban:
> Why the duplication? If I create a file named 10-eth1.link and it has 
> Name="eth0" in it, what interface name is created when the address 
> matches? (Wouldn't it be better to have *one* source of truth for 
> renames like this?) 

It would create the interface "eth0". Yes, it is better to have one 
source. It was just an example to show that the first matching file 
applies. So the final setup depends on the file naming.

> Also, does it work to match NICs by device path instead of MAC 
> address, e.g. because I'm in some random virtualization environment 
> where that works, or because I'm a server that gets new NICs when they 
> fail? (That works in the setup I've put together, where the NIC alias 
> gets dereferenced by the ifup script, and so a NIC can have many 
> aliases of arbitrary length. Still haven't gotten time to commit that 
> to contrib/ though. :-/ )

Yes. Have a look at "|Path=pci-0000:02:00.0-*":|

|[Match]
Driver=brcmsmac
Path=pci-0000:02:00.0-*
Type=wlan
Virtualization=no
Host=my-laptop
Architecture=x86-64

[Link]
Name=wireless0
MTUBytes=1450
BitsPerSecond=10M
WakeOnLan=magic
MACAddress=cb:a9:87:65:43:21|


> Also also, is there a way to make systemd *not* do the rename at all, 
> and simply configure whatever device happens to show up that matches 
> the Match section? This is how I have the ifup patch working above 
> (nothing on the system cares if a NIC gets renamed from one boot to 
> the next, because the config is attached to something more permanent, 
> either the MAC or path), and it works really well to avoid the renaming.

The file |/etc/udev/rules.d/80-net-setup-link.rules is responsible| for 
renaming. So it can be disabled with:

|ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules

See: 
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
|



More information about the lfs-dev mailing list