Re: on nmcli improvements or needs of improvement

[Xen <list xenhideout nl>]

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                                  |
|     192.168.1.5                          enp3s0       |
|     fe80::cc9a:c827:9ff5:26d8            enp3s0       |
|                                                       |
|   Wireless Connection 1                               |
|     192.168.103.144                      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.

Regards.