Hi, I'm currently reading the upstream "Considerations in adopting RHEL 8" document. The chapter about networking states that traditional networking scripts (shipped with the network-scripts package) are considered obsolete. I bluntly admit I don't see the point in this. As far as I'm concerned, I've been a happy user of NetworkManager since the early days (when folks used to call it NotworkManager :oD). It's one of those nifty pieces of software that brought the Linux desktop to the masses - or at least a bit nearer to them - since it allows managing wireless and wired interfaces transparently and easily on a laptop or any computer with a wireless card. On servers though, one of the first post-installation steps I performed was to get rid of Network-Manager and all its components. The servers I'm working on are relatively small-scale and have from one to four network interfaces. Each interface has a corresponding configuration in /etc/sysconfig/network-scripts, and that's it. From there, I rarely - if ever - touch it. In all my setups, NetworkManager is merely a useless layer of abstraction, and I like sticking to the KISS principle and shave off useless layers. Maybe there's a reason to make NetworkManager more or less mandatory from now on, but I don't see it. So I thought I'd rather ask on this list. Cheers from the foggy South of France, Niki -- Microlinux - Solutions informatiques durables 7, place de l'?glise - 30730 Montpezat Site : https://www.microlinux.fr Mail : info at microlinux.fr T?l. : 04 66 63 10 32 Mob. : 06 51 80 12 12
On Mon, 10 Feb 2020 at 02:55, Nicolas Kovacs <info at microlinux.fr> wrote:> Hi, > > I'm currently reading the upstream "Considerations in adopting RHEL 8" > document. The chapter about networking states that traditional networking > scripts (shipped with the network-scripts package) are considered obsolete. > > I bluntly admit I don't see the point in this. As far as I'm concerned, > I've > been a happy user of NetworkManager since the early days (when folks used > to > call it NotworkManager :oD). It's one of those nifty pieces of software > that > brought the Linux desktop to the masses - or at least a bit nearer to them > - > since it allows managing wireless and wired interfaces transparently and > easily > on a laptop or any computer with a wireless card. > > On servers though, one of the first post-installation steps I performed > was to > get rid of Network-Manager and all its components. The servers I'm working > on > are relatively small-scale and have from one to four network interfaces. > Each > interface has a corresponding configuration in > /etc/sysconfig/network-scripts, > and that's it. From there, I rarely - if ever - touch it. In all my > setups, > NetworkManager is merely a useless layer of abstraction, and I like > sticking to > the KISS principle and shave off useless layers. > > Maybe there's a reason to make NetworkManager more or less mandatory from > now > on, but I don't see it. So I thought I'd rather ask on this list. > >The reason is that having 1 way to configure networks makes it so the developer and tech support only have to diagnose issues from 1 set of tools versus two different ones (and occasionally 2 competing ones if both are trying to do their job at the same time). Basically network-scripts has been on the backburner for 10+ years and has to be dusted off every now and then to add a new networking corner case or some other item. For the developer it usually means context swapping back from python (or whatever language they prefer) to bash and then figure out what the problem is.. cause a couple of new ones they then have to fix and then get it right. Or they could do that work in 1 language they know and get it done. Does it makes sense to us as sysadmins who are happy with a working set of scripts and configs we have to know possibly rewrite? No it doesn't.. but unless one of us takes over the network-scripts and puts in the work to make it work in all the different layers (or pay someone to do so).. we get what the soup kitchen serves :). -- Stephen J Smoogen.
Once upon a time, Stephen John Smoogen <smooge at gmail.com> said:> The reason is that having 1 way to configure networks makes it so the > developer and tech support only have to diagnose issues from 1 set of tools > versus two different ones (and occasionally 2 competing ones if both are > trying to do their job at the same time).Not only that - the hodge-podge bash network scripts are kind of a mess. It is impressive that they do what they do so reliably after so long, but every new feature appears to have been hacked in by a different developer, leaving parts of them almost indecipherable. That's not intended as a criticism of the scripts or the people who wrote that code - it's just that IMHO they managed to go beyond what is reasonable in bash scripting, which makes for a difficult to read (and I'm sure fix/extend) set of scripts. And even on servers now, there are often dynamic network changes that work much better with NetworkManager than the old-style static scripts. Containers, VMs, and VPNs all come and go, and work better with a single system configuring their networks (rather than each layer implementing their own setup). -- Chris Adams <linux at cmadams.net>
On 09/02/2020 23:55, Nicolas Kovacs wrote: Hi Nicolas, [snip]> Maybe there's a reason to make NetworkManager more or less mandatory > from now on, but I don't see it. So I thought I'd rather ask on this list.Like you, I read about NetworkManager becoming the default tool for CentOS 8. So I sat down with a colleague to figure out how we could use NetworkManager, and convert our existing network configs (on CentOS 6 and 7) to work with NetworkManager. I'm sad to report that we ran into at least 3 issues (listed below). We found solutions to the first two, but the last one was a show-stopper, and we came to the conclusion that for servers, NetworkManager is still overkill, and for us, actually unusable. So even on CentOS 8, we will keep using the legacy scripts. 1. When NetworkManager activates interfaces, it does not wait for IPv6 DAD to complete. This makes systemd reach the "network-online" target before IPv6 is fully initialised, and some daemons fail to start. We eventually found a work-around, but not before I'd lost some of my hair. 2. NetworkManager doesn't know how to activate dummy interfaces from ifcfg-dummy* files. You have to create dummy interfaces directly in NetworkManager. This is not a problem on CentOS 8, but on CentOS 7, there is a subtle issue with loading the dummy module that makes things fail at boot. We again found the solution, but it's annoying that none of it was documented. 3. Some of our servers run full routing daemons (BIRD), and have multiple route tables. On these, when we start NetworkManager, it attempts to read the entire route tables into memory using the netlink API. This makes it log lots of errors. Then, NetworkManager's RAM usage goes up and up, going to over 3 GB!! Finally, it barfs and dies. And then systemd starts it again, and it goes and does the same. We have NOT been able to find any solution to this stupidity of NetworkManager. And so we have made the choice to abandon it, and remain with legacy network scripts. Regards, Anand
> On 09/02/2020 23:55, Nicolas Kovacs wrote: > > Hi Nicolas, > > [snip] > >> Maybe there's a reason to make NetworkManager more or less mandatory >> from now on, but I don't see it. So I thought I'd rather ask on this >> list. > > Like you, I read about NetworkManager becoming the default tool for > CentOS 8. So I sat down with a colleague to figure out how we could use > NetworkManager, and convert our existing network configs (on CentOS 6 > and 7) to work with NetworkManager. > > I'm sad to report that we ran into at least 3 issues (listed below). We > found solutions to the first two, but the last one was a show-stopper, > and we came to the conclusion that for servers, NetworkManager is still > overkill, and for us, actually unusable. So even on CentOS 8, we will > keep using the legacy scripts. > > 1. When NetworkManager activates interfaces, it does not wait for IPv6 > DAD to complete. This makes systemd reach the "network-online" target > before IPv6 is fully initialised, and some daemons fail to start. We > eventually found a work-around, but not before I'd lost some of my hair. > > 2. NetworkManager doesn't know how to activate dummy interfaces from > ifcfg-dummy* files. You have to create dummy interfaces directly in > NetworkManager. This is not a problem on CentOS 8, but on CentOS 7, > there is a subtle issue with loading the dummy module that makes things > fail at boot. We again found the solution, but it's annoying that none > of it was documented. > > 3. Some of our servers run full routing daemons (BIRD), and have > multiple route tables. On these, when we start NetworkManager, it > attempts to read the entire route tables into memory using the netlink > API. This makes it log lots of errors. Then, NetworkManager's RAM usage > goes up and up, going to over 3 GB!! Finally, it barfs and dies. And > then systemd starts it again, and it goes and does the same. > > We have NOT been able to find any solution to this stupidity of > NetworkManager. And so we have made the choice to abandon it, and remain > with legacy network scripts.Thanks for confirming that NetworkManager is not the solution for everyone. To me it seems that NetworkManager was developed by laptop users for laptop users and that's why it is what it is today. Useful for laptops/desktops and simple server setups. Unfortunately, instead of fixing/refactoring the whole bash networking script mess, another new project was started instead, called systemd-networkd :-) Regards, Simon
hi, On Mon, Feb 10, 2020 at 8:55 AM Nicolas Kovacs <info at microlinux.fr> wrote:> Hi, > > .... > On servers though, one of the first post-installation steps I performed > was to > get rid of Network-Manager and all its components. The servers I'm working > on > are relatively small-scale and have from one to four network interfaces. > Each > interface has a corresponding configuration in > /etc/sysconfig/network-scripts, > and that's it. From there, I rarely - if ever - touch it. In all my > setups, > NetworkManager is merely a useless layer of abstraction, and I like > sticking to > the KISS principle and shave off useless layers. >Interesting philosophical discussion but using centos means you need to go with whatever red hat decides, so if they say so, then you have few options. I must admit I have long refused to use networkmanager, but since centos 7 it has been rock solid. And as we use config tools (salt right now, but it is the same with the rest of the competition) I do not really care what they use to abstract the network configuration as long as it works. And work it does, so everybody is happy. Another huge selling point is that it is what cockpit uses to configure the network interfaces, and cockpit is really nice for less advanced users. So our more junior people can get their feet wet using cockpit, and we can automate everything using configuration management, and both tools use the same api so nobody gets left behind. Tab completion makes it easy to use, too ;-) In the end, my take is: whoever comes after me needs to understand whatever we were doing, so let's just sitck with what the vendor provides (regarding the operating system) and use best of breed tooling to manage it (which may or may not be what the OS vendor recommends, but can fit better the business's requirements). -- regards from the sunny Netherlands, natxo