Re: Proposal: enable stateless persistant network interface names
On 06/26/2015 11:14 AM, Marco d'Itri wrote: I believe that firmware-based device names work well enough in practice since RHEL 7 uses them by default: I tend to trust a market-based approach to maintenability more than anecdote from a very selected population like the debian-devel@ subscribers. Oh, how nice is that... So our opinions don't count, and Red Hat is just always right! Opinions do not make a statistic, indeed. I'm sure you will agree that (computer) science is *not* about statistics anyway. I also tend to feel uncomfortable when I read market-based next to [technical] approach, it's too marketing-ish, and I like to think that marketing isn't what influences Debian's technical decision (let's hope I'm not wrong here...). And you have not been paying attention, because right here I have expressed many times disagreement with some Red Hat decisions. Well, we don't have to follow all of what they do! All from redhat. /me not surprised... Yes, at this point it is not a surprise that they produce good documentation and we do not. I was trying to make the point that all of this ifname renaming cruft comes from Red Hat, and from systemd guys. Do we *have* to do it, just because they do? I'm really not convinced, as I saw how much trouble it can bring. For a single desktop machine, it's manageable. For a large cloud deployment with (very) heterogeneous hardware and multiple ifaces on each node, it can be hell to get the deployment right. So your proposal is: if the default is unusable (like above), then the poor user has to find a way to fix that... I'm not convince that this is what we want. I'd very much prefer a usable default. Me too, but there is none that we can use. Sure there is: keep the good old ethX naming, which has always worked for many, many years. Now, expecting someone will raise the fact that sometimes, we get a different order of the ifaces. Well, there's many ways around that, the persistent naming file is one solution (which I don't like, as I think it shouldn't be written by default, it should be the user's decision to write it if he wants to, but hey, let's not discuss that...). Cheers, Thomas ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Proposal: enable stateless persistant network interface names
On 05/11/2015 05:53 AM, Marco d'Itri wrote: On May 08, Martin Pitt mp...@debian.org wrote: I propose to retire [mac], i. e. drop /lib/udev/rules.d/75-persistent-net-generator.rules and enable [ifnames] by default. I see a large enough consensus about switching by default to ifnames, FWIW: I don't. In this very thread, I have read many counter-arguments. and I believe that the few people who want MAC-based names for USB interfaces can easily set NamePolicy=mac or write a custom rule. As always (and as it was for systemd), what counts here is the default. So we can only let time and replacing/reinstalling machines take care of this. /etc/udev/rules.d/70-persistent-net.rules requires zero maintenance from us (it's just like the admin had manually set their own rules). Actually it requires us to keep maintaining the Revert-udev-network-device-renaming patch as long as there will be systems with a 70-persistent-net.rules file renaming eth* to eth*. The other solution would be to upstream that patch (maybe as a kernel option if that is relevant). I believe that firmware-based device names work well enough in practice since RHEL 7 uses them by default: I tend to trust a market-based approach to maintenability more than anecdote from a very selected population like the debian-devel@ subscribers. Oh, how nice is that... So our opinions don't count, and Red Hat is just always right! FYI, I had non-anecdotal very bad experience to report, with the ifnames from udev causing not-so-easy to fix issues deploying OpenStack on a variety of hardware. I'm talking about large deployments here (in my mind, large means more than 200 machines...). This is the relevant documentation, which I strongly recommend everybody interested in this issue to read: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Understanding_the_Device_Renaming_Procedure.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Understanding_the_Predictable_Network_Interface_Device_Names.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Consistent_Network_Device_Naming_Using_biosdevname.html All from redhat. /me not surprised... Maybe biosdevname would be nice to have, but: - somebody needs to actually maintain it in Debian - by default it only works on Dell systems - it is not loved by the udev/systemd upstream maintainers - it does not seem to me to provide any benefit over the firmware-based names since in practice both would use by default an interface index in the common case So I do not think that we need to care about it. An obvious downside is longer names for devices which do not provide ID_NET_NAME_ONBOARD: e.g. the WiFi card in my Dell laptop does not (wlp2s0), but the Ethernet port does (eno1). It will be even worse when not even ID_NET_NAME_PATH is defined (e.g. on my Allwinner-based ARM computer), which means that interfaces will get a mac-based name like enx028909xx. Which is so convenient to type on the shell, right? :) But if somebody cares about the aesthetic value of network interface names then they can probably write a custom udev rule to rename them, or keep using 75-persistent-net-generator if we can keep it around. So your proposal is: if the default is unusable (like above), then the poor user has to find a way to fix that... I'm not convince that this is what we want. I'd very much prefer a usable default. Cheers, Thomas Goirand (zigo) ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Proposal: enable stateless persistant network interface names
On Jun 26, Thomas Goirand z...@debian.org wrote: Actually it requires us to keep maintaining the Revert-udev-network-device-renaming patch as long as there will be systems with a 70-persistent-net.rules file renaming eth* to eth*. The other solution would be to upstream that patch (maybe as a kernel option if that is relevant). This cannot happen since the patch actually reverts an upstream change. I believe that firmware-based device names work well enough in practice since RHEL 7 uses them by default: I tend to trust a market-based approach to maintenability more than anecdote from a very selected population like the debian-devel@ subscribers. Oh, how nice is that... So our opinions don't count, and Red Hat is just always right! Opinions do not make a statistic, indeed. And you have not been paying attention, because right here I have expressed many times disagreement with some Red Hat decisions. All from redhat. /me not surprised... Yes, at this point it is not a surprise that they produce good documentation and we do not. So your proposal is: if the default is unusable (like above), then the poor user has to find a way to fix that... I'm not convince that this is what we want. I'd very much prefer a usable default. Me too, but there is none that we can use. -- ciao, Marco pgp3TVDcZqnNG.pgp Description: PGP signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Proposal: enable stateless persistant network interface names
Martin Pitt mpitt@... writes: - [mac] For many many years our we have installed an udev rule /lib/udev/rules.d/75-persistent-net-generator.rules which on first boot creates a MAC address → current name mapping and writes /etc/udev/rules.d/70-persistent-net.rules. Hm, that usually worked for me. Can we please opt out of the new scheme? Thanks, //mirabilos ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Proposal: enable stateless persistant network interface names
Maybe biosdevname would be nice to have, but: - somebody needs to actually maintain it in Debian I actually had it ready to upload, but then given the approach RHEL 7 took and the general trend towards systemd-based approaches, I held off. If there is interest, though, I'm happy to maintain biosdevname for Debian (and also work on the same team as the biosdevname maintainer). - by default it only works on Dell systems That's not entirely true. It's more the case that we make sure our BIOS people don't mess things up so that biosdevname stops working correctly on our hardware. Having consistent interface naming is important for us. (We also have started caring about consistent enumeration for storage.) The end result is the same, though. - it does not seem to me to provide any benefit over the firmware-based names since in practice both would use by default an interface index in the common case Firmware based in what sense? From the biosdevname readme, biosdevname uses: PCI Configuration Space PCI IRQ Routing Table ($PIR) PCMCIA Card Information Structure SMBIOS 2.6 Type 9, Type 41, and HP OEM-specific types --Jared -- Jared Domínguez Infrastructure Software Engineering Dell | Enterprise Solutions Group ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Proposal: enable stateless persistant network interface names
Hello, Karsten Merker [2015-05-11 20:22 +0200]: From what Ben Hutchings has described in 1431294933.2233.66.ca...@decadent.org.uk, the race condition could easily be avoided with the current codebase by simply not using eth as the prefix, but e.g. en. Right, that would solve one problem, but not the others. Could you explain why the existing code does not provide stable names in virtual machines? As long as the virtual ethernet controller keeps the same MAC address over time (which I believe to be the normal case), I see no reason why the existing codebase should not provide stable names in a VM in the same way it does on physical hardware. I'm afraid you have to ask folks more familiar with clouds about the why, but it seems MAC addresses change all the time there as with every new instance or even boot you get a different virtual ethernet card assigned. See all the reports that we are getting about adding entries to the blacklist. As slot has been shown to be not really stable for a number of use cases (even for PCI, see above), I think that mac is the only way that works for all cases. It clearly doesn't work for all cases, like replacing network cards (in physical servers, but this is what by and large happens in clouds too), or where you have to rely on the location of cards instead of their MACs (like running the same config on a rack of servers, where what you see, wire, and configure are port locations). Anyway, I do see that we want to use MAC addresses by default for at least USB. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Proposal: enable stateless persistant network interface names
On May 08, Martin Pitt mp...@debian.org wrote: I propose to retire [mac], i. e. drop /lib/udev/rules.d/75-persistent-net-generator.rules and enable [ifnames] by default. I see a large enough consensus about switching by default to ifnames, and I believe that the few people who want MAC-based names for USB interfaces can easily set NamePolicy=mac or write a custom rule. I am not sure that we really need to retire 75-persistent-net-generator right now: the annoying part to maintain is the kernel patch which we will need anyway for at least a couple of releases, and once we make it use em* or eno* instead of eth* then it should be robust. It is trivial to make it opt-in by setting something like net.ifnames=0 (or even a different and specific value), and we can revisit this decision when we will be closer to the release. So we can only let time and replacing/reinstalling machines take care of this. /etc/udev/rules.d/70-persistent-net.rules requires zero maintenance from us (it's just like the admin had manually set their own rules). Actually it requires us to keep maintaining the Revert-udev-network-device-renaming patch as long as there will be systems with a 70-persistent-net.rules file renaming eth* to eth*. I believe that firmware-based device names work well enough in practice since RHEL 7 uses them by default: I tend to trust a market-based approach to maintenability more than anecdote from a very selected population like the debian-devel@ subscribers. This is the relevant documentation, which I strongly recommend everybody interested in this issue to read: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Understanding_the_Device_Renaming_Procedure.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Understanding_the_Predictable_Network_Interface_Device_Names.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Consistent_Network_Device_Naming_Using_biosdevname.html Maybe biosdevname would be nice to have, but: - somebody needs to actually maintain it in Debian - by default it only works on Dell systems - it is not loved by the udev/systemd upstream maintainers - it does not seem to me to provide any benefit over the firmware-based names since in practice both would use by default an interface index in the common case So I do not think that we need to care about it. An obvious downside is longer names for devices which do not provide ID_NET_NAME_ONBOARD: e.g. the WiFi card in my Dell laptop does not (wlp2s0), but the Ethernet port does (eno1). It will be even worse when not even ID_NET_NAME_PATH is defined (e.g. on my Allwinner-based ARM computer), which means that interfaces will get a mac-based name like enx028909xx. But if somebody cares about the aesthetic value of network interface names then they can probably write a custom udev rule to rename them, or keep using 75-persistent-net-generator if we can keep it around. (I believe that it would be a good idea for the ARM porters to have a look at which values are exported by their network drivers, because probably nobody else is going to work on this any time soon.) FWIW, I did a quick survey of my hardware: - HP G8: OK - HP G8 + add-on Intel card: OK (but obviously no index) - HP G8 + FlexFabric: OK - HP Gen9 + FlexFabric: stupid but will work (the SMBIOS indexes start from 49 instead of 1!) - Cisco UCS: OK - IBM BladeCenter + Emulex CNA: very broken (only eth0 has an index! I only checked biosdevname but it should not matter) - IBM Flex + Emulex CNA: broken like the BladeCenter - Some Intel-based Supermicro: OK (If any of the HP people here can find out who is responsible to fix the Gen9 BIOS then I can have my HP account manager make a business case for it. Submitting a support case would be time consuming for me and unnecessarily cruel for the support people...) -- ciao, Marco pgpqeby3JgoLK.pgp Description: PGP signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Proposal: enable stateless persistant network interface names
Hey Marco, Marco d'Itri [2015-05-11 5:53 +0200]: I am not sure that we really need to retire 75-persistent-net-generator right now: the annoying part to maintain is the kernel patch which we will need anyway for at least a couple of releases Which kernel patch? I think all of this ought to work on a vanilla kernel. It is trivial to make it opt-in by setting something like net.ifnames=0 (or even a different and specific value), and we can revisit this decision when we will be closer to the release. Yes, that will be the case once we drop the Debian specific Make-net.ifnames-opt-in-instead-of-opt-out.patch . Actually it requires us to keep maintaining the Revert-udev-network-device-renaming patch as long as there will be systems with a 70-persistent-net.rules file renaming eth* to eth*. Argh, that's true. I. e. another decade or so :/ Maybe biosdevname would be nice to have, but: [...] So I do not think that we need to care about it. Full ack. ifnames does everything biosdevname does and is both more universal and also more flexible to configure, so there is absolutely zero reason to introduce biosdevname now. It's mostly a backwards compatibility problem for systems which already have it installed (i. e. not pure Debian). An obvious downside is longer names for devices which do not provide ID_NET_NAME_ONBOARD: e.g. the WiFi card in my Dell laptop does not (wlp2s0), but the Ethernet port does (eno1). It will be even worse when not even ID_NET_NAME_PATH is defined (e.g. on my Allwinner-based ARM computer), which means that interfaces will get a mac-based name like enx028909xx. Remember, MAC based names aren't used with the default policy, you have to opt-in. Although it might happen that we do configure this by default for USB devices in the Debian policy, see the other parts of the thread. Thanks! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Proposal: enable stateless persistant network interface names
Hey Paul, Paul Wise [2015-05-09 16:15 +0800]: Is there a tool to list interfaces based on their characteristics? Right now at $work our initial setup code does glob eth* in /sys/class/net in order to setup a bond interface using all NICs, so network works no matter which NIC one plugs a cable into. It sounds like this proposal would break that, so we would need a way to list all Ethernet interfaces but not the bond interface and not any USB network interfaces etc. en* should be the equivalent with ifnames (but not with biosdevname!). Wifis are called wl*, and virtual interfaces like vlans, bridges, bonds, etc. are assigned by the admin (or at least not by the kernel and udev) anyway. However, I don't know how USB ethernet interfaces look like (neither in the kernel driver nor with ifnames). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Proposal: enable stateless persistant network interface names
[dropping d-devel@ as recipient] Quoting Martin Pitt (2015-05-09 11:26:14) [1] I don't have USB-ethernet devices myself; if you have one, please get in touch with me, I'd like to investigate how they look like in udev, and what udevadm test /sys/class/net/iface |grep NAME says about these. root@hamlet:~# udevadm test /sys/class/net/eth1|grep NAME ID_NET_NAME_MAC=enx000ec6f05c06 ID_NET_NAME_PATH=enp5s0u1 ...or do you need all the debug output too? Here's it's entry from lsusb: Bus 004 Device 002: ID 0b95:772a ASIX Electronics Corp. AX88772A Fast Ethernet - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Proposal: enable stateless persistant network interface names
The main downside is that by nature the device names are not familiar to current admins yet. For BIOS provided names you get e. g. ens0, for PCI slot names enp1s1 (ethernet) or wlp3s0 (wlan). But that's a necessary price to pay (biosdevname names look similar). The stability of these names appears to be an illusion. The path based names use the PCI bus number as their root. PCI bus numbers are dynamically allocated as the bios enumerates the busses. Other than the root PCI bus they aren't a fundamental chactertistic of the hardware. Installing or removing an expansion card can add or remove PCI busses from the system and hence risks changing bus numbers. I'm sure I even recall one case of a laptop with switchable graphics where switching graphics setup changed the PCI bus numbers. Someone else has raised concerns about the stability of bios based names over bios updates. I feel this change is likely to make things better for companies that want to deploy images to loads of identical machines and rarely modify a system but worse for those of us with more ad-hoc hardware arrangements. The current system really works quite well for individual machines with ad-hoc changes, my interfaces have consistent easy to remember names regardless of where I plug them in and if I do have to replace an interface card it's easy enough to open the persistent net rules file and give the replacement interface the number of the interface it replaced. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Proposal: enable stateless persistant network interface names
Is there a tool to list interfaces based on their characteristics? Right now at $work our initial setup code does glob eth* in /sys/class/net in order to setup a bond interface using all NICs, so network works no matter which NIC one plugs a cable into. It sounds like this proposal would break that, so we would need a way to list all Ethernet interfaces but not the bond interface and not any USB network interfaces etc. -- bye, pabs https://wiki.debian.org/PaulWise ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Proposal: enable stateless persistant network interface names
Bjørn Mork [2015-05-08 16:13 +0200]: PCI buses can be and are hotplugged, similar to network devices. Yes, that's certainly a valid point. It's not unanimously clear how you define the identity of an interface, whether it's more like by location or by MAC address. There are pros and cons for either POV. Karsten Merker [2015-05-08 18:31 +0200]: while this probably works resonably well for (semi-)fixed devices like onboard-NICs and PCI/PCIe cards, it results in a completely unsuitable behaviour with pluggable devices such as USB network adapters. TBH, hotpluggable USB network adapters which change all the time sound like a corner case in a server world where you have hand-written config files referring to interface names. They are of course common on the client side, but there stable interface names don't matter at all. But see below. peter green [2015-05-09 8:49 +0100]: The path based names use the PCI bus number as their root. PCI bus numbers are dynamically allocated as the bios enumerates the busses. PCI bus and slot numbers are stable across reboots, unless of course you physically change the cards (what Bjørn raised above). So, there's obviously two schools of thoughts here. Some people think in terms of MAC addresses, which breaks if you replace a broken or outdated card with a new one. Some people think in terms of location, like the left port goes to the internet, the right port to the intranet, and there is absolutely nothing wrong with that either; in that scenario you can replace a network card, but keep the cables etc, and everything will still work. I don't want to get down into philosophical questions whether rearranging the hardware in your server should or shouldn't be considered an identical configuration still, as that's just bikeshedding and we'll never find 100% consensus there. Neither MAC or location based stable names are flawless; the above show pitfalls of location based ones, the whole cloud story (or replacing faulty hardware) shows that MAC addresses are totally unsuitable in common situations. But what I do want to get rid of is the current 70-persistent-net-names.rules which have the inherent race condition and have no configurability at all; and it provides no stable interface names for any virtualized environment. With ifnames you can always choose your own policy (see man systemd.link), and e. g. say NamePolicy=onboard mac if you so prefer. We can even discuss preferring mac over slot by default (although I personally think that would be a worse default). One could even default to mac for USB based hardware and the default (kernel database onboard slot path) for others [1]. Martin [1] I don't have USB-ethernet devices myself; if you have one, please get in touch with me, I'd like to investigate how they look like in udev, and what udevadm test /sys/class/net/iface |grep NAME says about these. -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Proposal: enable stateless persistant network interface names
Martin Pitt [2015-05-08 7:59 +0200]: Details about [mac] --- [...] * It requires a writable /etc/udev/rules.d/ for persistantly storing the assignment. We don't want/have that with system-image (touch/snappy). Sorry, these are Ubuntu specific terms, forgot to edit. This meant to say: we don't have that with read-only or stateless root file systems, which become increasingly more popular. We do get bug reports in Debian as well about stuff that breaks r/o root; it's not much of an issue yet, so if you don't consider this a valid/sane use case just ignore this bit of the argument (the other reasons are still strong enough to change this anyway). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Proposal: enable stateless persistant network interface names
Hello Konstantin, Konstantin Khomoutov [2015-05-08 13:08 +0300]: Is it possible to provide a tool (a shell script?) that would print out the new would-be name of the interface provided by the user so that it would be possible to migrate remote systems only accessible via SSH? The closest thing to that would be something like this: $ sudo udevadm test /sys/class/net/wlan0 |grep ID_NET_NAME_ ID_NET_NAME_MAC=wlxa44e31848d2c ID_NET_NAME_PATH=wlp3s0 As I wrote the _MAC name isn't used by default (this has to be enabled explicitly, and it's a bit unwieldy); the default policy is to use the first existing variable in ID_NET_NAME_ONBOARD, ID_NET_NAME_SLOT, or ID_NET_NAME_PATH. Indeed it sounds useful to put that into a little shell script in /usr/share/doc/udev/ or so which the admin can run if she wants to migrate to the new names. I mean, a sysadmin would then be able to determine the new name of the network interface, reflect this change in the firewall setup and other relevant places, delete 70-persistent-net.rules and reboot the box (or may be perform some more involved encantation with calling ifdown / ip link name ... / ifup while in a screen/tmux session). It's not advisable to change network names at runtime. Well, you could stop all networking services and unload and reload the driver modules, but that sounds about as error prone as just rebooting :-) I don't know whether it's possible to change the name while the interface is up and in use. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Proposal: enable stateless persistant network interface names
On Fri, 8 May 2015 00:33:58 -0700 Josh Triplett j...@joshtriplett.org wrote: I propose to retire [mac], i. e. drop /lib/udev/rules.d/75-persistent-net-generator.rules and enable [ifnames] by default. [...] Having spent a non-trivial amount of time fighting persistent-net.rules on various systems, I'd very much welcome this change. To help migrate existing systems, I'd suggest including a NEWS.Debian file that explains the change, and recommends deleting /etc/udev/rules.d/70-persistent-net.rules on systems that don't depend on the exact names (for instance, systems that run NetworkManager rather than hard-coding network configuration in ifupdown's /etc/network/interfaces). Is it possible to provide a tool (a shell script?) that would print out the new would-be name of the interface provided by the user so that it would be possible to migrate remote systems only accessible via SSH? I mean, a sysadmin would then be able to determine the new name of the network interface, reflect this change in the firewall setup and other relevant places, delete 70-persistent-net.rules and reboot the box (or may be perform some more involved encantation with calling ifdown / ip link name ... / ifup while in a screen/tmux session). ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Proposal: enable stateless persistant network interface names
Martin Pitt mp...@debian.org writes: - [ifnames] For about two years (since 197) upstream's udev has a builtin persistant name generator which checks firmware/BIOS provided index numbers or slot names (like biosdevname), falls back to slot names (PCI numbers, Note that this makes the same bogus assumption about stable kernel names, just in a different subsystem. PCI buses can be and are hotplugged, similar to network devices. PCI bus numbering is no more guaranteed than say ethX network device numbering for any bus number 0. But if will appear to produce stable names most of the time, of course. Just like your builtin ethernet interface will be eth0 most of the time. Just a heads up for the first bug report... Bjørn ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Proposal: enable stateless persistant network interface names
Hi, Karsten Merker: while this probably works resonably well for (semi-)fixed devices like onboard-NICs and PCI/PCIe cards, it results in a completely unsuitable behaviour with pluggable devices such as USB network adapters. Why? I can envision two likely scenarios for using a USB adapter. (a) you need to test something, so you plug in a handy USB adapter and configure it statically. So you're root and mucking about in /etc anyway, so also adding a one-liner to /etc/udev/rules.d/70-persistent-net.rules which names the adapter statically should not be a problem. (b) you're a client (e.g. you configure a new router), likely to use NetworkManager to just run a dhcp client on the adapter or configure a one-off RFC1918 address. So what if the adapter gets a different name next time? Most likely you need to configure a different device in a different '1918 subnet anyway. Or, if you use DHCP, there's no difference either way. In all other situations, quickly configuring a static address is no problem IMHO. Despite the problems of the MAC-based system that we use currently, the ifnames method appears way worse to me than what we have now. On a server, a missed rename due to interfaces showing up in exactly the wrong order makes the system unreachable. Frankly, I cannot imagine anything way worse than that. Not in this context. -- -- Matthias Urlichs signature.asc Description: Digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Proposal: enable stateless persistant network interface names
Just my 0.02$ against using the BIOS method. I have and Do see inconsistent bios vendor naming used from release to release of their Firmware updates. I have had to fix HP Propliants servers numerous time due to a firmware update changing the number and/or order of SATA ports, PCI and other things. So I for one dislike using bios provided info for any sort of userland namespace mapping method due to the above issues caused. -Joel On 8 May 2015 at 01:59, Martin Pitt mp...@debian.org wrote: Hello Debianists, Quick intro to the problem: The kernel generally detects network interfaces (eth0, wlan1, etc.) in an unpredictable and often unstable order. But in order to refer to a particular one in /etc/network/interfaces, firewall configs etc. you need to use a stable name. The general schema for this is to have an udev rule which does some matches to identify a particular interface, and assigns a NAME=foo to it. Interfaces with an explicit NAME= property get that name, and others just get a kernel driver default, usually ethN, wlanN, or sometimes others (some wifi drivers have their own naming schemas). Over the years several solutions have appeared: - [mac] For many many years our we have installed an udev rule /lib/udev/rules.d/75-persistent-net-generator.rules which on first boot creates a MAC address → current name mapping and writes /etc/udev/rules.d/70-persistent-net.rules. - [biosdevname] is a package originally written by Dell (IIRC), which reads port/index/slot names from the BIOS and sets them in /lib/udev/rules.d/71-biosdevname.rules. - [ifnames] For about two years (since 197) upstream's udev has a builtin persistant name generator which checks firmware/BIOS provided index numbers or slot names (like biosdevname), falls back to slot names (PCI numbers, etc., in the spirit of /dev/disks/by-path/), and then optionally (not done by default) falls back to MAC address (similar to [mac]). This happens in /lib/udev/rules.d/80-net-setup-link.rules. Note that these solutions can, and do get combined: The first rule which sets a name wins, i. e. currently [biosdevname] beats [mac] beats [ifnames]. Details about [mac] --- This is our current solution which applies to most hardware out there. It was an useful hack almost a decade ago, but it really shows its age: * It's subject to inherent race conditions (detecting a new device vs. renaming an existing one), which sometimes leads to devices being called renameX and breaking your boot. * It requires a writable /etc/udev/rules.d/ for persistantly storing the assignment. We don't want/have that with system-image (touch/snappy). * It's incompatible with how cloud images operate, as the physical (emulated from the VM host) devices can change between boots. Hence we maintain an ever-growing blacklist in 75-persistent-net-generator.rules which causes bugs and pain with each new cloud or virtualization provider. Recent examples: LP #1437375, #1367883, #1361272, #1317776, #1274348, #1099278. Support for [mac] got dropped in upstream udev two years ago, and since then we have maintained it on the Debian/Ubuntu side. Details about [biosdevname] --- This is a very good approach in principle, but unfortunately most desktop and laptop BIOSes out there don't actually set this kind of information, and of course none of the non-x86 machines do. I don't know how pervasive it is on dedicated server hardware. So this only actually helps for a small minority of cases, and currently falls back to [mac]. biosdevname isn't packaged in Debian, so it's not much of a concern in a Debian context. Some people might have installed the package from Dell or Ubuntu. Details about [ifnames] --- This is a generic solution which extends the [biosdevname] idea and thus applies to all practical cases and all architectures. It doesn't need any persistant state (i. e. dynamic /etc/udev/rules.d/) and thus applies nicely to snappy/touch, and also avoids the race condition. The main downside is that by nature the device names are not familiar to current admins yet. For BIOS provided names you get e. g. ens0, for PCI slot names enp1s1 (ethernet) or wlp3s0 (wlan). But that's a necessary price to pay (biosdevname names look similar). As this hasn't been discussed yet, Debian and Ubuntu disable this by default. You can opt into this by booting with net.ifnames=1 (which is a patch against upstream: there you disable it by booting with net.ifnames=0 or disabling 80-net-setup-link.rules). Proposal I propose to retire [mac], i. e. drop /lib/udev/rules.d/75-persistent-net-generator.rules and enable [ifnames] by default. This will provide the new stable interface names for all new installations, stop the different handling of server/client, work with
Re: Proposal: enable stateless persistant network interface names
On Fri, May 08, 2015 at 09:06:25PM +0200, Karsten Merker wrote: On Fri, May 08, 2015 at 10:50:30AM -0700, Josh Triplett wrote: Karsten Merker wrote: while this probably works resonably well for (semi-)fixed devices like onboard-NICs and PCI/PCIe cards, it results in a completely unsuitable behaviour with pluggable devices such as USB network adapters. When using ifnames, the interface name depends on the USB port into which the device is currently plugged and the interface name changes when one uses a USB hub or plugs the device into another host port. This would mean that a user would always have to plug his USB network device into the same port that was used during initial setup to keep it working, and one-off use of a USB hub would require changing the network configuration. Despite the problems of the MAC-based system that we use currently, the ifnames method appears way worse to me than what we have now. That would only be a problem if you're using ifupdown and its hardcoded network interface names. Other network software handles dynamic names. How is for example iptables supposed to handle changing interface names? Associate the rules with addresses, names, or other aspects of network topology, rather than specific interfaces. And for servers or routers (the common case for iptables usage), ifnames should provide quite stable names. IPtables rules often specify a specific incoming or outgoing interface, so the interface name must be known at the ruleset load time. This would mean that with the ifnames mechanism and its port-based interface naming, an iptables ruleset on a laptop with a USB network adapter would only work if the adapter is either always plugged into the same port or the user changes the ruleset every time he uses another USB port. On a laptop (or anywhere else), ideally you're using a higher-level tool than iptables. For instance, if you're trying to share connectivity from one network and NAT it to another, that's easily done with a few clicks these days. And it doesn't depend on which adapter Without this, you can't reliably use a system with *two* USB network devices, because they won't consistently come up with the same names. Or, for that matter, a system with a built-in network interface and a USB network interface. The current default MAC-based mechanism handles exactly this case very well on a number of systems for me (one built-in network interface and one or two USB network adapters). Every adapter always gets the same interface name, regardless of the bringup order. Answered in my other response, sorry. Yes, the MAC-based mechanism handles this too, but it has quite a few other issues. - Josh Triplett ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Proposal: enable stateless persistant network interface names
Le vendredi 08 mai 2015 à 07:59 +0200, Martin Pitt a écrit : Proposal I propose to retire [mac], i. e. drop /lib/udev/rules.d/75-persistent-net-generator.rules and enable [ifnames] by default. Yes, yes, yes, please. Let’s get rid of that horrible thing. -- .''`. Josselin Mouette : :' : `. `' `- ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
