"NetworkManager may provide a great gui/tui/cli for managing network configurations, but how does RedHat expect it to integrate into environments where "none of the above" is the correct answer, i.e., where distributed configuration management is the norm and logging in to individual servers to manage any aspect of configuration is not appropriate?"

The kind of config-mgmt you describe is not at odds with NetworkManager. If you're pushing out network config files (with e.g., puppet), you'll have to run some commands whether you're using NM or not.

Old-school serialized initscript:

1. push out config files: network-scripts/ifcfg-*, /etc/hostname, /etc/resolv.conf, /etc/hosts

2. restart network service, potentially run a hostname command

New-school hotness integrated with systemd:

1. push out config files: network-scripts/ifcfg-*, /etc/hostname, /etc/resolv.conf, /etc/hosts

2. restart NetworkManager service

PS: I should make clear that both of the above options are there in RHEL7.

I hear you Ed. I haven't read through the new RHEL7 Networking Guide, so I'm not sure how much it offers in terms of answers to your questions.

I'll say two things:

1. There's no rush. You don't need to use NetworkManager AT ALL. If you don't have any time to play with or audit it, by all means keep disabling it like in RHEL6. In fact, there are some cases where the old initscript still must be used in place of NetworkManager, and there even might be some situations where NetworkManager is programmed to do stupid things you and I wouldn't like; however, in both cases, the remedy is the same: keep using the old network service while NetworkManager is further improved. Not every server needs the benefits NetworkManager currently provides (parallelizing connection-starting, allowing intelligent on-demand connection-starting [due to services, other connections going down, whatever else], enhanced logging and debugging of problems); however, it's where everything is going [IMHO].

2. With regards to:

   "How do I know that puppet and NM aren't going to duel over file contents or ownership or permissions or connection states?"

   As far as I understand: NetworkManager will make no changes to the above-mentioned config files as long as you don't ever make changes in the NetworkManager apps (nmtui, nmcli, nm-connection-editor, gnome desktop applet). The common exception would be resolv.conf, but of course that can be avoided by ensuring you're either using all static networking or have PEERDNS=no in all DHCP ifcfg files.

Hi PixelDrift. I'm just gonna give a quick warning for other readers that have not heard of dnssec-triggerd.

"If you choose to remove/disable dnssec-triggerd, you can provide /etc/resolv.conf options as you have historically."

The dnssec-triggerd service mentioned by PixelDrift has is not intsalled by default (dnssec-trigger rpm) and only has relevance on DNS servers running unbound. This is not some additional NetworkManager change you need to worry about.

EDIT:

Someone (thanks Stephen) pointed me to the DNSSEC documentation in the RHEL 7 Security Guide and I see now that what I said above ("dnssec-triggerd ... only has relevance on DNS servers") is not true. Good reading!

I stand by my "this is not some additional NetworkManager change you need to worry about" statement though. Sure, dnssec-trigger can cause NM to modify resolv.conf, but so can starting a VPN. It's kind of a special case -- I think people that are using those 2 things already understand that.

Ed, you can manage your email notifications through your profile area (click your name in the top right of the Portal interface and select "profile").

For now, I've unsubscribed you from this thread.