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, because for them it pays to invest in a pretty number. On the subject of interface (device) names, people who were never at risk of seeing changing names, do not care about it. They did not gain anything. They did lose something, which is the ability to remember this name. Just yesterday - and the reason I am writing this today - there was another user on some ubuntu IRC channel who said: "that's would be better because my wlan0 new name is like wlx00259c96cafb" There you have a real user who just got introduced to this scheme (because he upgraded to 16.04 having skipped 15.04/15.10). So on the topic of caring, I think you can very confidently state that: - most users do not care about this stability you have gotten them - most users when asked would probably say that they like the new naming scheme less You wanted to know about caring, this is caring for you. People do not care about the advancements you have made. For most people they are detriments, because even if you can attest that the benefits of pretty names are small, the benefits of this stability are zero. Zero. By definition, any amount of caring will be greater than that. PEOPLE DO NOT CARE about what you've "given" them. They don't care. They don't care about this stability. At all. They just don't care about it. They did not ask for it (even if they could have been asking for it) and they probably didn't want it, and now that they have it, it doesn't mean that they like it just because they are not vocally submitting bug reports about it. You say people do not care about those interface names. They care less about this new stability. Much less. Because it doesn't affect them. Now any user who does need to write a firewall suddenly does care. Any user who does need to use ifup/ifdown now and then, does care. Any user who does need to write NetworkManager scripts depending on interface, does care. My script stopped working from one host to the next because the names were not the same. The script depended on wlan0. I needed to change it to whatever. > 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. No, those stable names provide no benefit to the class of users you describe. You are creating a logical fallacy for yourself: 1. The people who benefit from stable names are those likely to care 2. Those who care would be ones to think about some mapping 3. Manual mapping would not be an issue for those who care about stable names. Whereas you say that the stable names are required for people who do not care or should not care. These are two disjunct groups of users. A. People who have no need for stability and do not configure their system B. People who have a need for stability and already configure their systems. Now you are creating this situation: C. People who have a need for stability do not need to configure their system D. People who have no need for stability, may need to do it regardless (or may want to do it regardless) because to them the change has been detrimental. But group C does not exist because they need to configure their systems anyway. You can dream of group C but they are irrelevant because the system does not exist that benefits from this stability and yet needs no configuration. >> 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. You can say that you want that, but this question was about what people want. This question was about dissecting the two quite disjunct groups of people with very different requirements (as per this scenario and topic) and different levels of skill and different needs in configuring their systems, and then seeing if the current default is actually a fair thing. If there is only 0.001% that benefit at a cost to 99.999% of people (just exaggerating, perhaps) then you might still say that is irrelevant because you want it, but why is what you want so important? Shouldn't it be about fairness for users? You try to downplay the cost to the average user saying that average user does not care about presentation and manual usability of a network interface name. That that average user would never want to write any script. Or manually configure an interface. That the average user also does not care about seeing something recognisable and understandable, which also helps in learning about the system and learning about Linux --- because these new names..... they do not lead to understanding, familiarity or knowledge. They make it harder to get to know the system as well. So what I am saying is that the practical advantage, no matter how noble, of a multi-NIC system that never gets in trouble... is indeed irrelevant or at least insignificant, considering that to those people that do get in trouble, the cost of fixing it is abysmally small. Yes it is a noble cause. No it does not matter in the grand scheme of things. Yes it would be helpful if this issue was solved for real. No the current solution does not improve the lives of people. For most people it worsens it. Even if they are not affected by it to any large degree, since the advantages are none, any amount of detriment will be felt. People do not like it, how hard is that to understand. Mr. Lennart Poettering himself has once uttered the words akin to "achieving the right technical solution in opposition to political objections". Such "dislike" is exactly what would be qualified in this case as "political objection". People dislike it, but we ignore them, because we know what's best for them. So you have three issues here: 1. The burden of configuring the system is now placed on users that do not need any advanced configuration. You say that they don't need to. You say that they don't care about it. But have you asked users? Have you done research? Have you put up questionaires? Have you asked questions such as "If it was easy to revert to the old scheme, would you do it?". Have you actually been *interested* in their opinions? 2. A non-configured system (as per configuration of firewall and routing roles) does not benefit from this stability. Only a configured system (most usually, manually) will benefit from the newfound stability. 3. The burden of fixing the issue for users that did need it, was not great. >> 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. But again that user with multiple NICs needs to configure anyway, and like Andrei said, this particular thing worked for most users. > 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. So who is paying you? Whom are you doing it for? What person is going to hold you responsible? What person requires this kind of sacrifice to the system? Why is it not an issue if the user wants to customize the names (I have told you why it is not easy or pleasant) -- but at the same time it is an issue if the system maintainer NEEDS to configure it to have a stable system? Nothing was stopping that system maintainer either. I agree that having this randomness is not nice. But fixing it no matter the cost, is not nice either. You say there is no cost. There is. You can only maintain this by downplaying the cost. And like Andrei said, the names are not predictable. That in itself is a cost --- of changing scripts, and making it impossible to remember the names. It is *NOT* easy to customize the names the way it is now, even if you could do it in 10 minutes, you first have to go online to search for it, then you need to find either MAC address or PCI location (apparently) and then you need to write a config file for every interface, there are no example files on disk in that directory, the only one that is available doesn't help, and you depend on the man page entirely, but no user is going to know about "systemd.network" so will have to try to find it online. You can say stuff about "udev properties" but this is incomprehensible. I do not even know how to find the persisent path. I have no freaking clue. I could look it up online, but I'm trying by myself. I have no clue. "enp3s0" is not a /dev/ device name. Ifconfig does not show anything useful. lspci might provide something I can use to construct it, but I'm not sure. "dmesg | grep enp3s0" confirms this, but I still need to manually construct the entire string. In my KInfoCenter the information is not shown either - MAC address is, but not PCI path. So I look online and find "udevadm info" -- but like I said, I don't know the device name to use. I execute "find /sys | grep enp3s0" and discover "/sys/devices/pci0000:00/0000:00:0a.0/0000:03:00.0/net/enp3s0". I also discover "/sys/class/net/enp3s0". Okay, finally. Now I can do "udevadm info /sys/class/net/emp3s0" and then finally there is my pci..... string. That took a while for a new user. First without prior knowledge it is impossible to know how to do "man systemd.link" to find the info. Then without much knowledge it is easy to find udevadm info. But. What about the device path. You need to find it using find and grep. You say it is easy to customize. It is not. If you have all the knowledge, yes. But what makes a system user-unfriendly is requiring lots of knowledge. So no I do not consider it well documented, or at least I could not find it. Meanwhile I don't even need it because I can turn the thing off. However, that is only documented online as far as I know. > 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. You are still talking about some minority. I consider myself a pretty proficient computer user. I do not know what enp3s0 means. Some of the wlan names are much worse. I'm a desktop user and it is not irrelevant for me. *Currently* I am not doing any scripting or advanced stuff which means that indeed I have not yet saw fit to rename it (turn it off) -- not because I didn't want to, but because of the effort required. NetworkManager has been buggy and I have had to resort to manual wpa_supplicant as well on a prior laptop. Even if it had no practical implications to date on this here system (just a regular desktop in a home LAN) I still wanted to change it, I still wanted to undo it. For instance, when I changed the DHCP server on my network, I have had to manually configure my interface. Now NetworkManager got in the way so I had to do it through NM regardless, but it would have been a lot more pleasant if it had been eth0. Scripts I write are more portable if this renaming is turned off. So I'm a bit of a "under the hood" person. The moment you take a single step under the hood, it becomes relevant. The moment you edit your connection per the NM applet, it becomes relevant. (The name is shown there and it is incomprehensible). You try to keep people from diving under the hood but this is not the reality of a Linux system. In Windows it is equally absurd that you have to write "Local Area Network Connection 1" or something similar to use the command line tools. And then in a different language version your script won't work because the names have been localized. "a location-based naming matches people's intuition a lot better than the old MAC-based enumeration from persistent-net-generator" There is probably no difference between what you do now, and using those PCI addresses. enp3s0 and emp3s1 and not going to be more intuitive than eth0 and eth1, if someone can count on those names. Yup the names will stay the same even if you take the first card out. Then enable it for those kinds of people, not for everyone. >> 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. First you say it is easy to change it if you want it. Then you say it is a strong assumption to say that multiple-NIC people will not have a hard time doing it. Which is it gonna be? When it's the people you don't care about, it is easy, but when it is the people you do care about, it is hard? Seems a rather flexible proposition, this. >> 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. First of all, it is not dangerous. Practically no one requires the stability you espouse. Second of all, it was not advice. If you read it as advice, it means you have a stake in users not being informed about certain things, or not getting certain ideas that you think would be bad for them. That's a bit the same thing as keeping people from "dangerous ideas" (forbidden books etc). In practice, it means you are going to censor certain thoughts or ideas, because they would cause people to choose differently. To any user who comes into the chat channels to complain about the new names, I advise them to turn it off. According to you, that would be dangerous. Yet there is no danger involved at all. They do not have multiple NICs and do not run important firewalls where important roles are defined in a business setting, where people run important junction points in important networks where nothing may go wrong, while at the same time having no network administrator skills at all. You seem to be protecting a certain kind of business where a certain kind of failure would be disastrous, and want to prevent any kind of mistake happening in that kind of environment at all costs. You want to prevent the situation where a system administrator forgets to make the change after having installed a new Linux system, configures his router or firewall and then ends up seeing disaster strike. In this situation, you judge the convenience cost to regular users to be irrelevant as to compared to the cost to a real "business" that would be impacted by say a data breach. Now someone is going to be looking for the one responsible, and you don't want it to be you. I mean, that's not lacking of sympathy ;-). >> 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. The point to begin with is that you need to know the name of "./udev/rules.d/80-net-setup-link.rules" and I am not even sure if it is the correct one - the name changed between systemd versions. Creating symlinks to /dev/null, putting stuff into a file you don't know what, or changing kernel parameters, all do not fall within the bounds of "easy to configure". Basically, it requires anyone that wants to do this, to search for it on the internet. And that might not even be easy to find for a casual user. It's not "easy to configure". At the very least distributions could prompt the choice to users - with full information, and not lies - and then see how many users would choose the new scheme. As it stands users are usually misinformed about security. Granted, if it actually *was* easy to turn off, it wouldn't be so much of an issue. But this depends on installation environments and GUI options, as well as not lying about the security risks. It is rare that a desktop OS would require the feature at all, but who knows. Personally? If I were to install Ubuntu or Kubuntu. I would want the system to be turned on, and then have the names mapped to "ethernet0" and "wireless0". That would be my preference. That is what I would like. It is more comprehensible than the old names. However, for the system to configure this by default: the names are not predictable!!!!. The installer would need to load a system where this renaming already happens, find the network interfaces, acquire their PCI bus IDs, then create a scheme for their mappings, and then put the configuration files for that in /etc/systemd/network. Then you would have a proper mapping by default, that is not as stable (if you actually remove a NIC) but it is stable as long as you keep the same amount of NICs available. Apparently this system was already in place and could have been used. This solves the security risk for the largest part, except for the fact that to those with the knowhow to discern, it is not actually "predictable". But why should it be. > 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. There is simply no naming schema that fits everyone's needs, so you pick the one that suits the 5%. "Every default we pick will have to be changed in some circumstance" -- I am glad you attest to that. Then limit the amount of times those circumstances occur? You have caused the majority of users to pay the price and the cost for a minority of users in which a certain "oops, forgot to configure" could be disastrous according to that business running that server, and not even that, but according to a certain perspective, a disaster could happen. One man's death is another man's bread, but apart from that. You (or the ones designing it) seem to have done a risk analysis. Risk is defined as chance of something happening times the cost if it did happen. So a cost of $10 with a risk of 100% for a billion users would amount to a cost of $10b anually, so to speak. A cost of $10b with a risk of 0.5% for a single user would amount to a cost of $50m anually, and if you make that 200 users, the number is the same. And it is really only meant to catch the scenario where an important computer with multiple interfaces (e.g. a kind of router, usually) has not received this necessary change, and now the reboot causes the entire system to fail, but it might fail in a way you do not notice. And for this you have caused all Linux systems to have changed, incomprehensible, and hard to use/understand/remember interface names. And the question has been whether that is a good trade-off, and whether a better trade-off would not be possible. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel