[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33832: The VPN service 'org.freedesktop.NetworkManager.openvpn' was
|
From: |
Tomáš Čech |
|
Subject: |
bug#33832: The VPN service 'org.freedesktop.NetworkManager.openvpn' was not installed. |
|
Date: |
Tue, 19 Feb 2019 21:10:30 +0100 |
|
User-agent: |
Mutt/1.11.2 (2019-01-07) |
On Thu, Jan 10, 2019 at 07:51:07AM -0500, Maxim Cournoyer wrote:
Debugging a bit further, it seems that my change to the
network-manager-service-type had the following effect:
A file populated at /etc/dbus-1/system-local.conf now has an include
directive for network-manager-openvpn:
--8<---------------cut here---------------start------------->8---
<includedir>/gnu/store/gw3ckmw2pihc44d23lc8pipfw7wr16g7-network-manager-openvpn-1.8.0/etc/dbus-1/system.d</includedir>
--8<---------------cut here---------------end--------------->8---
There is no /etc/dbus-1/system.conf file, which usually should source
the above system-local.conf, although the package holds a copy of it
such as
/gnu/store/5bda3bgy871dyb9cna4k7gnz002j88rq-dbus-1.12.6/share/dbus-1/system.conf,
and this file has:
--8<---------------cut here---------------start------------->8---
<!-- This is included last so local configuration can override what's
in this standard file -->
<include ignore_missing="yes">/etc/dbus-1/system-local.conf</include>
--8<---------------cut here---------------end--------------->8---
I'm not sure if it works though, because using the Emacs dbus support to
view the available definitions, I cannot see the ones from the
system-local.conf file:
--8<---------------cut here---------------start------------->8---
(require 'dbus)
(dbus-list-activatable-names ':system)
;; Results:
("org.freedesktop.DBus" ;
"org.freedesktop.UPower" ;from /etc/dbus-1/system-services
"org.freedesktop.GeoClue2" ;from /etc/dbus-1/system-services
"org.freedesktop.login1" ;from /etc/dbus-1/system-services
"org.freedesktop.UDisks2" ;from /etc/dbus-1/system-services
"org.freedesktop.ColorHelper" ;from /etc/dbus-1/system-services
"org.freedesktop.PolicyKit1" ;from /etc/dbus-1/system-services
"org.freedesktop.Accounts" ;from /etc/dbus-1/system-services
"org.freedesktop.ColorManager" ;from /etc/dbus-1/system-services
"org.freedesktop.nm_dispatcher") ;from /etc/dbus-1/system-services
--8<---------------cut here---------------end--------------->8---
So it could be that the system-local.conf file is not read in.
I've tried stracing the dbus-daemon (by attaching to it) as suggested by
Ludovic on #guix, but that doesn't mention anything about reading the
files.
So, to debug this further, I've added the documentation to dbus [1] and
in `man dbus-daemon`, we can read:
--8<---------------cut here---------------start------------->8---
DEBUGGING
If you're trying to figure out where your messages are going or why you
aren't getting messages, there are
several things you can try.
Remember that the system bus is heavily locked down and if you haven't
installed a security policy file to
allow your message through, it won't work. For the session bus, this is
not a concern.
The simplest way to figure out what's happening on the bus is to run the
dbus-monitor program, which comes
with the D-Bus package. You can also send test messages with dbus-send.
These programs have their own man
pages.
If you want to know what the daemon itself is doing, you might consider
running a separate copy of the daemon
to test against. This will allow you to put the daemon under a debugger,
or run it with verbose output,
without messing up your real session and system daemons.
To run a separate test copy of the daemon, for example you might open a
terminal and type:
DBUS_VERBOSE=1 dbus-daemon --session --print-address
The test daemon address will be printed when the daemon starts. You will
need to copy-and-paste this address
and use it as the value of the DBUS_SESSION_BUS_ADDRESS environment
variable when you launch the applications
you want to test. This will cause those applications to connect to your
test bus instead of the
DBUS_SESSION_BUS_ADDRESS of your real session bus.
DBUS_VERBOSE=1 will have NO EFFECT unless your copy of D-Bus was compiled
with verbose mode enabled. This is
not recommended in production builds due to performance impact. You may
need to rebuild D-Bus if your copy
was not built with debugging in mind. (DBUS_VERBOSE also affects the
D-Bus library and thus applications
using D-Bus; it may be useful to see verbose output on both the client
side and from the daemon.)
If you want to get fancy, you can create a custom bus configuration for
your test bus (see the session.conf
and system.conf files that define the two default configurations for
example). This would allow you to
specify a different directory for .service files, for example.
--8<---------------cut here---------------end--------------->8---
This should help in further debbugging the issue, along with this local
definition that enables the verbose mode of dbus:
--8<---------------cut here---------------start------------->8---
gnu/packages/glib.scm | 11 +++++++++++
modified gnu/packages/glib.scm
@@ -68,6 +68,7 @@
;; Export variables up-front to allow circular dependency with the 'xorg'
;; module.
#:export (dbus
+ my-dbus
glib
gobject-introspection
dbus-glib
@@ -156,6 +157,16 @@ or through unencrypted TCP/IP suitable for use behind a
firewall with
shared NFS home directories.")
(license license:gpl2+))) ; or Academic Free License 2.1
+(define my-dbus
+ (package
+ (inherit dbus)
+ (name "my-dbus")
+ (arguments
+ (substitute-keyword-arguments
+ (package-arguments dbus)
+ ((#:configure-flags flags)
+ `(cons "--enable-verbose-mode" ,flags))))))
+
(define glib
(package
(name "glib")
--8<---------------cut here---------------end--------------->8---
To be continued...
You seem to be on very right track. There is another unexpect problem
- NetworkManager doesn't seem to respect NM_VPN_PLUGIN_PATH in the
right place.
Try this quick patch:
From fc8bbfe018b4f19fb383391c71e3518a9c46e0f3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tom=C3=A1=C5=A1=20=C4=8Cech?= <address@hidden>
Date: Sun, 17 Feb 2019 13:23:43 +0100
Subject: [PATCH] respect NM_VPN_PLUGIN_DIR
---
src/vpn/nm-vpn-manager.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/src/vpn/nm-vpn-manager.c b/src/vpn/nm-vpn-manager.c
index 8e708d1..86238c9 100644
--- a/src/vpn/nm-vpn-manager.c
+++ b/src/vpn/nm-vpn-manager.c
@@ -223,6 +223,7 @@ nm_vpn_manager_init (NMVpnManager *self)
GSList *infos, *info;
const char *conf_dir_etc = _nm_vpn_plugin_info_get_default_dir_etc ();
const char *conf_dir_lib = _nm_vpn_plugin_info_get_default_dir_lib ();
+ const char *conf_dir_user = _nm_vpn_plugin_info_get_default_dir_user
();
/* Watch the VPN directory for changes */
file = g_file_new_for_path (conf_dir_lib);
@@ -241,6 +242,14 @@ nm_vpn_manager_init (NMVpnManager *self)
G_CALLBACK
(vpn_dir_changed), self);
}
+ file = g_file_new_for_path (conf_dir_user);
+ priv->monitor_etc = g_file_monitor_directory (file,
G_FILE_MONITOR_NONE, NULL, NULL);
+ g_object_unref (file);
+ if (priv->monitor_etc) {
+ priv->monitor_id_etc = g_signal_connect (priv->monitor_etc,
"changed",
+ G_CALLBACK
(vpn_dir_changed), self);
+ }
+
/* first read conf_dir_lib. The name files are not really user
configuration, but
* plugin configuration. Hence we expect ~newer~ plugins to install
their files
* in /usr/lib/NetworkManager. We want to prefer those files.
@@ -255,6 +264,11 @@ nm_vpn_manager_init (NMVpnManager *self)
try_add_plugin (self, info->data);
g_slist_free_full (infos, g_object_unref);
+ infos = _nm_vpn_plugin_info_list_load_dir (conf_dir_user, TRUE, 0,
NULL, NULL);
+ for (info = infos; info; info = info->next)
+ try_add_plugin (self, info->data);
+ g_slist_free_full (infos, g_object_unref);
+
priv->active_services = g_hash_table_new_full (g_str_hash, g_str_equal,
g_free, NULL);
}
--
2.20.1
HTH,
S_W
signature.asc
Description: Digital signature
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#33832: The VPN service 'org.freedesktop.NetworkManager.openvpn' was not installed.,
Tomáš Čech <=