NetworkManager 1.0 Released After Ten Years Development

An anonymous reader writes: After ten years of development focused on improving and simplifying Linux networking, NetworkManager 1.0 was released. NetworkManager 1.0 brings many features including an increasingly modernized client library, improved command-line support, a lightweight internal DHCP client, better Bluetooth support, VPN enhancements, WWAN IPv6 support, and other features.

Comments

NetworkManager

[NotInHere]

One of the few unix command line tools whose command begins with a major letter.

Re:NetworkManager

[fustakrakich]

Why isn't it just a thin wrapper on systemd?

Oh, that's cold, man!

Re:NetworkManager

[fnj]

All you have to know about the NetworkManager abortion is that you can disable the service and remove the package. Then the operating system's own network configuration files, dhclient and everything, like, actually work as intended and documented.

Re:NetworkManager

[thegarbz]

Yes and then you just use the commandline to handle failover of network interfa.... eh no.
Well you can use the commandline to automate the connection to preferred wireles.... no?
What about moving between netwo...

Ahh fuck it I'm re-installing NetworkManager. A turd of a system service with a turd of a user interface is better than busting open the command line every time I do something as mind mindbogglingly complicated on my laptop as plugging in a network cable.

It may have its warts, but it does what it says on the box. It simplifies network management in a time where networks are not a single solid stable connection to the host. You wouldn't want it on a server, but you wouldn't want to be without it on pretty much any other use case.

Re:NetworkManager

[kthreadd]

Modern NetworkManager releases also include a handy tool called nmtui which is basically the GUI implemented in curses. Nmcli can sometimes be a bit unintuitive so it's a good thing to have around.

Re:NetworkManager

[Eric Green]

Yes, NetworkManager should be fine on most servers. Unless you want to use network bonding. And VLANs. And bridges. Nevermind bridged VLAN's (yes, those are a thing) on top of 802.3Ad bonds. And ... and... well, 90% of the other functionality that is offered by the Linux networking stack. NetworkManager works fine for managing the 10% of the network stack that is used 90% of the time. For the other 10% of the time, it is an abortion that should be taken out back of the barn and shot like a rabid dog. And this other 10% that NetworkManager won't do is 99% of why people pay me big bucks to make Linux do what they need it to do, since you will not get high performance networking out of a server using the limited functionality provided by NetworkManager. As in, the servers I work with generally have at least half a dozen gigabit NICs and two 10Gbit NIC's. NetworkManager won't get me 1/10th of what I need to put these servers into the midst of a large network for use in server consolidation, and is utterly useless once we start talking about Open vSwitch and other such SDN components.

So sure, if you're a sandwich shop putting a $500 server under the cash register, or you are a teenage college student setting up a video sharing network for your bro's in the flop house you board in, NetworkManager will work fine for you. For those of us doing anything more complex, it is a useless abomination and the first thing done when bringing up a new server image is "chkconfig NetworkManager off ; service NetworkManager stop". (Or the AbominationD equivalents thereof).

Re:NetworkManager

[fisted]

One of the few unix command line tools whose command begins with a major letter.

Sorry, but there's nothing unix about NetworkManager.

Re:NetworkManager

[Antique Geekmeister]

> All you have to know about the NetworkManager abortion is that you can disable the service and remove the packag

It's unfortunately built into most installers toolkits, so it's difficult to avoid completel, and more tools have unnecessary dependencies on it. So deleting it can lead to re-installing it

With RHEL based sysysstems, at least, the simplest way to block it is to put "NM_CONTROLLED=no" in the "/etc/sysconfig/network. That helps ensure it stays disabled, until, and unless you specifically select it for any network port..

Re:NetworkManager

[WoodstockJeff]

"With RHEL based sysysstems, at least, the simplest way to block it is to put "NM_CONTROLLED=no" in the "/etc/sysconfig/network. That helps ensure it stays disabled, until, and unless you specifically select it for any network port.."

If NM is installed, even telling it to not control a network interface is insufficient to keep it from interfering with that interface. Just a week ago, I installed a new NIC in a server, configured it manually with NM told to leave it alone. 12 hours later, the server disappeared from the network. It didn't crash, it just disconnected, because NM decided to take over control of the NIC.

Why? Because I had not put the MAC address into the configuration. Seems NM will ignore NM_CONTROLLED=no if you don't tell it the MAC address. So my fixed-IP server suddenly became a dynamic-IP workstation, with DNS pointing to the wrong network and a different gateway.

So, no, I'm not going to leave NM installed on any machine that is NOT moving around the country using WiFi.

Re:NetworkManager

[LordLimecat]

As someone who is deeply familiar with networking but only vaguely familiar with Linux's arcane ways of configuring its network-- which apparently change drastically depending on such things as:
  * whether you want it to be per-session (ifconfig)
  * or persistent (/etc/DependsOnYourDistro/someFiles)
  * whether it should actually persist with the interface rather than how the kernel decides to allocate /devs to the actual interface
and so on-- I am quite happy to see NetworkManager. THere is no reason that setting up a bonded or tagged interface should be more complicated than saying it verbally, or why I should have to fall back to CLI in order to do that.

Heres a fun tip: not everyone wants to be a full-time Linux admin devoted to a particular breed of distro. Some of us have a job in supporting a very wide array of systems, and the less arcane black magic we need to learn for each individual system the better. Historically Linux's networking has been AWFUL, as just a few years ago it was considered normal for a box's IP-to-interface mapping change on reboot because apparently its logical that the OS randomly assign interface IDs to physical interfaces, and there were roughly a hundred different methods and places to configure all of the various networking pieces (resolvers, mac addresses, firewall, bonding, vlans, device/interface mapping).

It boggles my mind that there are people who think that complexity for complexity's sake is a good thing. CLI is wonderful for batch operations that you do every day. GUI is wonderful for things you will do once a month, and dont want to use mental bandwidth for remembering a command.

Re:what's wrong with ifconfig?

[Narcocide]

Those are too simple and reliable. For Linux to compete with mainstream operating systems it needs more complexity and more bugs.

mask NM

[Anonymous Coward]

The most important feature is that it can be disabled, masked and unistalled without loosing functionality, as oppposed to other new TM things that I can't get rid of that easily

Re:what's wrong with ifconfig?

[Narcocide]

Probably, and probably also pulseaudio.

Never heard of it

[gweihir]

And I have been a constant Linux user since 1994. This cannot be too important.

Re:Never heard of it

[SeaFox]

The best software does its job quietly and doesn't need a bunch of attention from the user, allowing your to do your actual work.
Something that seems to be lost on the makers of many other software projects, OSS and commercial.

Re:It's totally superfluous

[Yosho]

And these guys spent 10 years simplifying that?

No, they spent 10 years simplifying things like scanning for wireless access points, detecting the encryption type, and storing credentials. Or setting up routing over Bluetooth. Or configuring and switching between different types of VPNs. Or bridging between multiple interfaces. And having a little icon in your system tray that you can right-click on to do it all.

If the only thing you ever do is set a static IP for your ethernet card then you probably don't need it, but a lot of people do more complex things than that.

Re: It's totally superfluous

[bill_mcgonigle]

oh, does bridging work finally? I spent well over an hour with nmcli docs and on Google trying to setup bridges for each vlan I was using on an el7 machine and got nowhere close to working. Spent 5 min setting up redhat ifcfg- files and was done after yum uninstalling nm. It says that nmcli got some love in 1.0, and boy that's a good thing.

Re:what's wrong with ifconfig?

[hobarrera]

On Linux? To connect to WPA2 networks (including WPA2+802.1X). That's an everyday scenario for a pretty much every laptop user.

Sure, you can also do it via cli (with more tools than just those you mentioned), but, do you remember all the steps? Can you teach them to your mum? Can you automate it?

Re:It's totally superfluous

[hobarrera]

> It's hard to see how one could simplify Linux networking. It requires one ip addr command to set an IP address and one ip route command to set a default route. And on IPv6 even those are unnecessary, it's automatic.

And a dns, too. And the wireless network name. And the wireless network username+password.

And then, I have to do it all again in two minutes when you walk out of range. And then again when you get home. And then again at a cafe.

NM might not be the nicest of things, but it sure beats the hell out of running several commands every time I relocate myself/my laptop.

I like NetworkManager, but....

[DerPflanz]

Since NetworkManager, day-to-day network use (be it WiFi, wired or whatever) Just Works. I like that.

However, when (as a developer, hardware-tinkerer or network problem solver) you are plugging in and out cables, connecting devices, etc, it would be nice to have NetworkManager to be put on "mute" or something. Just keep my fixed IP on the correct devices and stop enabling and disabling connections. That's the only time I turn the service off.