Re: [systemd-devel] Proposal: integrate biosdevname into systemd tree
Am 04.01.2013 10:02, schrieb Alexander E. Patrakov: [Yes I know that this mail is several months too late, but better late then never. Also it is too verbose.] As of systemd-189, the persistent rule generators for network cards were removed. They did serve a purpose - they prevented the multiple network cards from being randomly renumbered during every boot due to bus scanning and module loading being performed in parallel threads/processes (i.e. modules were loaded in unpredictable order) but hopefully /etc/udev/rules.d/70-persistent-net.rules will be recognized forever if it exists because there are many servers especially virtual ones where you hardly need to control ethernet device names to avoid breaking iptables-scripts as example keep in mind there are MANY setups which do not need nor want biosdevname and are bootet with biosdevname=0 on the kernel line P.S.: i HATE it to need ifconfig -a and hack 70-persistent-net.rules by hand instead as all the years open it and change back the last line to eth0 after probe-restore of a virtual machine to temporary access a datarecovery backup from some weeks ago signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: integrate biosdevname into systemd tree
2013/1/4 Reindl Harald h.rei...@thelounge.net: but hopefully /etc/udev/rules.d/70-persistent-net.rules will be recognized forever if it exists because there are many servers especially virtual ones where you hardly need to control ethernet device names to avoid breaking iptables-scripts as example Yes, the existing rules will continue to be recognized. The bug is that even they are intrinsically unreliable (as happened with that rented server), so I think you actually don't want that. keep in mind there are MANY setups which do not need nor want biosdevname and are bootet with biosdevname=0 on the kernel line And that's indeed something that we need to think about. The real problem is that it is hard to explain the whole interface-renumbering issue and the reasons why he needs persistence to an average sysadmin. It's too low level. IMHO it is safer to always install biosdevname and use it even if not strictly required than to rely on the sysadmin to know about the issue. For me, even with the old solution in place, the bug surfaced after ~10 reboots. That's more than an average sysadmin is willing to test before saying I think it always boots as it should. Besides, the sysadmin can be wrong about not needing the persistent names. Again, my position is: better safe than sorry, especially with remotely-managed servers. P.S.: i HATE it to need ifconfig -a and hack 70-persistent-net.rules by hand instead as all the years open it and change back the last line to eth0 after probe-restore of a virtual machine to temporary access a datarecovery backup from some weeks ago With biosdevname, the interface names are determined only by PCI bus slot. I.e., if the replacement card is inserted into the same slot as the failed one, the name won't change. And in virtual machines biosdevname deactivates itself automatically. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: integrate biosdevname into systemd tree
Am 04.01.2013 10:40, schrieb Alexander E. Patrakov:
2013/1/4 Reindl Harald h.rei...@thelounge.net:
but hopefully /etc/udev/rules.d/70-persistent-net.rules will be recognized
forever if it exists because there are many servers especially virtual
ones where you hardly need to control ethernet device names to avoid
breaking iptables-scripts as example
Yes, the existing rules will continue to be recognized. The bug is
that even they are intrinsically unreliable (as happened with that
rented server), so I think you actually don't want that.
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
keep in mind there are MANY setups which do not need nor want
biosdevname and are bootet with biosdevname=0 on the kernel line
And that's indeed something that we need to think about. The real
problem is that it is hard to explain the whole interface-renumbering
issue and the reasons why he needs persistence to an average sysadmin.
It's too low level. IMHO it is safer to always install biosdevname and
use it even if not strictly required than to rely on the sysadmin to
know about the issue.
currently syaadmins who knew over years how to handle
70-persistent-net.rules are more pissed of than ever before
P.S.: i HATE it to need ifconfig -a and hack 70-persistent-net.rules
by hand instead as all the years open it and change back the last line
to eth0 after probe-restore of a virtual machine to temporary access
a datarecovery backup from some weeks ago
With biosdevname, the interface names are determined only by PCI bus
slot. I.e., if the replacement card is inserted into the same slot as
the failed one
you are missing the real problem with the new shiny biosdevname
nobody can rely on eth0 any longer
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
with the new shiny names this you have to replace interface names
if you are knowing your scripts and iptables rules you do not
always look who is WAN interface here, you like to see eth1
and know what it does
the name won't change. And in virtual machines
biosdevname deactivates itself automatically
fine, even there i stay with force disable it because
after the large changes in a few years i do not trust
any behavior to stay since subsystems are changed and
rewritten like a slut changes her man :-)
signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: integrate biosdevname into systemd tree
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
Re: [systemd-devel] Proposal: integrate biosdevname into systemd tree
On Fri, Jan 4, 2013 at 10:02 AM, Alexander E. Patrakov patra...@gmail.com wrote: What worries me now is that I was able to learn about the recommended replacement (biosdevname) only via IRC, from Kay Sievers. There are no pointers to biosdevname in any documentation that comes with systemd-196. How are distributions supposed to learn that they have to install it by default? And some of them don't learn. Here are some examples from rolling-release or beta distributions: We plan to have something in a future systemd version, which should be able to cover all the common use cases. It will be similar to the /dev/disk/by-*/ symlinks, just with the obvious limitations of a single name that is 15 characters long. The current systemd git code: http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c has some explanations in it. It already adds (currently unused) candidates for names in the udev database: # for i in /sys/class/net/*; do echo $(realpath $i); udevadm test-builtin net_id $i 2/dev/null; echo; done /sys/devices/pci:00/:00:19.0/net/enp0s25 ID_NET_NAME_MAC=enxf0def180d479 ID_OUI_FROM_DATABASE=Wistron InfoComm (Kunshan)Co ID_NET_NAME_PATH=enp0s25 /sys/devices/pci:00/:00:1c.3/:05:00.0/net/ens1 ID_NET_NAME_MAC=enx0466 ID_NET_NAME_PATH=enp5s0 ID_NET_NAME_SLOT=ens1 /sys/devices/pci:00/:00:1c.1/:03:00.0/net/wlp3s0 ID_NET_NAME_MAC=wlx0024d7e31130 ID_OUI_FROM_DATABASE=Intel Corporate ID_NET_NAME_PATH=wlp3s0 /sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.6/net/wwp0s29u1u4i6 ID_NET_NAME_MAC=wwx028037ec0200 ID_NET_NAME_PATH=wwp0s29u1u4i6 We originally planned to use the biosdevname naming scheme, but it turns out that it on one hand not flexible enough, and on the other hand it invents its own enumeration based on crawling the entire system for all network hardware, and coming up with new numbers. This wasn't what we envision for systemd, so we decided to stick with the model closer to what we already use for the disks and other subsystems. It will not use the same names as biosdevname, especially not invent new numbers when the PCI spec and the kernel already have numbers sufficiently stable enough. It's all still blurry, how the facility will look like in the end, and it we need to find out with which policy to apply the currently dead names to the actual interfaces. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: integrate biosdevname into systemd tree
Op 4 jan. 2013, om 10:54 heeft Reindl Harald h.rei...@thelounge.net het volgende geschreven: Am 04.01.2013 10:40, schrieb Alexander E. Patrakov: 2013/1/4 Reindl Harald h.rei...@thelounge.net: but hopefully /etc/udev/rules.d/70-persistent-net.rules will be recognized forever if it exists because there are many servers especially virtual ones where you hardly need to control ethernet device names to avoid breaking iptables-scripts as example Yes, the existing rules will continue to be recognized. The bug is that even they are intrinsically unreliable (as happened with that rented server), so I think you actually don't want that. how can something like this be unreliable? hwaddresses does not change randomly Actually, they do for a lot of 'embedded' setups. If you have an SMSC usb-ethernet chip with a blank eeprom (e.g. a beagleboard xM) the kernel will assign a random mac on 1) every reboot (3.x kernels) or 2) every ifup (2.6.x kernels). If you have a board where the bootloader is supposed to read an eeprom or hidden register and pass it to the kernel this will fail if you use a devicetree enabled kernel since the kernel driver writers from the silicon vendor don't care about the bootloader (e.g. beaglebone). There are patches available to assign a static mac based on e.g. die IDs, but those aren't in mainine linux yet. And that's just for the 2 platforms I care for at $dayjob and I don't think they are the only ones. It sucks, it's a bug and must be fixed, but right now you can't say 'hwaddresses does not change randomly' :( regards, Koen ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: integrate biosdevname into systemd tree
On Fri, Jan 4, 2013 at 1:07 PM, Koen Kooi k...@dominion.thruhere.net wrote: Op 4 jan. 2013, om 10:54 heeft Reindl Harald h.rei...@thelounge.net het volgende geschreven: Am 04.01.2013 10:40, schrieb Alexander E. Patrakov: 2013/1/4 Reindl Harald h.rei...@thelounge.net: but hopefully /etc/udev/rules.d/70-persistent-net.rules will be recognized forever if it exists because there are many servers especially virtual ones where you hardly need to control ethernet device names to avoid breaking iptables-scripts as example Yes, the existing rules will continue to be recognized. The bug is that even they are intrinsically unreliable (as happened with that rented server), so I think you actually don't want that. how can something like this be unreliable? hwaddresses does not change randomly Actually, they do for a lot of 'embedded' setups. If you have an SMSC usb-ethernet chip with a blank eeprom (e.g. a beagleboard xM) the kernel will assign a random mac on 1) every reboot (3.x kernels) or 2) every ifup (2.6.x kernels). If you have a board where the bootloader is supposed to read an eeprom or hidden register and pass it to the kernel this will fail if you use a devicetree enabled kernel since the kernel driver writers from the silicon vendor don't care about the bootloader (e.g. beaglebone). There are patches available to assign a static mac based on e.g. die IDs, but those aren't in mainine linux yet. And that's just for the 2 platforms I care for at $dayjob and I don't think they are the only ones. It sucks, it's a bug and must be fixed, but right now you can't say 'hwaddresses does not change randomly' :( We see this since years, not only on cheap hardware. Things like this happens everywhere. The kernel exports the source of the address now though, and we should be able to skip the usage of the MAC entirely if it was created randomly. The old udev rules did not check for that, but the code in systemd now should do that properly already. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
