Is udev's new network naming really as stable as they claim? (was: Re: overriding udev rules)
They are stable as long as the kernel and the hardware do not change too much; e.g. enabling the other graphics card in a hybrid setup sometimes adds a PCIe bus, so all names shift around. Or adding something like a firewire card which happens to be based on a PCIe to PCI bridge chip would also add a bus and therefore has the potential for names to shift arround. The new scheme seems to have the same problem the original kernel scheme had but moved one level up. Instead of network names depending on the order in which the kernel enumerated network adaptors they now depend on the order in which the BIOS enumerated PCI busses* Is that an improvement over just letting the kernel assign names? is it an improvement over debian's scheme? For servers the answer is probablly yes, servers often have a lot of network adaptors, adaptors may be replaced by maintinance personell who are different from those setting up the OS and the chances of people adding or removing hardware that creates extra PCI busses is pretty low. For desktops on the other hand i'm inclined to belive the answer is no. Desktops rarely have more than one or two network adaptors but they are much more likely than servers to have things like graphics cards, firewire cards, serial cards etc added or removed which can mess with the PCI bus numbers. * in quotes because on modern hardware a logical PCI bus may or may not represent a real PCI bus. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52413f50.9070...@p10link.net
Re: overriding udev rules
Am 10.09.2013 01:28, schrieb Uoti Urpala: Russ Allbery wrote: Kay Sievers k...@vrfy.org writes: Hmm, why would upgrades break? The old file would still be there, rename the devices (if you keep the patch to swap names, which upstream does not support any more), and take precedence over tht new names; the old rules file would just not be updated anymore when new devices appear. Manually-deployed /etc/network/interfaces files that assume a specific device naming come to mind. We have tons of those at work. Why would those break? Just having a manually-deployed /etc/network/interfaces file that uses names like eth0 should not break upgrades, because as mentioned in the part you quoted, the existing already-generated rules should still trigger and keep renaming the same card to eth0. So you need to assume something more to have an example of a problem case. As I mentioned earlier, the problem is for those cases, where we *didn't* generate persistent network interface names and used the kernel provided names. The conditions are listed at [1]. In such a case, the file /etc/udev/rules.d/70-persistent-net.rules will *not* be created. (There is also the case where an administrator decided to opt-out and not use the persistent naming by running echo : /etc/udev/rules.d/75-persistent-net-generator.rules) Kay was kind enough to point out [2], that the new network interface naming has similar rules where it skips the renaming but there might be setups where those rules don't overlap, and there you would get a network interface name change after an upgrade. Kay expects this number to be very low. The risk of breaking setups on upgrades made me uneasy though. We have to be reasonably sure that the number of breakages is indeed very low and ideally can detect such cases before we decide making the new interface naming the default (at least for upgrades). So far nobody did the analysis for that. Michael [1] http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=blob;f=debian/extra/rules/75-persistent-net-generator.rules;h=b6fcb917ee220b6ec6305b7170680caac3f0acdd;hb=refs/heads/debian-experimental#l23 [2] capxgp11nncysl1xrwm+z2ux5aukomkpodxothqro8dps1qi...@mail.gmail.com -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: overriding udev rules
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
Russ Allbery wrote:
Kay Sievers k...@vrfy.org writes:
Hmm, why would upgrades break?
The old file would still be there, rename the devices (if you keep the
patch to swap names, which upstream does not support any more), and take
precedence over tht new names; the old rules file would just not be
updated anymore when new devices appear.
Manually-deployed /etc/network/interfaces files that assume a specific
device naming come to mind. We have tons of those at work.
Why would those break? Just having a manually-deployed
/etc/network/interfaces file that uses names like eth0 should not
break upgrades, because as mentioned in the part you quoted, the
existing already-generated rules should still trigger and keep renaming
the same card to eth0. So you need to assume something more to have an
example of a problem case.
Things will break because the new scheme changes interface names which
never have been added to the generated rules.
As just one example, these names have been in use at some point in time
on my laptop:
bjorn@nemi:~$ egrep ^iface /etc/network/interfaces
iface lo inet loopback
iface eth0 inet manual
iface wlan0 inet manual
iface default inet dhcp
iface mbm0 inet dhcp
iface mb0 inet dhcp
iface wwan0 inet dhcp
iface wwan1 inet dhcp
iface test inet dhcp
iface debug inet dhcp
iface mob inet dhcp
iface mbb inet dhcp
iface testv4 inet dhcp
iface testv6 inet6 manual
iface usb0 inet dhcp
iface usb1 inet dhcp
iface tap0 inet manual
iface tap0.42 inet manual
iface bnep0 inet dhcp
Only two of them have persistent entries and can be expected to continue
working:
bjorn@nemi:~$ grep NAME /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==00:21:86:a3:25:7d, ATTR{type}==1, KERNEL==eth*, NAME=eth0
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==0c:8b:fd:08:09:71, ATTR{dev_id}==0x0, ATTR{type}==1,
KERNEL==wlan*, NAME=wlan0
I'm not claiming that I use all those entries, and some of them were
added due to breakage caused by the existing scheme. But this doesn't
change the fact that converting to the new scheme will cause additional
breakage, e.g. by renaming my internal wwanX devices to wwsomething.
I'll leave up to others to decide whether such breakage is acceptable or
not.
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ob81t0u0@nemi.mork.no
Re: new persistent network interface naming [Re: overriding udev rules]
Btw, we didn't remove support for the new predictable network interface naming scheme. It's explicitly opt-in atm and you can use it by setting the net.ifnames=1 kernel command line parameter [1]. Existing NAMEs set via /etc/udev/rules.d/70-persistent-net.rules still take precedence, so you will have to remove that file. Just wanted to mention this in case anyone want's to test the new scheme in Debian. You'll need udev 204-1 or later. Michael [1] http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=commitdiff;h=d5051f7666e25ecf2b32c7076ce18c1de969d01b -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: overriding udev rules
Hi, Am 10.09.2013 02:06, schrieb Patrick Lauer: On 09/10/2013 02:50 AM, Lennart Poettering wrote: See http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ The resulting names are somtimes a bit ugly, but predictable and stable, and do not change on every VM reboot... [..] There are still race conditions. The point here is, that the new network naming scheme doesn't reuse the ethX namespace but completely different names which do not clash with the kernel names. Say you have two network interfaces A and B and a udev rule which assigns A the NAME eth1. So if the kernel would assign A eth0 an B eth1, and you are in the process of renaming A to eth1, you get a race condition. By using a completely different naming scheme you avoid that problem. But maybe I misunderstood you what you meant to imply saying it still has race conditions and it would be great if you can elaborate. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: overriding udev rules
On Mon, 26.08.13 01:22, Thomas Goirand (z...@debian.org) wrote: On 08/24/2013 03:53 PM, Ben Hutchings wrote: There is a very clear standard that distinguishes globally and locally administered addresses. While you would possibly to buy your own OUI and make global assignments to your VMs, I seriously doubt you are doing that. Don't steal address space. Ben. By reading the above, I don't think I made myself clear enough. In the case of a bare-metal driver for cloud computing IaaS, you would an have operating system image that could be booted once on one physical machine, then shutdown and later restarted on another hardware. In such use case, physical hardware is used to run the virtual machine images without virtualization. It is *not possible to choose the MAC*, as this is the one that is physically in the hardware, though udev should continue to behave as if it was a virtual machine MAC address. Therefore, I think there should be an easy, documented way, of telling udev to behave one way or another. I'd say /etc/udev/udev.conf could be the correct place to configure this. If we want to keep the current behavior of double-guessing the use case of the network interface (which I recognize is the most useful case), then it could stay as default, as long as there is a reliable way to configure udev. systemd/udev upstream do not assign persistent fixed names anymore to network interfaces, in order not to race against the kernel. Instead we now assign predictable names insteads, which avoids the whole issue. See http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ The resulting names are somtimes a bit ugly, but predictable and stable, and do not change on every VM reboot... It's now a Debianism to stick to the persistant names, all support for it has been removed upstream. From upstream we hope DEbian eventually drops support for the old persistant names too. As a side note, also note that the MAC address range definitions are all blurred these days, MAC addresses are reused by manufacturers and most parsable meaning of MAC addresses has been removed (simply because the namespace is mostly depleted these days...) Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130909185048.ga6...@tango.0pointer.de
Re: overriding udev rules
Hi Lennart, Am 09.09.2013 20:50, schrieb Lennart Poettering: It's now a Debianism to stick to the persistant names, all support for it has been removed upstream. From upstream we hope DEbian eventually drops support for the old persistant names too. We (Debian pkg-systemd team) decided to keep the old persistent naming scheme as default for now, for the simple reason, that we didn't want to break upgrades. It just didn't seem possible to detect every case where the old ethX names were used and losing network connection as part of the upgrade is a big no-go. As documented in the debian changelog, you can opt-in to use the new naming scheme, but this requires explicit configuration from the administrator. We might make the new network interface naming the default for new installations, but this isn't something we haven't been working on yet. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: overriding udev rules
On Mon, Sep 9, 2013 at 11:48 PM, Michael Biebl bi...@debian.org wrote: Am 09.09.2013 20:50, schrieb Lennart Poettering: It's now a Debianism to stick to the persistant names, all support for it has been removed upstream. From upstream we hope DEbian eventually drops support for the old persistant names too. We (Debian pkg-systemd team) decided to keep the old persistent naming scheme as default for now, for the simple reason, that we didn't want to break upgrades. It just didn't seem possible to detect every case where the old ethX names were used and losing network connection as part of the upgrade is a big no-go. As documented in the debian changelog, you can opt-in to use the new naming scheme, but this requires explicit configuration from the administrator. We might make the new network interface naming the default for new installations, but this isn't something we haven't been working on yet. Hmm, why would upgrades break? The old file would still be there, rename the devices (if you keep the patch to swap names, which upstream does not support any more), and take precedence over tht new names; the old rules file would just not be updated anymore when new devices appear. Kay -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capxgp13syupgweorgm6xmvrvqrqpzafdbf3bxp1sb-abstj...@mail.gmail.com
Re: overriding udev rules
On Mon, Sep 9, 2013 at 11:26 PM, Ben Hutchings b...@decadent.org.uk wrote: On Mon, Sep 09, 2013 at 08:50:48PM +0200, Lennart Poettering wrote: [...] As a side note, also note that the MAC address range definitions are all blurred these days, MAC addresses are reused by manufacturers and most parsable meaning of MAC addresses has been removed (simply because the namespace is mostly depleted these days...) There is no shortage of namespace; only a tiny fraction of the 2^22 valid OUIs have been allocated. But perhaps some OUIs are abused for volatile and non-unique assignments and you're right that this breaks the old naming policy. The new udev policy isn't any better for Thomas's use case, though. He seems to want to take his chances with kernel probing order... It's hopefully still better for most virtual machine use cases, as it will not write out config to disk at every boot and not use MAC addresses, which can change from boot-to-boot on some boxes. With the old model we've seen virtual machines with 1000s of entries in the rules files created by just rebooting them. :) Kay -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capxgp11wppj6kenbbiudywppyae_tk2x-hn2hcjto19apt7...@mail.gmail.com
Re: overriding udev rules
Hi Kay, Am 09.09.2013 23:53, schrieb Kay Sievers: Hmm, why would upgrades break? See [1], there are several cases where 75-persistent-net-generator.rules doesn't generate a persistent name (mostly VM related). In those cases, you would typically use eth0 in your /etc/network/interface etc. On upgrades, the new networking naming would kick in, and suddenly it's no longer eth0. Michael [1] http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=blob;f=debian/extra/rules/75-persistent-net-generator.rules;h=b6fcb917ee220b6ec6305b7170680caac3f0acdd;hb=refs/heads/debian-experimental#l27 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: overriding udev rules
Hi Kay, Am 09.09.2013 23:53, schrieb Kay Sievers: Hmm, why would upgrades break? See [1], there are several cases where 75-persistent-net-generator.rules doesn't generate a persistent name (mostly VM related). In those cases, you would typically use eth0 in your /etc/network/interface etc. On upgrades, the new networking naming would kick in, and suddenly it's no longer eth0. Michael [1] http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=blob;f=debian/extra/rules/75-persistent-net-generator.rules;h=b6fcb917ee220b6ec6305b7170680caac3f0acdd;hb=refs/heads/debian-experimental#l27 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: overriding udev rules
On Mon, Sep 09, 2013 at 08:50:48PM +0200, Lennart Poettering wrote: [...] As a side note, also note that the MAC address range definitions are all blurred these days, MAC addresses are reused by manufacturers and most parsable meaning of MAC addresses has been removed (simply because the namespace is mostly depleted these days...) There is no shortage of namespace; only a tiny fraction of the 2^22 valid OUIs have been allocated. But perhaps some OUIs are abused for volatile and non-unique assignments and you're right that this breaks the old naming policy. The new udev policy isn't any better for Thomas's use case, though. He seems to want to take his chances with kernel probing order... Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130909212630.gk7...@decadent.org.uk
Re: overriding udev rules
On Tue, Sep 10, 2013 at 12:00 AM, Michael Biebl bi...@debian.org wrote: Am 09.09.2013 23:53, schrieb Kay Sievers: Hmm, why would upgrades break? See [1], there are several cases where 75-persistent-net-generator.rules doesn't generate a persistent name (mostly VM related). In those cases, you would typically use eth0 in your /etc/network/interface etc. On upgrades, the new networking naming would kick in, and suddenly it's no longer eth0. The new names should only get active where the old rules also matched, it currently supports PCI parent devices only, most VM use cases, xen, virt drivers would be excluded anyway. But sure, there can be setups where that could happen, I would just expect that the number is very very low. Kay -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capxgp11nncysl1xrwm+z2ux5aukomkpodxothqro8dps1qi...@mail.gmail.com
Re: overriding udev rules
Kay Sievers k...@vrfy.org writes: On Mon, Sep 9, 2013 at 11:48 PM, Michael Biebl bi...@debian.org wrote: We (Debian pkg-systemd team) decided to keep the old persistent naming scheme as default for now, for the simple reason, that we didn't want to break upgrades. It just didn't seem possible to detect every case where the old ethX names were used and losing network connection as part of the upgrade is a big no-go. As documented in the debian changelog, you can opt-in to use the new naming scheme, but this requires explicit configuration from the administrator. We might make the new network interface naming the default for new installations, but this isn't something we haven't been working on yet. Hmm, why would upgrades break? The old file would still be there, rename the devices (if you keep the patch to swap names, which upstream does not support any more), and take precedence over tht new names; the old rules file would just not be updated anymore when new devices appear. Manually-deployed /etc/network/interfaces files that assume a specific device naming come to mind. We have tons of those at work. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txhtskxc@windlord.stanford.edu
new persistent network interface naming [Re: overriding udev rules]
Am 10.09.2013 00:05, schrieb Kay Sievers: On Tue, Sep 10, 2013 at 12:00 AM, Michael Biebl bi...@debian.org wrote: Am 09.09.2013 23:53, schrieb Kay Sievers: Hmm, why would upgrades break? See [1], there are several cases where 75-persistent-net-generator.rules doesn't generate a persistent name (mostly VM related). In those cases, you would typically use eth0 in your /etc/network/interface etc. On upgrades, the new networking naming would kick in, and suddenly it's no longer eth0. The new names should only get active where the old rules also matched, it currently supports PCI parent devices only, most VM use cases, xen, virt drivers would be excluded anyway. But sure, there can be setups where that could happen, I would just expect that the number is very very low. Ok, thanks for the input. The new network interface naming is certainly an interesting approach and probably a better one then what we currently use (in Debian). That said, we didn't want to tackle this issue at this point but rather focus on getting v204 into sid/testing. We will certainly revisit this decision when we have time for it, it's definitely not set in stone. We just wanted to avoid having to deal with the (possible) fallout at the current stage. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: overriding udev rules
Russ Allbery wrote: Kay Sievers k...@vrfy.org writes: Hmm, why would upgrades break? The old file would still be there, rename the devices (if you keep the patch to swap names, which upstream does not support any more), and take precedence over tht new names; the old rules file would just not be updated anymore when new devices appear. Manually-deployed /etc/network/interfaces files that assume a specific device naming come to mind. We have tons of those at work. Why would those break? Just having a manually-deployed /etc/network/interfaces file that uses names like eth0 should not break upgrades, because as mentioned in the part you quoted, the existing already-generated rules should still trigger and keep renaming the same card to eth0. So you need to assume something more to have an example of a problem case. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1378769281.30447.8.camel@glyph.nonexistent.invalid
Re: overriding udev rules
On 09/10/2013 02:50 AM, Lennart Poettering wrote: On Mon, 26.08.13 01:22, Thomas Goirand (z...@debian.org) wrote: On 08/24/2013 03:53 PM, Ben Hutchings wrote: There is a very clear standard that distinguishes globally and locally administered addresses. While you would possibly to buy your own OUI and make global assignments to your VMs, I seriously doubt you are doing that. Don't steal address space. Ben. By reading the above, I don't think I made myself clear enough. In the case of a bare-metal driver for cloud computing IaaS, you would an have operating system image that could be booted once on one physical machine, then shutdown and later restarted on another hardware. In such use case, physical hardware is used to run the virtual machine images without virtualization. It is *not possible to choose the MAC*, as this is the one that is physically in the hardware, though udev should continue to behave as if it was a virtual machine MAC address. Therefore, I think there should be an easy, documented way, of telling udev to behave one way or another. I'd say /etc/udev/udev.conf could be the correct place to configure this. If we want to keep the current behavior of double-guessing the use case of the network interface (which I recognize is the most useful case), then it could stay as default, as long as there is a reliable way to configure udev. systemd/udev upstream do not assign persistent fixed names anymore to network interfaces, in order not to race against the kernel. Instead we now assign predictable names insteads, which avoids the whole issue. See http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ The resulting names are somtimes a bit ugly, but predictable and stable, and do not change on every VM reboot... They are predictable from within a booted linux install with a new kernel. They are stable as long as the kernel and the hardware do not change too much; e.g. enabling the other graphics card in a hybrid setup sometimes adds a PCIe bus, so all names shift around. There are still race conditions. It's now a Debianism to stick to the persistant names, all support for it has been removed upstream. From upstream we hope DEbian eventually drops support for the old persistant names too. As a side note, also note that the MAC address range definitions are all blurred these days, MAC addresses are reused by manufacturers and most parsable meaning of MAC addresses has been removed (simply because the namespace is mostly depleted these days...) Reusing would be extremely bad - Medion once shipped a few charges of machines with the same MACs on all, so people that bought more than one had fascinating network failures. I hope no vendor is *THAT* insane and still allowed to assign MACs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/522e6270.1010...@gentoo.org
Re: overriding udev rules
On Mon, 2013-08-26 at 01:22 +0200, Thomas Goirand wrote: On 08/24/2013 03:53 PM, Ben Hutchings wrote: There is a very clear standard that distinguishes globally and locally administered addresses. While you would possibly to buy your own OUI and make global assignments to your VMs, I seriously doubt you are doing that. Don't steal address space. Ben. By reading the above, I don't think I made myself clear enough. In the case of a bare-metal driver for cloud computing IaaS, you would an have operating system image that could be booted once on one physical machine, then shutdown and later restarted on another hardware. In such use case, physical hardware is used to run the virtual machine images without virtualization. Sorry, I get it now. That's not something I've ever heard of people doing on a regular basis, but I can see you would want to override udev's behaviour in this case. It is *not possible to choose the MAC*, as this is the one that is physically in the hardware, though udev should continue to behave as if it was a virtual machine MAC address. Therefore, I think there should be an easy, documented way, of telling udev to behave one way or another. [...] The current behaviour is right for almost everyone, and it doesn't need to be that easy to change it. What you're asking for is, I think, doable with: echo /etc/udev/rules.d/70-kernel-net-device-name.rules \ 'ACTION==add, SUBSYSTEM==net, NAME=%k' But you don't actually want that behaviour. You cannot assume anything about the order in which net devices are created and therefore you still need rules for persistent names unless your machines have only one Ethernet(-like) interface (the usual VM case). You'll need to install rules that work out which interface should be 'eth0' (or, better, some meaningful name) based on the site conventions for wiring up network ports. Ben. -- Ben Hutchings This sentence contradicts itself - no actually it doesn't. signature.asc Description: This is a digitally signed message part
Re: overriding udev rules
Ben Hutchings wrote: But you don't actually want that behaviour. You cannot assume anything about the order in which net devices are created and therefore you still need rules for persistent names unless your machines have only one Ethernet(-like) interface (the usual VM case). You'll need to install rules that work out which interface should be 'eth0' (or, better, some meaningful name) based on the site conventions for wiring up network ports. Note that such a convention is already the default in upstream udev [1] (at least assuming the hardware layout on the machines is the same - if it isn't, then it's of course impossible to have any non-site-specific rule which could determine which parts of different hardware layouts should correspond to each other). The udev packages in experimental support that naming scheme, but as a Debian-specific change still default to the old naming rules (the ones that modify configuration when they see a new MAC address for the first time). [1] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1377528642.20022.17.camel@glyph.nonexistent.invalid
Re: overriding udev rules
On 08/24/2013 03:53 PM, Ben Hutchings wrote: There is a very clear standard that distinguishes globally and locally administered addresses. While you would possibly to buy your own OUI and make global assignments to your VMs, I seriously doubt you are doing that. Don't steal address space. Ben. By reading the above, I don't think I made myself clear enough. In the case of a bare-metal driver for cloud computing IaaS, you would an have operating system image that could be booted once on one physical machine, then shutdown and later restarted on another hardware. In such use case, physical hardware is used to run the virtual machine images without virtualization. It is *not possible to choose the MAC*, as this is the one that is physically in the hardware, though udev should continue to behave as if it was a virtual machine MAC address. Therefore, I think there should be an easy, documented way, of telling udev to behave one way or another. I'd say /etc/udev/udev.conf could be the correct place to configure this. If we want to keep the current behavior of double-guessing the use case of the network interface (which I recognize is the most useful case), then it could stay as default, as long as there is a reliable way to configure udev. Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/521a91c1.7000...@debian.org
Re: overriding udev rules
On 08/22/2013 03:12 AM, Peter Samuelson wrote: [Thomas Goirand] Oh ok. Not useful at all if you ask me. Why? Because sometimes, you can't change the MAC address. For example, if you use the OpenStack bare metal driver, then you continue to use virtual machine images, though they will be used on a real hardware where you can't change the MAC address. So you're saying, when your NIC is tied to actual physical hardware, udev behaves as though it is tied to actual physical hardware. No. I'm saying that udev is making the wrong assumption that virtual machines are only bound to a specific MAC address range, when this is not at all the reality, for example when using read hardware for running cloud applications. Seriously, the reason for udev to not make a VM NIC persistent is not because it is virtual, per se, but because certain virtualization platforms may randomly generate a MAC at boot time. What is happening is udev is making assumption on what type of usage one will do with a piece of hardware. There must be some clean ways to disable such feature, which by the way, has always annoyed me (even when not using cloud computing or even virtualization). I think the problem you're trying to solve is more related to imaging and cloning. The fact that you're doing imaging and cloning in the context of virtual machines instead of physical is a bit of a red herring. You can't tell that my usage is wrong, and the software is right. Software should be adapted to use cases, and not the opposite way. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52188c53.9040...@debian.org
Re: overriding udev rules
On Sat, 2013-08-24 at 12:34 +0200, Thomas Goirand wrote:
On 08/22/2013 03:12 AM, Peter Samuelson wrote:
[Thomas Goirand]
Oh ok. Not useful at all if you ask me. Why? Because sometimes, you
can't change the MAC address. For example, if you use the OpenStack
bare metal driver, then you continue to use virtual machine images,
though they will be used on a real hardware where you can't change
the MAC address.
So you're saying, when your NIC is tied to actual physical hardware,
udev behaves as though it is tied to actual physical hardware.
No. I'm saying that udev is making the wrong assumption that virtual
machines are only bound to a specific MAC address range, when this is
not at all the reality, for example when using read hardware for running
cloud applications.
There is a specific MAC address range for locally administered
addresses, and it's very large indeed - everything with the 7th bit set
(i.e. (addr[0] 2) == 2). Which is the main thing udev checks for:
ENV{MATCHADDR}==?[2367abef]:*,ENV{MATCHADDR}=
(after white-listing some manufacturer screw-ups).
[...]
You can't tell that my usage is wrong, and the software is right.
Software should be adapted to use cases, and not the opposite way.
There is a very clear standard that distinguishes globally and locally
administered addresses.
While you would possibly to buy your own OUI and make global assignments
to your VMs, I seriously doubt you are doing that. Don't steal address
space.
Ben.
--
Ben Hutchings
Never put off till tomorrow what you can avoid all together.
signature.asc
Description: This is a digitally signed message part
Re: overriding udev rules
I think I gonna simply skip the udev rules overriding, it will be up to the user to do the cleaning if he wants to do cloning etc... as done in cloud-init package, waiting for easier udev management from package side. Thanks to all for your advises. quoting previous... -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Re: overriding udev rules
On Tue, Aug 20, 2013 at 09:58:43PM +0200, Thomas Goirand wrote:
I'd be happy to find a correct and clean way to do this, because I also
need to do it, and it seems to be a fairly common use case. I currently
only delete the 75-persistent-net-generator.rules file (which I know is
the wrong way to do it as it wont survive upgrades, though I currently
don't know how to do it cleanly, so I have fallen back to that).
It would be really nice to have a switch somewhere in /etc for this.
Maybe upstream could work that out, so that we don't have to hack and
hack again? I'm sure I'm not the only one to think that dpkg-divert
over-engineering something that should be fixed upstream.
The least ugly thing we came up with was:
$ cat /lib/udev/rules.d/60-${our_package}.rules
# Avoid udev persistent names (see
# /lib/udev/rules.d/75-persistent-net-generator.rules )
ACTION==add, SUBSYSTEM==net, KERNEL==eth*,NAME=$kernel
You can make that rule more specific to only disable it for specific
cards. It works because of:
$ grep -B1 -w NAME /lib/udev/rules.d/75-persistent-net-generator.rules | head
-n2
# ignore the interface if a name has already been set
NAME==?*, GOTO=persistent_net_generator_end
--
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il || best
tzaf...@debian.org|| friend
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130822110202.ge14...@lemon.cohens.org.il
Re: overriding udev rules
Michael Biebl bi...@debian.org writes: The persistent network interface naming rules are already skipped if udev is run within a virtual machine. Which made me look closer at /lib/udev/rules.d/75-persistent-net-generator.rules I find it a bit strange that it has lots of logic involving different OUIs, but doesn't seem to care at all about the addr_assign_type sysfs attribute. I believe you never should generate any persistent rules if this attribute is different from 0 (NET_ADDR_PERM). And I'll now go fix some drivers which doesn't set it as appropriate. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ioyy3r6q@nemi.mork.no
Re: overriding udev rules
On Tue, 20 Aug 2013, Thomas Goirand wrote: I'd be happy to find a correct and clean way to do this, because I also need to do it, and it seems to be a fairly common use case. I currently only delete the 75-persistent-net-generator.rules file (which I know is the wrong way to do it as it wont survive upgrades, though I currently don't know how to do it cleanly, so I have fallen back to that). touch /etc/udev/rules.d/75-persistent-net-generator.rules http://anonscm.debian.org/gitweb/?p=mirror/dsa-misc.git;a=blob;f=scripts/VM-installs/ganeti-bytemark;hb=HEAD#l116 HTH, Cheers, weasel -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130821072010.gl1...@anguilla.noreply.org
Re: overriding udev rules
2013/8/21 Peter Palfrader wea...@debian.org On Tue, 20 Aug 2013, Thomas Goirand wrote: I'd be happy to find a correct and clean way to do this, because I also need to do it, and it seems to be a fairly common use case. I currently only delete the 75-persistent-net-generator.rules file (which I know is the wrong way to do it as it wont survive upgrades, though I currently don't know how to do it cleanly, so I have fallen back to that). touch /etc/udev/rules.d/75-persistent-net-generator.rules yeap, as a user, but it is said that packages must not write rules in /etc/udev/rules.d http://anonscm.debian.org/gitweb/?p=mirror/dsa-misc.git;a=blob;f=scripts/VM-installs/ganeti-bytemark;hb=HEAD#l116 HTH, Cheers, weasel -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130821072010.gl1...@anguilla.noreply.org -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Re: overriding udev rules
[Thomas Goirand] Oh ok. Not useful at all if you ask me. Why? Because sometimes, you can't change the MAC address. For example, if you use the OpenStack bare metal driver, then you continue to use virtual machine images, though they will be used on a real hardware where you can't change the MAC address. So you're saying, when your NIC is tied to actual physical hardware, udev behaves as though it is tied to actual physical hardware. Seriously, the reason for udev to not make a VM NIC persistent is not because it is virtual, per se, but because certain virtualization platforms may randomly generate a MAC at boot time. Which is not at all the case in the example you give. I think the problem you're trying to solve is more related to imaging and cloning. The fact that you're doing imaging and cloning in the context of virtual machines instead of physical is a bit of a red herring. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130822011215.gb6...@p12n.org
overriding udev rules
hi, I need for a package to override some udev standard rules. If I put an identical rule name in /etc/udev/rules.d, I know it overrides the one in /lib/udev/rules.d However, lintian raises an error if I put an udev rule in /etc instead of /lib. And if I try to put the file in /lib, it fails at install because the file is owned by udev package. This particular package is for use in virtual machines creation where package removes default network persistence. Is there an other way to override udev rules in package or should I simply override the lintian error message? Thanks Olivier -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Re: overriding udev rules
olivier sallou olivier.sal...@gmail.com writes: hi, I need for a package to override some udev standard rules. If I put an identical rule name in /etc/udev/rules.d, I know it overrides the one in /lib/udev/rules.d However, lintian raises an error if I put an udev rule in /etc instead of /lib. And if I try to put the file in /lib, it fails at install because the file is owned by udev package. This particular package is for use in virtual machines creation where package removes default network persistence. Is there an other way to override udev rules in package or should I simply override the lintian error message? I think you should divert (see man dpkg-divert) the original file in /lib and install a new file in it's place. This way the /etc override mechanism is still usable by the admin if needed. -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mwoc3fgd@kirika.int.wmdata.fi
Re: overriding udev rules
On Tue, Aug 20, 2013 at 10:39:13AM +0200, olivier sallou wrote: hi, I need for a package to override some udev standard rules. If I put an identical rule name in /etc/udev/rules.d, I know it overrides the one in /lib/udev/rules.d [...] Is there an other way to override udev rules in package or should I simply override the lintian error message? Stick it in /lib/udev/rules.d/ prefixed with a higher number than the rules file you want to override. This is described, along with more guidelines on picking a number in /lib/udev/rules.d/README. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: overriding udev rules
Am 20.08.2013 10:39, schrieb olivier sallou: hi, I need for a package to override some udev standard rules. If I put an identical rule name in /etc/udev/rules.d, I know it overrides the one in /lib/udev/rules.d However, lintian raises an error if I put an udev rule in /etc instead of /lib. And if I try to put the file in /lib, it fails at install because the file is owned by udev package. This particular package is for use in virtual machines creation where package removes default network persistence. Could you elobarate why you need that? The persistent network interface naming rules are already skipped if udev is run within a virtual machine. Might be better to just fix udev if it doesn't work in your case. For that, it would be good to know more about your problem / use case. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: overriding udev rules
On Tue, Aug 20, 2013 at 10:39:13AM +0200, olivier sallou wrote: I need for a package to override some udev standard rules. Well. This would be not suitable for a package in Debian itself. However, lintian raises an error if I put an udev rule in /etc instead of /lib. lintian is moot for private packages. This particular package is for use in virtual machines creation where package removes default network persistence. Use local administered MAC addresses. udev properly ignores them. Is there an other way to override udev rules in package or should I simply override the lintian error message? You should neither. You have to fix the real problem. Bastian -- Without facts, the decision cannot be made logically. You must rely on your human intuition. -- Spock, Assignment: Earth, stardate unknown -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130820101807.gb9...@mail.waldi.eu.org
Re: overriding udev rules
On Aug 20, olivier sallou olivier.sal...@gmail.com wrote: This particular package is for use in virtual machines creation where package removes default network persistence. Please explain what you are actually trying to achieve. Is there an other way to override udev rules in package or should I simply override the lintian error message? Packages MUST NOT install files in /etc/udev/rules.d/ . -- ciao, Marco signature.asc Description: Digital signature
Re: overriding udev rules
olivier sallou olivier.sal...@gmail.com writes: hi, I need for a package to override some udev standard rules. If I put an identical rule name in /etc/udev/rules.d, I know it overrides the one in /lib/udev/rules.d However, lintian raises an error if I put an udev rule in /etc instead of /lib. And if I try to put the file in /lib, it fails at install because the file is owned by udev package. This particular package is for use in virtual machines creation where package removes default network persistence. Is there an other way to override udev rules in package or should I simply override the lintian error message? I think you should divert (see man dpkg-divert) the original file in /lib and install a new file in it's place. This way the /etc override mechanism is still usable by the admin if needed. Maybe doesn't apply here but why was LAST_ACTION removed anyway, apparently in Debian first. It is clear to me that whilst a great big warning and wrong usage resulting in a pounding would be fine, removing it is simply bad design and removes freedom from users and simply causes them problems. An example being automatic removal of a usb key for Truecrypt which is then remounted and so has to be manually unmounted before removal. A ro mount may do but still. Overriding files creates management that shouldn't be required and GOTO is the wrong fix that doesn't really work and requires editing of packages files or management of new files which is dumb when a USERS rule applies to a single usb device. ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/611516.87910...@smtp140.mail.ir2.yahoo.com
Re: overriding udev rules
2013/8/20 Michael Biebl bi...@debian.org Am 20.08.2013 10:39, schrieb olivier sallou: hi, I need for a package to override some udev standard rules. If I put an identical rule name in /etc/udev/rules.d, I know it overrides the one in /lib/udev/rules.d However, lintian raises an error if I put an udev rule in /etc instead of /lib. And if I try to put the file in /lib, it fails at install because the file is owned by udev package. This particular package is for use in virtual machines creation where package removes default network persistence. Could you elobarate why you need that? The persistent network interface naming rules are already skipped if udev is run within a virtual machine. Might be better to just fix udev if it doesn't work in your case. For that, it would be good to know more about your problem / use case. ok, I am packaging a package for OpenNebula that is to be installed on virtual machine images. It does many setup at startup. Among other things, in upstream packages, it replaces 2 udev rules: 75-cd-aliases-generator.rules and 75-persistent-net-generator.rules. The new rules does nothing, it just expects to skip the existing one. I did not know that udev skipped (at least) persistent-net in virtual machines so I did not try without those replacement rules (how does it know it is a virtual machine?). Olivier Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Re: overriding udev rules
2013/8/20 olivier sallou olivier.sal...@gmail.com 2013/8/20 Michael Biebl bi...@debian.org Am 20.08.2013 10:39, schrieb olivier sallou: hi, I need for a package to override some udev standard rules. If I put an identical rule name in /etc/udev/rules.d, I know it overrides the one in /lib/udev/rules.d However, lintian raises an error if I put an udev rule in /etc instead of /lib. And if I try to put the file in /lib, it fails at install because the file is owned by udev package. This particular package is for use in virtual machines creation where package removes default network persistence. Could you elobarate why you need that? The persistent network interface naming rules are already skipped if udev is run within a virtual machine. Might be better to just fix udev if it doesn't work in your case. For that, it would be good to know more about your problem / use case. ok, I am packaging a package for OpenNebula that is to be installed on virtual machine images. It does many setup at startup. Among other things, in upstream packages, it replaces 2 udev rules: 75-cd-aliases-generator.rules and 75-persistent-net-generator.rules. As additional information, this is needed when you clone, reuse some virtual machine. The new rules does nothing, it just expects to skip the existing one. I did not know that udev skipped (at least) persistent-net in virtual machines so I did not try without those replacement rules (how does it know it is a virtual machine?). Olivier Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Re: overriding udev rules
On 08/20/2013 07:02 PM, olivier sallou wrote: ok, I am packaging a package for OpenNebula that is to be installed on virtual machine images. It does many setup at startup. Among other things, in upstream packages, it replaces 2 udev rules: 75-cd-aliases-generator.rules and 75-persistent-net-generator.rules. The new rules does nothing, it just expects to skip the existing one. I did not know that udev skipped (at least) persistent-net in virtual machines so I did not try without those replacement rules (how does it know it is a virtual machine?). Olivier I'd be happy to find a correct and clean way to do this, because I also need to do it, and it seems to be a fairly common use case. I currently only delete the 75-persistent-net-generator.rules file (which I know is the wrong way to do it as it wont survive upgrades, though I currently don't know how to do it cleanly, so I have fallen back to that). It would be really nice to have a switch somewhere in /etc for this. Maybe upstream could work that out, so that we don't have to hack and hack again? I'm sure I'm not the only one to think that dpkg-divert over-engineering something that should be fixed upstream. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5213ca73.6080...@debian.org
Re: overriding udev rules
On 08/20/2013 07:02 PM, olivier sallou wrote: I did not know that udev skipped (at least) persistent-net in virtual machines so I did not try without those replacement rules (how does it know it is a virtual machine?). Oh, missed that part! I also would be happy to know how it does it. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5213cace.5000...@debian.org
Fwd: Re: overriding udev rules
Ccing the list -- Message transféré -- De : olivier sallou olivier.sal...@gmail.com Date : 20 août 2013 22:27 Objet : Re: overriding udev rules À : Thomas Goirand z...@debian.org Le 20 août 2013 22:18, Thomas Goirand z...@debian.org a écrit : On 08/20/2013 07:02 PM, olivier sallou wrote: I did not know that udev skipped (at least) persistent-net in virtual machines so I did not try without those replacement rules (how does it know it is a virtual machine?). Oh, missed that part! I also would be happy to know how it does it. With a quick look at script it seems to skip the rule for a set of MAC address masks commonly used in different systems (KVM VMWARE..) but this does not fit for all nor users custom config. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5213cace.5000...@debian.org
Re: overriding udev rules
❦ 20 août 2013 22:00 CEST, Thomas Goirand z...@debian.org : I did not know that udev skipped (at least) persistent-net in virtual machines so I did not try without those replacement rules (how does it know it is a virtual machine?). Oh, missed that part! I also would be happy to know how it does it. It relies on the MAC address starting with 52:54:00 or things like that. -- Use recursive procedures for recursively-defined data structures. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
Re: overriding udev rules
On 08/20/2013 11:44 PM, Vincent Bernat wrote: ❦ 20 août 2013 22:00 CEST, Thomas Goirand z...@debian.org : I did not know that udev skipped (at least) persistent-net in virtual machines so I did not try without those replacement rules (how does it know it is a virtual machine?). Oh, missed that part! I also would be happy to know how it does it. It relies on the MAC address starting with 52:54:00 or things like that. Oh ok. Not useful at all if you ask me. Why? Because sometimes, you can't change the MAC address. For example, if you use the OpenStack bare metal driver, then you continue to use virtual machine images, though they will be used on a real hardware where you can't change the MAC address. So this is a very wrong assumption that udev is doing here, and we still need a way to fix it (by fixing, I mean disabling the presistent-net rule in a non-too-hackish way). Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5213f358.6030...@debian.org
