Re: Proposal v2: enable stateless persistant network interface names
Philip Hands dixit: So, is what you are asking for that rather than simply deleting 75-persistent-net-generator.rules, that it instead be moved to /usr/share/doc/udev/examples/ with a note suggesting that people not use it? That would be sufficient. Ideally add a note on how to use it (I see the new thing is in /lib/systemd (with a comment that the location is due to udev, not systemd- specific), not in /etc any more, so it clearly needs to be overridden somehow, as we cannot delete things from there as admin, except with a local diverson). Even more great would be to put into the note instead the situations when it should not be used, and the situations in which it is “probably” safe (including “I’ve been using it successfully on this particular hardware before” maybe), plus – admittedly – a remark on that the new thing is still probably better for many? most? users. bye, //mirabilos -- 15:39⎜«mika:#grml» mira|AO: mit XFree86® wär’ das nicht passiert - muhaha 15:48⎜thkoehler:#grml also warum machen die xorg Jungs eigentlich alles kaputt? :)15:49⎜novoid:#grml thkoehler: weil sie als Kinder nie den gebauten Turm selber umschmeissen durften? -- ~/.Xmodmap wonders… -- 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/pine.bsm.4.64l.1507222109460.27...@herc.mirbsd.org
Re: Proposal v2: enable stateless persistant network interface names
Thorsten Glaser t...@mirbsd.de writes: Simon McVittie dixit: You can still do this via manual configuration; as far as I understand Yes, but… * the current Debian-specific persistent-net-generator scheme pitti wants to drop this; however, this is where we usually do the manual renaming when needed. By all means, do your new thing, but don’t break things for the people who wish to continue using persistent-net-generator and for whom it works and who don’t have any problems with the problems it has you outlined a few weeks ago. (Heh. I sound like I’m repeating myself every year now…) tl;dr: Just keep persistent-net-generator, even discourage people from using it who don’t know what they’re doing, but don’t remove it. So, is what you are asking for that rather than simply deleting 75-persistent-net-generator.rules, that it instead be moved to /usr/share/doc/udev/examples/ with a note suggesting that people not use it? Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Proposal v2: enable stateless persistant network interface names
Simon McVittie dixit: You can still do this via manual configuration; as far as I understand Yes, but… * the current Debian-specific persistent-net-generator scheme pitti wants to drop this; however, this is where we usually do the manual renaming when needed. By all means, do your new thing, but don’t break things for the people who wish to continue using persistent-net-generator and for whom it works and who don’t have any problems with the problems it has you outlined a few weeks ago. (Heh. I sound like I’m repeating myself every year now…) tl;dr: Just keep persistent-net-generator, even discourage people from using it who don’t know what they’re doing, but don’t remove it. Thanks, //mirabilos -- emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;) Hallo, ich bin der Holger (Hallo Holger!), und ich bin ebenfalls ... pine-User, und das auch noch gewohnheitsmäßig (Oooohhh). [aus dasr] -- 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/pine.bsm.4.64l.1507212030590.12...@herc.mirbsd.org
Re: Proposal v2: enable stateless persistant network interface names
On 25/06/15 23:14, Philipp Kern wrote: On the other hand I'm more of a fan of actually naming interfaces by their purpose or external labeling. Makes for even less mental gymnastics. \-: You can still do this via manual configuration; as far as I understand it, nobody is proposing to take away the ability to rename interfaces to lan and wan, or whatever, selected on the basis of path, MAC address, driver or any other udev attribute, via udev rules analogous to those written out by persistent-net-generator. However, in the absence of manual configuration, *something* needs to happen, one of: * the kernel defaults (eth0, ... in arbitrary order) * the current Debian-specific persistent-net-generator scheme * one of the various ifnames schemes * different ifnames schemes depending on device type (as implemented in systemd = 220-5, which uses MAC-based IDs for USB and path-based for PCI) and there are some additional considerations that might not be obvious to some readers of this thread: * the default setup cannot use /var because that might be remote * the udev maintainers do not want the default to involve writing to /etc * each network device has exactly one name, and no aliases (kernel limitation) * renaming to ethN or wlanN, where N is a small integer, cannot work reliably regardless (because it can race with the kernel assigning the same ethN/wlanN name to different hardware; this is why ifnames never assigns names in that form) To some extent, all of this complexity is because network devices aren't device nodes in /dev, so they can't have aliases (symlinks) but must instead have precisely one name. udev has been able to introduce new disk naming schemes without breaking old ones, precisely because symlinks to disk device nodes work fine. S -- 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/558d1729.2070...@debian.org
Re: Proposal v2: enable stateless persistant network interface names
Am Mittwoch, den 03.06.2015, 12:01 +0200 schrieb Martin Pitt: The main objection in the discussion was that path based names aren't appropriate for USB based devices. I agree, so I change my proposal to use MAC based names for anything USB based. The names will look even worse as they include the MAC in hex (enx112233445566), but the two goals use MAC for these devices, don't maintain state files in /etc, and avoid any collisions don't leave room for much else. However, on a desktop you don't ever care about the device names, and higher-level firewall tools will also hide this. After all, we survived the step from /dev/sda1 to UUID=112233DEADBEEF... as well :-) How about adding a easy-to-type symlink for MAC named devices? Would that work? Then users could refer to a device by the persistent MAC name enx112233445566, but also could use a short name like eth2 (which might not be persistent). It would be similar to hard drives. I used UUIDs in /etc/fstab, but short names like /dev/sdb3 when calling mount on the command line. -- Benjamin Drung System Developer Debian Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 D - 10405 Berlin Email: benjamin.dr...@profitbricks.com URL: http://www.profitbricks.com Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 125506B. Geschäftsführer: Andreas Gauger, Achim Weiss. signature.asc Description: This is a digitally signed message part
Re: Proposal v2: enable stateless persistant network interface names
On Jun 25, Martin Pitt mp...@debian.org wrote: Unlike /dev nodes, network interfaces can't have aliases as far as I know. Am I missing anything? No. As is usual with udev, the people who do not understand how it works are always ready to propose solutions. -- ciao, Marco pgp5RW1jnlifi.pgp Description: PGP signature
Re: Proposal v2: enable stateless persistant network interface names
Hey Benjamin, Benjamin Drung [2015-06-25 12:44 +0200]: How about adding a easy-to-type symlink for MAC named devices? Would that work? Then users could refer to a device by the persistent MAC name enx112233445566, but also could use a short name like eth2 (which might not be persistent). It would be similar to hard drives. I used UUIDs in /etc/fstab, but short names like /dev/sdb3 when calling mount on the command line. Unlike /dev nodes, network interfaces can't have aliases as far as I know. Am I missing anything? 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 v2: enable stateless persistant network interface names
* Marco d'Itri m...@linux.it [150625 07:27]: On Jun 25, Martin Pitt mp...@debian.org wrote: Unlike /dev nodes, network interfaces can't have aliases as far as I know. Am I missing anything? No. As is usual with udev, the people who do not understand how it works are always ready to propose solutions. -- ciao, Marco I think what some people are missing in this discussion is the relative importance of two design goals. In the original message, one of the stated design goals was to eliminate the state file in /etc (or /var, which might be a better place for it). The obfuscated interface names are a direct result of attempting to achieve that goal. The goal that wasn't on the list, but should have been, was to have interface names that a human sysadmin could easily recognize, distinguish, and type _on the command line_. This goal is at least an order of magnitude (I think two orders of magnitude) more important than eliminating the state file. Think about it. Any program can deal with any name or naming convention. It doesn't matter whether the name is obfuscated or not. A human sysadmin, however, has a much easier time using eth2 than enx3c52ca. Binary ids are for programs; short, easy-to-use names are for humans. If the priority of the goals is realigned to make sense, then we must eliminate any solution that satisfies the no-state-file goal if it does not also satisfy the human-usable goal. If this brings us back to where we currently are, so be it. But please do not add significant cognitive burden on the humans who must use the interface names just to get rid of a state file. Eliminating the state file is not worth it. (I'm not saying that a solution that satisfies both can't be found, and if it is found, that's great. But the current proposal absolutely fails the human-usable goal.) ...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/20150625121612.gb3...@basil.wdw
Re: Proposal v2: enable stateless persistant network interface names
On Jun 25, Marvin Renich m...@renich.org wrote: If the priority of the goals is realigned to make sense, then we must eliminate any solution that satisfies the no-state-file goal if it does not also satisfy the human-usable goal. If this brings us back to where we currently are, so be it. But please do not add significant cognitive burden on the humans who must use the interface names just to get rid of a state file. Eliminating the state file is not worth it. Please read the precedent thread which explained why we cannot continue supporting the old mechanism. If the new names trouble you then you can just manually configure new ones. -- ciao, Marco pgpxJVBtfmJpT.pgp Description: PGP signature
Re: Proposal v2: enable stateless persistant network interface names
On Thu, 25 Jun 2015 13:26:54 +0200, m...@linux.it (Marco d'Itri) wrote: On Jun 25, Martin Pitt mp...@debian.org wrote: Unlike /dev nodes, network interfaces can't have aliases as far as I know. Am I missing anything? No. As is usual with udev, the people who do not understand how it works are always ready to propose solutions. Do you ever come without insults? 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/e1z8a9p-0001q6...@swivel.zugschlus.de
Re: Proposal v2: enable stateless persistant network interface names
[ sorry for replying late, I wasn't subscribed, but I read both threads and I hope I got the In-Reply-To / References right ] As someone with decent experience deploying RHEL/Centos and Debian on anything from ARM boards, through x86 desktops/servers (HP/IBM/Dell), IBM POWER, to IBM System Z (s390), I thought I'd share some thoughts. Please stop calling ifnames predictable or persistent, they are neither - the logic upon which the name changes is different, but that's it - in my experience, they're far less persistent than static udev rules. Also, don't assume everyone has access to a mouse to easily copy-paste the 12-character interface names, things like z/VM (x3270 term) don't even have screen clear support and typing the interface manually for the tenth time is very ... CAPTCHA-like. It doesn't matter how many excuses you make or how many managers you layer on top, interface names are a *frontend* and critical for any slightly complex network firewall setup (xtables/nftables) - think of a multihomed 30-VLAN-using VM host with 64 bridges, various containers, openvswitch, ... in a HA setup. You can't rely just on IP addresses and rp_filter, using interface names also vastly simplifies things, not mentioning ebtables. About the actual persistence or which approach is the best - the thing is that every setup is different. While the idea of biosdevname is nice and it mostly works, there are cases where it doesn't, so it's an invalid choice by design. Amongst others: * regular desktops are fine with PCI, BIOS or MAC addr * x86/ppc servers you service - MAC addr (more stable on reboots or network-unrelated hw changes) * servers you don't - PCI or MAC addr (depending on the person servicing it) * USB NICs - MAC addr * QEMU VMs - MAC addr (libvirt/cmdline assigns a static one) or PCI (specified on cmdline or in libvirt XML) * containers (Linux namespaces) - none (veth generates random MACs) or MAC addr (depending on management software) * simple ARM boards - MAC addr or none * z/VM - qeth ccwgroup magic (ifnames: enccw0.0.4100) * ... It kind of becomes clear that any consensus on PCI bus/slot/function/dev or MAC addr based numbering cannot be universally reached. The none above means don't mess with it - leave the kernel specified device name. This may sound crazy, but is actually the most universal and in a lot of cases the most user-friendly thing to do, especially on systems that change HW every time (live distros - dhclient eth0 is so much easier than ifnames) and/or systems that have just one NIC (simple ARM boards, most VMs, most containers, a lot of mass-deployed virtual cluster nodes, ...). In fact, I found that removing the generator when provisioning hundreds of identical single-NIC virtual systems simplified things a lot - the virtual hardware could be diverse changed over time and eth0 was always eth0 (no biosdevname-enforcing drivers, fortunately). Which kind of leaves us where we are now (in Debian) - the best persistence is achieved though udev rules, where you can even use multiple rules per one interface name to express OR relationships, with the generator creating a stable enough template until the sysadmin changes the iface names. None of the above is made impossible with ifnames, which are simply a new default for device names, but my issue is that *they aren't any better than the old system* in terms of persistence, they are actually worse in my experience. If you want static /etc, sure, use /var/lib/udev for the generated rules. If you find $setup with variable MAC addresses, but some persistent property, you can at least use it in the generator, whereas with ifnames, you don't (AFAIK) have much choice. The usability issue is not in using some generator (and fixing the race), but in the default names being *easy to use* for the user and the rename an optional operation whereas with enpff5d605a-c543-43fd-9777-0989f3879a2e it's pretty much mandatory. Disk (filesystem) UUIDs worked, because people could still use /dev/sda for fdisk. Not denying that ifnames can be useful in some scenarios (I can imagine a few), but should they be opt-out rather than opt-in? If you decide to use ifnames as default, please at least make renaming interfaces easier, like providing commented-out examples in the .rules file (in /etc or /usr/share/doc). Just my .. err, $2. Thanks for reading. -- 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/558c4fbe.3060...@redhat.com
Re: Proposal v2: enable stateless persistant network interface names
On Thu, Jun 25, 2015 at 08:16:12AM -0400, Marvin Renich wrote: Think about it. Any program can deal with any name or naming convention. It doesn't matter whether the name is obfuscated or not. A human sysadmin, however, has a much easier time using eth2 than enx3c52ca. Binary ids are for programs; short, easy-to-use names are for humans. While I agree that including the complete hex ID of a network interface isn't very user friendly, I also can't extract any value out of eth2 or em1 if there is more than one interface and (especially) more than one machine. So I usually resort to the MAC address in ip link. In which case not including part of the identifier makes for an additional roundtrip. On the other hand I'm more of a fan of actually naming interfaces by their purpose or external labeling. Makes for even less mental gymnastics. \-: Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Proposal v2: enable stateless persistant network interface names
On Thu, 2015-06-04 at 19:41, Michael Biebl wrote: Am 04.06.2015 um 10:10 schrieb Josselin Mouette: How about using only the last 3 bytes of the MAC? The probability of using, on the same system, *two or more* controllers from *different brands* with a collision in the last 3 bytes is nonexistent in practice. The clear benefit would be that 3 bytes / 6 hex digits are easy enough to remember in the short term memory when you need to type a command. 6 hex digits are also regularly used as short git references for that same reason. That's an interesting idea.I don't think though we should change the existing mac NamePolicy. After all, this naming policy could already be in use. Maybe introduce a new type, say mac-short ? Maybe I have unusual configuration but look at this: arya:~# ip link show 1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: lan: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000 link/ether 14:da:e9:ab:a4:e9 brd ff:ff:ff:ff:ff:ff 4: br0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether 14:da:e9:ab:a4:e9 brd ff:ff:ff:ff:ff:ff 10: kvm0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN mode DEFAULT group default qlen 500 link/ether 4a:f9:f8:e1:5a:7a brd ff:ff:ff:ff:ff:ff MAC address for lan and br0 are the same. lan is physical Ethernet interface and br0 is bridge interface. When I plug USB Ethernet adapter I have the next: arya:~# ip link show 1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: lan: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000 link/ether 14:da:e9:ab:a4:e9 brd ff:ff:ff:ff:ff:ff 4: br0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether 00:60:6e:00:48:1a brd ff:ff:ff:ff:ff:ff 10: kvm0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN mode DEFAULT group default qlen 500 link/ether 4a:f9:f8:e1:5a:7a brd ff:ff:ff:ff:ff:ff 16: usb: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000 link/ether 00:60:6e:00:48:1a brd ff:ff:ff:ff:ff:ff Now, USB Ethernet interface (usb) and bridge (br0) have the same MAC. I know that I made unusual config but anyway I think that the naming interface by using MAC (or part of it) is not good idea. Or I still live in the time when the interfaces have had real (i.e. human readable and easy to remember) names. -- Best regards -- 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/20150605085741.ga25...@arvanta.net
Re: Proposal v2: enable stateless persistant network interface names
On Jun 05, Milan P. Stanic m...@arvanta.net wrote: Now, USB Ethernet interface (usb) and bridge (br0) have the same MAC. This is not relevant, because virtual interfaces like br0 are not subject to renaming. -- ciao, Marco pgpfCA5WWp_SS.pgp Description: PGP signature
Re: Proposal v2: enable stateless persistant network interface names
Am 04.06.2015 um 10:10 schrieb Josselin Mouette: How about using only the last 3 bytes of the MAC? The probability of using, on the same system, *two or more* controllers from *different brands* with a collision in the last 3 bytes is nonexistent in practice. The clear benefit would be that 3 bytes / 6 hex digits are easy enough to remember in the short term memory when you need to type a command. 6 hex digits are also regularly used as short git references for that same reason. That's an interesting idea.I don't think though we should change the existing mac NamePolicy. After all, this naming policy could already be in use. Maybe introduce a new type, say mac-short ? -- 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 v2: enable stateless persistant network interface names
]] Stephan Seitz On Wed, Jun 03, 2015 at 12:01:34PM +0200, Martin Pitt wrote: However, on a desktop you don't ever care about the device names, and Of course you do. How will you use tcpdump or tshark without the device names? In most desktop setups a „tcpdump -i eth0” is the right command. `-i any` is quite often just as easy. -- 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/874mmoj9e7@xoog.err.no
Re: Proposal v2: enable stateless persistant network interface names
j...@debian.org wrote: How about using only the last 3 bytes of the MAC? The probability of using, on the same system, *two or more* controllers from *different brands* with a collision in the last 3 bytes is nonexistent in practice. The clear benefit would be that 3 bytes / 6 hex digits are easy enough to remember in the short term memory when you need to type a command. 6 hex digits are also regularly used as short git references for that same reason. Good suggestion, yes. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast. Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html -- 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/e1z0ssu-0007ry...@mail.einval.com
Re: Proposal v2: enable stateless persistant network interface names
At Wed, 3 Jun 2015 17:11:08 +0200, Stephan Seitz wrote: On Wed, Jun 03, 2015 at 12:01:34PM +0200, Martin Pitt wrote: However, on a desktop you don't ever care about the device names, and Of course you do. How will you use tcpdump or tshark without the device names? In most desktop setups a „tcpdump -i eth0” is the right command. I think people who know how to use tcpdump will also be able to type in ip addr to look up the device name they want to dump. Jeroen Dekkers -- 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/874mmnzzzu.wl-jer...@dekkers.ch
Re: Proposal v2: enable stateless persistant network interface names
Hi, Martin Pitt mp...@debian.org wrote: The main objection in the discussion was that path based names aren't appropriate for USB based devices. I agree, so I change my proposal to use MAC based names for anything USB based. The names will look even worse as they include the MAC in hex (enx112233445566), but the two goals use MAC for these devices, don't maintain state files in /etc, and avoid any collisions don't leave room for much else. How about using only the last 3 bytes of the MAC? The probability of using, on the same system, *two or more* controllers from *different brands* with a collision in the last 3 bytes is nonexistent in practice. The clear benefit would be that 3 bytes / 6 hex digits are easy enough to remember in the short term memory when you need to type a command. 6 hex digits are also regularly used as short git references for that same reason. -- 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/1433405437.10710.53.ca...@dsp0698014.postes.calibre.edf.fr
Re: Proposal v2: enable stateless persistant network interface names
Vincent Danjean [2015-06-03 12:43 +0200]: So, you can show a debconf note, try (or not) to migrate the file automatically, remove (or comment-out) the 70-persistent-net.rules, or ... but, please, do not write a preinst script that fails because the admin did not update its config before upgrading. Fair enough. We can just point out that this is an unsupported configuration in stretch+2. There is no way we can reliably migrate the whole system. One good solution would probably a new kind of scripts run by dpkg and apt *prior to any other things* (for all involved packages) to decide if the upgrade can run or not. But that would involve lots of change in apt/dpkg and I'm sure I do not oversee all the implications of such a proposal. Indeed, and this should probably also happen at a higher level (like Ubuntu's release-upgrader, which has extra pre/post hooks). 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/20150604093701.gb3...@piware.de
Re: Proposal v2: enable stateless persistant network interface names
Le 03/06/2015 12:59, Marco d'Itri a écrit : On Jun 03, Vincent Danjean vdanjean...@free.fr wrote: stretch+1 (or maybe +2): - Check existance/non-emptiness of /etc/udev/rules.d/70-persistent-net.rules in udev.preinst, Show critical debconf note, and refuse to upgrade No. It is always a real pain when a preinst script fails. This part is not negotiable, because: All is negotiable. It is a matter of what is less problematics. So, you can show a debconf note, try (or not) to migrate the file automatically, remove (or comment-out) the 70-persistent-net.rules, or ... but, please, do not write a preinst script that fails because the admin did not update its config before upgrading. None of these solutions is applicable: either the upgrade can continue or the network interfaces names will change with unpredictable consequences. I would *largely* prefer a debconf notice + question asked to retry (admin can fix in-between) or continue (admin will have to leave with consequence of interface rename) than having a dist-upgrade aborted in the middle of its way. I remember upgrades aborted due to dependencies between udev and the running kernel. It was really a mess when I forgot to upgrade the kernel at first (until, if I remember correctly, the abort was modified to big debconf warnings). One good solution would probably a new kind of scripts run by dpkg and apt *prior to any other things* (for all involved packages) to decide if the upgrade can run or not. But that This is more or less what apt does when apt-extracttemplates from apt-utils is available. You would have to ensure that the apt hook is available *before* dist-upgrade is run. To my knowledge, no dependency can ensure this. So, this hook would have to be imposed in strech so that strech+1 can use it. Anyway, I will be very pleased if you find a way to abort the upgrade before its begining (and not just before udev upgrade) 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/556f4c89.8040...@free.fr
Proposal v2: enable stateless persistant network interface names
Hello all, some 4 weeks ago I sent a first proposal to change persistent network interface naming away from our current /lib/udev/rules.d/75-persistent-net-generator.rules (which is inherently racy and doesn't apply to all virtualized environments) to udev's net.ifnames: https://lists.debian.org/debian-devel/2015/05/msg00170.html Thanks to the comments and followups! Based on that I updated the proposal. (Sorry for the delay..) Martin Pitt [2015-05-08 7:59 +0200]: 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). The main objection in the discussion was that path based names aren't appropriate for USB based devices. I agree, so I change my proposal to use MAC based names for anything USB based. The names will look even worse as they include the MAC in hex (enx112233445566), but the two goals use MAC for these devices, don't maintain state files in /etc, and avoid any collisions don't leave room for much else. However, on a desktop you don't ever care about the device names, and higher-level firewall tools will also hide this. After all, we survived the step from /dev/sda1 to UUID=112233DEADBEEF... as well :-) Proposal I propose to retire [mac], i. e. drop /lib/udev/rules.d/75-persistent-net-generator.rules and enable [ifnames] by default. Amendment: ... and ship a naming policy by default which uses MAC based names for USB. FYI, this will look like | $ cat /lib/systemd/network/01-mac-for-usb.link | [Match] | Path=*-usb-* | | [Link] | NamePolicy=kernel database mac onboard slot path | MACAddressPolicy=persistent It's easy enough to override/customize, see man systemd.link. (Despite the name, this is all udev; it doesn't depend on using systemd or networkd). This will of course also be included in the documentation. 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. Michael Biebl and I discussed that the other day. We plan to do that in steps: stretch: - Enable ifnames for new installations - Drop [mac] generator - Point out the transition/documentation in NEWS - Ship example rules to show how to use your own custom names stretch+1 (or maybe +2): - Check existance/non-emptiness of /etc/udev/rules.d/70-persistent-net.rules in udev.preinst, Show critical debconf note, and refuse to upgrade - Drop our hack to retry renames for a while (to mitigate the race) Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: Proposal v2: enable stateless persistant network interface names
Martin Pitt [2015-06-03 12:01 +0200]: | $ cat /lib/systemd/network/01-mac-for-usb.link | [Match] | Path=*-usb-* | | [Link] | NamePolicy=kernel database mac onboard slot path | MACAddressPolicy=persistent Sorry, that was an old version. We want this: NamePolicy=kernel database onboard mac I. e. prefer onboard names over mac, and never use slot/path based names for USB; the latter will hardly make a practical difference, but it's cleaner that way. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: Proposal v2: enable stateless persistant network interface names
Le 03/06/2015 12:01, Martin Pitt a écrit : stretch+1 (or maybe +2): - Check existance/non-emptiness of /etc/udev/rules.d/70-persistent-net.rules in udev.preinst, Show critical debconf note, and refuse to upgrade No. It is always a real pain when a preinst script fails. It is (nearly) ok when you upgrade only one package. But if you upgrade lots of packages, when the preinst script will fail, other packages will be in non-canonical state (unpacked but unconfigurated, etc.) and recovering from such a state is always really problematic. apt-get install -f can help but, I observed several times, the resolution is not necessarily the same as the one tried before, leading to new packages installed and, more problematic, other packages to be removed even if not expected initially. So, you can show a debconf note, try (or not) to migrate the file automatically, remove (or comment-out) the 70-persistent-net.rules, or ... but, please, do not write a preinst script that fails because the admin did not update its config before upgrading. One good solution would probably a new kind of scripts run by dpkg and apt *prior to any other things* (for all involved packages) to decide if the upgrade can run or not. But that would involve lots of change in apt/dpkg and I'm sure I do not oversee all the implications of such a proposal. Regards, Vincent - Drop our hack to retry renames for a while (to mitigate the race) 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/556eda66.9010...@free.fr
Re: Proposal v2: enable stateless persistant network interface names
On Jun 03, Vincent Danjean vdanjean...@free.fr wrote: stretch+1 (or maybe +2): - Check existance/non-emptiness of /etc/udev/rules.d/70-persistent-net.rules in udev.preinst, Show critical debconf note, and refuse to upgrade No. It is always a real pain when a preinst script fails. This part is not negotiable, because: So, you can show a debconf note, try (or not) to migrate the file automatically, remove (or comment-out) the 70-persistent-net.rules, or ... but, please, do not write a preinst script that fails because the admin did not update its config before upgrading. None of these solutions is applicable: either the upgrade can continue or the network interfaces names will change with unpredictable consequences. One good solution would probably a new kind of scripts run by dpkg and apt *prior to any other things* (for all involved packages) to decide if the upgrade can run or not. But that This is more or less what apt does when apt-extracttemplates from apt-utils is available. -- ciao, Marco pgpjkqAZNTbcx.pgp Description: PGP signature
Re: Proposal v2: enable stateless persistant network interface names
Am 03.06.2015 um 12:59 schrieb Marco d'Itri: On Jun 03, Vincent Danjean vdanjean...@free.fr wrote: stretch+1 (or maybe +2): - Check existance/non-emptiness of /etc/udev/rules.d/70-persistent-net.rules in udev.preinst, Show critical debconf note, and refuse to upgrade No. It is always a real pain when a preinst script fails. This part is not negotiable, because: So, you can show a debconf note, try (or not) to migrate the file automatically, remove (or comment-out) the 70-persistent-net.rules, or ... but, please, do not write a preinst script that fails because the admin did not update its config before upgrading. None of these solutions is applicable: either the upgrade can continue or the network interfaces names will change with unpredictable consequences. Does anyone remember how linux-base handled this when there was the /dev/hd* to /dev/sd* transition. Did it bail out if it failed to do the conversion? -- 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 v2: enable stateless persistant network interface names
On Wed, 2015-06-03 at 13:11 +0200, Michael Biebl wrote: Am 03.06.2015 um 12:59 schrieb Marco d'Itri: On Jun 03, Vincent Danjean vdanjean...@free.fr wrote: stretch+1 (or maybe +2): - Check existance/non-emptiness of /etc/udev/rules.d/70-persistent-net.rules in udev.preinst, Show critical debconf note, and refuse to upgrade No. It is always a real pain when a preinst script fails. This part is not negotiable, because: So, you can show a debconf note, try (or not) to migrate the file automatically, remove (or comment-out) the 70-persistent-net.rules, or ... but, please, do not write a preinst script that fails because the admin did not update its config before upgrading. None of these solutions is applicable: either the upgrade can continue or the network interfaces names will change with unpredictable consequences. Does anyone remember how linux-base handled this when there was the /dev/hd* to /dev/sd* transition. Did it bail out if it failed to do the conversion? It gave the option to retry conversion (assuming you manually fix something before answering) or to continue without automatic conversion. In that case the old kernel version would generally still be available as a fallback, whereas this is of course not true with udev. Ben. -- Ben Hutchings Editing code like this is akin to sticking plasters on the bleeding stump of a severed limb. - me, 29 June 1999 signature.asc Description: This is a digitally signed message part
Re: Proposal v2: enable stateless persistant network interface names
On Wed, Jun 03, 2015 at 12:01:34PM +0200, Martin Pitt wrote: However, on a desktop you don't ever care about the device names, and Of course you do. How will you use tcpdump or tshark without the device names? In most desktop setups a „tcpdump -i eth0” is the right command. higher-level firewall tools will also hide this. After all, we survived the step from /dev/sda1 to UUID=112233DEADBEEF... as well :-) Well, but /dev/sda1 is still available. And I prefer /dev/sdaX because I have far less problems with it than with UUID=XXX. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: Digital signature
