Hacker News new | ask | show | jobs
by Bnshsysjab 2170 days ago
Yeah but that doesn’t teach much about core components in real systems, such as systemd, the init process, how dependencies work etc.

I’m not saying you won’t learn, but I learnt a heap by avoiding systemd using gentoo. I eventually gave in when it became clear that it was no longer a viable option for various reasons, but the knowledge I learnt was mostly relevant.

That being said, every time I try and do something remotely advanced with network manager I fail. I can no longer have static ips, or customise DNS on a DHCP controlled connection without google

1 comments

Yeah, the basic use case of simple wired network connectivity has gotten extremely complicated, especially in Ubuntu 18+, where you configure Netplan with YAML to render templates or...something.. that configures NetworkManager or not NetworkManager to do whatever to finally run `ip` to set the address.

I miss just editing /etc/network/interfaces and /etc/resolv.conf by hand. I get that that sucks for laptops, but why can't the rest of us just have an exceedingly simple and pleasant setup?

My current cross-distribution method of choice is systemd-networkd. It supports a lot of configuration options and can set up VPN tunnels (like WireGuard).

https://wiki.archlinux.org/index.php/Systemd-networkd

Here's a sample config file from my home desktop using a static IP:

  $ cat /etc/systemd/network/lan.network

  [Match]
  Name=enp3s0
  
  [Network]
  Address=192.168.100.200/24
  Gateway=192.168.100.1
  DNS=1.1.1.1
  DNS=1.0.0.1
This'll work on any systemd distribution.

netplan is one of those Canonical projects that'll probably disappear in a year or two.

Are there any Canonical projects, outside of Ubuntu itself, that dont just eventually fizzle out?

I feel like after all these years, Canonical has still not figured out how to make Open Source work.

Nearly everything they do leads to controversy, and them eventually accepting the community alternative with a huff.

I feel they do stuff in a whatever way, and that signals other developers on what matters, and leads to working on something to do that properly. Like, their solutions don't get used but if they are not done than no good solution comes up.
Ugh, this resonates with me so much. I recently tried to fix some kind of mundane network issue (had a Fedora machine configured for a static IP and wanted to use DHCP instead), and the absolute mess of tooling that is the Linux networking landscape baffled me. How could it get this bad? As far as I could tell, there were at least 4 competing ecosystems (NetworkManager, the 'ip' tool, /etc/network/interfaces, /etc/sysconfig/network-scripts) all extant at the same time.

Does 'ip' tool update one of those files? How do I tell systemd to re-load the configuration? Is NetworkManager running or not? Does it matter? Does NM update these files, or do something magical to the interface? Are these even the right files? The best answer at which I could arrive is "who knows?"

Every time I attempted to change the network interface settings, it only stuck around until the machine rebooted. Something was resetting it back to a static IP, and I had no tools to tell me what.

Why did distro maintainers ever allow things to become this confusing? Why do we have so many tools and config files for the same thing?

In the end I reinstalled a fresh copy of Fedora on the machine and set the DHCP configuration in the setup wizard. It's that bad.

My experience tells me to anticipate a comment along the lines of "Hey, those programs and config files are all actually the same tool, and you must have just been configuring it wrong." If that's the case - it's an even stronger point that this chaos has reached a critical mass, where parts of the same networking configuration tool are so disjoint that they don't visibly interoperate at all.

I'm almost positive your problems were caused by NetworkManager. I usually disable and blacklist it everywhere (or wipe entirely if the distribution dependency tree allows it), and my systems never behave in this unpredictable way.

It tries to be helpful and rewrites network configuration files to align them with its own configuration.

The 'ip' command only operates on runtime state (it doesn't save anything to disk).

NetworkManager used to be configured to save it's config to /etc/sysconfig/network-scripts on Fedora, for backwards compatibility (see /etc/NetworkManager/NetworkManager.conf).

/etc/network/interfaces is the Debian alternative to network-scripts. I don't use Debian based distros much so I don't know too much about that.

There's also systemd's networkd, which has it's own config in /etc/systemd/network.

Honestly I'm surprised you've got a Fedora machine with networkd. Usually NetworkManager has been the goto choice (and is what my Fedora 32 install has, although this install has been upgraded from Fedora 23 so take that for what it's worth).

Most of this mess comes from ifconfig (which again, only operated on runtime state), which people then wrote scripts around to automate the setup of the networks. Then ip came along to access networking features that ifconfig couldn't.

You best off sticking to NetworkManager (in my opinion) for desktop usage. It has a far better GUI integration than networkd (which is fine for server/embedded use).

Until about 5 years ago debian used /etc/network/interfaces since the 90s to configure network.

Redhat has used /etc/sysconfig/network-scripts.

Then the network stack was changed in the kernel, and traditional tools (ifconfig) carried on working, but didn't expose all the new features, so a new tool to configure your ethernet link was created called "ip" which you had to use despite not running IP on that interface.

But things still worked. Those with complex requirements would drop in extra things into post-up hooks - e.g. I add route tagging for my dual homed machines so that traffic coming in on eth0 would go back out of eth0's gateway, and traffic on eth1 would go back out of eth1, and sockets specifically bound to eth0 (or eth1) would use the correct gateway.

(oh yes, upto about 5 years ago network cards were called eth0 through ethx, now they have unpredictable names)

However as is common across software nowadays, this wasn't good enough, and had to be redone. By dozens of different groups. Because cloud.

On eth0 times it was a lot more fun to script things.

I also felt wpa-supplicant was a very dramatic name.

/etc/network/interfaces & /etc/sysconfig/network-scripts aren't part of NetworkManager (the directories don't even exist on my machine).

You should probably check out `systemctl list-units` to see what is actually enabled and running on your machine.

Thanks, that's a pretty nifty systemd command[1]. Sadly my confusion is only furthered, since I'm seeing both target files and daemons (although maybe they're both considered 'units' in systemd) and now a new name ("networkd") joins the fray. No sign of NetworkManager at least.

What's also interesting is I've somehow managed to have the networkd-wait-online.service fail, despite having an internet connection.

This is mostly a curiosity at this point, nothing's broken - but it is a really humbling experience to realize how little I know about the modern Linux network stack after "using" desktop Linux for a decade or so.

[1]: https://imgur.com/a/VYX7lmu

I really don't understand the motivation for netplan existing. It's such a primitive tool that provides very little abstraction over it's backends that aren't pluggable or really configurable at all.

It's super weird that they didn't just do the thing with NetworkManager since all they needed to write was a plugin a la ifcfg-rh to process turn YAML into NM settings and then you're done. And since they have NM as a backend they clearly are perfectly capable of doing this.

I’ve always been surprised that RHEL/CentOS 7 doesn't have a simplified server-mode for installing a basic, headless system with a static IP address with an Ethernet connection. The default configuration and prescribed usage is to configure the networking with Network Manager - even though its added complexity is to solve the problems faced by portable computers using Wi-Fi. I’d wager the majority of RHEL/CentOS 7 installations are on static hosts (virtual or physical) rather than mobile devices.
Try dropping netplan and using systemd-networkd.