rhel-7/centos-7 network configuration is bizarre — largely because they are straddling between the old (shell scripts usually invoked by /etc/init.d/network which mutate configuration state of network devices) and new way (NetworkManager daemon which manages network device settings).
To the best of my understanding — rhel7/centos-7 are simultaneously supporting both configuration modes for network devices. They use a plugin for NetworkManager called ifcfg-rh which reads/writes network configuration from /etc/sysconfig/network-scripts/ifcfg-* with configuration going into NetworkManager from these files at startup, and changes made via NetworkManager (sometimes) getting serialized back to these files through ifcfg-rh plugin during system operation (which involves translations to/from the weird legacy configuration file format in /etc/sysconfig/network-scripts/ifcfg-* — a format which was originally interpreted by a pile of shell scripts.) This situation scares me and makes me think about dragons.
My take is that straddling the two worlds is confusing and error prone — particularly if you have to automate network configuration changes for various reasons, and also when you have to educate co-workers about ‘new way’ of doing things on modern systems — people who might forget and cause configuration control to drift out of sync between the two worlds …
So, to avoid the potential for weird bugs, I want to just fully adopt NetworkManager and get rid of the legacy options. Should I expect side effects with the following approach:
> cat /etc/NetworkManager/NetworkManager.conf [main] plugin=keyfile > cat /etc/NetworkManager/system-connections/dhcp-profile.conf [connection] id=dhcp uuid=50263651-4f14-46bc-8dd8-818bf0fe3367 type=ethernet autoconnect=true [ipv6] method=auto [ipv4] method=auto > systemctl disable networking > systemctl enable NetworkManager
I this should ensure the keyfile formatted file is source of truth for all NetworkManager settings — and should remove all behaviors which depend on the contents of
It seems to work and behaves normally so far … I’m a little bit worried there might be side-effects from disabling the /etc/init.d/network ‘service’ … I don’t think there are any reasons why /etc/init.d/network should still be called in a fully NetworkManager world …?
Does anybody know of behaviors this would break or reasons this wouldn’t be a good idea?
If you’re using NetworkManager, there is no reason to – and you should not – enable the legacy network service.
Conversely, if you’re using the legacy network service, you should not enable or start NetworkManager.
You might have breakage if you have legacy scripts that expect to use the old network service and don’t understand NetworkManager. These should be adapted as appropriate, if possible. Otherwise, you can always use the old network service.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.