Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Monday January 21 2019, @07:14AM   Printer-friendly
from the their-way-or-the-highway dept.

Michael Biebl, long-time maintainer of systemd for Debian (2010 or earlier, based on changelog.Debian.gz), is taking undetermined holidays from packaging it. The e-mail was short:

Will stop maintaining systemd in debian for a while.

What's going on is just too stupid/crazy.

This takes place after he discussed a bug in which he expected systemd to respect local settings, and not rename network devices:

@yuwata a default policy like /lib/systemd/network/99-default.link should never trump explicit user configuration.

Later he seems surprised about how things roll there:

I'm amazed that I have to point this out....

The issue is locked currently, and also archived just in case, so everyone can read the initial report and the replies he got.

Opinion: It seems distribution developers are starting to get the stick too, not just users with their "errors" (taken from a reply). Will distributions finally wake up or is that they don't still grok the attitude of projects like this? [Or is it something else? --Ed.]


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Interesting) by PocketSizeSUn on Monday January 21 2019, @11:10AM (9 children)

    by PocketSizeSUn (5340) on Monday January 21 2019, @11:10AM (#789510)

    Really?
    To me it appears that Mr Biebl's notice on the mailing list is what prompted escalation of the issue and Pottering to consider that *maybe* breaking existing rules wasn't very nice .. but he really didn't seem all that concerned about it ... because the rule 'wasn't well written'.

    The fact remains that the rule in question follows the pattern of the rule in every example of 'how to rename Ethernet device names using udev' ... so breaking that is going to break a metric ton of machines.

    Full disclosure, I am not a fan Pottering or systemd.

    Starting Score:    1  point
    Moderation   +3  
       Interesting=2, Informative=1, Total=3
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 1, Informative) by Anonymous Coward on Monday January 21 2019, @03:32PM (8 children)

    by Anonymous Coward on Monday January 21 2019, @03:32PM (#789615)

    "break a metric ton of machines"

    Redhat already did that once before, or does nobody remember that interface names made sense before redhat fucked them up? Systemd is a trojan horse. It always was.

    I get that it is important to know bus location of a card. But what makes more sense, serializing the devices and symlinking the card/port names to them, or renaming every port on the box because "fuck you, we wrote it so you must comply with our custom"? The only devices that care about the slot are switches, routers and firewalls. Almost every other host just wants eth0 and eth1.

    Of course they knew that. The fact that they ignored it, is what tells you that they're malicious. Because it is harder to do it wrong, than it is to do it right. The way they did it made configuring interface scripts rediculous, and undoubtedly has resulted in fewer people actually making the effort to develop portable security policies. We aren't just talking about one line of bash here. We are talking about every network script on every box having to do interface discovery in order to be portable. That is quite literally thousands of lines of code that other people have to write because RH are dicks.

    It is the same shit that MS does, Debian developers should have known that the minute they saw the ini files.

    • (Score: 5, Informative) by jdccdevel on Monday January 21 2019, @06:59PM (7 children)

      by jdccdevel (1329) on Monday January 21 2019, @06:59PM (#789693) Journal

      I have some serious problems with systemd. The Logging facilities are atrocious, and the software is poorly documented, unintuitive, and non-deterministic in some instances. Mostly though, I dislike it because the lead developer is so arrogant he has no problems dumping decades of status quo built from hard-earned experience because he can't bother to take the time to understand why things were done that way.

      That said, changing the network device names from eth0, eth1, etc to something based on the hardware itself is a definite improvement, and I'll tell you why.

      The problem with the way cards were named before is that it isn't consistent. It would depend on what order your network drivers were loaded by the kernel, or at the whim of the driver developer. I've had network device names change with a kernel updates and OS updates before. I even had one situation where the device names on a 2-port card were seemingly randomly assigned at boot.

      I regularly work with machines that have 4 or more network interfaces, and having them re-shuffle for any reason is completely unacceptable, and has happened to me on more than one occasion.

      Now, most Distros use a dynamically written config file (part of UDev) that associates network device names (eth0, etc) with a particular device using MAC addresses. That works fine for most workstations, but what if a card dies in a server? The hardware MAC addresses are going to change when that card is replaced, and the old device won't exist any more.

      That will completely mess up the configuration on boot, since the new card will be assigned a new device number (ethY) and the old device (ethX) won't exist any more. Anything associated with ethX won't work anymore.

      Granted, that's a distro issue, and the developers could have fixed it using bus slot locations instead of MAC addresses, but what about other kinds of devices where their bus locations can be expected to change? (USB adapters, for example).

      In many respects, it's a trade off between easier for beginners to understand (eth0, etc), and easier to work with.

      However, for pretty much anything with two or more network interfaces, the new naming scheme is better. It's more predictable and consistent, which makes it easier to use. It has logical rules, so it doesn't need a "device name configuration file" written at boot. It's driver and kernel version agnostic too, which means I can swap network cards, and even change brands, and I don't have to change my configuration at all.

      About the only thing that the old convention is better at is copy/paste from the Internet, which is something I would never recommend without understanding what they do anyway.

      The new naming convention was created first, [wikipedia.org] for Very good reasons [freedesktop.org] prior to being implemented by systemd.

      TLDR: Of all of the changes made by systemd, predictable network names is, IMHO, the MOST justified. Probably because it wasn't Pottering's idea in the first place.

      PS: If you're writing network security scripts, or "Portable Security Policies" and can't be bothered to figure out how to make it device name agnostic, WTF are you doing writing "security scripts" in the first place? Seriously? Shell variables, Environment variables, SED, M4, Even Perl will fix that for you. If it takes more than 5 minutes to fix your script so it doesn't matter what the network names are, you're doing it wrong.

      • (Score: 0) by Anonymous Coward on Monday January 21 2019, @08:28PM (1 child)

        by Anonymous Coward on Monday January 21 2019, @08:28PM (#789749)

        PS: If you're writing network security scripts, or "Portable Security Policies" and can't be bothered to figure out how to make it device name agnostic, WTF are you doing writing "security scripts" in the first place? Seriously? Shell variables, Environment variables, SED, M4, Even Perl will fix that for you. If it takes more than 5 minutes to fix your script so it doesn't matter what the network names are, you're doing it wrong.

        Can you elaborate on how to make network scripts device name agnostic? Please and thank you...

        • (Score: 3, Interesting) by jdccdevel on Monday January 21 2019, @11:46PM

          by jdccdevel (1329) on Monday January 21 2019, @11:46PM (#789851) Journal

          The question real is, What is the purpose of the script?

          I assume you're talking about the simple example, where there's only one interface connected?

          All you need to do is find out which link is connected, put that name in a shell variable, and replace "eth0" with the variable holding the device name ("${edev}" for example...)

          Something like this bash script should work fine, even if you have multiple connected interfaces. (Off the top of my head so please forgive any bugs. This assumes you have iproute2 installed like most modern distros. you can do something similar with ifconfig easily enough.)

          #!/bin/bash
          ETHDEV=$(ip link show | grep LOWER_UP | cut -d: -f2 | grep -v lo);
          echo "Your connected interface names are:"
          echo "${ETHDEV}"
          echo "${ETHDEV}" | while read edev; do
              echo "Network statistics for device: ${edev}"
              ip -s link show dev ${edev};
          done

          Of course, if you're talking a firewall script, or something similar, you need to identify which interface you want the script to use for what purpose anyway, so that should be less of an issue.

      • (Score: 1, Interesting) by Anonymous Coward on Monday January 21 2019, @09:53PM (2 children)

        by Anonymous Coward on Monday January 21 2019, @09:53PM (#789799)

        It's not just "beginners." When you have a server with multiple interfaces and need the names to never change, you can be expected to be someone who knows what they are doing and can enable this feature. On the other hand, most desktops, laptops, and many servers have only one interface, or maybe one ethernet and one wifi, which have different names anyway. "Predictable" network names means that you have no idea what the names are going to be, but traditional names are always eth0/wlan0 regardless of your hardware, as long as you fall into this common case. Predictable depends on your situation and your perspective, not just your experience level.

        • (Score: 3, Insightful) by jdccdevel on Tuesday January 22 2019, @12:07AM (1 child)

          by jdccdevel (1329) on Tuesday January 22 2019, @12:07AM (#789864) Journal

          For situations with only one network device I see this as a non-issue. The VAST majority of these users have no idea that their network device is called "eth0" or anything else. They will never even see it, nor will they need to care, the distro install tools and the GUI will hide those details from them.

          For the relative few entering commands in a terminal, or following a script of some sort... Those sorts of users are perfectly capable of running a couple of commands to find out what their network device's name is, and substituting that in the commands themselves as required.

          Seriously, it's not hard to do. It can almost be automated. Give them instructions to enter "ip link show" or "ifconfig -a", or give them a little script to find out what their network device is called.

          Yes, not having the name always be eth0 stops some people from copy/pasting from the Internet. IMHO that's not a bad thing, it encourages a better understanding of what the commands they're running are actually doing if they have to edit them to replace a device name.

          Alternatively, If you already have a good understanding of what's going on, adding "ip link show" to the set of commands you're familiar with is probably a good thing.

          TLDR: Real novices will never see the device name anyway (It'll hidden behind a gui), and power users can easily adjust.

           

          • (Score: 0) by Anonymous Coward on Tuesday January 22 2019, @09:03AM

            by Anonymous Coward on Tuesday January 22 2019, @09:03AM (#789999)

            . It can almost be automated.

            Thank YOU

            This is what keeps me employed and will continue to do so for some time.

      • (Score: 1, Interesting) by Anonymous Coward on Tuesday January 22 2019, @02:50AM (1 child)

        by Anonymous Coward on Tuesday January 22 2019, @02:50AM (#789937)

        I'll except everything you said... until it gets to the point that you rob users of control. As per the defect report, if a user explicitly sets system settings a specific way, the system should respect that.

        My computer should belong to me. Not to Pottering, not to Gates, not to Jobs. It should belong to ME.

        Setting sane defaults is great. Ignoring the user's will is reprehensible and unacceptable.

        The moment Pottering (or one of his developers) comes along and says "don't worry your pretty little head over this, it's too complicated for somebody as precious as you to be trusted with" is the moment I leave them for something else. (This includes using older and unsupported operating systems... i.e. Windows 7 next year even after it leaves support.)

        • (Score: 0) by Anonymous Coward on Friday January 25 2019, @09:57PM

          by Anonymous Coward on Friday January 25 2019, @09:57PM (#792044)

          > "don't worry your pretty little head over this, it's too complicated for somebody as precious as you to be trusted with"
          Like talking to a child bride