Re: [systemd-devel] Network Interface Names: solution for a desktop OS
On Mon, Apr 11, 2016 at 12:27:24AM +0200, Xen wrote: > Michael Biebl schreef op 11-04-16 00:22: > > So why don't you implement such a scheme? Talk is cheap > > Criticising an idea by saying "do it yourself" is even cheaper. > > MUCH MUCH cheaper. > > Idiot. No he isn't. The developers here put a lot of thought and energy working with numerous hardware requirements an user cases in order to come up with the current situation. It works for almost everyone, which is vastly better than the previous scheme of "first driver loaded wins!", which barely worked for anyone, and caused so many problems it wasn't funny (just ask any of us who have been in support for a distro about the problems...) If you have an alternative proposal, great, it can be fit into the existing system (note the heirachy of names that are picked depending on just how well your hardware describes itself.) Please propose that. If you don't like the current scheme, that's also fine, there is a trivial way to "opt-out" of it. So I don't understand your complaints, you don't like the current scheme, yet you don't have any proposal other than "I liked the original way", which you still have access to. So really, there isn't anything to change here that I can see, unless you have a new naming scheme that can be implemented as well? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Michael Biebl schreef op 11-04-16 00:22: > So why don't you implement such a scheme? Talk is cheap Criticising an idea by saying "do it yourself" is even cheaper. MUCH MUCH cheaper. Idiot. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
So why don't you implement such a scheme? Talk is cheap 2016-04-10 18:22 GMT+02:00 Xen : > I just want to present my conclusion here succintly. > > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ > > Was introduced to safeguard against a rare occasion where an important > network computer in a critical environment would suffer from the kernel > anomaly that assigned network interface names may be unreliable. > > In any system not configured by the system administrator to cater to > this issue, even simply forgetting to do it could result in some > security breach. > > This is how I read the issue today. The designers wanted to create > something that would never fail, and never cause this scenario to happen. > > But now all desktop users pay the price of having incomprehensible names > for their network devices, and all server administrators who like > writing scripts or defining firewalls have to deal with names that are > going to change from system to system. > > There is a solution to map the original hardware devices (not the new > names) to more meaningful names by manual choice. However, this is not > usually implemented and I do not know of any distribution that does this > by default. > > The solution requires the user to either know about the way to find help > (man systemd.link) or to look it up on the web (and know that systemd > causes it). Then he or she needs to create multiple files for each > interface containing either the hardware address (MAC) that is easy to > find, or the PCI bus address according to udev that is less easy to find. > > While many people would probably like a more comprehensible naming > scheme, the burden is now on each individual user to create it, while a > consensus on a regular scheme would not be hard to reach. > > For instance, calling wired internet devices "ethernet0" while wireless > ones would be called "wireless0" would not be an odd thing to do at all. > > So what I am simply calling for is for distributions to make a choice in > the names they want, and then to configure it by default. > > PCI hardware names can be mapped to predictable names, most likely. MAC > addresses could equally be used. > > The only thing to decide upon is the actual naming scheme. As said, > "ethernet#" and "wireless#" would be obvious. > > It wouldn't take more for a distribution's installer than to find these > devices and create mapping files based on them. > > The configuration with multiple files in /dev/systemd/network is not > easy, but for an installer that would not be an issue. The configuration > is not easily discoverable by any user traversing the filesystem, nor is > it intuitive to use multiple files for a single configuration but a > likelihood of a user needing to change it, would be very low. > > If you want systemd to make sense, you must make it easier for users. > > The names I propose would be easy to understand and contain no risk for > the scenario I described unless hardware is removed from a system (but > not put back). > > And it might not even have that issue. > > Comprehensibility increases legibility and it could even reduce the risk > of some administrator making mistakes. > > What it would create on a desktop OS is user-friendly names while having > scarcely any implication, or not at all, for the risk situation > described. PCI bus addresses could be used by default, or MAC addresses > if that was an issue. The kernel-based reordering as described would > never happen. > > And all it requires is for the current system to create a default > mapping that requires the installer of the system to do some work. > > And not much. > > So what I vouch for is a default mapping, that is all. > > A default mapping to names such as "wireless0" "ethernet0". People could > also think about renaming "lo" to "loopback". > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Network Interface Names: solution for a desktop OS
I just want to present my conclusion here succintly. https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ Was introduced to safeguard against a rare occasion where an important network computer in a critical environment would suffer from the kernel anomaly that assigned network interface names may be unreliable. In any system not configured by the system administrator to cater to this issue, even simply forgetting to do it could result in some security breach. This is how I read the issue today. The designers wanted to create something that would never fail, and never cause this scenario to happen. But now all desktop users pay the price of having incomprehensible names for their network devices, and all server administrators who like writing scripts or defining firewalls have to deal with names that are going to change from system to system. There is a solution to map the original hardware devices (not the new names) to more meaningful names by manual choice. However, this is not usually implemented and I do not know of any distribution that does this by default. The solution requires the user to either know about the way to find help (man systemd.link) or to look it up on the web (and know that systemd causes it). Then he or she needs to create multiple files for each interface containing either the hardware address (MAC) that is easy to find, or the PCI bus address according to udev that is less easy to find. While many people would probably like a more comprehensible naming scheme, the burden is now on each individual user to create it, while a consensus on a regular scheme would not be hard to reach. For instance, calling wired internet devices "ethernet0" while wireless ones would be called "wireless0" would not be an odd thing to do at all. So what I am simply calling for is for distributions to make a choice in the names they want, and then to configure it by default. PCI hardware names can be mapped to predictable names, most likely. MAC addresses could equally be used. The only thing to decide upon is the actual naming scheme. As said, "ethernet#" and "wireless#" would be obvious. It wouldn't take more for a distribution's installer than to find these devices and create mapping files based on them. The configuration with multiple files in /dev/systemd/network is not easy, but for an installer that would not be an issue. The configuration is not easily discoverable by any user traversing the filesystem, nor is it intuitive to use multiple files for a single configuration but a likelihood of a user needing to change it, would be very low. If you want systemd to make sense, you must make it easier for users. The names I propose would be easy to understand and contain no risk for the scenario I described unless hardware is removed from a system (but not put back). And it might not even have that issue. Comprehensibility increases legibility and it could even reduce the risk of some administrator making mistakes. What it would create on a desktop OS is user-friendly names while having scarcely any implication, or not at all, for the risk situation described. PCI bus addresses could be used by default, or MAC addresses if that was an issue. The kernel-based reordering as described would never happen. And all it requires is for the current system to create a default mapping that requires the installer of the system to do some work. And not much. So what I vouch for is a default mapping, that is all. A default mapping to names such as "wireless0" "ethernet0". People could also think about renaming "lo" to "loopback". ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: Random X crash on nvidia card on Gnome 3.20
Thanks guys, I'm just a noob and don't know where to go, just followed system log suggested links to here. On Sun, Apr 10, 2016 at 11:49 PM, Tomasz Torcz wrote: > > Bob, > > There is so much wrong with this email, I'll be brief: > – this is gnome-shell crashing, nothing related to systemd (and this is > systemd-devel) > - you are using binary nvidia drivers, which is nothing community can > help you with > - you are using this driver in unsupported configuration, which is > clearly communicated in attached log; so I think even nVidia won't > take your bug report. > > > -- > Tomasz TorczOnce you've read the dictionary, > xmpp: zdzich...@chrome.pl every other book is just a remix. > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: Random X crash on nvidia card on Gnome 3.20
On Sun, Apr 10, 2016 at 11:12:00PM +0800, Bob Peng wrote: > Today I upgraded to 3.20 and it begins random crash, log is attached. > and dmesg log too. This isn't a systemd issue, it's a nvidia issue, please contact them for support as they are the only ones that can do so because of their closed source kernel driver that you are using. best of luck, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: Random X crash on nvidia card on Gnome 3.20
Bob, There is so much wrong with this email, I'll be brief: – this is gnome-shell crashing, nothing related to systemd (and this is systemd-devel) - you are using binary nvidia drivers, which is nothing community can help you with - you are using this driver in unsupported configuration, which is clearly communicated in attached log; so I think even nVidia won't take your bug report. -- Tomasz TorczOnce you've read the dictionary, xmpp: zdzich...@chrome.pl every other book is just a remix. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames
Am 10.04.2016 um 16:57 schrieb Martin Pitt: Andrei Borzenkov [2016-04-10 11:31 +0300]: It had been working out of the box for quite a lot of users actually. Because we had a mechanism for stable (but not predictable) interfaces names, the 75-persistent-net-generator.rules thingy. Without either, the first time you plugged in a second card/USB dongle/add an ibmveth etc., chaos would start. that worked perfectly and chaos only started as it's funtionality went away while people knew how to use it nothing easier to handel than a single textfile with all mac/name mappings where any new interface appears on bottom and you can also leave the older entries for not present in case of removeable hardware signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames
Thank you Andrei and Reindl for your answers. Let's stick to the facts for the moment or as much of it as we can. Martin Pitt schreef op 10-04-16 10:17: > There are very good reasons for having a mechanism for stable names by > default. Most importantly, to keep your machine actually > booting/working .. when names suddenly move around and your server is > suddenly not online any more, or your firewall silently stops working, > this is a tad bad. :-) The fact is that not having this as a default would require a very small percentage of users to have to configure static ethX names, and the fact is that if they did not do this, they would land in trouble. The fact is also that these users need to configure their firewall and from my experience this is a much more challenging endeavour, or at least, is a task that requires some thinking and takes some time. The actual time spent on mapping the interfaces would be abysmally small in comparison. So much so as to make it negligible from the viewpoint of effort required. As Reindl Harald says: you have to configure them anyways, even if you had a ready-made firewall, you would still need to configure which device is going to fit which role or which zone or whatever. So zero-configuration from the viewpoint of a functioning system is a lie in this case anyway. There might be DHCP on one of the nics giving it automatic address and perhaps a route to the internet, but other than this nothing would happen to that if those device names would swap either. So in the old system, the system DID work out of the box given what a fresly installed system is capable of. That means that by default and in all cases the system worked out of the box given a default non-configured firewall and aspects surrounding it. It is only when you *would* configure a firewall or advanced routing between NICs that this ethX scheme would no longer function correctly out of the box. Perhaps while theoretically it would be preferable to have the least amount of configuration required for any system, currently you ARE trading configuration in one area for configuration in another. It is MY opinion that this tradeoff has increased the overall cost to all users combined. All of these are facts, including the last part where I state that it is my opinion. At the same time, I did propose a mechanism in which your current system would map onto meaningful and consistent and predictable names, but you did not respond to that suggestion. Meanwhile I was not fully aware of how unpredictable the names are. My current NIC is "enp3s0". I have no clue (I honestly don't remember) what it was on other systems. I do know that the wlan name was readily incomprehensible or could have been incomprensible. So again, the fact is: you are saving an abysmally small amount of configuration time for a very small subset of users that need to configure their system anyway in a larger extent than what you have saved them, by far. Whether that is a fair tradeoff is up for debate and what this thread is about. >> "Finally, many distributions support renaming interfaces to user-chosen >> names (think: "internet0", "dmz0", ...) keyed off their MAC addresses or >> physical locations as part of their networking scripts. This is a very >> good choice but does have the problem that it implies that the user is >> willing and capable of choosing and assigning these names." > > This isn't true -- having the option of customizing the names doesn't > mean that you *have* to do it. That's precisely why we must provide > some schema for stable names by default -- because the majority of > users does not care and should not *have* to care. That text came from the freedesktop website. That was official systemd parlance. And in fact, but I do not know: I think the majority of users do care or would care if you gave them the choice. Most people actually do like nice and pleasant names in their system, but whether they care enough to actually go and change it based on current difficulties in doing so depends entire on how easy it is to do that. You say: "That's precisely why we must provide some schema for stable names by default -- because the majority of users does not care and should not *have* to care." Most people would care less about stable names because to those people the old names were already stable. So indeed, they should not have to care, because they didn't and still don't for that matter. They don't care about stable names. That's like caring about whether your country code number will change. People don't care, because it will never change like that. Regular phone numbers might change and people care about its stability, yes. Sometimes they care about the numbers looking nice. They care about stability because number changes are an issue to most people. They care less about having pretty numbers because in a general sense they do not remember phone numbers and the ones that do care are usually companies,
Re: [systemd-devel] How to log to journald using fifo?
I would like to write to /dev/stderr and tried that but it didn’t work. I think it’s something to do with the way it works internally (nginx + phusion passenger). > On 11/04/2016, at 12:43 AM, Mantas Mikulėnas wrote: > > On Sun, Apr 10, 2016 at 1:57 PM, Samuel Williams > mailto:space.ship.travel...@gmail.com>> > wrote: > Hello, > > I've been trying to figure out the best way to support legacy applications > that don't support syslog for logging. The best we can do, I think, is to use > fifo and have another process read the fifo to journald. > > I made the following unit journald-fifo@.service > > [Unit] > Description=A fifo for logging to journald > AssertPathExists=/var/log/%i.fifo > > [Service] > Type=simple > ExecStart=/bin/sh -c 'while true; do systemd-cat -t %i < /var/log/%i.fifo; > done' > Nice=5 > > [Install] > WantedBy=multi-user.target > > I was wondering is this a good approach? Is there a better way? (of course, > we'd like to fix the original software to work better). > > If the software can log to stdout/stderr, just use that. If not, make it > write logs to "/dev/stderr". Either way, systemd will log service stdout > automatically. > > -- > Mantas Mikulėnas mailto:graw...@gmail.com>> ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Fwd: Random X crash on nvidia card on Gnome 3.20
Today I upgraded to 3.20 and it begins random crash, log is attached. and dmesg log too. Cheers 1] % dmesg [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.4.5-1-ARCH (builduser@tobias) (gcc version 5.3.0 (GCC) ) #1 SMP PREEMPT Thu Mar 10 07:38:19 CET 2016 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=407c80a5-9750-4e0e-9e7c-5b78d7fefe42 rw quiet [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers' [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. [0.00] x86/fpu: Using 'eager' FPU context switches. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable [0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xca77] usable [0.00] BIOS-e820: [mem 0xca78-0xca786fff] ACPI NVS [0.00] BIOS-e820: [mem 0xca787000-0xcabc9fff] usable [0.00] BIOS-e820: [mem 0xcabca000-0xcb15afff] reserved [0.00] BIOS-e820: [mem 0xcb15b000-0xdddacfff] usable [0.00] BIOS-e820: [mem 0xdddad000-0xdde42fff] reserved [0.00] BIOS-e820: [mem 0xdde43000-0xdde92fff] usable [0.00] BIOS-e820: [mem 0xdde93000-0xddfc7fff] ACPI NVS [0.00] BIOS-e820: [mem 0xddfc8000-0xdeffefff] reserved [0.00] BIOS-e820: [mem 0xdefff000-0xdeff] usable [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00021dff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.8 present. [0.00] DMI: MSI MS-7817/B85M-E45 (MS-7817), BIOS V10.9 04/21/2015 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x21e000 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-C write-protect [0.00] D-E7FFF uncachable [0.00] E8000-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 00 mask 7E write-back [0.00] 1 base 02 mask 7FF000 write-back [0.00] 2 base 021000 mask 7FF800 write-back [0.00] 3 base 021800 mask 7FFC00 write-back [0.00] 4 base 021C00 mask 7FFE00 write-back [0.00] 5 base 00E000 mask 7FE000 uncachable [0.00] 6 disabled [0.00] 7 disabled [0.00] 8 disabled [0.00] 9 disabled [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT [0.00] e820: update [mem 0xe000-0x] usable ==> reserved [0.00] e820: last_pfn = 0xdf000 max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000fd810-0x000fd81f] mapped at [880fd810] [0.00] Scanning 1 areas for low memory corruption [0.00] Base memory trampoline at [88097000] 97000 size 24576 [0.00] Using GB pages for direct mapping [0.00] BRK [0x01b3f000, 0x01b3] PGTABLE [0.00] BRK [0x01b4, 0x01b40fff] PGTABLE [0.00] BRK [0x01b41000, 0x01b41fff] PGTABLE [0.00] BRK [0x01b42000, 0x01b42fff] PGTABLE [0.00] BRK [0x01b43000, 0x01b43fff] PGTABLE [0.00] BRK [0x01b44000, 0x01b44fff] PGTABLE [0.00] RAMDISK: [mem 0x37926000-0x37c8afff] [0.00] ACPI: Early table checksum verification disabled [0.00] ACPI: RSDP 0x000F04A0 24 (v02 ALASKA) [0.00] ACPI: XSDT 0xDDF97080 84 (v01 ALASKA A M I01072009 AMI 00010013) [0.00] ACPI: FACP 0xDDFA6098 00010C (v05 ALASKA A M I01072009 AMI 00010013) [0.00] ACPI: DSDT 0xD
Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames
Andrei Borzenkov [2016-04-10 11:31 +0300]: > It had been working out of the box for quite a lot of users actually. Because we had a mechanism for stable (but not predictable) interfaces names, the 75-persistent-net-generator.rules thingy. Without either, the first time you plugged in a second card/USB dongle/add an ibmveth etc., chaos would start. > Again - configuring location based naming was pretty easy in the past. Again -- nothing changed wrt. manually configuring interface names if you desire so. > You need to explain why your new naming scheme is better than that. See "Why" on https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ Also, it's not "my" schema, but I do think it's a fairly good compromise between all the bad options how to do interface naming. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to log to journald using fifo?
On Sun, Apr 10, 2016 at 1:57 PM, Samuel Williams < space.ship.travel...@gmail.com> wrote: > Hello, > > > I've been trying to figure out the best way to support legacy applications > that don't support syslog for logging. The best we can do, I think, is to > use fifo and have another process read the fifo to journald. > > > I made the following unit journald-fifo@.service > > > [Unit] > > Description=A fifo for logging to journald > > AssertPathExists=/var/log/%i.fifo > > > [Service] > > Type=simple > > ExecStart=/bin/sh -c 'while true; do systemd-cat -t %i < /var/log/%i.fifo; > done' > > Nice=5 > > > [Install] > > WantedBy=multi-user.target > > I was wondering is this a good approach? Is there a better way? (of > course, we'd like to fix the original software to work better). > If the software can log to stdout/stderr, just use that. If not, make it write logs to "/dev/stderr". Either way, systemd will log service stdout automatically. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames
Am 10.04.2016 um 10:17 schrieb Martin Pitt: Any user running a system with multiple NICs should be willing and capable of choosing and assigning these names. To be frank, this is the attitude of the 90's when you had to sit down with a thick book and spend a week until your Linux system was up and running no - because you have to configure them anyways - multiple network interfaces don't know magically their roles to be frank the attitude above of the 2000's on single NIC systems (like most virtual machines) leads in *everybody* has to configure something if it comes to virtual servers and iptables rules while having just "eth0" as all the years before on such setups would be safe and make it possible to just re-use your existing scripts signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to log to journald using fifo?
Hello, I've been trying to figure out the best way to support legacy applications that don't support syslog for logging. The best we can do, I think, is to use fifo and have another process read the fifo to journald. I made the following unit journald-fifo@.service [Unit] Description=A fifo for logging to journald AssertPathExists=/var/log/%i.fifo [Service] Type=simple ExecStart=/bin/sh -c 'while true; do systemd-cat -t %i < /var/log/%i.fifo; done' Nice=5 [Install] WantedBy=multi-user.target I was wondering is this a good approach? Is there a better way? (of course, we'd like to fix the original software to work better). Finally, if this is a good approach, is this method worth putting into systemd/journald as a standard service? If so, how do I submit a PR or where to begin? Kind regards, Samuel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames
10.04.2016 11:17, Martin Pitt пишет: > Hello, > > Xen [2016-04-09 20:29 +0200]: >> 1. I believe most users do not like the "enp5s0" scheme >> 2. I do not think there are any good reasons for making it the default. > > There are very good reasons for having a mechanism for stable names by > default. Most importantly, to keep your machine actually > booting/working .. when names suddenly move around and your server is > suddenly not online any more, or your firewall silently stops working, > this is a tad bad. :-) > There was no problem having interface names based on PCI location before as well. So this is irrelevant. If PCI enumeration changes between reboot, your new names will change as well. >> "Finally, many distributions support renaming interfaces to user-chosen >> names (think: "internet0", "dmz0", ...) keyed off their MAC addresses or >> physical locations as part of their networking scripts. This is a very >> good choice but does have the problem that it implies that the user is >> willing and capable of choosing and assigning these names." > > This isn't true -- having the option of customizing the names doesn't > mean that you *have* to do it. That's precisely why we must provide > some schema for stable names by default -- because the majority of > users does not care and should not *have* to care. > >> What is really the amount of systems or proportion thereof that have >> multiple NICs? > > I actually think "most" (at least an ethernet and a wifi card), but > this question is also fairly irrelenvant -- even if it's just 5% we > still want those to function correctly. > Most of those users have single eth0 and single wlan0. So yes, from perspective of interface naming they have single NIC with given name pattern. >> Any user running a system with multiple NICs should be willing and >> capable of choosing and assigning these names. > > To be frank, this is the attitude of the 90's when you had to sit down > with a thick book and spend a week until your Linux system was up and > running. > It had been working out of the box for quite a lot of users actually. > If a user wants to customize the names, nothing stops them, and it's > well-documented how to do that. But that doesn't mean that we aren't > responsible for being correct and safe by default. > >> The new biosdev scheme is so meaningless that mostly any user WILL want >> to change this scheme to become something meaningful, but the obstacles >> to it are too great currently for the regular user. > > From my POV of a desktop-oriented developer and distro engineer who > sees a lot of bug reports -- "most users" don't care. It's totally > irrelevant on a desktop where the network is usually configured > dynamically (NetworkManager) and it's mostly irrelevant for virtual > environments which most of the time only have one network card which > the OS installer sets up by default. It is highly relevant for > embedded setups (think RasPi board) and servers with multiple NICs, > and there a location-based naming matches people's intuition a lot > better than the old MAC-based enumeration from > persistent-net-generator. > Again - configuring location based naming was pretty easy in the past. You need to explain why your new naming scheme is better than that. And the fact that it is mistakenly named "predictable" makes things no better, because it is anything else than predictable - please try to predict interface names on random system out there *before* you have installed Linux on it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames
Hello, Xen [2016-04-09 20:29 +0200]: > 1. I believe most users do not like the "enp5s0" scheme > 2. I do not think there are any good reasons for making it the default. There are very good reasons for having a mechanism for stable names by default. Most importantly, to keep your machine actually booting/working .. when names suddenly move around and your server is suddenly not online any more, or your firewall silently stops working, this is a tad bad. :-) > "Finally, many distributions support renaming interfaces to user-chosen > names (think: "internet0", "dmz0", ...) keyed off their MAC addresses or > physical locations as part of their networking scripts. This is a very > good choice but does have the problem that it implies that the user is > willing and capable of choosing and assigning these names." This isn't true -- having the option of customizing the names doesn't mean that you *have* to do it. That's precisely why we must provide some schema for stable names by default -- because the majority of users does not care and should not *have* to care. > What is really the amount of systems or proportion thereof that have > multiple NICs? I actually think "most" (at least an ethernet and a wifi card), but this question is also fairly irrelenvant -- even if it's just 5% we still want those to function correctly. > Any user running a system with multiple NICs should be willing and > capable of choosing and assigning these names. To be frank, this is the attitude of the 90's when you had to sit down with a thick book and spend a week until your Linux system was up and running. If a user wants to customize the names, nothing stops them, and it's well-documented how to do that. But that doesn't mean that we aren't responsible for being correct and safe by default. > The new biosdev scheme is so meaningless that mostly any user WILL want > to change this scheme to become something meaningful, but the obstacles > to it are too great currently for the regular user. From my POV of a desktop-oriented developer and distro engineer who sees a lot of bug reports -- "most users" don't care. It's totally irrelevant on a desktop where the network is usually configured dynamically (NetworkManager) and it's mostly irrelevant for virtual environments which most of the time only have one network card which the OS installer sets up by default. It is highly relevant for embedded setups (think RasPi board) and servers with multiple NICs, and there a location-based naming matches people's intuition a lot better than the old MAC-based enumeration from persistent-net-generator. > So we may have 5% or less of all systemd/linux networking users that > actually requires this. > The 5% or less that does require it is not the type of user that would > not be able to adjust the naming scheme. That's a rather strong assumption, and IMHO it's unnecessary to make. > Now you are causing 95% of users that really need to turn it off. This is not true, and a dangerous piece of advice to give to anybody. > At the very least create a configuration file where this is a simple > named option. And then, at the very least, don't turn it on by default. All of this is very easy to configure. In the end, the root cause of this is that Linux' handling of network devices is so completely different than just about every other device. For the latter (nodes in /dev) we can easily have aliases so that we can provide suitable names for every use case (by-serial, by-uuid, by-label, etc.), but this is impossible with network devices unfortunately. So there simply is no naming schema that fits everybody's needs, and every default that we pick will have to be changed in some circumstance. But I believe that the current one is a fairly safe, reasonable, and most importantly, *working* default, at the price of having to adjust to slighly "odd" names. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
