Isn't it great to have the choice wether some tool manages the system or one does it manually? Thanks GNU/Linux, thanks all the Linux distributions maintained by hundreds of volunteers!
I got the opposite out of this post; not only do RH/Cent use hellish network middlemen, but other distros have their own fresh hells. Is there really a choice that doesn't commandeer your configs?
Standard practice for me was to rip out every last shred of NetworkManager on every fresh build, but I didn't realize how many other utilities broke the resolver config as well.
What's wrong with Network Manager? I've yet to find a better tool for managing wired, wireless, vpn, and mobile broadband anywhere as well as NM. Sticking with the theme of the original post, NM combined with unbound and dnssec-triggerd is downright amazing. Your vpn connection passes down a nameserver and search zone? Bam, NM pushes that into unbound, and now queries for your vpn domain go to the vpn resolvers, and your other queries go out to whatever you set for your default resolver.
To be fair, in that particular config, resolv.conf never changes as it always points to loopback, with your preferred nameservers only existing in memory in unbound, and in network manager's config.
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.
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.
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.
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.
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).
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.
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.
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.
I don't use these things. I run servers. It does nothing but break stuff, and it keeps butting in like that annoying acquaintance at parties. It's very difficult to make go away short of uninstalling every last vestige of it.
I'm on Debian stable and there's no systemd-resolved or NetworkManager running.
When I'm on a DHCP network dhclient runs and manages my resolv.conf asexpected.
We're still entirely in control in GNU/Linux, if you assert control. It turns out however that most people actually want the distros to do all the magic and for things to Just Work.
Choice is "do you want to <x> or <y>" not "if you don't want <x> figure out how to implement <y> on your own". That's simply known as "doing the work yourself" and is largely possible on even closed sourced systems assuming you have rights on the box.
There is nothing wrong with that but it shouldn't be conflated as choice and paraded as success of such.
The GP is referring to all the other Linux distributions who really give you <y> (or <z> or <Þ>), not to implementing <y> on your own.
There are distributions (e.g. Linux from Scratch) for when the option you want is the NULL option—i.e., doing things yourself. But there are N other managed options, not just one managed option and NULL.
Ah yes, the strawman disto which matches exactly what <user> needs and is the reason <problem> isn't actually an issue since they can just switch to strawman distro!
Unfortunately strawman distro is never real and the problems still exist after congratulating the ability to switch to it.
