systemd FAIL: Network Interface Names
|
| Author | Content |
|---|---|
| dotmatrix Jul 06, 2017 1:15 PM EDT |
Carla Schroder, linux.com wrote:My Ubuntu system likes to give network interfaces strange names. enp0s25 is my wired Ethernet interface. Thanks to Poettering and his nonsensical systemd naming conventions: https://www.freedesktop.org/wiki/Software/systemd/Predictabl... |
| jdixon Jul 06, 2017 3:09 PM EDT |
I've carefully kept quiet during the last two systemd security bug postings, since I'm pretty sure everyone here knows my opinion of systemd specifically and Poettering's coding in general. |
| theBeez Jul 06, 2017 4:04 PM EDT |
You're not the only one who detests systemd, jdixon.. |
| skelband Jul 06, 2017 4:24 PM EDT |
I'm as big a systemd hater as the next man, but I have to say that the new naming convention for devices makes a lot of sense.
There is a defensible rationale behind it and I do approve. This style of convention is not even that new. Various *NIXs in the past (inc. HP/UX I think) do something similar. eth0, eth1... was always a bit of a hack. |
| jdixon Jul 06, 2017 5:13 PM EDT |
> ... but I have to say that the new naming convention for devices makes a lot of sense. There are pros and cons to both methods. I'd have a hard time arguing that either is actually better than the other. It has the advantage of being consistent, at the cost of additional complexity. But then, as Ralph Waldo Emerson said, "A foolish consistency is the hobgoblin of little minds..." |
| seatex Jul 06, 2017 5:50 PM EDT |
You just need to take another shot of systemd kool aid, I'm sure. |
| dotmatrix Jul 06, 2017 7:02 PM EDT |
After a year of testing before server deploys... overall, systemd kinda sucks, and I've decided not to deploy it on my servers. The last straw was the latest vulnerability that I saw sitting in the newswire a few days ago. http://lxer.com/module/newswire/view/244070/index.html However... it's not all bad, but there is a significant learning curve to figuring out what connects to what and why. The idea of a unified and consistent system interface is not a bad idea. It's the specific implementation which seems to be problematic. I know there are a few sans-systemd Distros out there, and, of course, there's Devuan. But, I like using standard Debian repos on my servers so: https://wiki.debian.org/systemd#Installing_without_systemd Anyone using Devuan on servers? If so, any thought? |
| penguinist Jul 07, 2017 1:23 AM EDT |
My solution was to continue with CentOS 6 on my servers. It's a solid sans-systemd server distro with still a long lifetime left to go. |
| CFWhitman Jul 07, 2017 11:47 AM EDT |
Predictable interface names appeared in the server version of some distributions before systemd did. For example, Ubuntu server 14.04 had predictable interface names. I'm not sure offhand if the convention was exactly the same as systemd, but there is a rationale behind predictable interface names. Anyone who's tried to set up a server with three or four wired interfaces and routing rules probably understands the rationale (interfaces won't otherwise always get the same name when the server is rebooted). |
| dotmatrix Jul 07, 2017 11:58 AM EDT |
@penguinist: >My solution was to continue with CentOS 6 on my servers. Watch out for Outlaw... http://www.zdnet.com/article/linux-malware-leak-exposes-cias... |
| skelband Jul 07, 2017 1:06 PM EDT |
eth* style names are also a problem in VMs. Since a lot of the assignments are based on MAC address on a rolling basis, cloned VMs often have their network device names scrambled even if the configuration is identical internally. Same if you replace a faulty card. I think the pros/cons vary depending on your situation. For most people, a single card in a desktop/server there is no obvious benefit. For anything a bit more complex or in a VM the benefits are a bit more obvious. |
| skelband Jul 07, 2017 1:29 PM EDT |
Actually, I should clarify a bit on my last post: Some distros assign ethX on a first-come, first-served basis. If you have a system startup that is non-deterministic, then if you have more than one card, it is impossible to know based on device name which name is associated with which card which is important for some people. Some distros deal with this more recently (Centos that I know of) by trying to persist the assignment by recording the MAC address of each card and using it to match names in the future consistently. However, this has its own issues in VMs which are spun up as clones requiring a randomised MAC. Again, if the distro has not seen the card before, it's pot-luck as to which name you get. |
| gus3 Jul 07, 2017 1:37 PM EDT |
You lost me at "systemd." Once it passes a security audit a la OpenBSD -base, I'll consider it. Until then, no way. |
| skelband Jul 07, 2017 3:00 PM EDT |
Hah, well yes I don't disagree. Any half decent ideas coming out of the systemd camp are going to be tainted with the creeping scent of dependency-coupling induced monoculture which is my main issue with systemd. I actually wouldn't really have that big a beef with systemd if it hadn't become so unreasonably integrated with so many components that it should not have anything to do with. But then the arguments are nothing new. Helps to re-iterate them every now and again though. |
| nmset Jul 07, 2017 3:38 PM EDT |
There should be good reasons why most Linux distributions have adopted systemd and they must have published them somewhere. As far as I can tell, Red Hat cannot and did not impose it on any one, independent distributions have *chosen* to adopt systemd. Now no one is obliged to use all the tools provided beyond init. You can for instance mask systemd-journald and completely ignore systemd-networkd (I do that). For this particular question of NIC naming, systemd documents how to fallback to traditional naming(I do that) (link in first post). That's kind and polite. So beyond init, the user is free to ignore most of systemd, perhaps not systemd-udevd. And it even instructs how to ignore some new ways of doing things. The fact that it's Linux only has been criticized, but at least, it takes full advantage of Linux specifics. For devs, the code (well on top of me) should be more cleaner and consistent, should it have to run on BSD too. Hence I don't fully understand the complaints against systemd all year through. Fortunately, Devuan is out, I hope it will get enough traction for everyone to be happy... with GNU/Linux as a common glue. |
| jdixon Jul 07, 2017 3:58 PM EDT |
> There should be good reasons why most Linux distributions have adopted systemd... Red Hat's influence and Gnome dependencies. > So beyond init, the user is free to ignore most of systemd, perhaps not systemd-udevd. If I want to ignore it, why should I have it in the first place? Fortunately, I use Slackware. > Hence I don't fully understand the complaints against systemd... They've been discussed to death. There's no reason to rehash them here. IMO, it comes down to systemd ignoring or deliberately breaking a number of basic Unix philosophical principles and Poettering himself. > Fortunately, Devuan is out, I hope it will get enough traction for everyone to be happy... with GNU/Linux as a common glue. Agreed completely. |
| CFWhitman Jul 07, 2017 5:21 PM EDT |
I'm always wary of a component of a GNU/Linux operating system that you can't easily rip out and replace with something else. I don't have a problem with systemd per se; I just question how dependent everyone should be on it. The situation with replacing X Window with something new being a monumental undertaking illustrates the problem with becoming too dependent on a component. This was largely unavoidable with X Window, but it seems avoidable with systemd. |
| jdixon Jul 07, 2017 6:58 PM EDT |
> The situation with replacing X Window with something new being a monumental undertaking illustrates the problem with becoming too dependent on a component. There used to be a competitor to X called MGR: http://hack.org/mc/mgr/ I suspect updating it to a current system would indeed be a monumental undertaking. |
| tuppp Jul 08, 2017 3:06 PM EDT |
jdixon wrote:I'm pretty sure everyone here knows my opinion of systemd specifically and Poettering's coding in general. ... Just guessing that you have a similar opinion of Poettering & Co's arrogance. nmset wrote:There should be good reasons why most Linux distributions have adopted systemd... By that logic, there should be good reasons why Miley Cyrus and Justin Bieber get a lot of radio airplay -- certainly it's not because either is better than the Beatles. nmset wrote:So beyond init, the user is free to ignore most of systemd No. The user is not free to ignore any of systemd, because there are too many unnecessary, arbitrary dependencies on systemd. There should not be a single unnecessary, arbitrary dependency on systemd (nor on any other software, for that matter)! This is the very basic principle of keeping options open, which applies to all endeavors -- not just software. nmset wrote:The fact that it's Linux only has been criticized... I think that you'll find that there are one or two additional criticisms of systemd. nmset wrote:Fortunately, Devuan is out, I hope it will get enough traction for everyone to be happy... Devuan is great. However, in spite of Devuan (and other systemd-less distros) the problem remains of having to constantly reverse-engineer creeping, arbitrary, unnecessary dependencies on systemd. We won't be happy until we see the purging of all of those arbitrary, unnecessary dependencies on systemd. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!