Re: vpn and stuff

[Xen <list xenhideout nl>]

Hi, thanks for your responses.

On 09/14/2015 02:10 PM, Thomas Haller wrote:
> You bring up so many different points, that it's hard to keep track of
> them. It would be better to discuss them individually or open Bugs for
> it.

I know, just imagine having to file bug reports for all of them ;-).

> KDE/plasma-nm design decision. Please open a bug.

Useless. It even seems to be a theme default. I don't know, it's 
system-wide. And I just don't know how much use it still is to 
contribute to KDE 4.... Anyway I just wanted to mention it. I just 
mentioned everything.


>  From your wrapper script, do you invoke the openvpn binary with "exec",
> contrary to "call"? That seems important.

I tried changing it to exec, but that didn't seem to make a difference.


> > /usr/lib/nm-openvpn-service-openvpn-helper --tun -- tun0 1500 1528
> > 10.8.0.6 10.8.0.5 init
> >
> > Could not send configuration information: The name
> > org.freedesktop.NetworkManager.openvpn was not provided by any
> > .service
> > files".
>
> your installation seems broken.

This happened when OpenVPN connected after the link had been lost for a 
while due to the tunnel disappearing, remember. Killing and reopening 
openvpn reinstates (reinstores, restores) it perfectly and then the 
error does not arise. I just don't know enough about NM to appreciate or 
evaluate or to be able to do something meaningful with your statement 
here; I just don't know what it means. All I know is that .... the error 
is related to this 'openvpn going ghost' thing.


> > Then you have the problem that NM doesn't know about OpenVPN's
> > "cipher
> > none" mode. You cannot get it (I cannot get it) to pass that
> > parameter
> > to OpenVPN.
>
> It's a UI bug only (https://git.gnome.org/browse/network-manager-openvp
> n/commit/?id=be63c404a146704e3e4840f050d5bdd63bc94826)
> You can still use the none cipher by configuring it either with nmcli
> or by editing the connection file under /etc/NetworkManager/system
> -connections/.

Is it an older version problem? I had already tried what you suggest, in 
that I edited /etc/NetworkManager/system-connections/MyVPNThing by 
adding "cipher=none" to the [vpn] section. See, I wasn't entirely 
unprepared before sending this email.

The point was that by inspecting the resulting command line of the 
OpenVPN process, I could see no --cipher option being added.

/usr/sbin/openvpn --remote localhost --comp-lzo --nobind --dev tun 
--proto tcp-client --port 1193 --auth-nocache --syslog nm-openvpn 
--script-security 2 --up /usr/lib/nm-openvpn-service-openvpn-helper 
--tun -- --up-restart --persist-key --persist-tun --management 127.0.0.1 
1194 --management-query-passwords --route-noexec --ifconfig-noexec 
--client --auth-user-pass --ca /etc/openvpn/cert.crt

And indeed my OpenVPN is defunct. This is why I added the wrapper 
script. Now I can turn off cipherless mode but it's a drag on my OpenVPN 
server since it's just a little machine.

My NM version is 0.9.10.0. Wah, you committed that today? :P.



> IP4_GATEWAY environment variable. See `man NetworkManager`
> Or `nmcli -t -f IP4.GATEWAY connection show uuid $CONNECTION_UUID`

Again, older version. I was looking to upgrading to 1.0 but the library 
thing confused me and I just wanted to compile myself. And I wasn't sure 
how to get it right with plasma-nm.

So I thought I'd just ask first. Replacing distribution-supplied 
packages with files you compile yourself is not always the easiest thing....

Currently installing a prepackaged 1.0.6.

It now has --cipher none. My apologies, I was just still on the "stable" 
version supplied by distros. :(.

IP4_GATEWAY is now also there (in the manual, and it works. Integrated).


> > When NM has a connection as managed, manual interference with IP
> > address
> > and such becomes impossible. I consider this a big problem. The
> > problem
> > does not arise with adding new IP addresses to any device.
>
> What is your basis to claim "impossible". It is possible. What issues
> did you encounter?

Maybe it can be done by /CONFIGURING/ NM to keep its hands off it. But 
that's the same as first making it managed and then unmanaging it. It is 
not possible by default. (How should anyone know about it? It's just 
hidden mystery).

> > The fallacy is to think or consider that NM is always fully
> > configured.
>
> You can configure default-routes externally. NM should not interfere if
> you set "ipv4.never-default=yes".

But that means NM will NEVER set the default route for that interface. 
Look, with OpenVPN you create like an inner block in which some local 
variables are changed, so to speak. When OpenVPN enters, it wants to 
change the default route for the existing interface (say wlan0) by 
removing that route (in a default config) and then adding a new route 
(default route) to another interface (call it tun0).

Then, when OpenVPN disconnects, this situation is reversed: tun0 0.0.0.0 
is removed, and the original is reinstated.

But without using NM's openvpn shit, NM is just going to be oblivious to 
any of that. It will apparently get some notification that the default 
route was deleted, and will think "hey, that's not right, let's put it 
back".

Now perhaps all of that IS possible but it requires study and learning 
and discovery that is not obvious to any user. If NM is some "addon" to 
the system it should behave as an addon, which is to not interrupt with 
the operation of the base system unless asked.

And not try to "replace" the entire base system, which means now 
suddenly there is an alien thing in my computer that I don't understand 
and which now controls everything, and I can't do anything anymore 
unless I ask for "permission" with my new alien friends. Or enemies.

It's like a coupe d'etat. I just have better things to do with my time 
than to learn how to make my computer behave /AS IT DID BEFORE/.

My hobby is not configuring this computer. I have better things to do. 
The computer is meant to serve me, not me serve it. But with all of 
these things (also SystemD, which is also from Red Hat ???).... that 
keep ruining existing functionality with the proposition that if you 
invest enough time, maybe you can have your old system back......

I find it is working against me. I know to do a certain thing, but the 
overlord is interfering and undoing my changes. Now I first have to 
follow a course in pleasing the overlord so he will let me be.

See, this is like a hierarchy where NM sits at the top. It is controlled 
from the top. It is not controlled from the roots.

NM does not respond to changes by providing a wrapper around that. It 
does not monitor, listen and obey. Instead it replaces what exists; now 
in addition to your regular /etc/openvpn/myvpn.ovpn you have one in 
/etc/NetworkManager/system-connections/ and it is fundamentally the same 
kind of thing. It is a VPN config file.

It would be terribly easy to parse existing VPN files. It would be a 
little harder and require more safeguards to modify existing ones. But 
it would be more integrated and if you could be sure the mapping to and 
from NM's configurator applet/UI would keep the data intact, having NM 
overwrite your files would not be an issue either.

Then you would approach what would be called "seemless integration" or 
"being the same system".

But to be that kind of thing NM must monitor and observe, and respond 
when needed; not interfere by default.

Not all of Linux's existing subsystems are all that amazing (e.g. 
ifupdown) but ifupdown's main flaw from my perspective is that it 
doesn't actually keep track of device states, no it depends on some run 
file it creates itself. NM is probably better in most respects from a 
functional and internal-model perspective, it just doesn't integrate at 
all with the existing base system, and that is it's (or my) problem ;-).

I never knew though that e.g. OpenSUSE does network config very 
different from debian based systems, it seems?.

There is not even any /etc/network/interfaces (anymore?).

But I considered the "interfaces" script-filter feature a better 
candidate for scripting something different, than NM. Simply because NM 
is hard to understand. And "man NetworkManager" doesn't document very 
much, at all.

So how are you supposed to know what to do? You're just sitting there 
needing to achieve something and you have no clue how to do it.

It's a case of first buying and reading a 300 page book on NM before you 
can go ahead and do something.

And all I want (in this case) is for my VPN to work. Or my eth0 IP 
address. When I first installed some Debian 7 server.....

I did

ifconfig eth0 192.168.1.2 up

Then my link was up.

5 seconds later, my IP address had disappeared from that link.

WTF.

20 hours later I discovered that something called "NetworkManager" was 
the culprit. Actually, it took much longer than that. Eventually I 
learned that I had to go into its config and set "managed" to false.

How was I supposed to know? Some alien thing was just messing with my 
system and I couldn't do anything about it (without more knowledge).

/I just wanted to have an SSH link going/.

/I didn't want to study "New Culprit in User Network Design" for 5 hours 
before I could get a SSH link up./

/I just wanted the thing to work like it always has. I just wanted to 
get a simple, static, 192.168 based network link up./

And it was no longer a simple thing.

Because the DEFAULT CONFIGURATION WAS TO SABOTAGE ANY MANUAL STATIC 
LINKS YOU PUT UP.

My system's default configuration was to mysteriously undo anything I 
did myself.



Can you imagine that most of Linux works this way? And it is getting 
worse. Most of Linux these days is like this:

1. You are writing a paper or letter or anything of value in your life
2. The program crashes.
3. The crash handler asks you to submit a bug report.
4. First you have to make a bug reporting account.
5. Then the bug reporting tool wants to download debug symbols worth 200 meg
6. Then it complains you are not supplying enough information in your 
bug report.
7. Finally after 45 minutes of not doing productive work, your bug/crash 
is reported.
8. The program still crashes regularly.

9. After ten years of trying to improve the crashing tool, you can 
finally continue where you left off, which was writing a paper or letter 
or anything of value in your life.


Perhaps it serves to note that usually people use computers to get work 
done; but the Linux system these days wants to have you invest time in 
it first before it allows you to do anything you want yourself. You are 
now a servant of the system.

It's like it's jealous of your time. No, spend time on meeeeeeeeee!.

NetworkManager, like these other things, is abolutely not no-fuss for me.



---------------------------------
"Networking on Linux can be painful, especially in comparison to other 
operating systems."

Pretty much only in terms of wlan roaming....

"You should never need to use the command line or configuration files to 
manage your network (unless you want to!); everything should "Just Work" 
as automatically as possible and never stop you from doing what you want 
to do."

Let us just rephrase that.

"Using the command line or configuration files to manage your network is 
a powerful thing and should continue to work. Any new management tool 
should not break existing workflows. Things that require no human 
intervention, should just work out of the box and continue to work out 
of the box."



"NetworkManager attempts to make networking as invisible as you want it 
to be."

Including its attempts to thwart you when you try to use an alternative 
system.

"Whether at home, work, or on the move, NetworkManager automatically 
connects to the last network you told it to connect to."

Except when there is no DHCP, then it will just try to ruin everything 
you do manually. Oh, it keeps doing that anyway.

"From wired to wireless to mobile broadband to Bluetooth, NetworkManager 
has you covered."

Not until you find the GUI configuration, which is pretty hard if there 
is no GUI. Actually; there was one, I just had no clue where the config 
screen was. Other than that, nmcli is not an easy tool. Editing config 
files for NM is exactly what you want to avoid. I forget how to use 
nmcli within days after having last used it.

It's just this jealousy thing you know. You want to be the most 
important thing in my life. You won't have me look to other women.

I am just broken with NM. Right now it works because the GUI is quite 
good and after several months I learned where the configuration screen 
entry point was located (not before asking on a mailing list...) (or 
forum) and until I learned that I had learned to put "managed" to false 
and that was about the extent of my ability. So I just try to get 
something concocted that would work with me.

But using wifi without a GUI is horror.

Using VPN without a GUI is quite horror.

It's now 8 months later and I am finally able to achieve more or less 
what is quite annoying in Windows (because I cannot script there) but 
regardless (if the scripts/tools would exist) would have been done in a 
day. And that's only the VPN part.

SystemD is also a jealous thing like that. It wants to own everything. 
It wants to be everything in your life. You will have no Init system 
besides systemD.

You will also have no process scheduler besides SystemD.

You will have no network interface naming scheme beside SystemD.

You will have no logging system beside SystemD.

You will have no way to access your logs other than through SystemD.

The list probably goes on, I just don't know about everything yet.

:-/.

---------------------------------




> > The issues with "forgetting" the OpenVPN process could be caused by
> > my
> > renaming openvpn to openvpn.real. But that would be rather odd
> > because
> > it would imply a dependency on the process NAME whereas it seems as
> > though NM takes care of a 'callback' feature in OpenVPN.
>
> Maybe it's "forgetting" the process, because your wrapper script spawns
> away. Did you use "exec"?

It seems NM kills any openvpn process when a timeout is exceeded, but it 
may do this in a way that was frustrated by the wrapper script. I did 
use exec. Now that the wrapper script is gone I cannot reproduce the 
"ghost vpn process" anymore.


> Thomas

Thanks, Thomas.