NetworkManager is the bane of my existence and I hate it

Once again, tonight, it has tripped me up while trying to get a web app up on a non-standard port on HTTPD. Test environment - works fine. Prod staging environment - doesn't work. What's the difference? NetworkManager, of course!

That doesn't sound right at all. There are only a couple of things that I know of that would prevent a non-standard port from working:

• The default SELinux/AppArmor policy will not allow certain non-standard ports to be used with Apache HTTPD unless you explicitly allow them
• The firewall service needs to be adjusted to allow the port through

NetworkManager itself doesn't do anything about ports. That's not its job. All it does is ensure the network is up based on your configuration.

This may just be a confusion on my part

But why is the production server using networkmanager for the web app, and the test application, for the web app, is not using the same network tools?

Wouldn't this be a fairly glaring issue in testing, or am I wrong?

I think your problem might me more about lack of training (as a sysadmin you should probably ask your employer for that) and the fact that your test environment is different from prod in such glaring way as having different networking setup.

Also - maybe try ansible?

In my years of using Linux, NM has never been a problem on any server or desktop I have setup and/or worked on...i think you are cursed.

OP: You're mad and I get it, I'm an old bastard who also doesn't have time for new fangled bullshittery, but NM is definitely a step in the right direction.

> It's become part of my SOP to remove/disable it ASAP.

This will not be a good plan going forward, spend some time spinning up a system in a vm, and learn how it works.

​

Options you have here, are remote console via something like idrac, hpilo, etc (and remote power) or intercept the boot sequence and setup a rescue netboot environment which you can trigger on demand. All of these are 'enterprisey' features and maybe not suitable for your environment.

You shouldnt try to 'cut the NIC loose' from NM and yet still expect your 'network management' service to manage it. The network environment that NM caters for is more complex than the previous ifcfg- style deployments.

> So here I am stuck without access to the staging server because I can't get rid of that POS >trash method to manage a network. Leave me happily with my /etc/sysconfig/network-scripts/ifcfg-xxxxx.

If you're impatient like myself, I have found that you can always still use the ifcfg- style files AND keep networkmanager around if you setup ifcfg-rh as a plugin for networkmanager ( See https://developer-old.gnome.org/NetworkManager/stable/NetworkManager.conf.html )

The easiest way is to make your own tests in an environment you control, make sure your understanding of the changes makes sense then deploy on your production.

In regards to your "not listening on a standard port" as far as I know, networkmanager has no capability of preventing listening on standard ports, this is likely either the firewall (firewalld) or perhaps a selinux policy.

Good luck.

I donno. It sounds like a personal issue.

There was a time where i would edit ifcfg multiple times a week and understood all the ins and outs. I would setup complex layers of configuration involving multiple networks and setup bridges for vlans over bonded network interfaces.

Now it's been like 7 or 8 years since I last looked at /etc/sysconfig/network-scripts/ much less edited anything.

And I can thank NetworkManager for doing that. Which I do profusely.

Ifcfg scripts are garbage and always have been. Easily one of the worst features of old school Redhat. Debian's approach is vastly superior. And Network-Manager actually made this worse by trying to bridge the gap between ifcfg scripts and itself.

Network-Manager supports multiple back-ends for configuration files. This way distributions could pick the type of configuration they wanted. Redhat tried to develop a ifcfg backend for NetworkManager and it was garbage.

The reason for this wasn't because NetworkManager's ifcfg backend didn't work. It was because it was actually incompatible with existing ifcfg scripts in significant, but subtle ways. And documentation was terrible. The whole thing was just a massive mistake.

But that is all in the past.

~/# egrep '^NAME' /etc/os-release
NAME="CentOS Stream"
~/# ls -altr /etc/sysconfig/network-scripts/ 
total 4
drwxr-xr-x. 2 root root    6 Jan 12 16:09 .
drwxr-xr-x. 3 root root 4096 Jan 23 00:56 ..

This is what I like to see.

My advise to you: Learn how to use nmcli. Especially 'nmcli c edit'

And if you are remotely working on a machine;s network.. make sure you have console access. Servers have lights out management controls that you should have access to. Cloud systems have at least serial consoles that should be working.

Making sure you have access to that before ssh'ng to a machine and mucking around with it's network config is is just 101 level stuff.

Lol, if you don't like it don't use it :) also I can smell some different configurations on your test env

From my experience you just don't use NetworkManager on servers, especially production. If it doesn't suit you just disable it. It's one useless process less.

NetworkManager always worked fine for me, but a few years back I switched to plain systemd-networkd, which works pretty well also.