Re: on nmcli improvements or needs of improvement

Francesco Giudici schreef op 19-05-2016 10:16:

Hi Xen,
thanks for sharing your thoughts, we are always glad to receive advice
on how to improve NetworkManager and make it more user friendly.

There is already a nCurses interface to NM: nmtui (please, give it a try!).
We found from the survey that only few know this tool but many of them
love it: this caught our attention and we are going to pay much more
attention to nmtui.

At the same time, we realized that nmcli should become easier to use and
more intuitive.
We want to preserve backwards compatibility to avoid breaking scripts
which make use of it, but this would not stop us from adding new
ways to do configurations in a more quick and intuitive manner.

Summing up, our commitment is to pay more attention to nmtui and make
nmcli more user-friendly.

Thank you man, that is very friendly.

At present day, present time I have little need for configuration, because I am using DHCP configured with static addresses at the DHCP server. That is in part, because manual configuration has been too troublesome for me at the client device, and because this makes it easier to have local DNS (dnsmasq).

But if and when I ever have a laptop again, which I needed to do more advanced configuration with (obviously wifi, roaming, but also VPN and some scripting for that) I will give everything a try again. I am glad NM is improving and I like and in that sense deeply love the direction it is going, because my feeling is that it is really getting better or at least that the people are "sobering up" or "wisening up" at least since version 1 I think, and that indeed things are going in a very nice direction, if that is not too belligerent for me to say (hostile, obnoxious, self-serving).

But of course I will give nmtui a try.... And I will say that.... the menu interface is very action oriented but does not provide much information or feedback. The program does not even provide what "nmcli c" provides (no parameters).

So currently for me that means there is no "background awareness" in the program. You start it, and have 3 options, but no information prior to selecting an option and that is not the way it should be. So because of that, it seems a collection of screens that provide each a single action also provided (likely) by nmcli, just you don't need to guess for the parameters now. However a real program would first show NM version, current IP configuration, current list of devices, etc. It would show devices to begin with (or interfaces, or active connections) with the ability to see stats on them, to deactivate them, etc. In essence, it would need to show, something similar to the output of the program "ifconfig" without parameters.

So any such system would need an "awareness mode" where you see:

- current hostname
- current connections (active, not active)
- possibly current routes
- currently assigned IP addresses

And from there, you would be able to select a connection and perform actions on them. You could call this "context-based operations". The same way GIMP doesn't have that :p. If you right-click an object in GIMP, you get the global menu, completely defeating the purpose of a right click (context menu).

So there are basically two modes: first select action, then object to perform it on (procedural, in a sense), and first select object, then action to perform on it (object oriented, in a sense).

And object oriented is always more natural unless you are selecting "tools" first. But in real life if you want to cut some paper, you first select the paper, position it, then select the scissors, and then work on the paper. You do not first select the scissors, then seek the paper you need to cut. So object manipulation is still the core of what people do.

So what you'd get is:

|                                                       |
| hostname.localdomain                         NM 1.0.6 |
|                                                       |
| Currently active connections:                         |
|                                                       |
|   Wired Connection 1                                  |
|                          enp3s0       |
|     fe80::cc9a:c827:9ff5:26d8            enp3s0       |
|                                                       |
|   Wireless Connection 1                               |
|                      wlp0s1       |
|                                                       |
| Currently inactive connections:                       |
|                                                       |
|   VPN 1                                               |
|   ---.---.---.---                        tun0         |
|                                                       |
| Add new connection                                    |
| List unused interfaces                                |

As a matter of speaking.

What has always bugged me about NM is that I couldn't use the (debian) oriented /etc/network/interfaces file anymore.

The NM configuration was harder to reach, and now there were 2 dispatch directories, with their own variables and execution style.

And in part, that is because the "connection" for NM supersedes the "interface".

Some people hold that "regular people" or "normal users" do not "want" to see the interface names. This is a sort of excuse for having chosen the zero-configuration "enp3s0" model by SystemD. Personally as soon as it matters to me I turn the thing off as quickly as I can. I prefer to see interface names, because as soon as I need to write any script, it matters to me. Any firewall script, it is going to matter to me. And some of the wifi names are very long when they use a MAC based naming scheme, or something similar.

Also in the past NM used to bug with the wifi. Occasionally it happened that my connection got corrupted, it went down, and I could not bring it up again without restarting NM. That implied a "service networkmanager restart" or something of the kind.

Because of this I had even created manual wpa_supplicant configurations and scripts, with the only real downside that roaming was now pretty much impossible, and I had no graphical feedback icons (in my KDE).

I also did not know how to transform my openvpn config script into a NM configuration. As a consequence I tried to stay away from NM for that: the thing worked outside of NM, why go through all that trouble to get it to work inside of it?

However eventually I realized, even though I did not know how to import my config, I could just set all of the same parameters. Then I had the amazing benefit of actually seeing in my GUI whether the VPN was active or not (lock icon). This is no exaggeration, this feedback was just instrumental because my VPN would sometimes fall away.

I was actually behind a "hotspot" type firewall, and though I still don't know how to recognise this the way some devices do (phones) I created some manual scripts that would recognise the "being walled" state, and that would then execute the form the user would normally be forced to click "accept" on (license terms) so that whenever I brought my wifi online, I would get automatically "logged in" (passing the routing blockade, so to speak). This was also pretty.... important to me because the wifi connection itself would sometimes fall away, and the sweet little system would forget you had already "authorized" and would ask you again to identify (accept the terms).

These scripts were first executed from /etc/network/if-up.d/ but I later put them in the NM dispatch directory (that I don't know by heart anymore).

At least I think I did.

Connecting was now 2 steps in the GUI: first bring up wifi, it would recognise being walled, execute the license terms acceptance script, and then I would manually activate VPN, and get on with it. Actually it was even more involved than that:

The firewall would also block VPN. Even on port 80. So I first had to initiate an SSH connection that would tunnel VPN over TCP :P.

So the former of my scripts, would not only bypass the firewall for regular port 80 traffic, it would then also activate SSH.

Then if the SSH connection dropped off, I would sometimes be in trouble as I had no visual indication of it. The firewall bypass system would sometimes bug out (at the server) causing pretty much no one in that building to be able to get online. So dropping the wifi was also not always an option ;-). Restarting wifi could mean no internet for days. There were days I was the only person with active internet because my wifi had been running for several days without interruption on my laptop.

So restarting NM, or downing the wifi and upping it again, was also not always an option ;-). Haha.

One more reason I could not rely on NM with its buggy wifi support....

So now I had to run scripts like "sshtest" that would tell me if my SSH tunnel was still up. If it wasn't, I had to manually restart it, but since it is not really a "connection" I could not automatically chain into the firewall bypass script, etc.

At which point I probably started doing "run-parts" on the directory with the scripts manually, I guess.

Because my SSH connection implied the VPN was actually being serviced from a localhost port, I could not automatically obtain the required routes. Principially, I needed one static route to the VPN host (at a distance) so that when the default route changed, I did not lose access to it. For some reason that was all I needed to do in the VPN config in NM.

I even tried (this was on OpenSUSE) to create different routing tables for "allowed" traffic (port 80, 443) and "disallowed" traffic (everything else) so that allowed traffic would not go over the VPN. However this failed and I never found out why my routing did not work.

I had created an additional routing table and then a single iptables rule that would "mark" the required connections, then a rule in "ip rule" (I believe) that would send that connection over the other routing table. But although I could see (by tcpdump) that my packets returned as they should, the kernel would never pass them on to my programs no matter what I did; and I had followed all the instructions to the letter.

So that is my story of using NM in this sense ;-). Perhaps a deviating story, an uncommon story, but at the same time: if this works for me, it is going to work for pretty much basically everyone ;-).

I'm sorry I did not intend to make this such a long story or message, but I seem to fail to express myself sometimes.

I am sorry if this does feel like a little obnoxious or unwanted feedback at this point. Or if it does feel self-serving or "belligerent".

I seem to use that word a lot but perhaps I am looking for something else; and I do not know if it exists in English ;-).

In any case if you did have a model that would allow for the configuration I just explained, it would be very powerful indeed.

That would probably require an SSH tunnel to become a "connection" in its own right, even thought it has no separate IP, and no separate interface either. It is just an SSH connection you start in "daemon mode". It contains forwards but executes no commands, nor does it open a remote shell. The -N flag. Also requires key-based login. Maybe we could design it some day.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]