2013/1/4 Reindl Harald <h.rei...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel