On Tue, 2016-06-14 at 08:22 -0400, Martin Langhoff wrote:
Hi Thomas, thanks for the explanation. It generally matches my understanding of the world :-) The odd thing is: this is a vanilla client connection, all the details are in ovpn file, I am connecting to OpenVPN servers. Import works, but the connection fails to connect. Debugging it is, um, nontrivial. It clearly tries, but it hasn't imported some setting or secret right.
Also, import silently ignores unknown values from the file. https://git.gnome.org/browse/network-manager-openvpn/tree/properties/import-export.c?id=96081a2c2e05f64d89433d150053291516bddd5e#n1409 Maybe that is a bug, but fixing it might mean that we fail to import a lot of connections that we imported previously (and which may actually work, as it is not clear that the ignored properties are essential).
You are right, NM starts the libexec binary. I've tried to debug connections in the past, and the best I could do was to replace /usr/libexec/nm-openvpn-server with a shell wrapper that logged the debug output. It is a pita if you're not an NM developer.
Another way to debug VPN plugins is https://wiki.gnome.org/Projects/NetworkManager/Debugging#Debugging_NetworkManager-openvpn With (not yet released) 1.4 you will also be able to enable debug logging of the plugin via nmcli general logging level KEEP domains VPN_PLUGIN:TRACE
Is there a way in which openvpn, called from the commandline, can call /usr/libexec/nm-openvpn-service-openvpn-helper ? :-) probably not, and you'll tell me I'm misguided.
if you pass --up /usr/libexec/nm-openvpn-service-openvpn-helper to openvpn, then it will act like as started by the plugin. But that wouldn't do you much good, because the helper tries to contact NetworkManager via D-Bus, which isn't expecting the request. From logging (above) or via `ps aux | grep openvpn` you can see the arguments passed to openvpn. You can then retrace what the plugin does and compare the result. Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part