Re: Proposal: enable stateless persistant network interface names
* Marco d'Itri m...@linux.it [2015-05-11 05:55]: 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'm not sure we had consensus at that time, however after the discussion has pretty much ended now it seems, at least to me, that your proposal is the best way to go forward. 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*. Does it make sense to stop shipping it on new installations rsn, provide legacy support in stretch but disable it (and remove support) with the following release? Or do you see the necessity to already do a hard-way upgrade for stretch, disabling 70-persistent-net.rules but giving the local admin a manual way to reenable it or a sample udev file to reenable its functionality? yours Martin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150702141732.gi3...@anguilla.debian.or.at
Re: Proposal: enable stateless persistant network interface names
On 06/30/2015 12:14 AM, Vincent Bernat wrote: ❦ 29 juin 2015 22:29 +0200, Thomas Goirand z...@debian.org : 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...). It has worked for many many years as long as the drivers were loaded synchronously. This is not the case anymore. When you have two brands of network card (for example bnx2 and e1000, quite common on HP servers), at each boot, you can get something different. And while the persistent naming file is a solution that worked almost all the time, there was some time where an interface were renamed to renameXX due to a naming conflict with the kernel. An alternative would be to use something like emX. Only the first boot would be random which might prove complex when deploying on a large cluster of identical nodes. This has already been explained in this very same thread. Thanks for explaining it again. I have to admit I didn't have time to read the (huge) thread entirely. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55930e1e.7040...@debian.org
Re: Proposal: enable stateless persistant network interface names
❦ 29 juin 2015 22:29 +0200, Thomas Goirand z...@debian.org : 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...). It has worked for many many years as long as the drivers were loaded synchronously. This is not the case anymore. When you have two brands of network card (for example bnx2 and e1000, quite common on HP servers), at each boot, you can get something different. And while the persistent naming file is a solution that worked almost all the time, there was some time where an interface were renamed to renameXX due to a naming conflict with the kernel. An alternative would be to use something like emX. Only the first boot would be random which might prove complex when deploying on a large cluster of identical nodes. This has already been explained in this very same thread. -- Use variable names that mean something. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5591aab8.6070...@debian.org
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 pgpisrqazVIXl.pgp Description: PGP signature
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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558d1507.1010...@debian.org
Re: Proposal: enable stateless persistant network interface names
On 05/17/2015 09:28 PM, Josh Triplett wrote: If that's a standard property of VMWare VMs, you could submit a udev rule that improves the default naming on such systems. I believe there are already some rules defining policies in that area, including VM-specific information. the only thing I can imagine which would work is the mac based version as pci ids and ordering will change when you press the upgrade button in the vcenter. Or maybe have a look at the pci id of the scsi/sas controller, thats the only way I know to figure out on which ids the ethernet controller will start -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/555a4cd5.4020...@bzed.de
Re: Proposal: enable stateless persistant network interface names
On 05/08/2015 09:28 AM, Josh Triplett wrote: Marc Haber wrote: I have tried this just last week and have found it kind of unsatisfactory that it doesn't work in virtualized environments. For example, in a KVM VM with virtio ethernet, the network devices still end up in the system as eth0, eth1, eth2. As I understand it, that's intentional and expected, for two reasons. First, because on a virtual machine, the network interfaces are likely to be more stable, always showing up with the same numbers. And second, because there's little else to go on when naming them. Unfortunately that is not true for VMware. If you run a vm with more than three vmxnet(3) network interfaces it will depend on the hw version of the vm in which order they appear (due to other pci ids and different order on the pci bus!), it might happen that the 3rd or 4th interface is ordered in front of the first interface. Also mixing e1000 and vmxnet(3) interfaces will result in a mess. It would be really great to fix this, as far as I can see the only way would be using mac address based interface names as the pci bus ids will change while upgrading hardware versions in vmware. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5558d80a@bzed.de
Re: Proposal: enable stateless persistant network interface names
On Sun, May 17, 2015 at 08:03:54PM +0200, Bernd Zeimetz wrote: On 05/08/2015 09:28 AM, Josh Triplett wrote: Marc Haber wrote: I have tried this just last week and have found it kind of unsatisfactory that it doesn't work in virtualized environments. For example, in a KVM VM with virtio ethernet, the network devices still end up in the system as eth0, eth1, eth2. As I understand it, that's intentional and expected, for two reasons. First, because on a virtual machine, the network interfaces are likely to be more stable, always showing up with the same numbers. And second, because there's little else to go on when naming them. Unfortunately that is not true for VMware. If you run a vm with more than three vmxnet(3) network interfaces it will depend on the hw version of the vm in which order they appear (due to other pci ids and different order on the pci bus!), it might happen that the 3rd or 4th interface is ordered in front of the first interface. Also mixing e1000 and vmxnet(3) interfaces will result in a mess. It would be really great to fix this, as far as I can see the only way would be using mac address based interface names as the pci bus ids will change while upgrading hardware versions in vmware. If that's a standard property of VMWare VMs, you could submit a udev rule that improves the default naming on such systems. I believe there are already some rules defining policies in that area, including VM-specific information. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150517192803.GC8326@x
Re: Proposal: enable stateless persistant network interface names
On Thu, 14 May 2015 09:07:16 +1000, Russell Stuart russell-deb...@stuart.id.au wrote: On Wed, 2015-05-13 at 17:16 +0200, Vincent Lefevre wrote: Well, having some of the network traffic (more precisely, connections to machines that have an IPv6 address) re-routed to some unknown machine on the local network is not a nice feature. IMHO, such a feature should be enabled only by the network management system, not by default at the kernel level. Now I've looked up what Marc is referring to in an earlier reply, SLAAC and DHCP look pretty similar to me. Both have the re-route your NIC to some unknown machine feature. I'm sure everybody here will be the victim of a rouge router sending NDP responses, just as everybody has already been the victim of a rouge DHCP server. Good networks know which machines are allowed to send DHCP offers and Router Advertisements and do not allow such packets to enter from unauthorized network ports. ARP and NDP spoofing is way more dangerous since all end systems need to be able to legitimately send such packets, and maintaining a static list between MAC and IP addresses is a significant burden and a significant loss in flexibility. Genereally, you need to trust your LAN. If you don't, you need to restrict access to your LAN (for example by locking your network ports away, not patching unneeded ports, or using technical level network access control such as 802.1x) so that you can trust it. With this in mind, IPv6 is no less secure than IPv4 is. I have to violently oppose any voice that suggests that enabling IPv6 is a security risk. It isn't. The one difference between the two right now is dhclient make it easy for the client to watch for changes using scripts. AFAICT, there is no off the shelf way of doing it for SLAAC. It's easy enough to do - just have a daemon listen to kernel netlink messages and fire off a script. The right place to put that now would be in systemd, but if they are opposed to scripts as Marc says that ain't going to happen. Sigh. They are walking in this direction via systemd-networkd. In systemd terminology, there will probably be a target or a regular unit that will be subjected to some state change whenever the network configuration changes. One will then be able to depend on that target/unit with one's own units, and they will of course be able to call scripts. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1ysnfy-00076j...@swivel.zugschlus.de
Re: Proposal: enable stateless persistant network interface names
On May 13, D. Jared Dominguez jared_doming...@dell.com wrote: - 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 Yes, but how often in practice it is able to provide an emN name while at the same time udev is unable to provide an enoN name? -- ciao, Marco pgpWxaxgx1CBE.pgp Description: PGP signature
Re: Proposal: enable stateless persistant network interface names
On 2015-05-12 22:31:43 +0200, Marc Haber wrote: On Tue, 12 May 2015 17:08:33 +0200, Vincent Lefevre vinc...@vinc17.net wrote: On 2015-05-11 18:04:14 +0200, Marc Haber wrote: In IPv6, routers advertise prefixes. If a new prefix comes, end systems configured for SLAAC will allocate an IP address in this prefix and begin to use it. On this subject, end systems under Debian are configured for SLAAC by default. :-( I consider that a feature. Well, having some of the network traffic (more precisely, connections to machines that have an IPv6 address) re-routed to some unknown machine on the local network is not a nice feature. IMHO, such a feature should be enabled only by the network management system, not by default at the kernel level. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513151607.ga14...@xvii.vinc17.org
Re: Proposal: enable stateless persistant network interface names
On Sat, May 09, 2015 at 02:49:35AM -0500, peter green wrote: 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. Note that biosdevname uses slot numbers, not PCI bus numbers. The following provides technical details on how biosdevname enumerates: http://linux.dell.com/files/whitepapers/consistent_network_device_naming_in_linux.pdf -- Jared Domínguez Infrastructure Software Engineering Dell | Enterprise Solutions Group -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513212008.gx11...@dell.com
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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513212930.gy11...@dell.com
Re: Proposal: enable stateless persistant network interface names
On Wed, 2015-05-13 at 17:16 +0200, Vincent Lefevre wrote: Well, having some of the network traffic (more precisely, connections to machines that have an IPv6 address) re-routed to some unknown machine on the local network is not a nice feature. IMHO, such a feature should be enabled only by the network management system, not by default at the kernel level. Now I've looked up what Marc is referring to in an earlier reply, SLAAC and DHCP look pretty similar to me. Both have the re-route your NIC to some unknown machine feature. I'm sure everybody here will be the victim of a rouge router sending NDP responses, just as everybody has already been the victim of a rouge DHCP server. Not having the automatically make my NIC usable on bootup feature enabled by default would seem like a major omission to me. The one difference between the two right now is dhclient make it easy for the client to watch for changes using scripts. AFAICT, there is no off the shelf way of doing it for SLAAC. It's easy enough to do - just have a daemon listen to kernel netlink messages and fire off a script. The right place to put that now would be in systemd, but if they are opposed to scripts as Marc says that ain't going to happen. Sigh. signature.asc Description: This is a digitally signed message part
Re: Proposal: enable stateless persistant network interface names
On Wed, 13 May 2015 17:16:07 +0200, Vincent Lefevre vinc...@vinc17.net wrote: On 2015-05-12 22:31:43 +0200, Marc Haber wrote: On Tue, 12 May 2015 17:08:33 +0200, Vincent Lefevre vinc...@vinc17.net wrote: On 2015-05-11 18:04:14 +0200, Marc Haber wrote: In IPv6, routers advertise prefixes. If a new prefix comes, end systems configured for SLAAC will allocate an IP address in this prefix and begin to use it. On this subject, end systems under Debian are configured for SLAAC by default. :-( I consider that a feature. Well, having some of the network traffic (more precisely, connections to machines that have an IPv6 address) re-routed to some unknown machine on the local network is not a nice feature. Same can be accomplished with arp spoofing or by spoofing ND. Disabling SLAAC does not improve security. otoh, it is very convenient to have new systems reachable immediately. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1ysyrw-gz...@swivel.zugschlus.de
Re: Proposal: enable stateless persistant network interface names
Marvin Renich wrote: Yes, I use ifupdown and wpasupplicant. Based on some of the threads on this list there are many people who love Network Manager and many who dislike it. I am one of the ones who dislike it. Given the fact that it is (or at least was recently) clearly controversial, choosing a path that relies on its use seems detrimental to me, regardless of whether it is the default or not. I'm not suggesting that we mandate the use of NetworkManager in particular. I'm suggesting that it's fine to have a solution that assumes the use of *some* modern network stack that doesn't inherently care about interface names, at least by default. (That doesn't make it impossible to match on interface names for the cases where that's appropriate; for instance, networkd lets you match on interface name *or* MAC *or* a variety of other properties.) In general, any new approach to networking should not be constrained by the limitations of ifupdown, which is effectively in eternal maintenance mode, and unlikely to ever gain the features current network management tools already have. All that said, I don't strongly care *which* policy we use, as long as we use a policy that's actually supported upstream, which the current MAC-based persistent naming is not. Given that I'm in favor of tools that don't care what you name the interfaces, I don't particularly care what the interfaces end up named. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513200838.GA3270@jtriplet-mobl1
Re: Proposal: enable stateless persistant network interface names
On Mon, May 11, 2015 at 07:40:38PM +0200, Karsten Merker wrote: On Mon, May 11, 2015 at 09:29:21AM +0100, Jonathan Dowland wrote: On Fri, May 08, 2015 at 11:03:55PM +0200, Marc Haber wrote: On Fri, 8 May 2015 13:33:06 -0700, j...@joshtriplett.org wrote: There are much better alternatives for most common cases. For example being? ufw is quite nice. AFAICS (please correct me if I am wrong) ufw appears to be designed for simple block all access from everywhere on all interfaces and explicitly allow exceptions for a few services from everywhere setups, but anything more complex appears to be out of its scope. So while it is surely nice and useful for the use case it was designed for, I cannot see it as a replacement for traditional iptables scripts if your setup is even slightly more complex. The thread I was replying to was 'common cases'. UFW indeed can't do more complex things, but it is more sophisticated than your summary: it can do rate limiting and various other things beyond simple deny-by-default. I wasn't proposing it as a replacement for bare iptables in all cases. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150512084714.ga14...@chew.redmars.org
Re: Proposal: enable stateless persistant network interface names
On Tue, 12 May 2015 17:08:33 +0200, Vincent Lefevre vinc...@vinc17.net wrote: On 2015-05-11 18:04:14 +0200, Marc Haber wrote: In IPv6, routers advertise prefixes. If a new prefix comes, end systems configured for SLAAC will allocate an IP address in this prefix and begin to use it. On this subject, end systems under Debian are configured for SLAAC by default. :-( I consider that a feature. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1ysgq7-00049m...@swivel.zugschlus.de
Re: Proposal: enable stateless persistant network interface names
On 2015-05-11 18:04:14 +0200, Marc Haber wrote: In IPv6, routers advertise prefixes. If a new prefix comes, end systems configured for SLAAC will allocate an IP address in this prefix and begin to use it. On this subject, end systems under Debian are configured for SLAAC by default. :-( -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150512150833.ga26...@ypig.lip.ens-lyon.fr
Re: Proposal: enable stateless persistant network interface names
On Mon, 11 May 2015 10:18:18 +1000, Russell Stuart russell-deb...@stuart.id.au wrote: I get the distinct feeling some people posting here consider ifup/down old fashioned. Granted it doesn't have a nice GUI, but from the point of view of someone who deploys lots of similar machines a GUI of any sort is a negative, and it has a far nicer property - it is easily scriptable. ifupdown _is_ scriptable. For example, it doesn't know dependencies between Interfaces, which is rather common for a server jockey (consider a VLAN on a bridge which is connected to the network via a bonding device), and it doesn't handle IP addresses that come and go at run time (as it is to be expected on IPv6 networks). And, when it comes to scriptability and flexiblity, systemd-networkd is vastly superior. It was made with a server in mind. Otoh, it is much harder to debug, extend and modify than ifupdown, which has a _very_ flexible script interface. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yri9n-0006om...@swivel.zugschlus.de
Re: Proposal: enable stateless persistant network interface names
On Sun, May 10, 2015 at 09:04:23PM +0200, Stephan Seitz wrote: On Sun, May 10, 2015 at 07:09:41PM +0200, Marc Haber wrote: Just for the record, an unexpected interface name change hasn't happened in my professional career in more than ten years. Same here. I have never seen unexpected interface changes. I have, during my 10 year tenure as a systems administrator. Shade and sweet water! Still on the wrong side of your signature separator... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150511083432.gc1...@chew.redmars.org
Re: Proposal: enable stateless persistant network interface names
On Fri, May 08, 2015 at 11:03:55PM +0200, Marc Haber wrote: On Fri, 8 May 2015 13:33:06 -0700, j...@joshtriplett.org wrote: There are much better alternatives for most common cases. For example being? ufw is quite nice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150511082921.gb1...@chew.redmars.org
Re: Proposal: enable stateless persistant network interface names
On Mon, 11 May 2015 09:29:43 +0200, Marc Haber mh+debian-de...@zugschlus.de wrote: On Mon, 11 May 2015 10:18:18 +1000, Russell Stuart russell-deb...@stuart.id.au wrote: I get the distinct feeling some people posting here consider ifup/down old fashioned. Granted it doesn't have a nice GUI, but from the point of view of someone who deploys lots of similar machines a GUI of any sort is a negative, and it has a far nicer property - it is easily scriptable. ifupdown _is_ scriptable. Eh, it _is_ old-fashioned, I wanted to write. For example, it doesn't know dependencies between Interfaces, which is rather common for a server jockey (consider a VLAN on a bridge which is connected to the network via a bonding device), and it doesn't handle IP addresses that come and go at run time (as it is to be expected on IPv6 networks). Greetings Ma need more coffee rc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yrikp-0007cn...@swivel.zugschlus.de
Re: Proposal: enable stateless persistant network interface names
Just a quick observation: a lot of the problems people have experienced with network interface naming is a combination of two things: both whatever persistence scheme is in place (or not), but also the fact they *need to know a network interface name at all*. Many times I've wanted to express launch DHCPd on the only network device you see or are going to see with something like ifupdown, the actual network device name is irrelevant, but I'm forced to use it because ifupdown is old-aged. (This in particularly with VMs that might be cloned or moved around a lot). I think it's important to consider the state of our networking tools and what we want to see there going forward in concert with device naming considerations, and not make decisions based on the false premise that the way we do things now is how we want to do them Tomorrow. -- Jonathan Dowland -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150511082632.ga1...@chew.redmars.org
Re: Proposal: enable stateless persistant network interface names
Ben Hutchings b...@decadent.org.uk wrote: The NM configuration is based on MAC addresses and doesn’t care about the interface name at all. This is the exact opposite of “handling dynamic names ungracefully”. Well, that's assuming hardware that has a permanent MAC address. What does it do for virtual or cheap hardware that gets a different locally- assigned address at each boot or hotplug? In most situations, the default behavior (starting a DHCP connection when the first adapter is plugged on) is what you want. When you use manual configuration, the daemon’s default is to write MAC-based configuration files, but you can change them to remove the 802-3-ethernet/mac-address setting and use connection/interface-name instead. See https://developer.gnome.org/NetworkManager/unstable/ref-settings.html -- Joss -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1431339406.4239.7.ca...@dsp0698014.postes.calibre.edf.fr
Re: Proposal: enable stateless persistant network interface names
On Mon, 2015-05-11 at 12:16 +0200, Josselin Mouette wrote: Ben Hutchings b...@decadent.org.uk wrote: The NM configuration is based on MAC addresses and doesn’t care about the interface name at all. This is the exact opposite of “handling dynamic names ungracefully”. Well, that's assuming hardware that has a permanent MAC address. What does it do for virtual or cheap hardware that gets a different locally- assigned address at each boot or hotplug? In most situations, the default behavior (starting a DHCP connection when the first adapter is plugged on) is what you want. When you use manual configuration, the daemon’s default is to write MAC-based configuration files, but you can change them to remove the 802-3-ethernet/mac-address setting and use connection/interface-name instead. See https://developer.gnome.org/NetworkManager/unstable/ref-settings.html I think you missed a point: permanent and locally-assigned MAC addresses are distinguishable, so Network Manager can and should avoid matching on the basis of a locally-assigned MAC address. Ben. -- Ben Hutchings For every action, there is an equal and opposite criticism. - Harrison signature.asc Description: This is a digitally signed message part
Re: Proposal: enable stateless persistant network interface names
* Marco d'Itri m...@linux.it [150510 23:55]: 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. Huh? This thread seems to have lots of opinions on both sides with no consensus at all. I don't see how you can make this assertion with a straight face. ...Marvin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2015051923.gc18...@basil.wdw
Re: Proposal: enable stateless persistant network interface names
On Mon, 2015-05-11 at 05:53 +0200, Marco d'Itri wrote: [...] 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. [...] For ARM (and any other architecture using Device Tree) the on-board indices should be specified as aliases 'ethernet0', 'ethernet1', etc. The aliases will be listed in the uevent as OF_ALIAS_0 (or OF_ALIAS_1, etc., as a device can have multiple aliases). Ben. -- Ben Hutchings For every action, there is an equal and opposite criticism. - Harrison signature.asc Description: This is a digitally signed message part
Re: Proposal: enable stateless persistant network interface names
On Mon, 2015-05-11 at 09:29 +0200, Marc Haber wrote: For example, it doesn't know dependencies between Interfaces, which is rather common for a server jockey (consider a VLAN on a bridge which is connected to the network via a bonding device) I haven't had to solve that example, but I have had a problem again involving bridges that sounds similar. It was solvable with ifup/down - by calling ifup in the /etc/network/interfaces pre-up. I'll grant you it's not pretty, but I've only had to do it once so I forgive aj. [ifupdown] it doesn't handle IP addresses that come and go at run time (as it is to be expected on IPv6 networks). Could you explain when IPv6 addresses come and go? You are talking to a IPv6 neophyte here. In the IPv4 world addresses handed out by DHCP do come and go. It's true that isn't handled by ifupdown, but that's not a problem because if you want to do something about it, you do it in the dhclient hook. It seems the right place to me. That aside, I don't see anything in man systemd.network that allows you to watch for IPv6 addresses coming and going, or for that matter anything else coming and going except devices. And, when it comes to scriptability and flexiblity, systemd-networkd is vastly superior. It was made with a server in mind. This para is the real reason I'm responding. I must be missing something, because nowhere in man systemd.network do I see to a way to run a script of any sort. For me the acid test is can it do totally manual configuration, ie the equivalent of ifupdown's manual method. (I occasionally use manual - it's a great way of ensuring there are no surprises.) systemd.network's [Match] section combined with the sort of demonstrated by ifupdown's manual method would be a match made in heaven. But if it exists I've missed it. You could perhaps emulate it if it were possible to make a systemd.service depend on a systemd.network, but that appears to be right out of scope. As it stands, networkd looks to be one of the least scriptable networking configuration options I've seen since ... oh redhat 7.0 or so. Otoh, it is much harder to debug, extend and modify than ifupdown, which has a _very_ flexible script interface. Up until recently I thought the systemd mob had solved the visibility problem by logging everything written to stdout and stderr with journald. I was disabused of that notion just this weekend, when apache2 failed to start after an apt-get dist-upgrade. journalctl -xn helpfully told me: $ ssu journalctl -xn -- Logs begin at Mon 2015-05-11 21:16:17 AEST, end at Mon 2015-05-11 22:22:42 AEST. -- May 11 22:21:43 russell-laptop systemd[1]: apache2.service: control process exited, code=exited stat May 11 22:21:43 russell-laptop systemd[1]: Failed to start LSB: Apache2 web server. -- Subject: Unit apache2.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit apache2.service has failed. -- -- The result is failed. Which is about as useful as a hip pocket in a singlet. In the end this told me what was going on: $ _SYSTEMCTL_SKIP_REDIRECT=true /etc/init.d/apache2 start [FAIL] Starting web server: apache2 failed! [warn] The apache2 configtest failed. ... (warning). Output of config test was: apache2: Syntax error on line 141 of /etc/apache2/apache2.conf: Could not open configuration file /etc/apache2/mods-enabled/php5_cgi.conf: No such file or directory Action 'configtest' failed. The Apache error log may have more information. Having to troll through scripts in /var/lib/lsb in order to figure out how to disable the systemd redirect in order to see the error message the sysV init script sent to stdout is NOT an improvement. (The Apache error log was empty.) If debugging networkd stuff is harder, then ... *shudder*. signature.asc Description: This is a digitally signed message part
Re: Proposal: enable stateless persistant network interface names
On May 11, Marvin Renich m...@renich.org wrote: 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. Huh? This thread seems to have lots of opinions on both sides with no consensus at all. I don't see how you can make this assertion with a straight face. I see some concerns about using firmware-derived names for USB devices, but not significant objections for the general case. Consensus does not mean that there is no disagreement at all, but that all objections have been addressed. -- ciao, Marco pgp7ZFmNSPj61.pgp Description: PGP signature
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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150512041237.gb3...@piware.de
Re: Proposal: enable stateless persistant network interface names
On May 11, Ben Hutchings b...@decadent.org.uk wrote: For ARM (and any other architecture using Device Tree) the on-board indices should be specified as aliases 'ethernet0', 'ethernet1', etc. Is this something that I can experiment on by patching just the device tree definition or does it happen in the driver? Do you have an example that I can look at? The aliases will be listed in the uevent as OF_ALIAS_0 (or OF_ALIAS_1, etc., as a device can have multiple aliases). udev does not know about this variable, so unless the index will also appear somewhere else it will not be enough. -- ciao, Marco pgpac1S8rFPbz.pgp Description: PGP signature
Re: Proposal: enable stateless persistant network interface names
On Mon, 11 May 2015 22:37:40 +1000, Russell Stuart russell-deb...@stuart.id.au wrote: On Mon, 2015-05-11 at 09:29 +0200, Marc Haber wrote: For example, it doesn't know dependencies between Interfaces, which is rather common for a server jockey (consider a VLAN on a bridge which is connected to the network via a bonding device) I haven't had to solve that example, but I have had a problem again involving bridges that sounds similar. It was solvable with ifup/down - by calling ifup in the /etc/network/interfaces pre-up. I'll grant you it's not pretty, but I've only had to do it once so I forgive aj. Of course you can do that with /e/n/i, it's just clumsy and manual. [ifupdown] it doesn't handle IP addresses that come and go at run time (as it is to be expected on IPv6 networks). Could you explain when IPv6 addresses come and go? You are talking to a IPv6 neophyte here. In the IPv4 world addresses handed out by DHCP do come and go. It's true that isn't handled by ifupdown, but that's not a problem because if you want to do something about it, you do it in the dhclient hook. It seems the right place to me. In IPv6, routers advertise prefixes. If a new prefix comes, end systems configured for SLAAC will allocate an IP address in this prefix and begin to use it. End systems with privacy extensions enabled will automatically allocate an (additional?) random IP address and change it after a given amount of time. IP address change happens by first configuring the new address and then deprecating, but not deconfiguring, the old IP address. A deprecated IP address is not used for new connections, but allows already existing connections to live. That aside, I don't see anything in man systemd.network that allows you to watch for IPv6 addresses coming and going, or for that matter anything else coming and going except devices. As far as I know, this is not yet implemented, but systemd as a central daemon with dbus and other links is predestined to take care of IP address changes as well. Unfortunately, it does not yet have appropriate hooks, but I guess that it will advertise interfaces and addresses coming and going via dbus so that third party software can act on those events. I have never actually tried that and am not familiar enough with dbus to even look what's happening here. And, when it comes to scriptability and flexiblity, systemd-networkd is vastly superior. It was made with a server in mind. This para is the real reason I'm responding. I must be missing something, because nowhere in man systemd.network do I see to a way to run a script of any sort. For me the acid test is can it do totally manual configuration, ie the equivalent of ifupdown's manual method. It cannot do that, no. It doesn't need to. Manual configuration can still be done from a regular systemd unit or old fashioned /e/n/i. Afaik, it only acts on interface it can find configuration for, so you're free to have it ignore interfaces you want to handle manually. (I occasionally use manual - it's a great way of ensuring there are no surprises.) systemd.network's [Match] section combined with the sort of demonstrated by ifupdown's manual method would be a match made in heaven. But if it exists I've missed it. You could perhaps emulate it if it were possible to make a systemd.service depend on a systemd.network, but that appears to be right out of scope. As it stands, networkd looks to be one of the least scriptable networking configuration options I've seen since ... oh redhat 7.0 or so. the systemd people are working hard to eliminate scripts from system administration. Hence they're quite reluctant to add interfaces to plug new scripts into. This is indeed one of the biggest turn-offs with systemd for me. Otoh, it is much harder to debug, extend and modify than ifupdown, which has a _very_ flexible script interface. Up until recently I thought the systemd mob had solved the visibility problem by logging everything written to stdout and stderr with journald. I was disabused of that notion just this weekend, when apache2 failed to start after an apt-get dist-upgrade. journalctl -xn helpfully told me: $ ssu journalctl -xn -- Logs begin at Mon 2015-05-11 21:16:17 AEST, end at Mon 2015-05-11 22:22:42 AEST. -- May 11 22:21:43 russell-laptop systemd[1]: apache2.service: control process exited, code=exited stat May 11 22:21:43 russell-laptop systemd[1]: Failed to start LSB: Apache2 web server. -- Subject: Unit apache2.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit apache2.service has failed. -- -- The result is failed. Which is about as useful as a hip pocket in a singlet. In the end this told me what was going on: $ _SYSTEMCTL_SKIP_REDIRECT=true /etc/init.d/apache2 start [FAIL] Starting web server: apache2 failed!
Re: Proposal: enable stateless persistant network interface names
Le 10/05/2015 16:24, Vincent Bernat a écrit : Actually, when rebooting your (mission-critical) server, you can have a race condition where eth1 is not the interface that was eth1 on the previous boot and rename5 is the interface that should be eth1. That's what needs to be fixed. Doing nothing won't fix that. Can someone confirms that the race condition comes from the fact that both the initial-kernel name and the udev-setup name both use the 'ethX' template ? Would we still have a race condition if /etc/udev/rules.d/70-persistent-net.rules was stting up other names (such as renethX or any other template different from the default kernel name) ? If the answer of the last question is no, whatever the default that will be chosen, I will configure my systems to use MAC-based names but with a different template (enX for example). Regards, Vincent -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/554fbe56.6040...@free.fr
Re: Proposal: enable stateless persistant network interface names
On Sun, 2015-05-10 at 22:23 +0200, Vincent Danjean wrote: Le 10/05/2015 16:24, Vincent Bernat a écrit : Actually, when rebooting your (mission-critical) server, you can have a race condition where eth1 is not the interface that was eth1 on the previous boot and rename5 is the interface that should be eth1. That's what needs to be fixed. Doing nothing won't fix that. Can someone confirms that the race condition comes from the fact that both the initial-kernel name and the udev-setup name both use the 'ethX' template ? Yes, that's it. Would we still have a race condition if /etc/udev/rules.d/70-persistent-net.rules was stting up other names (such as renethX or any other template different from the default kernel name) ? Not since systemd 215-14. Previously there was another race condition in updating that file (#765577). If the answer of the last question is no, whatever the default that will be chosen, I will configure my systems to use MAC-based names but with a different template (enX for example). Ben. -- Ben Hutchings When in doubt, use brute force. - Ken Thompson signature.asc Description: This is a digitally signed message part
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 pgpDRqydQ5FrC.pgp Description: PGP signature
Re: Proposal: enable stateless persistant network interface names
On May 08, Marc Haber mh+debian-de...@zugschlus.de wrote:
That would mean changing local code to _both_ handle en* and eth*,
which is (a) a surprise and (b) unsatisfying in _my_ personal opinion.
I'd rather have it fully and consistently or not at all.
Not at all is going to be harder and harder to support, so we need
something better.
If you just want everything to be called em* then you can drop in your
VMs a /etc/udev/rules.d/70-persistent-net.rules file containing:
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, ATTR{dev_id}==0x0,
ATTR{type}==1, KERNEL==eth0, NAME=em0
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, ATTR{dev_id}==0x0,
ATTR{type}==1, KERNEL==eth1, NAME=em1
...
--
ciao,
Marco
pgp0fH5qcCccr.pgp
Description: PGP signature
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
Re: Proposal: enable stateless persistant network interface names
Le vendredi 08 mai 2015 à 20:14 +0200, Marc Haber a écrit : Do we have other network software other than ifupdown, systemd-networkd and network-manager, the latter handling dynamic names rather ungracefully. The NM configuration is based on MAC addresses and doesn’t care about the interface name at all. This is the exact opposite of “handling dynamic names ungracefully”. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1431295030.5547.14.ca...@debian.org
Re: Proposal: enable stateless persistant network interface names
On Sun, 2015-05-10 at 17:11 +0200, Vincent Bernat wrote: The disease is that actual servers running actual free software can break at each boot because we cannot have both a persistent naming scheme and use the eth* prefix is worse that the cure because old versions of Novell ZENworks may stop to work on upgrade? Speaking as someone who runs Debian on his servers and laptop, I don't care about what you guys choose. I don't care on the laptop mostly because of the reasons Josh Triplet pointed out earlier. I manage the network through GUI interfaces, and it doesn't care what the interfaces are called. For servers the interfaces are all assigned fixed, well known names. The reason is their configuration is completely automated through 100's of scripts. In all instances I've seen it done like this well known interface names are used. It's not difficult to understand why if you've done it - you can sort out what NIC is supposed to be doing at install or boot up and rename it accordingly, or you can do it in every script that deals with the network. The choice is obvious. You have the disease wrong. These scripts have been around for over a decade. In that time various fashions in interface naming have come and gone. This is yet another one. The disease isn't the kernel choosing different names on boot up, it's people inventing new interface naming schemes every few years, just as being done here. Everyone who has had to support many servers over a long period gets sick of this and writes yet another script that does in the renaming in the way they want, in a way that will be stable forever more. Thus they don't care what choice is made here - as they have already given up relying on Debian to do it, because Debian isn't stable enough. That said when writing our own scripts most of us long ago came to the conclusion the bus path to the interface was the most useful way to identify it. Again the reason is straight forward - if you have an image tuned for a piece of hardware that you have deployed en-masse the one thing that is the same on all of them is the paths to the NIC's. Note that when, long ago, the kernels actually managed to repeatability name the NIC's eth0, eth1 etc, it was because the buses were enumerated in a repeatable order so the NIC's got seen in a repeatable order. So in effect the name was determined by the bus path. Ergo, nothing has changed in 20 years. I get the distinct feeling some people posting here consider ifup/down old fashioned. Granted it doesn't have a nice GUI, but from the point of view of someone who deploys lots of similar machines a GUI of any sort is a negative, and it has a far nicer property - it is easily scriptable. In fact underneath the hood it's driven by scripts. If there is a network configuration it isn't capable of setting up, I haven't seen it. In my very brief look at networkd it didn't provide anything like the same amount of flexibility. signature.asc Description: This is a digitally signed message part
Re: Proposal: enable stateless persistant network interface names
On Sun, 2015-05-10 at 23:57 +0200, Josselin Mouette wrote: Le vendredi 08 mai 2015 à 20:14 +0200, Marc Haber a écrit : Do we have other network software other than ifupdown, systemd-networkd and network-manager, the latter handling dynamic names rather ungracefully. The NM configuration is based on MAC addresses and doesn’t care about the interface name at all. This is the exact opposite of “handling dynamic names ungracefully”. Well, that's assuming hardware that has a permanent MAC address. What does it do for virtual or cheap hardware that gets a different locally- assigned address at each boot or hotplug? Ben. -- Ben Hutchings For every action, there is an equal and opposite criticism. - Harrison signature.asc Description: This is a digitally signed message part
Re: Proposal: enable stateless persistant network interface names
On Sat, May 09, 2015 at 02:36:30PM -0700, Josh Triplett wrote: Why? What does a stable name matter in the case you mentioned? Because I don’t want to look up the interface name of the day when I use wireshark/tshark? Because I don’t want to change my iptables scripts which is working very well the way it is? Were you actually using ifupdown to manage the varied set of wireless networks? Because if not, then the name shouldn't matter. Yes, I’m using ifupdown. Besides USB NICs don’t have to be WiFi. You may switch the the naming scheme in virtual environments, but only here. SLES is using some strange interface names like em1 or p1p2, but I hate it. I prefer my eth0 name. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Proposal: enable stateless persistant network interface names
On 05/10/2015 at 07:36 AM, Stephan Seitz wrote: On Sat, May 09, 2015 at 02:36:30PM -0700, Josh Triplett wrote: Why? What does a stable name matter in the case you mentioned? Because I don’t want to look up the interface name of the day when I use wireshark/tshark? Because I don’t want to change my iptables scripts which is working very well the way it is? Were you actually using ifupdown to manage the varied set of wireless networks? Because if not, then the name shouldn't matter. Yes, I’m using ifupdown. Besides USB NICs don’t have to be WiFi. Lots of people are, and it's inappropriate and IMO a bad idea to just assume that you can safely break what was once and may very well still be the single most widely-used method of controlling network interfaces under *nix. It has been safe to assume that wired interfaces will be named ethX, and wireless ones wlanX, for so long that that assumption is built into many existing procedures - both as implemented in code, and as implemented in human habits and practices. If that assumption is to be broken, IMO at minimum a multi-year explicit deprecation period (such as that used for Linux-kernel feature removal) would be appropriate. You may switch the the naming scheme in virtual environments, but only here. SLES is using some strange interface names like em1 or p1p2, but I hate it. I prefer my eth0 name. I'll note that I've also seem some proprietary (but mission-critical) software which hardcodes interface names in some places; for example, older versions of Novell ZENworks' system-imaging utility would crash when attempting to multicast on a machine with an interface named em1 and no interface named eth0, reporting an inability to get the MAC address. That's been fixed in more recent versions, but I don't know whether it was fixed by adding em* to the list of names to check or by adding logic to enumerate all available interfaces without making assumptions about their names - though the former seems more likely. Now, ZENworks by default uses a custom LiveCD/initrd environment, and is not based on Debian - but it's entirely possible to either build custom versions of that environment (I've done it) or pull out the imaging utility and run it in a different environment, and in any case there's no way to be sure this is the only such example of important software with this sort of problem. (I can't check right now, but I actually suspect that at least one of the custom wireless-network-connection-management scripts I've written for that environment also relies on being able to assume the name wlan0... and trying to implement properly robust parse-sysfs logic to identify all available network adapters and distinguish wireless ones from wired ones would be considerably more than I'd want to do in bash.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Proposal: enable stateless persistant network interface names
On Sat, May 09, 2015 at 05:55:36PM -0700, Cameron Norman wrote: On Sat, May 9, 2015 at 2:36 PM, Josh Triplett j...@joshtriplett.org wrote: Marvin Renich wrote: * Martin Pitt mp...@debian.org [150509 05:27]: 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. I disagree that stable interface names do not matter for USB adaptors for consumer laptops. I have owned two laptops where the on-board WiFi adaptor was too new to have reliable Linux drivers until 6-12 months after I purchased them. While waiting for the Linux drivers, I used a USB WiFi dongle that has good kernel support. I have plugged the adaptor into different USB ports based on where my laptop was situated wrt varied surroundings. I suspect (with no real data to back it up) that the biggest use of USB WiFi dongles on consumer machines is when the on-board WiFi doesn't work for some reason (too new or broken). In this case, it is often the main internet connection and a stable name is important. Why? What does a stable name matter in the case you mentioned? Were you actually using ifupdown to manage the varied set of wireless networks? Because if not, then the name shouldn't matter. Does networkd handle this situation well? Yes. It has an arbitrary matching mechanism based on various attributes of interfaces and networks. While you *can* match the interface name, you don't need to, and you have many other options. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150510180651.GA11593@x
Re: Proposal: enable stateless persistant network interface names
On Sun, 10 May 2015 17:11:03 +0200, Vincent Bernat ber...@debian.org wrote: The disease is that actual servers running actual free software can break at each boot because we cannot have both a persistent naming scheme and use the eth* prefix is worse Just for the record, an unexpected interface name change hasn't happened in my professional career in more than ten years. Plugging persistent network naming with -this- imminent danger destroys the pro-faction's credibility. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yrujv-0005i7...@swivel.zugschlus.de
Re: Proposal: enable stateless persistant network interface names
On 05/10/2015 at 10:24 AM, Vincent Bernat wrote: ❦ 10 mai 2015 08:20 -0400, The Wanderer wande...@fastmail.fm : Were you actually using ifupdown to manage the varied set of wireless networks? Because if not, then the name shouldn't matter. Yes, I’m using ifupdown. Besides USB NICs don’t have to be WiFi. Lots of people are, and it's inappropriate and IMO a bad idea to just assume that you can safely break what was once and may very well still be the single most widely-used method of controlling network interfaces under *nix. Do you speak about ifupdown? It's Debian only. eth* interfaces is not *nix at all since all BSD are using per-driver naming convention. Upon consideration, I suspect that I've been making - at least - the following three assumptions: * That ifupdown is essentially (in functionality if not in implementation) a set of wrappers around ifconfig, with a few additional scripts. * That ifconfig uses /etc/network/interfaces just as ifupdown does, and so would have the same interface-naming limitations. (I think this one was based in part on observation of real-world behavior.) * That ifconfig has been the standard way of working with network interfaces for more-or-less as long as there _has_ been a standard userspace way of doing that. If any (or all!) of those assumptions are false, then some of my conclusions may not hold. It has been safe to assume that wired interfaces will be named ethX, and wireless ones wlanX, for so long that that assumption is built into many existing procedures - both as implemented in code, and as implemented in human habits and practices. If that assumption is to be broken, IMO at minimum a multi-year explicit deprecation period (such as that used for Linux-kernel feature removal) would be appropriate. On Linux, wireless drivers have long used eth* names, except for some out-of-tree drivers. It was the introduction fo the MAC 802.11 soft layer (2.6.22+) that gradually switched drivers to use wlan* names. And this change was driver by driver, at each release without much publicity. Drivers not using the new framework to register themselves are still using eth* names (like the Prism54 full mac driver). I wasn't aware of the specifics of the shift; acknowledged. That would simply strengthen the argument for its having been safe to assume the ethX naming, though, at least as much as it weakens the argument for its having been safe to assume the wlanX naming. You may switch the the naming scheme in virtual environments, but only here. SLES is using some strange interface names like em1 or p1p2, but I hate it. I prefer my eth0 name. I'll note that I've also seem some proprietary (but mission-critical) software which hardcodes interface names in some places; for example, older versions of Novell ZENworks' system-imaging utility would crash when attempting to multicast on a machine with an interface named em1 and no interface named eth0, reporting an inability to get the MAC address. This thread is about changing the default naming convention for network interfaces. If you love to run an unmaintained version of Novell ZENworks, you can still have an eth0 interface if you want. Where do you get unmaintained from? And my point was not about that one specific program; I was just using it as an example to indicate that there do exist important programs, which may not always be within the power of the people using them to modify, which are not compatible with other naming conventions. As far as default - I'll just say that I wouldn't be pleased to have a script break under me because of a change from 'eth0' to 'ens0' or 'enp1s1' on a system which only _has_ one network device. On desktop systems, at least, such systems are by far the most common case - and while network-device references in scripts not shipped by packages may not be terribly common on such systems, I still don't think it's a good idea to break the ones which do exist. Actually, when rebooting your (mission-critical) server, you can have a race condition where eth1 is not the interface that was eth1 on the previous boot and rename5 is the interface that should be eth1. That's what needs to be fixed. Doing nothing won't fix that. I did not advocate doing nothing. I agree that having names change under one's feet is a bad thing. I simply think that a solution to this problem which breaks the interface-naming assumptions which have been in place for so long is quite likely to be, at least in some ways, a cure worse than the disease. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Proposal: enable stateless persistant network interface names
❦ 10 mai 2015 10:45 -0400, The Wanderer wande...@fastmail.fm : Do you speak about ifupdown? It's Debian only. eth* interfaces is not *nix at all since all BSD are using per-driver naming convention. Upon consideration, I suspect that I've been making - at least - the following three assumptions: * That ifupdown is essentially (in functionality if not in implementation) a set of wrappers around ifconfig, with a few additional scripts. Why not. * That ifconfig uses /etc/network/interfaces just as ifupdown does, and so would have the same interface-naming limitations. (I think this one was based in part on observation of real-world behavior.) ifconfig doesn't use /etc/network/interfaces. As far as I know, ifconfig doesn't use any configuration file. * That ifconfig has been the standard way of working with network interfaces for more-or-less as long as there _has_ been a standard userspace way of doing that. ifconfig is mostly unmaintained. The standard way to work with network interfaces on Linux is ip (unlike most *nix). Also ifconfig isn't able to see all IP addresses on a given interface. It has been safe to assume that wired interfaces will be named ethX, and wireless ones wlanX, for so long that that assumption is built into many existing procedures - both as implemented in code, and as implemented in human habits and practices. If that assumption is to be broken, IMO at minimum a multi-year explicit deprecation period (such as that used for Linux-kernel feature removal) would be appropriate. On Linux, wireless drivers have long used eth* names, except for some out-of-tree drivers. It was the introduction fo the MAC 802.11 soft layer (2.6.22+) that gradually switched drivers to use wlan* names. And this change was driver by driver, at each release without much publicity. Drivers not using the new framework to register themselves are still using eth* names (like the Prism54 full mac driver). I wasn't aware of the specifics of the shift; acknowledged. That would simply strengthen the argument for its having been safe to assume the ethX naming, though, at least as much as it weakens the argument for its having been safe to assume the wlanX naming. The point is that Linux did change the prefix without any prior warning. The world is still running despite this change. I'll note that I've also seem some proprietary (but mission-critical) software which hardcodes interface names in some places; for example, older versions of Novell ZENworks' system-imaging utility would crash when attempting to multicast on a machine with an interface named em1 and no interface named eth0, reporting an inability to get the MAC address. This thread is about changing the default naming convention for network interfaces. If you love to run an unmaintained version of Novell ZENworks, you can still have an eth0 interface if you want. Where do you get unmaintained from? And my point was not about that one specific program; I was just using it as an example to indicate that there do exist important programs, which may not always be within the power of the people using them to modify, which are not compatible with other naming conventions. Your key example is an old version of a proprietary software that nobody ever heard of. Great example. Actually, when rebooting your (mission-critical) server, you can have a race condition where eth1 is not the interface that was eth1 on the previous boot and rename5 is the interface that should be eth1. That's what needs to be fixed. Doing nothing won't fix that. I did not advocate doing nothing. I agree that having names change under one's feet is a bad thing. I simply think that a solution to this problem which breaks the interface-naming assumptions which have been in place for so long is quite likely to be, at least in some ways, a cure worse than the disease. The disease is that actual servers running actual free software can break at each boot because we cannot have both a persistent naming scheme and use the eth* prefix is worse that the cure because old versions of Novell ZENworks may stop to work on upgrade? Seriously. -- Terminate input by end-of-file or marker, not by count. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
Re: Proposal: enable stateless persistant network interface names
❦ 10 mai 2015 08:20 -0400, The Wanderer wande...@fastmail.fm : Were you actually using ifupdown to manage the varied set of wireless networks? Because if not, then the name shouldn't matter. Yes, I’m using ifupdown. Besides USB NICs don’t have to be WiFi. Lots of people are, and it's inappropriate and IMO a bad idea to just assume that you can safely break what was once and may very well still be the single most widely-used method of controlling network interfaces under *nix. Do you speak about ifupdown? It's Debian only. eth* interfaces is not *nix at all since all BSD are using per-driver naming convention. It has been safe to assume that wired interfaces will be named ethX, and wireless ones wlanX, for so long that that assumption is built into many existing procedures - both as implemented in code, and as implemented in human habits and practices. If that assumption is to be broken, IMO at minimum a multi-year explicit deprecation period (such as that used for Linux-kernel feature removal) would be appropriate. On Linux, wireless drivers have long used eth* names, except for some out-of-tree drivers. It was the introduction fo the MAC 802.11 soft layer (2.6.22+) that gradually switched drivers to use wlan* names. And this change was driver by driver, at each release without much publicity. Drivers not using the new framework to register themselves are still using eth* names (like the Prism54 full mac driver). You may switch the the naming scheme in virtual environments, but only here. SLES is using some strange interface names like em1 or p1p2, but I hate it. I prefer my eth0 name. I'll note that I've also seem some proprietary (but mission-critical) software which hardcodes interface names in some places; for example, older versions of Novell ZENworks' system-imaging utility would crash when attempting to multicast on a machine with an interface named em1 and no interface named eth0, reporting an inability to get the MAC address. This thread is about changing the default naming convention for network interfaces. If you love to run an unmaintained version of Novell ZENworks, you can still have an eth0 interface if you want. Actually, when rebooting your (mission-critical) server, you can have a race condition where eth1 is not the interface that was eth1 on the previous boot and rename5 is the interface that should be eth1. That's what needs to be fixed. Doing nothing won't fix that. -- Make your program read from top to bottom. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
Re: Proposal: enable stateless persistant network interface names
On Sun, May 10, 2015 at 07:09:41PM +0200, Marc Haber wrote: On Sun, 10 May 2015 17:11:03 +0200, Vincent Bernat ber...@debian.org wrote: The disease is that actual servers running actual free software can break at each boot because we cannot have both a persistent naming scheme and use the eth* prefix is worse Just for the record, an unexpected interface name change hasn't happened in my professional career in more than ten years. Plugging persistent network naming with -this- imminent danger destroys the pro-faction's credibility. Same here. I have never seen unexpected interface changes. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Proposal: enable stateless persistant network interface names
Marvin Renich wrote: * Martin Pitt mp...@debian.org [150509 05:27]: 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. I disagree that stable interface names do not matter for USB adaptors for consumer laptops. I have owned two laptops where the on-board WiFi adaptor was too new to have reliable Linux drivers until 6-12 months after I purchased them. While waiting for the Linux drivers, I used a USB WiFi dongle that has good kernel support. I have plugged the adaptor into different USB ports based on where my laptop was situated wrt varied surroundings. I suspect (with no real data to back it up) that the biggest use of USB WiFi dongles on consumer machines is when the on-board WiFi doesn't work for some reason (too new or broken). In this case, it is often the main internet connection and a stable name is important. Why? What does a stable name matter in the case you mentioned? Were you actually using ifupdown to manage the varied set of wireless networks? Because if not, then the name shouldn't matter. It doesn't seem that difficult to change the NamePolicy for that case. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150509213628.GA16843@x
Re: Proposal: enable stateless persistant network interface names
* Martin Pitt mp...@debian.org [150509 05:27]: 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. I disagree that stable interface names do not matter for USB adaptors for consumer laptops. I have owned two laptops where the on-board WiFi adaptor was too new to have reliable Linux drivers until 6-12 months after I purchased them. While waiting for the Linux drivers, I used a USB WiFi dongle that has good kernel support. I have plugged the adaptor into different USB ports based on where my laptop was situated wrt varied surroundings. I suspect (with no real data to back it up) that the biggest use of USB WiFi dongles on consumer machines is when the on-board WiFi doesn't work for some reason (too new or broken). In this case, it is often the main internet connection and a stable name is important. To address the statement about swapping a new adaptor for a broken adaptor (in server or client desktop), this happens so rarely and already requires a significant effort (opening the machine, etc.) that editing the udev persistent network rules is not an issue. This does not make MAC-based names less usable in that context. I'm not sure what the correct solution is, but from what I have seen in this thread, I have become convinced that [ifnames] is not it. (That is a change from my initial perception.) I would like to discourage the proposed change. Perhaps some compromise where ifnames is used for PCI-based devices and MAC is used for USB devices might work; I'm not sure. I have no problem with learning a new naming convention for the devices. Note that the naming convention makes no difference for programmatic use; any programmatic use should query the specific properties of the device that are important to the program. The naming convention is only relevant to the sysadmin, where it helps to identify properties in which the sysadmin might be interested (e.g. wired vs wireless). ...Marvin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150509203542.ga18...@basil.wdw
Re: Proposal: enable stateless persistant network interface names
* Josh Triplett j...@joshtriplett.org [150509 17:37]: Marvin Renich wrote: I disagree that stable interface names do not matter for USB adaptors for consumer laptops. I have owned two laptops where the on-board WiFi adaptor was too new to have reliable Linux drivers until 6-12 months after I purchased them. While waiting for the Linux drivers, I used a USB WiFi dongle that has good kernel support. I have plugged the adaptor into different USB ports based on where my laptop was situated wrt varied surroundings. I suspect (with no real data to back it up) that the biggest use of USB WiFi dongles on consumer machines is when the on-board WiFi doesn't work for some reason (too new or broken). In this case, it is often the main internet connection and a stable name is important. Why? What does a stable name matter in the case you mentioned? Were you actually using ifupdown to manage the varied set of wireless networks? Because if not, then the name shouldn't matter. It doesn't seem that difficult to change the NamePolicy for that case. Yes, I use ifupdown and wpasupplicant. Based on some of the threads on this list there are many people who love Network Manager and many who dislike it. I am one of the ones who dislike it. Given the fact that it is (or at least was recently) clearly controversial, choosing a path that relies on its use seems detrimental to me, regardless of whether it is the default or not. ...Marvin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150510003557.gb18...@basil.wdw
Re: Proposal: enable stateless persistant network interface names
On Sat, May 9, 2015 at 2:36 PM, Josh Triplett j...@joshtriplett.org wrote: Marvin Renich wrote: * Martin Pitt mp...@debian.org [150509 05:27]: 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. I disagree that stable interface names do not matter for USB adaptors for consumer laptops. I have owned two laptops where the on-board WiFi adaptor was too new to have reliable Linux drivers until 6-12 months after I purchased them. While waiting for the Linux drivers, I used a USB WiFi dongle that has good kernel support. I have plugged the adaptor into different USB ports based on where my laptop was situated wrt varied surroundings. I suspect (with no real data to back it up) that the biggest use of USB WiFi dongles on consumer machines is when the on-board WiFi doesn't work for some reason (too new or broken). In this case, it is often the main internet connection and a stable name is important. Why? What does a stable name matter in the case you mentioned? Were you actually using ifupdown to manage the varied set of wireless networks? Because if not, then the name shouldn't matter. Does networkd handle this situation well? -- Cameron Norman -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/calzwfr+xo1f7iirx67r51xwsjwivahdoopbrqewqq2zwhhs...@mail.gmail.com
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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6H9WPNm-OwDqA3a7UGkbJzobjr-y=ckj_rdzn4sp9n...@mail.gmail.com
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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150509094446.gc3...@piware.de
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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/554dbc0f.3070...@p10link.net
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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150509092614.gb3...@piware.de
Re: Proposal: enable stateless persistant network interface names
On Fri, 08 May 2015 21:54:11 +0300, Timo Juhani Lindfors timo.lindf...@iki.fi wrote: Marc Haber mh+debian-de...@zugschlus.de writes: Btw, why the expletive is the only way to configure this the kernel command line and no configuration inside /etc where one would expect it? Maybe because udev is started from initramfs before the root filesystem has been mounted? In other packages, update-initramfs acts on configuration and builds the initramfs accordingly. I find that vastly more elegant and much less error-prone. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yqytn-j6...@swivel.zugschlus.de
Re: Proposal: enable stateless persistant network interface names
On Fri, 8 May 2015 07:59:31 +0200, Martin Pitt mp...@debian.org wrote: 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. I have tried this just last week and have found it kind of unsatisfactory that it doesn't work in virtualized environments. For example, in a KVM VM with virtio ethernet, the network devices still end up in the system as eth0, eth1, eth2. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yqcam-0002wa...@swivel.zugschlus.de
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
Proposal: enable stateless persistant network interface names
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 system-image, and stops the woes cloud providers have with Ubuntu's [mac]. I'm happy to ship a commented example udev rule that shows how to configure your own names, if you want to continue using MAC based schemas, or call your interfaces internet and intranet or the like. This makes it easier to see how to do custom naming than having to start from scratch. For upgrades: As we don't know what refers to existing stable network names, we can't ever safely remove a generated /etc/udev/rules.d/70-persistent-net.rules. So when we do the above, names on existing installations will *not*
Re: Proposal: enable stateless persistant network interface names
Marc Haber wrote: On Fri, 8 May 2015 07:59:31 +0200, Martin Pitt mp...@debian.org wrote: 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. I have tried this just last week and have found it kind of unsatisfactory that it doesn't work in virtualized environments. For example, in a KVM VM with virtio ethernet, the network devices still end up in the system as eth0, eth1, eth2. As I understand it, that's intentional and expected, for two reasons. First, because on a virtual machine, the network interfaces are likely to be more stable, always showing up with the same numbers. And second, because there's little else to go on when naming them. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150508072843.GA5466@x
Re: Proposal: enable stateless persistant network interface names
Martin Pitt wrote: 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 system-image, and stops the woes cloud providers have with Ubuntu's [mac]. I'm happy to ship a commented example udev rule that shows how to configure your own names, if you want to continue using MAC based schemas, or call your interfaces internet and intranet or the like. This makes it easier to see how to do custom naming than having to start from scratch. For upgrades: As we don't know what refers to existing stable network names, we can't ever safely remove a generated /etc/udev/rules.d/70-persistent-net.rules. So when we do the above, names on existing installations will *not* change (as 70-persistent-net.rules trumps [ifnames]). 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). Opinions? 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). - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150508073356.GA5497@x
Re: Proposal: enable stateless persistant network interface names
On Fri, 8 May 2015 00:28:44 -0700, Josh Triplett j...@joshtriplett.org wrote: Marc Haber wrote: I have tried this just last week and have found it kind of unsatisfactory that it doesn't work in virtualized environments. For example, in a KVM VM with virtio ethernet, the network devices still end up in the system as eth0, eth1, eth2. As I understand it, that's intentional and expected, for two reasons. First, because on a virtual machine, the network interfaces are likely to be more stable, always showing up with the same numbers. And second, because there's little else to go on when naming them. That would mean changing local code to _both_ handle en* and eth*, which is (a) a surprise and (b) unsatisfying in _my_ personal opinion. I'd rather have it fully and consistently or not at all. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yqfgq-0004g4...@swivel.zugschlus.de
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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150508104039.gf12...@piware.de
Re: Proposal: enable stateless persistant network interface names
On Fri, 8 May 2015 00:33:58 -0700, Josh Triplett j...@joshtriplett.org wrote: 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). How about adding net.ifnames=0 explicitly on installation, thus keeping the system bootable, with the documentation that the configuration change should be (a) manually and (b) atomically? It's fine with me to have net.ifnames=1 by default. Btw, why the expletive is the only way to configure this the kernel command line and no configuration inside /etc where one would expect it? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yqfio-0004gr...@swivel.zugschlus.de
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). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150508130812.08ca75acabcaa262ccf9f...@domain007.com
Re: Proposal: enable stateless persistant network interface names
Tollef Fog Heen wrote: ]] Marc Haber That would mean changing local code to _both_ handle en* and eth*, which is (a) a surprise and (b) unsatisfying in _my_ personal opinion. By en*, you mean emN, enN, pXpY all, right? Or more generally anything that enumerates as a network device. It's entirely possible to ask what kind of network device is this, so if your local code is trying to find wired Ethernet devices, it should be enumerating all devices and looking for those that are wired. Remember way back in the day when some wireless devices showed up as ethN too, and some things got confused when they became wlanN? What's your local code trying to do? - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150508144750.GA6807@x
Re: Proposal: enable stateless persistant network interface names
On Fri, 08 May 2015 15:11:06 +0200, Tollef Fog Heen tfh...@err.no wrote: ]] Marc Haber That would mean changing local code to _both_ handle en* and eth*, which is (a) a surprise and (b) unsatisfying in _my_ personal opinion. By en*, you mean emN, enN, pXpY all, right? yes. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yqjv0-0006t7...@swivel.zugschlus.de
Re: Proposal: enable stateless persistant network interface names
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. 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. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150508174201.GA3687@jtriplet-mobl1
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
Re: Proposal: enable stateless persistant network interface names
On Fri, 8 May 2015 10:50:30 -0700, Josh Triplett j...@joshtriplett.org 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. Do we have other network software other than ifupdown, systemd-networkd and network-manager, the latter handling dynamic names rather ungracefully. 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, purely udev-based method with persistent net generator foo will note the MAC address of the USB interface and make sure that it always gets the same ethX name. It is even possible to hand-edit 70-persistent-net.rules and make it come up as usbeth0, regardles of the port it is being plugged in. Greetings Marc, seeing Karsten's point -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yqmn1-00052e...@swivel.zugschlus.de
Re: Proposal: enable stateless persistant network interface names
Marc Haber wrote: On Fri, 8 May 2015 10:50:30 -0700, Josh Triplett j...@joshtriplett.org 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. Do we have other network software other than ifupdown, systemd-networkd and network-manager, the latter handling dynamic names rather ungracefully. wicd (to the best of my knowledge; I haven't used it), connman... Pretty much everything other than ifupdown and tools built on or integrating with ifupdown doesn't care what you name your network interfaces. Also, what do you mean by NetworkManager handling dynamic names ungracefully? Every time I've used it, it seems to handle any device I throw at it just fine. I can plug in a wired or wireless network device it has never seen before, and a few seconds later have a connection through that device. (This isn't meant as a works for me, not a bug; I'd like to know what issue you've observed.) The only case I can think of where NetworkManager might not DTRT would be if it's hamstrung by the ifupdown plugin and some statically defined networks in /etc/network/interfaces. 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, purely udev-based method with persistent net generator foo will note the MAC address of the USB interface and make sure that it always gets the same ethX name. It is even possible to hand-edit 70-persistent-net.rules and make it come up as usbeth0, regardles of the port it is being plugged in. You're right, sorry. I was comparing ifnames to a lack of persistent naming. However, MAC-based persistent naming has many problems of its own. For instance, I've replaced USB network devices on headless systems and found the new one ignored (and had to log in at the console to disable MAC-based persistent naming). I've moved USB drives between systems, and had to disable MAC-based persistent naming on them. ifnames also makes it possible to use a truly read-only, stateless root filesystem shared between many systems, without requiring differences due to network MAC addresses. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150508183643.GA7419@jtriplet-mobl1
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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150508192903.GA9363@cloud
Re: Proposal: enable stateless persistant network interface names
On Fri, 8 May 2015 11:36:44 -0700, Josh Triplett j...@joshtriplett.org wrote: Also, what do you mean by NetworkManager handling dynamic names ungracefully? I just remember having horrible trouble. Otherwise I would have filed a bug report. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yqpp5-0007ap...@swivel.zugschlus.de
Re: Proposal: enable stateless persistant network interface names
Am 08.05.2015 um 18:31 schrieb 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. 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. ifnames is rather flexible. You can also use NamePolicy=mac [1] if you prefer. Cheers, Michael [1] http://www.freedesktop.org/software/systemd/man/systemd.link.html#NamePolicy= -- 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: 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
Marc Haber mh+debian-de...@zugschlus.de writes: Btw, why the expletive is the only way to configure this the kernel command line and no configuration inside /etc where one would expect it? Maybe because udev is started from initramfs before the root filesystem has been mounted? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/847fsij3xo@sauna.l.org
Re: Proposal: enable stateless persistant network interface names
On Fri, 8 May 2015 13:33:06 -0700, j...@joshtriplett.org wrote: There are much better alternatives for most common cases. For example being? Greetings Ma iptables --table INPUT --interface eth+ --jump REJECT rc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yqpr5-0007ai...@swivel.zugschlus.de
Re: Proposal: enable stateless persistant network interface names
❦ 8 mai 2015 23:03 +0200, Marc Haber mh+debian-de...@zugschlus.de : There are much better alternatives for most common cases. For example being? firewalld works nicely nowadays. You assign different level of security to different networks. When I dock my laptop, network manager configures the network interface and firewalld attach it to the work zone. When on the road, I am using the public profile for wired and wireless connections and at home, when I connect my wireless network, I use the home profile. So, I just do absolutely nothing, network-manager and firewalld handles that transparently. However, notice that it is still pretty young. I had in the past many occurrences where firewalld didn't start correctly (so no firewall). It doesn't happen anymore since quite some time. -- Use free-form input when possible. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
Re: Proposal: enable stateless persistant network interface names
]] Marc Haber That would mean changing local code to _both_ handle en* and eth*, which is (a) a surprise and (b) unsatisfying in _my_ personal opinion. By en*, you mean emN, enN, pXpY all, right? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m2bnhvmcyd@rahvafeir.err.no
Re: Proposal: enable stateless persistant network interface names
On Fri, 2015-05-08 at 12:41 +0200, Marc Haber wrote: On Fri, 8 May 2015 00:33:58 -0700, Josh Triplett j...@joshtriplett.org wrote: 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). How about adding net.ifnames=0 explicitly on installation, thus keeping the system bootable, with the documentation that the configuration change should be (a) manually and (b) atomically? [...] We don't currently have a way for packages to install kernel parameters that boot loaders should append to the command line. I think we should. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. signature.asc Description: This is a digitally signed message part
Re: Proposal: enable stateless persistant network interface names
On Fri, 8 May 2015 12:40:39 +0200, Martin Pitt mp...@debian.org wrote: I don't know whether it's possible to change the name while the interface is up and in use. It isn't. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yqgvr-0004jk...@swivel.zugschlus.de
Re: Proposal: enable stateless persistant network interface names
On Fri, May 08, 2015 at 10:04:36PM +0200, Karsten Merker wrote: On Fri, May 08, 2015 at 12:29:03PM -0700, j...@joshtriplett.org wrote: 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: 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. That is often very impractical - the logical way is often to have interface-based rules instead of address-based rules. This is particularly the case with laptops where the network topology on the outside interface changes very often and the only sensible way to specify rules is using the interface as designator. So use the interface name as the designator, then. If you really want to, you can turn on MAC-based naming with the new ifnames, with a one-line change to a configuration file. And for servers or routers (the common case for iptables usage), ifnames should provide quite stable names. Well, I think that running iptables on a laptop is also an absolutely common case, in particular as laptops are often running in foreign networks. iptables the underlying technology? Sure, absolutely. iptables directly, via fragile scripts that hard-code interface names? There are much better alternatives for most common cases. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150508203306.GA9714@cloud
