The legacy network service is in effect deprecated, like net-tools was, as no new features are being released for it and no RFE’s are being accepted. All future work is on NetworkManager.
Note as well this article was last updated in 2014 – NetworkManager has been updated to handle more use cases than back then.
As always it’s best to check with the upstream documentation:
Finally there was nothing to do with IPv6 in your article.
That address was an IPv4 address and the zeroconf stuff configures the
169.254.0.0/16 network as a ‘local link’ network on that interface.
If it was IPv6 it would have an address like fe80::33bb:5a14:be57:1690/64 … which is an IPv6 link local address.
Regards,
James
The truth is a lot of us run servers that don’t need to have their network “managed” by Networkmanager.
We just need to set an IP address, subnet mask, gateway, and DNS servers and we will never be changing that configuration ever again for the entire life of the server. Any 3-4 line script that does the job is sufficient, servers don’t need gimmicks, they’re not going to be hotspotting on wireless networks, the cable goes in, the server enters production and that’s it!
You’re opting to have your network managed by a bunch of unloved legacy scripts that you’re advised to avoid using unless necessary, or you’ve having it managed by NetworkManager. If you want to have it managing it this way, you’ll be writing your own scripts.
By 3-4 line script, I assume you mean the content of all the files in
/etc/sysconfig/network-scripts that aren’t your ifcfg files?
Oh okay, you really do want to back away from Redhat entirely. That’s entirely your choice.
What you end up with if you take this approach widely is effectively your own linux distribution.
jh
Not really, Redhat/CentOS has a lot to offer, but for me, networking is a one-time configuration, and the best way to configure it is using something that falls within this principle:
I’m not flaming NetworkManager, I’m just stating that for many (perhaps most), it is over-engineered for a server orientated distribution. I can run with the script above on 30 server instances, and it doesn’t, as yet, break any of the other features of CentOS that I enjoy.
It means you’re stuck in your own hand crafted niche. Which is fine, but it’s up to you to maintain the niche, or you find yourself using obsolete tools like ifconfig and route.
I’d argue there’s a gulf between keeping things simple and doing things your own way.
jh
I’m sure there are drop in replacements for ifconfig and route, but even if deprecated I have not needed to revisit that script for many years, so I’m not changing it. When it does eventually break I have to look at four lines to discover where the problem might be, I can troubleshoot it by trying to run each line manually and see what is going on.
When qw hit a bug in NetworkManager that breaks something specific that you’re doing then you can try to raise a bug with upstream, or you could try to review the thousands of lines of code that make it up and try to fix the problem yourself.
Or perhaps you’ll do what I did, remove it and put in a 4 line script.
That’s nice … but what you’ve provided is terrible advice that doesn’t handle a wide range of scenarios such as teaming, bonding, vlans, bridging, network interface changes, race conditions of things dependent on networking or acting as part of the network.target or network-online.target systemd units which declare when network is ready …
If you want to do something unsupportable in any sane environment that is on you … but really please don’t suggest to those who don’t know better to carry out such activities.
I didn’t suggest you use anything, you asked me what script I used, I
gave you that information YMMV.
My experience was very difficult going to 7.2 to 7.3 because of a change in the behavior of NetworkManager with respect to IPv6 but once I had it figured out (thanks to people on this list) it worked out quite well and I kept NetworkManager.
But I certainly understand why some don’t want to do that.
That’s fine Alice (and I remember your issue well with the minimally documented change to stable-privacy by default for new systems … argh I still need to write up a blog article about that) but in this case the person concerned isn’t even using the network service, which if legacy and semi-deprecated is still supported, but just doing a ridiculous and unsupportable mini script (I’m guessing from rc.local?)
which doesn’t handle pretty much any actual networking issue that may come up – eg failed/delayed interface.
Hello James,
your right in that position. I will correct it.
Sincerely
Andy
I agree – they are trying to make it like windows, and when something doesn’t work correctly you have no clue what is going on in the black box!
Certain application doesn’t like the NetworkManager
And on server stage it’s better to run without any complicate configuration tools.
Tools can make life harder in some cases.
Got many other distros run before CentOS, why not.
I personally like it slim and easy.
Sincerely
Andy
Yes it is really hard!
ip address add 192.168.0.1/24 dev enp0s25
ip route add default via 192.168.0.254 dev enp0s25
echo nameserver 8.8.8.8 > /etc/resolv.conf echo nameserver 8.8.4.4 >> /etc/resolv.conf
I do not agree with your conclusions about NetworkManager. First, I use it on several servers and firewalls that – theoretically at least –
should never change. Some of the most tiresome problems I have had to fix were what happened due to renaming of NICs after replacing a bad one, or a 100Mb with a Gb NIC, or adding a new NIC to connect with a new network. NetworkManager keeps NIC naming consistent with no surprises. I
am getting ready to install two new NICs in a firewall/router that already has two NICs and I am not dreading that change as I would have with the old network service.
I have had excellent results with NetworkManager and am very happy with it. I see it as a significant improvement over the old network service. If you are concerned about performance issues – don’t worry – you won’t have any. It works fine on my RaspberryPI forewall/router using CentOS 7
for ARM and on my ancient EeePC that runs a full installation of Fedora 25.
Don’t try to fix something that isn’t broken.
This is still a deliberately trivial case, as already said, with no teaming/bonding/vlan type fun in the mix.
You’re free to disentangle yourself from the bits of CentOS you don’t like, and there’s nothing at all stopping you, but after a while what you’re supporting isn’t CentOS. I realise this is only one little part of the whole, but still.
jh
Let us have a vote – how many of us do teaming/bonding/vlans on our servers?
Our networking gear does that in our installation.
Hello David,
It was not to flame something about NetworkManager. There some application that “needs” to wheel the old way.
I would never have thought it would be such an enlightenment for such a small, old thing.
1. There is a file that isn’t always needed (/etc/sysconfig/network)
2. I wanne have the same result in the old style. (NOZEROCONF=yes)
And just by the way. My Desktop computer here runs with the NetworkManager.
1. Outside lan
2. A dummy bridge adapter fired by the NetworkManager
(With a island name server + dhcp for kvm)
3. An internal lan that can also run an CentOS Diskless computer.
That was not my intention; really not.
For a network starter it is an absolute must to know, how it works in practically. Not me.
Sorry
to
everyone
That makes little sense …
Without cooperation of both endpoints (switch and host) LACP is not possible (and this is generally the preferred teaming/bonding method).
Without cooperation of both endpoints (switch and host) trunking multiple vlans (ie the time you would actually tag) is not possible.
That ridiculous “script” doesn’t even handle the basic situation that the NIC interface didn’t come up for any reason …
The majority of my servers are virtual, if I need multiple subnets
(VLANs) then I have multiple cards. Their throughput does not require bonding, resiliency is performed at a different level – by having multiple load balanced VMs.
I have to admit, on one hypervisor I use VLANs, but actually use NetworkManager in that case – and it worked since installation, if I
have a problem with it in the future though, I will resort to scripting it as well :-) – It would be the simplest way for me to resolve the issue – I can’t afford to wait for patches to a monolithic, as you say, black-box system, which is in effect just trying to apply sanity checking a bunch of scripts in the first place.
I don’t add VLANs and Bonds on my servers for _fun_, they are there to run the applications and infrastructure – faffing around with that once a server is in production is just asking for trouble.
If you’d like a really simple solution that avoids NetworkManager, I
suggest using systemd-networkd (both systemd-networkd and systemd-resolved packages required). I’ve used it to set up a bridge on my workstattion for use with libvirtd/kvm, and it is just as simple a text file but future compatible. Heck, it probably even works on other distros that use systemd.
You need to make sure that /etc/resolv.conf is a symlink
/run/systemd/resolve/resolv.conf if you want the systemd-resolved service to manage it. Just disable NetworkManager and network services and enable the systemd-networkd and systemd-resolved services.
Honestly, I’ve found systemd-networkd very useful for the more complex networking on my workstation (bridged VMs to external network) but its also useful for my tiny VMs that don’t need extra daemons running.
That’s interesting, I’ll snapshot and perhaps take that tangent on the next build and see how it goes.
Incidentally as far back as NM 1.0 (part of the 7.1 milestone but not part of the original 7.0 GA) it has supported a
‘configure-and-quit=yes’ option to just get the configuration right, emit the events etc needed to tell services/system network is configured and then get out of the way and not leave any running daemon:
I’ll give that a test as part of my upcoming article looking at how NM
has changed since the original 7.0 release.
Did I see an implicit “do as Red Hat says or else” there somewhere? Not appropriate. Linux is not Windows (yet). In the heat of the moment it may easily be forgotton that Linux is all about choice. We choose to run CentOS, and we choose to run it the way we see fit. We appreciate the efforts that go into the *Community* *Enterprise* OS, and if you have dealt with buggy crap like Ubuntu or Fedora, you appreciate it even more. This does not imply deference to upstream.
That statement about “effectively [running] your own Linux distribution” is scaremongering, at best. If there’s one thing I’ve learned on this list, it’s realizing how many use cases, scenarios and solutions there are that can make approaching the topic at hand without prejudice challenging at times.
You’re reaching here.
It’s simply there is good advice and sane management practices, and there’s bad advice and approaches to manage systems that have plenty of clear issues and step way outside of the documented and supported methods of handling things.
If you want to use a random script that has so many issues it’s even less supportable than the legacy network service, more power to you!
Just don’t advise people entering into this area to do that and don’t expect much help from those more knowledgeable in those areas who spend their own time assisting on the mailing list and IRC if you insist on jumping off the cliff with your homemade parachute after people have pointed out that patching it with small bits of cloth wasn’t the best of ideas …
I’ll obviously argue I wasn’t scaremongering. You can start with CentOS, and do anything you like with it, and as I’ve said, you’re absolutely free to do that. But at some point, you have to accept that what you’ve got left isn’t CentOS. If you don’t use what the distribution provides, what you’re doing isn’t the distribution. Given you’re getting no formal support on this, that possibly means little to you, but don’t be surprised by the community backing away from providing unofficial support to something that’s no longer CentOS.
You see this sort of thing in a more extreme way with things like cPanel.
jh
Well, let’s put it this way, the more someone argues that I need to run some software that I clearly don’t need, the more I become suspicious of what that software is doing. The network configuration of my servers is static, it doesn’t need to be changed once the server has booted up. So it doesn’t need some piece of software running away doing goodness knows what… I’m just going to be waiting for it to bug or error out and leave me high and dry without a network config.
I am not trying to suggest of encourage people to emulate what I have done, I have just been making a point that if you want to run something to manage your network configuration, and your network configuration is clearly not going to change, then it might be simpler to hardcode that configuration.
In any case, two alternatives have come out of this thread, the networkd alternative, and the configure-and-exit parameter to NetworkManager.
I think it best we leave this thread to die, and accept that others will not always do things your way and/or the Redhat/CentOS way, but go on their own path, and they will probably be happy to accept that this is their own creation and the risks associated with that (no support /
unknown behaviour in certain circumstances etc…). Their creation may address things that NetworkManager doesn’t do in the future, and if adopted everyone will benefit.
Is this the Catherdral or the Bazaar?
And for those interested in the NM changes Fedora Magazine just published this:
I’m of reasonable confidence we’ll see another bump in the NM version at 7.4 when it eventually hits beta so it’s worth looking out for the NM 1.6.0 and 1.8.0 changes.
`nmcli -g con sh ` will be lovely for scripting for instance and MACsec may see some love on corporate networks.
There doesn’t look to be any behaviour level changes that will be breaking like Alice faced before though … some outputs to differ if you are parsing specifically so check that.
One example that jumped out to me today was connection.zone (if using NetworkManager to define the firewalld zone of a connection which is not common yet) changes from “–” to “” when it’s not defined.
32 thoughts on - From Networkmanager To Self Managed Configuration Files
Sorry:
Can be a bug, because /etc/sysconfig/network isn’t nessesery.
Hello Guys,
update my post, because of a route from ipv6 on same networkcard, with only ipv4 enabled
Sincerely
Andy
Please accept this as honest constructive criticism from someone who also likes to blog.
On EL7 this is really bad advice:
You may be interested in this article of mine:
https://www.hogarthuk.com/?q=node/8
The recommended configuration for EL7 is to use NetworkManager unless you have a very specific edge case preventing you from doing so:
https://access.redhat.com/solutions/783533
The legacy network service is in effect deprecated, like net-tools was, as no new features are being released for it and no RFE’s are being accepted. All future work is on NetworkManager.
Note as well this article was last updated in 2014 – NetworkManager has been updated to handle more use cases than back then.
As always it’s best to check with the upstream documentation:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/index.html
Finally there was nothing to do with IPv6 in your article.
That address was an IPv4 address and the zeroconf stuff configures the
169.254.0.0/16 network as a ‘local link’ network on that interface.
If it was IPv6 it would have an address like fe80::33bb:5a14:be57:1690/64 … which is an IPv6 link local address.
Regards,
James
The truth is a lot of us run servers that don’t need to have their network “managed” by Networkmanager.
We just need to set an IP address, subnet mask, gateway, and DNS servers and we will never be changing that configuration ever again for the entire life of the server. Any 3-4 line script that does the job is sufficient, servers don’t need gimmicks, they’re not going to be hotspotting on wireless networks, the cable goes in, the server enters production and that’s it!
You’re opting to have your network managed by a bunch of unloved legacy scripts that you’re advised to avoid using unless necessary, or you’ve having it managed by NetworkManager. If you want to have it managing it this way, you’ll be writing your own scripts.
By 3-4 line script, I assume you mean the content of all the files in
/etc/sysconfig/network-scripts that aren’t your ifcfg files?
jh
ifconfig enp0s25 192.168.0.1 netmask 255.255.255.0
route add default gw 192.168.0.254 enp0s25
echo nameserver 8.8.8.8 > /etc/resolv.conf echo nameserver 8.8.4.4 >> /etc/resolv.conf
Oh okay, you really do want to back away from Redhat entirely. That’s entirely your choice.
What you end up with if you take this approach widely is effectively your own linux distribution.
jh
Not really, Redhat/CentOS has a lot to offer, but for me, networking is a one-time configuration, and the best way to configure it is using something that falls within this principle:
https://en.wikipedia.org/wiki/KISS_principle
I’m not flaming NetworkManager, I’m just stating that for many (perhaps most), it is over-engineered for a server orientated distribution. I can run with the script above on 30 server instances, and it doesn’t, as yet, break any of the other features of CentOS that I enjoy.
It means you’re stuck in your own hand crafted niche. Which is fine, but it’s up to you to maintain the niche, or you find yourself using obsolete tools like ifconfig and route.
I’d argue there’s a gulf between keeping things simple and doing things your own way.
jh
I’m sure there are drop in replacements for ifconfig and route, but even if deprecated I have not needed to revisit that script for many years, so I’m not changing it. When it does eventually break I have to look at four lines to discover where the problem might be, I can troubleshoot it by trying to run each line manually and see what is going on.
When qw hit a bug in NetworkManager that breaks something specific that you’re doing then you can try to raise a bug with upstream, or you could try to review the thousands of lines of code that make it up and try to fix the problem yourself.
Or perhaps you’ll do what I did, remove it and put in a 4 line script.
That’s nice … but what you’ve provided is terrible advice that doesn’t handle a wide range of scenarios such as teaming, bonding, vlans, bridging, network interface changes, race conditions of things dependent on networking or acting as part of the network.target or network-online.target systemd units which declare when network is ready …
If you want to do something unsupportable in any sane environment that is on you … but really please don’t suggest to those who don’t know better to carry out such activities.
I didn’t suggest you use anything, you asked me what script I used, I
gave you that information YMMV.
My experience was very difficult going to 7.2 to 7.3 because of a change in the behavior of NetworkManager with respect to IPv6 but once I had it figured out (thanks to people on this list) it worked out quite well and I kept NetworkManager.
But I certainly understand why some don’t want to do that.
That’s fine Alice (and I remember your issue well with the minimally documented change to stable-privacy by default for new systems … argh I still need to write up a blog article about that) but in this case the person concerned isn’t even using the network service, which if legacy and semi-deprecated is still supported, but just doing a ridiculous and unsupportable mini script (I’m guessing from rc.local?)
which doesn’t handle pretty much any actual networking issue that may come up – eg failed/delayed interface.
Hello James,
your right in that position. I will correct it.
Sincerely
Andy
I agree – they are trying to make it like windows, and when something doesn’t work correctly you have no clue what is going on in the black box!
Certain application doesn’t like the NetworkManager
for example take a look here.
https://www.rdoproject.org/install/quickstart/
And on server stage it’s better to run without any complicate configuration tools.
Tools can make life harder in some cases.
Got many other distros run before CentOS, why not.
I personally like it slim and easy.
Sincerely
Andy
Yes it is really hard!
ip address add 192.168.0.1/24 dev enp0s25
ip route add default via 192.168.0.254 dev enp0s25
echo nameserver 8.8.8.8 > /etc/resolv.conf echo nameserver 8.8.4.4 >> /etc/resolv.conf
I do not agree with your conclusions about NetworkManager. First, I use it on several servers and firewalls that – theoretically at least –
should never change. Some of the most tiresome problems I have had to fix were what happened due to renaming of NICs after replacing a bad one, or a 100Mb with a Gb NIC, or adding a new NIC to connect with a new network. NetworkManager keeps NIC naming consistent with no surprises. I
am getting ready to install two new NICs in a firewall/router that already has two NICs and I am not dreading that change as I would have with the old network service.
I have had excellent results with NetworkManager and am very happy with it. I see it as a significant improvement over the old network service. If you are concerned about performance issues – don’t worry – you won’t have any. It works fine on my RaspberryPI forewall/router using CentOS 7
for ARM and on my ancient EeePC that runs a full installation of Fedora 25.
Don’t try to fix something that isn’t broken.
This is still a deliberately trivial case, as already said, with no teaming/bonding/vlan type fun in the mix.
You’re free to disentangle yourself from the bits of CentOS you don’t like, and there’s nothing at all stopping you, but after a while what you’re supporting isn’t CentOS. I realise this is only one little part of the whole, but still.
jh
Let us have a vote – how many of us do teaming/bonding/vlans on our servers?
Our networking gear does that in our installation.
Hello David,
It was not to flame something about NetworkManager. There some application that “needs” to wheel the old way.
I would never have thought it would be such an enlightenment for such a small, old thing.
1. There is a file that isn’t always needed (/etc/sysconfig/network)
2. I wanne have the same result in the old style. (NOZEROCONF=yes)
And just by the way. My Desktop computer here runs with the NetworkManager.
1. Outside lan
2. A dummy bridge adapter fired by the NetworkManager
(With a island name server + dhcp for kvm)
3. An internal lan that can also run an CentOS Diskless computer.
That was not my intention; really not.
For a network starter it is an absolute must to know, how it works in practically. Not me.
Sorry
to
everyone
That makes little sense …
Without cooperation of both endpoints (switch and host) LACP is not possible (and this is generally the preferred teaming/bonding method).
Without cooperation of both endpoints (switch and host) trunking multiple vlans (ie the time you would actually tag) is not possible.
That ridiculous “script” doesn’t even handle the basic situation that the NIC interface didn’t come up for any reason …
The majority of my servers are virtual, if I need multiple subnets
(VLANs) then I have multiple cards. Their throughput does not require bonding, resiliency is performed at a different level – by having multiple load balanced VMs.
I have to admit, on one hypervisor I use VLANs, but actually use NetworkManager in that case – and it worked since installation, if I
have a problem with it in the future though, I will resort to scripting it as well :-) – It would be the simplest way for me to resolve the issue – I can’t afford to wait for patches to a monolithic, as you say, black-box system, which is in effect just trying to apply sanity checking a bunch of scripts in the first place.
I don’t add VLANs and Bonds on my servers for _fun_, they are there to run the applications and infrastructure – faffing around with that once a server is in production is just asking for trouble.
If you’d like a really simple solution that avoids NetworkManager, I
suggest using systemd-networkd (both systemd-networkd and systemd-resolved packages required). I’ve used it to set up a bridge on my workstattion for use with libvirtd/kvm, and it is just as simple a text file but future compatible. Heck, it probably even works on other distros that use systemd.
Here’s a super-simple static configuration:
# cat /etc/systemd/network/10-static-eno1.network
[Match]
name=eno1
[Network]
Address2.168.1.2
Gateway2.168.1.1
DNS2.168.1.1
You need to make sure that /etc/resolv.conf is a symlink
/run/systemd/resolve/resolv.conf if you want the systemd-resolved service to manage it. Just disable NetworkManager and network services and enable the systemd-networkd and systemd-resolved services.
Honestly, I’ve found systemd-networkd very useful for the more complex networking on my workstation (bridged VMs to external network) but its also useful for my tiny VMs that don’t need extra daemons running.
That’s interesting, I’ll snapshot and perhaps take that tangent on the next build and see how it goes.
Incidentally as far back as NM 1.0 (part of the 7.1 milestone but not part of the original 7.0 GA) it has supported a
‘configure-and-quit=yes’ option to just get the configuration right, emit the events etc needed to tell services/system network is configured and then get out of the way and not leave any running daemon:
https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS?h=1.0.0
I’ll give that a test as part of my upcoming article looking at how NM
has changed since the original 7.0 release.
Did I see an implicit “do as Red Hat says or else” there somewhere? Not appropriate. Linux is not Windows (yet). In the heat of the moment it may easily be forgotton that Linux is all about choice. We choose to run CentOS, and we choose to run it the way we see fit. We appreciate the efforts that go into the *Community* *Enterprise* OS, and if you have dealt with buggy crap like Ubuntu or Fedora, you appreciate it even more. This does not imply deference to upstream.
That statement about “effectively [running] your own Linux distribution” is scaremongering, at best. If there’s one thing I’ve learned on this list, it’s realizing how many use cases, scenarios and solutions there are that can make approaching the topic at hand without prejudice challenging at times.
You’re reaching here.
It’s simply there is good advice and sane management practices, and there’s bad advice and approaches to manage systems that have plenty of clear issues and step way outside of the documented and supported methods of handling things.
If you want to use a random script that has so many issues it’s even less supportable than the legacy network service, more power to you!
Just don’t advise people entering into this area to do that and don’t expect much help from those more knowledgeable in those areas who spend their own time assisting on the mailing list and IRC if you insist on jumping off the cliff with your homemade parachute after people have pointed out that patching it with small bits of cloth wasn’t the best of ideas …
I’ll obviously argue I wasn’t scaremongering. You can start with CentOS, and do anything you like with it, and as I’ve said, you’re absolutely free to do that. But at some point, you have to accept that what you’ve got left isn’t CentOS. If you don’t use what the distribution provides, what you’re doing isn’t the distribution. Given you’re getting no formal support on this, that possibly means little to you, but don’t be surprised by the community backing away from providing unofficial support to something that’s no longer CentOS.
You see this sort of thing in a more extreme way with things like cPanel.
jh
Well, let’s put it this way, the more someone argues that I need to run some software that I clearly don’t need, the more I become suspicious of what that software is doing. The network configuration of my servers is static, it doesn’t need to be changed once the server has booted up. So it doesn’t need some piece of software running away doing goodness knows what… I’m just going to be waiting for it to bug or error out and leave me high and dry without a network config.
I am not trying to suggest of encourage people to emulate what I have done, I have just been making a point that if you want to run something to manage your network configuration, and your network configuration is clearly not going to change, then it might be simpler to hardcode that configuration.
In any case, two alternatives have come out of this thread, the networkd alternative, and the configure-and-exit parameter to NetworkManager.
I think it best we leave this thread to die, and accept that others will not always do things your way and/or the Redhat/CentOS way, but go on their own path, and they will probably be happy to accept that this is their own creation and the risks associated with that (no support /
unknown behaviour in certain circumstances etc…). Their creation may address things that NetworkManager doesn’t do in the future, and if adopted everyone will benefit.
Is this the Catherdral or the Bazaar?
And for those interested in the NM changes Fedora Magazine just published this:
https://fedoramagazine.org/networkmanager-changes-improvements/
I’m of reasonable confidence we’ll see another bump in the NM version at 7.4 when it eventually hits beta so it’s worth looking out for the NM 1.6.0 and 1.8.0 changes.
`nmcli -g con sh ` will be lovely for scripting for instance and MACsec may see some love on corporate networks.
There doesn’t look to be any behaviour level changes that will be breaking like Alice faced before though … some outputs to differ if you are parsing specifically so check that.
One example that jumped out to me today was connection.zone (if using NetworkManager to define the firewalld zone of a connection which is not common yet) changes from “–” to “” when it’s not defined.