Re: vpn and stuff

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

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 init

Could not send configuration information: The name
org.freedesktop.NetworkManager.openvpn was not provided by any

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
none" mode. You cannot get it (I cannot get it) to pass that
to OpenVPN.

It's a UI bug only (
You can still use the none cipher by configuring it either with nmcli
or by editing the connection file under /etc/NetworkManager/system

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 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 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
and such becomes impossible. I consider this a big problem. The
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

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 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 up

Then my link was up.

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


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.


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
renaming openvpn to openvpn.real. But that would be rather odd
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.


Thanks, Thomas.

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