[bubblethink]

>What's wrong with Network Manager?

It's opaque and hard to debug. It may have utility on laptops, but on servers, it is absolutely counterproductive. I could not for the life of me figure out what it was doing w.r.t ipv6 prefix delegation and how it was dealing with dhclient6 internally. My leases would expire but not renew. Eventually, I had to rip it out and create simple configs by hand that work well.

[subway]

I'll grant you that it's extremely different from static network configs, but it's far from opaque. If anything having all the logging under NM can make troubleshooting a pleasure `journalctl -f -u NetworkManager` is a godsend.

I'll also agree that the benefits on a server are next to non-existant, but at the same time it's just a default that's trivial to turn off, and I could probably count on one hand the number of times it's bitten me while building and deploying tens of thousands of hosts over the last 15 years.

It's a tool I've learned to love on my workstations, and rarely even notice on production systems.

[bubblethink]

You don't notice until it bites you. And trust me, I spent a lot of time debugging the ipv6 issues to no avail. It may be in general the whole ipv6 ecosystem is just not as mature, but the end result is that user experience suffers.

[rconti]

Disagree. I've "disabled" it in policy countless times, and been bitten in the ass by it re-enabling itself countless times. The only thing that works is deleting it entirely. After the umpteenth troubleshooting session, only to find out "oh, it's that thing again? That thing we keep trying to make go away?" I'm not going to spend one more minute trying to figure out how I could keep from hurting its feelings.

[subway]

It sounds like you don't understand the tools you use, and have no interest in learning them. NetwokManager (just like any other daemon) cannot "re-enable" itself. It's possible if you were on an Debian derived host that package post-install scripts enable the service (as is the case with all services on Debian derived distros due to packaging policies. The right way forward here is to indeed remove the package if you aren't using NM. Or better yet, get a better grip on the packages you install in the first place, and just don't install NM to begin with.

If you're on a RH or Arch derived distro, policy is just the opposite, and if the service is ever magically enabled (aside from Anaconda enabling it after the package was selected at install time), it's a massive bug (I can't find any such bug report in Arch or Fedora).

[rconti]

No, it's just that, for the purpose of an internet forum comment, I don't wish to revisit years of regular and maddening problems across fleets of thousands of servers. Over the years they may be subject to different initial build and deployment regimes, to say nothing of different OS versions that may have been released over that time, and various Puppet manifests that may have been changed over that time.

When something is regularly found to be the problem, and has never made my life any easier, it gets yanked. Sometimes I may have had time to analyze further, other times it may have been an emergency. Regardless, it's been at least 1.5 years since I worked in that environment, and my memory has faded. In the real world, we don't have infinite time to analyze infinite failures.

Here's what I remember:

NetworkManager = problems.

No NetworkManager = no problems.

You may care to look down on people who don't always have the time to analyze every single occurrence of every single problem to the nth degree, and subsequently catalogue the exact cause and fix for reference when posting on forums in the future, and that's fine.

My opinion is, it sucks, and I don't want it.

If you like it, and enjoy its benefits, please do. I'm not denigrating you for your choice.

[bubblethink]

systemd's dependency logic about what is enabled or disabled is not straightforward. For example, I disable buetooth on general principle, and yet it gets enabled (as in activated) in some scenarios due to other stuff depending on it (i think something in gnome does). "systemctl is-enabled foo.service" is not a guarantee about anything. Something else can still start the service without the user's authorization.

[JdeBP]

> enabled (as in activated)

Not understanding the difference between these is likely part of the problem here.

[bubblethink]

It's not really the user's fault though. If you really want to make sure that something else doesn't start it, you need to mask the service. But then, you can't start it either. What you really need is "disabled unless I start it". I don't think there is a state like that.

[pnutjam]

Opensuse uses wicked for servers. It's nice and more suitable.