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