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---
>/gnu/store/gw3ckmw2pihc44d23lc8pipfw7wr16g7-network-manager-openvpn-1.8.0/etc/dbus-1/system.d
>--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---
>
> /etc/dbus-1/system-local.conf
>--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?=
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