Re: Proposal: enable stateless persistant network interface names
Marc Haber wrote: >On Fri, 8 May 2015 07:59:31 +0200, Martin Pitt >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
Bug#784730: ITP: golang-raven-go -- Go client for the Sentry event/error logging system
Package: wnpp Severity: wishlist Owner: Tim Potter * Package name: golang-raven-go Version : 0.0~git20150427 Upstream Author : Jonathan Rudenberg * URL : https://github.com/getsentry/raven-go * License : BSD Programming Lang: Go Description : Go client for the Sentry event/error logging system Go client for the Sentry event/error logging system. Sentry is a realtime, platform-agnostic error logging and aggregation platform. -- 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/20150508074414.8649.56909.report...@ozlabs.org
Bug#784731: ITP: golang-gocapability -- Utilities for manipulating POSIX capabilities in Go
Package: wnpp Severity: wishlist Owner: Tim Potter * Package name: golang-gocapability Version : 0.0~git20150507 Upstream Author : Suryandaru Triandana * URL : https://github.com/syndtr/gocapability * License : BSD Programming Lang: Go Description : Utilities for manipulating POSIX capabilities in Go Utilities for manipulating and checking POSIX capabilities in the Go language. -- 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/20150508075333.12807.45126.report...@ozlabs.org
Re: Proposal: enable stateless persistant network interface names
On Fri, 8 May 2015 00:33:58 -0700 Josh Triplett 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
On Fri, 8 May 2015 00:28:44 -0700, 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. 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 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 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 12:40:39 +0200, Martin Pitt 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
]] 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, 08 May 2015 15:11:06 +0200, 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? 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
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
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
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
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
On Fri, 8 May 2015 10:50:30 -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. 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 > 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
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 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
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, 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
Re: Proposal: enable stateless persistant network interface names
Marc Haber writes: > Btw, why the 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 11:36:44 -0700, Josh Triplett 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
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 : >>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
On Fri, 2015-05-08 at 12:41 +0200, Marc Haber wrote: > On Fri, 8 May 2015 00:33:58 -0700, Josh Triplett > 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, 08 May 2015 21:54:11 +0300, Timo Juhani Lindfors wrote: >Marc Haber writes: >> Btw, why the 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
