Context for newbies: Linux refers to network adapters (wifi cards, ethernet cards, etc.) by so called “interfaces”. For the longest time, the interface names were assigned based on the type of device and the order in which the system discovered it. So, eth0, eth1, wlan0, and wwan0 are all possible interface names. This, however, can be an issue: “the order in which the system discovered it” is not deterministic, which means hardware can switch interface names across reboots. This can be a real issue for things like servers that rely on interface names staying the same.

The solution to this issue is to assign custom names based on MAC address. The MAC address is hardcoded into the network adaptor, and will not change. (There are other ways to do this as well, such as setting udev rules).

Redhat, however, found this solution too simple and instead devised their own scheme for assigning network interface names. It fails at solving the problem it was created to solve while making it much harder to type and remember interface names.

To disable predictable interface naming and switch back to the old scheme, add net.ifnames=0 and biosdevname=0 to your boot paramets.

The template for this meme is called “stop doing math”.

  • corsicanguppy@lemmy.ca
    link
    fedilink
    English
    arrow-up
    5
    arrow-down
    2
    ·
    3 days ago

    It’s amazing how many linux problems stem from ‘Redhat, however, found this solution too simple and instead devised their own scheme’. Just about every over complex, bloated bit of nonsense we have to fight with has the same genesis.

    Ansible can be heard mumbling incoherently and so, so slowly, from the basement.

    Remember who saw apt4rpm and said “too fast, too immune from python fuckage, so let’s do something slower and more frail”. twice.

    • thesporkeffect@lemmy.world
      link
      fedilink
      arrow-up
      9
      ·
      3 days ago

      I won’t hear any sass about Ansible. It doesn’t scale up to infinity but it’s the best there is at what it’s good at (modular, small scale declarative orchestration)

      • Possibly linux@lemmy.zip
        link
        fedilink
        English
        arrow-up
        4
        ·
        3 days ago

        You can totally can scale Ansible and especially Ansible pull. It will work with thousands of VMs and can be used with other tools to completely automate deployments.

        • thesporkeffect@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          3 days ago

          Oh agreed entirely. You can also use different execution strategies to mitigate most performance issues, but it can require some tuning at full enterprise scale.

    • notabot@lemm.ee
      link
      fedilink
      arrow-up
      4
      arrow-down
      1
      ·
      3 days ago

      I do use Ansible, partly because it’s easier to tell people that’s how you do it rather than “I wrote a shell script, it took half the time to write, it’s 20% the size and runs several times faster”. To be fair to Ansible, if you’re configuring a number of servers at the same time, it’s not too bad speedwise as it’ll do batches of them in parallel. Configuring one server at a time is agony though.