[systemd-devel] Proposal: integrate biosdevname into systemd tree

[Alexander E. Patrakov]

2013/1/4 Reindl Harald <h.reindl at thelounge.net>:
> how can something like this be unreliable?
> hwaddresses does not change randomly
>
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:bd:00:04", ATTR{dev_id}=="0x0",
> ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Good question, and it hits the very core of the problem. I don't know
the answer, maybe we should wait for Kay or Lennart to explain that. I
only know that it IS unreliable if the following renames have to be
the end result:

[removed card] -> eth0 (non-existing)
eth0 -> eth1
eth1 -> eth2

and it is claimed to be reliable for the case when the destination
names are not eth*, e.g.:

eth0 -> lan
eth1 -> wan

> currently syaadmins who knew over years how to handle
> 70-persistent-net.rules are more pissed of than ever before

Yeah, resistance to ANY change is an integral part of a human nature.
And it also makes a good sysadmin. The problem, as stated multiple
times, is that same-namespace renames do not work reliably, cannot
work reliably, and that the official preferred solution (yet to be
drilled into sysadmins' brains) now is to avoid them completely.

> you are missing the real problem with the new shiny biosdevname
> nobody can rely on eth0 any longer

Yes, that's a problem.

> if have thousands of firewall-scripts and configurations which
> are assuming eth0=LAN, eth1=WAn as example, the benefit of such
> scripts is that they can be easily adopted to a new but compareable
> setup and basic rules are always the same

You can achieve the same by manually writing the equivalent of the
persistent rules by hand, just don't name the renamed interfaces eth*.
Existing rules override what biosdevname thinks. And you can use
variables like $LAN and $WAN in the scripts.

-- 
Alexander E. Patrakov