After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 753966 - [review] lr/multiple-vpn: support multiple VPN connections of the same type
[review] lr/multiple-vpn: support multiple VPN connections of the same type
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: VPN (general)
git master
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
: 504763 (view as bug list)
Depends on:
Blocks: nm-review 749951
 
 
Reported: 2015-08-22 15:09 UTC by Lubomir Rintel
Modified: 2016-05-31 15:16 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Lubomir Rintel 2015-08-22 15:09:58 UTC
A separate instance of the support plugin is spawned for each connection with a different bus name. The bus name is passed via --bus-name <name> argument.  Plugins that support the feature indicate it with support-multiple-connections=true key in the [VPN Connection] section.

The bus name is currently generated by adding a .<connection.uuid> to the VPN service name. It's guarranteed unique, but if it proves to be too long or ugly it can easily be replaced with something more meaningful (such as the same number as is used for connection's DBus name).

NMVpnService has been removed and folded into NMVpnConnection. A NMVpnConnection will spawn a service plugin instance whenever it is activated and notices the bus name it needs is not provided.

The NMVpnManager no longer needs to keep track of the connections in use apart for compatibility purposes with plugins that don't support the feature.

0a2342f vpn-manager: support multiple VPN connections of the same type
ba610f1 device: allow multiple vpn IP configurations
3ec15e2 vpn-connection: add nm_vpn_connection_get_service_type()
584a669 vpn-connection: export add nm_vpn_connection_get_service()
56819cf libnm-core: add nm_vpn_plugin_info_supports_multiple()

See OpenVPN plugin review for a plugin that works with this: bug #753965

http://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=lr/multiple-vpn
Comment 1 Lubomir Rintel 2015-08-22 15:11:28 UTC
*** Bug 504763 has been marked as a duplicate of this bug. ***
Comment 2 Beniamino Galvani 2015-08-23 10:00:43 UTC
I didn't test it, but in general the branch looks good to me; I only
have some minor suggestions below.

> device: allow multiple vpn IP configurations

+  g_hash_table_foreach (priv->vpn4_config, _ip4_config_merge_default, composite);

IIUC right now the order in which configurations are merged is not
determistic. Wouldn't it be possible to follow a predefined order when
merging them, like the order of activation, if it makes sense?

+  nm_device_set_vpn4_config (gpointer conn, NMDevice *self, NMIP4Config *config)

Probably only a matter of taste, but maybe keep self as first
argument?

> vpn-manager: support multiple VPN connections of the same type

+  /* This is only used for services that don't support multiple
+   * connections, to guard access to them. */
+  GHashTable *active_services;

+  if (   !nm_vpn_plugin_info_supports_multiple (plugin_info)
+      && g_hash_table_lookup (priv->active_services, service_name)) {

Only keys in hash table are used, right? So what about using
g_hash_table_add() and g_hash_table_contains() instead?

Also, pushed some trivial fixups.
Comment 3 Lubomir Rintel 2015-08-26 15:07:23 UTC
(In reply to Beniamino Galvani from comment #2)
> I didn't test it, but in general the branch looks good to me; I only
> have some minor suggestions below.
> 
> > device: allow multiple vpn IP configurations
> 
> +  g_hash_table_foreach (priv->vpn4_config, _ip4_config_merge_default,
> composite);
> 
> IIUC right now the order in which configurations are merged is not
> determistic. Wouldn't it be possible to follow a predefined order when
> merging them, like the order of activation, if it makes sense?

Reworked it to be a GSList.

> +  nm_device_set_vpn4_config (gpointer conn, NMDevice *self, NMIP4Config
> *config)
> 
> Probably only a matter of taste, but maybe keep self as first
> argument?

Yes, that was stupid. It's gone now though.

> > vpn-manager: support multiple VPN connections of the same type
> 
> +  /* This is only used for services that don't support multiple
> +   * connections, to guard access to them. */
> +  GHashTable *active_services;
> 
> +  if (   !nm_vpn_plugin_info_supports_multiple (plugin_info)
> +      && g_hash_table_lookup (priv->active_services, service_name)) {
> 
> Only keys in hash table are used, right? So what about using
> g_hash_table_add() and g_hash_table_contains() instead?

Yes. This also fixes bad reference counting -- removal from the hash was unreffing, but addition did not take a ref.

> Also, pushed some trivial fixups.

Thank you. Fixups applied.

Pushed a new version.
Comment 4 Beniamino Galvani 2015-08-28 09:22:36 UTC
> vpn-connection: export add nm_vpn_connection_get_service()
> vpn-connection: add nm_vpn_connection_get_service_type()

Can these 2 commits be squashed together? 

> device: allow multiple vpn IP configurations

+static void
+_ip4_config_subtract (gpointer value, gpointer user_data)
+{
+       NMIP4Config *dst = (NMIP4Config *) value;
+       NMIP4Config *src = (NMIP4Config *) user_data;
+
+       nm_ip4_config_subtract (dst, src);
+}

Not sure about this, but it seems that it should be the other
way around:

        NMIP4Config *dst = (NMIP4Config *) user_data; /* ext config */
        NMIP4Config *src = (NMIP4Config *) value;     /* vpn config */

The rest looks good to me (pushed some fixups).
Comment 5 Thomas Haller 2015-08-31 12:17:36 UTC
pushed a few fixups.

Also, the last commit is a WIP, of things that IMO should change. I think that is blocked on lr/applied-connection-bgo724041, because the latter refactors NMVpnConnection too.
Comment 6 Lubomir Rintel 2015-09-18 17:02:35 UTC
Squashed most fix-ups and rebased on top of the applied connection split.

> af337f5 libnm-core: add nm_vpn_plugin_info_supports_multiple()
> edc468c vpn-connection: export add nm_vpn_connection_get_service()
> f248939 device: allow multiple vpn IP configurations
> 9641ecd vpn-manager: support multiple VPN connections of the same type

> 7f0ce59 fixup! vpn-manager: support multiple VPN connections of the same type

Fine with me, but need to modify the VPN plugins to disconnect once they see NetworkManager drop off the bus, since upon the crashes we'll just loose track of the bus names and thus won't be able to sync up.

> d7301ad WIP: fixup! vpn-manager: support multiple VPN connections of the same type
> 3a3542f Revert "WIP: fixup! vpn-manager: support multiple VPN connections of the same type"

I'm not convinced it's worth keeping the plugin_info copy for the lifetime of the connection when we only need it to spawn the service plugin.

I'd prefer to drop it altogether.
Comment 7 Lubomir Rintel 2015-09-23 11:19:43 UTC
Updated the branch. Significant changes:

1.) Using a counter instead of uuid for the bus name. Based on NMSettingsConnection bus object name -- is nice to read and allows connection reactivation with a single plugin instance avoiding the hassle with disconnected plugin cleanup.

2.) Added a property that allows the NMVpnServicePlugin to self-disconnect when client that triggered the activation drops off the bus. Updated the OpenVPN plugin to use it.
Comment 8 Thomas Haller 2015-09-24 14:49:22 UTC
>> libnm/vpn-service-plugin: add watch-peer property
    
names when the daemon crashes leaving to nice way to clean up on respawn.
                                     ^^^^


-    if (details) {
-         priv->interactive = TRUE;
+    if (priv->dbus_watch_peer)
+         priv->peer_watch_id = watch_peer (plugin, context);
+
+    if (details)
          success = vpn_class->connect_interactive (plugin, connection, details, &error);
-    } else
+    else


why does it no longer set "priv->interactive = TRUE"? If this is correct, could you split that to a separate patch with a description of why?




+              g_dbus_connection_signal_unsubscribe (nm_vpn_service_plugin_get_connection (plugin),
+                                        priv->peer_watch_id);
 
whitespace.




I thought there should be a signal at the NMVpnServicePlugin that gets emitted when NM disappears. Then the plugin can do whatever they want (like disconnect).
When doing that, the signal should always be effective, not only while the plugin is in a connected state.





>> vpn-manager: support multiple VPN connections of the same type

Needs update of commit message.




+         do {
+              id = ++path;
+              path = strchr (path, '/');
+         } while (path);

is this any different from strrchr?


priv->bus_name = g_strdup_printf ("%s.Connection_%s", nm_vpn_connection_get_service (self), id);

I would drop the "Connection_" part.





pushed a few fixups
Comment 9 Thomas Haller 2015-09-24 15:00:31 UTC
I still don't agree with re-using the bus path.


Previously, there was only one path per plugin. Hence it also made sense that one plugin-process could be reused and handle multiple VPN (re-)connections.
It also made sense with running them in the terminal for debugging.


Now, we usually spawn new processes (at least when activating multiple connections at the same time).
You obviously must be able to change the D-Bus path, so when already supporting that without issues, why reuse in some cases? Why not mirror:

  /org/freedesktop/NetworkManager/ActiveConnect/6
and
  org.freedesktop.NetworkManager.openvpn.6


instead of

  /org/freedesktop/NetworkManager/Settings/34
with
  org.freedesktop.NetworkManager.openvpn.Connection_34




Also, it's unclear how the persistent-mode now works for VPN plugins. 
When a connection disconnects, it seems there is little reason for the plugin process to hang around waiting for another connection. Even with your current version, the plugin will only be reused when activating the same connection.

Also, how does persistent-mode now works for debugging? Specifying the d-bus path on command line seems overly cumbersome.
Comment 10 Lubomir Rintel 2015-09-28 19:51:33 UTC
(In reply to Thomas Haller from comment #9)
> I still don't agree with re-using the bus path.
> 
> 
> Previously, there was only one path per plugin. Hence it also made sense
> that one plugin-process could be reused and handle multiple VPN
> (re-)connections.
> It also made sense with running them in the terminal for debugging.
> 
> 
> Now, we usually spawn new processes (at least when activating multiple
> connections at the same time).
> You obviously must be able to change the D-Bus path, so when already
> supporting that without issues, why reuse in some cases? Why not mirror:
> 
>   /org/freedesktop/NetworkManager/ActiveConnect/6
> and
>   org.freedesktop.NetworkManager.openvpn.6
> 
> 
> instead of
> 
>   /org/freedesktop/NetworkManager/Settings/34
> with
>   org.freedesktop.NetworkManager.openvpn.Connection_34

We do already reuse the plugins and we need the old ones to work. There's no way to tell the plugins to release the bus name and die (aside from side-channels in addition to the bus interface such as sending a signal after the response for the Disconnect call). It would be possible to add a call for that, however we'd then need two different code paths for plugins that don't understand the new call and the new ones.

It would all be possible in theory, but I'm a bit reluctant to make the plugin API as well as the VPNConnection more complicated. Plus the known plugin paths and reusability of the name per SettingsConnection solves the debugability problem without further complexity.

> Also, it's unclear how the persistent-mode now works for VPN plugins. 
> When a connection disconnects, it seems there is little reason for the
> plugin process to hang around waiting for another connection. Even with your
> current version, the plugin will only be reused when activating the same
> connection.
> 
> Also, how does persistent-mode now works for debugging? Specifying the d-bus
> path on command line seems overly cumbersome.

It doesn't seem cumbersome to me. It's fairly easy to create the bus name. Other possibility is to just turn off the supports-multiple option in the .name file.
Comment 11 Thomas Haller 2015-09-29 10:25:39 UTC
(In reply to Lubomir Rintel from comment #10)
> (In reply to Thomas Haller from comment #9)
> > I still don't agree with re-using the bus path.
> > 
> > 
> > Previously, there was only one path per plugin. Hence it also made sense
> > that one plugin-process could be reused and handle multiple VPN
> > (re-)connections.
> > It also made sense with running them in the terminal for debugging.
> > 
> > 
> > Now, we usually spawn new processes (at least when activating multiple
> > connections at the same time).
> > You obviously must be able to change the D-Bus path, so when already
> > supporting that without issues, why reuse in some cases? Why not mirror:
> > 
> >   /org/freedesktop/NetworkManager/ActiveConnect/6
> > and
> >   org.freedesktop.NetworkManager.openvpn.6
> > 
> > 
> > instead of
> > 
> >   /org/freedesktop/NetworkManager/Settings/34
> > with
> >   org.freedesktop.NetworkManager.openvpn.Connection_34
> 
> We do already reuse the plugins and we need the old ones to work.

Old plugins use *one* static path. So, there is no problem there...

> There's no
> way to tell the plugins to release the bus name and die (aside from
> side-channels in addition to the bus interface such as sending a signal
> after the response for the Disconnect call). It would be possible to add a
> call for that, however we'd then need two different code paths for plugins
> that don't understand the new call and the new ones.

I agree and see some problems/questions. But I don't see how the choice of the path is the answer.


Example problem:
If you have a VPN plugin connected and NetworkManager crashes, the plugin with (example) path
  org.freedesktop.NetworkManager.openvpn.Connection_34
stays up.

Possible solutions:
  (1) NetworkManager on startup explicitly disconnects all pending plugins.
  (2) have the plugins notice the disconnect from NetworkManager itself (and 
    shutdown)
    Actually, your commit "libnm/vpn-service-plugin: add watch-peer property" 
    already goes that way...



What is actually gained by reusing the path?






> It would all be possible in theory, but I'm a bit reluctant to make the
> plugin API as well as the VPNConnection more complicated. 

It's unclear to me which API has to change (or which problem an API change would address).

> Plus the known
> plugin paths and reusability of the name per SettingsConnection solves the
> debugability problem without further complexity.

reusing the settings-name for the D-Bus path indeed is ~one~ possible answer to the persistence mode of the plugin. I claim that it makes persistent mode cumbersome to use, you say below that it would be acceptable for you. ACK to that.

> > Also, it's unclear how the persistent-mode now works for VPN plugins. 
> > When a connection disconnects, it seems there is little reason for the
> > plugin process to hang around waiting for another connection. Even with your
> > current version, the plugin will only be reused when activating the same
> > connection.
> > 
> > Also, how does persistent-mode now works for debugging? Specifying the d-bus
> > path on command line seems overly cumbersome.
> 
> It doesn't seem cumbersome to me. It's fairly easy to create the bus name.
> Other possibility is to just turn off the supports-multiple option in the
> .name file.

Disabling support-multiple in the namefile is a possible answer to the persistent question too...

Or just dropping persistent mode for new plugins altogether (!?)...

Or, use one static D-Bus path for persistent mode and NM always trying that path first (in the hope that there is a persistent plugin listening there).







I am only partly against "reusing the path" (but I don't see what it helps).
I dislike "reuse the path by tying it to a property of the NMSettingsConnection" -- be that the UUID or it's D-Bus path.

The reason is, that after a restart, it's not clear that that property still identifies the ~same~ connection (if ~same~ means something more then "same UUID/D-Bus path").
Yes, there is a chance that they are the ~same~ connection. But there is no strong guarantee about that, so the code anyway must handle the case where they are completely unrelated connections. So, what does it help in the first place?
Comment 12 Lubomir Rintel 2015-10-01 16:14:02 UTC
(In reply to Thomas Haller from comment #11)
> (In reply to Lubomir Rintel from comment #10)
> > (In reply to Thomas Haller from comment #9)
> > > I still don't agree with re-using the bus path.
> > > 
> > > 
> > > Previously, there was only one path per plugin. Hence it also made sense
> > > that one plugin-process could be reused and handle multiple VPN
> > > (re-)connections.
> > > It also made sense with running them in the terminal for debugging.
> > > 
> > > 
> > > Now, we usually spawn new processes (at least when activating multiple
> > > connections at the same time).
> > > You obviously must be able to change the D-Bus path, so when already
> > > supporting that without issues, why reuse in some cases? Why not mirror:
> > > 
> > >   /org/freedesktop/NetworkManager/ActiveConnect/6
> > > and
> > >   org.freedesktop.NetworkManager.openvpn.6
> > > 
> > > 
> > > instead of
> > > 
> > >   /org/freedesktop/NetworkManager/Settings/34
> > > with
> > >   org.freedesktop.NetworkManager.openvpn.Connection_34
> > 
> > We do already reuse the plugins and we need the old ones to work.
> 
> Old plugins use *one* static path. So, there is no problem there...
> 
> > There's no
> > way to tell the plugins to release the bus name and die (aside from
> > side-channels in addition to the bus interface such as sending a signal
> > after the response for the Disconnect call). It would be possible to add a
> > call for that, however we'd then need two different code paths for plugins
> > that don't understand the new call and the new ones.
> 
> I agree and see some problems/questions. But I don't see how the choice of
> the path is the answer.
>
> Example problem:
> If you have a VPN plugin connected and NetworkManager crashes, the plugin
> with (example) path
>   org.freedesktop.NetworkManager.openvpn.Connection_34
> stays up.
> 
> Possible solutions:
>   (1) NetworkManager on startup explicitly disconnects all pending plugins.
>   (2) have the plugins notice the disconnect from NetworkManager itself (and 
>     shutdown)
>     Actually, your commit "libnm/vpn-service-plugin: add watch-peer
> property" 
>     already goes that way...

Yeah, this problem seems like a solved one to me.

> What is actually gained by reusing the path?

Reusing the path makes it possible to use the same plugin instance for subsequent activations of the same connection. It seems like a good idea to me compared to the alternatives.

The alternatives are:

1.) extending the API with a call to make the plugin commit suicide after disconnect. That looks bad to me as it adds extra complexity to the plugin and introduces different code paths for the old and new plugins. It just doesn't seem worth the effort.

2.) Just not caring and letting the once-used plugins time out. That means repeated efforts to activate the same connection results in a lot of helpers waiting to time out.

> > It would all be possible in theory, but I'm a bit reluctant to make the
> > plugin API as well as the VPNConnection more complicated. 
> 
> It's unclear to me which API has to change (or which problem an API change
> would address).

API to make the unused plugin terminate itself. Solve the problem of an unused plugin being left around waiting for a timeout.

> > Plus the known
> > plugin paths and reusability of the name per SettingsConnection solves the
> > debugability problem without further complexity.
> 
> reusing the settings-name for the D-Bus path indeed is ~one~ possible answer
> to the persistence mode of the plugin. I claim that it makes persistent mode
> cumbersome to use, you say below that it would be acceptable for you. ACK to
> that.
> 
> > > Also, it's unclear how the persistent-mode now works for VPN plugins. 
> > > When a connection disconnects, it seems there is little reason for the
> > > plugin process to hang around waiting for another connection. Even with your
> > > current version, the plugin will only be reused when activating the same
> > > connection.
> > > 
> > > Also, how does persistent-mode now works for debugging? Specifying the d-bus
> > > path on command line seems overly cumbersome.
> > 
> > It doesn't seem cumbersome to me. It's fairly easy to create the bus name.
> > Other possibility is to just turn off the supports-multiple option in the
> > .name file.
> 
> Disabling support-multiple in the namefile is a possible answer to the
> persistent question too...
> 
> Or just dropping persistent mode for new plugins altogether (!?)...
> 
> Or, use one static D-Bus path for persistent mode and NM always trying that
> path first (in the hope that there is a persistent plugin listening there).

Yeah. There seem to be multiple solutions to that, I'd prefer the less complex/invasive options.

> I am only partly against "reusing the path" (but I don't see what it helps).
> I dislike "reuse the path by tying it to a property of the
> NMSettingsConnection" -- be that the UUID or it's D-Bus path.

What would be the other way to generate a reusable path then?

> The reason is, that after a restart, it's not clear that that property still
> identifies the ~same~ connection (if ~same~ means something more then "same
> UUID/D-Bus path").
>
> Yes, there is a chance that they are the ~same~ connection. But there is no
> strong guarantee about that, so the code anyway must handle the case where
> they are completely unrelated connections. So, what does it help in the
> first place?

After the restart the plugin is no longer there.

The bus name generated using NMSettingsConnection path makes it possible to reuse the same plugin instance in two subsequent activations of the same VPN connection in the same NetworkManager run. That is because it 1.) helps debugability by using a known bus name 2.) is the same things old plugins do, reducing differencies between old and new plugins 3.) solves the problems of dangling service plugins after subsequent reconnections of the same connections 4.) is (marginally) more efficient.
Comment 13 Thomas Haller 2015-10-02 12:46:18 UTC
I'd just do:

1.1) new-style plugins only support one activation. After disconnect (or after NM exits), they exit too. No exit-on-idle-timer anymore.

NM knows that too, and it doesn't try to reuse new-style plugins.

2.) old style plugins work as before, always using their static path and supporting retry.


1.2.a) either drop persistent (debugging) mode entirely.

1.2.b) In persistent mode, the plugin again uses a static path. Like:
  "org.fd.NM.openvpn.static". In that case, the plugin behaves like old-style.
  NM before activating a new-style plugin, checks if a plugin is available 
  as "org.fd.NM.openvpn.static" (and not yet connected). If so, it takes it 
  over and behaves like old-style. Otherwise, new-style, generating unique 
  path, spawning plugin, no-reuse.




To support 1.2.b, all you need is an extra check whether to treat the new-style-plugin as old-style (using the static path).
Comment 14 Lubomir Rintel 2015-10-05 16:51:49 UTC
Okay.

* Applied fixups
* rebased on master
* made clients exit on disconnect (if watching peers, which means they got a bus name and are probably tied to a single client)
* restored the per-service counter (the bus names are now predictable; "1.2.a)" options sounds sane to me now. not carved in stone -- we can improve it if it turns out to be too annoying for debugging)
Comment 15 Thomas Haller 2015-10-10 22:14:03 UTC
>> libnm/vpn-service-plugin: add watch-peer property


I don't understand why you remove
-         priv->interactive = TRUE;
from _connect_generic()? Could you do this in a separate commit, explaining why that is correct?



I think stopping to watch should happen inside nm_vpn_service_plugin_set_state(), not in nm_vpn_service_plugin_disconnect().

Or better: why is nm_vpn_service_plugin_set_state() even a public function? I think it should be private. It allows to sidestep a proper disconnect.
We still can remove this function. It's unstable API.



Pushed few fixups.


Otherwise, LGTM.
Comment 16 Lubomir Rintel 2015-10-13 14:56:41 UTC
Updated. The branch.

Removed get/set state; we do the state transition on disconnect and failed now.
A lot nicer for the plugins.
Comment 17 Dan Williams 2015-10-13 16:27:59 UTC
> device: allow multiple vpn IP configurations

Maybe instead of having a GSList, the VPN connection could simply pass a unique identifier (maybe even just it's 'self' pointer as a 'gconstpointer') to NMDevice, and NMDevice could use a hash table for the VPN configs instead of a GSList?  That would make it quite easy to replace the old/new configs without having to search the list, and would mean that the NMVpnConnection wouldn't have to keep the old configs around either.

> vpn-manager: support multiple VPN connections of the same type

The commit message talks about "<connection.uuid>" but I think it's actually "Connection_<object id>" right?


Other than that, LGTM.  Though maybe if the plugin supports multiple, it would be nice to get rid of bus names entirely and use a private server instance betwee NM and the daemon?  That way we don't have to care about bus names at all...
Comment 18 Lubomir Rintel 2015-10-13 16:30:16 UTC
master:

f0422bb merge: branch 'lr/multiple-vpn'
5b48bef vpn-manager: support multiple VPN connections of the same type
9bbf5e9 device: allow multiple vpn IP configurations
965363a vpn-connection: export add nm_vpn_connection_get_service()
6c213e3 libnm-core/vpn-plugin-info: add nm_vpn_plugin_info_supports_multiple()
fd61b21 libnm/vpn-service-plugin: remove nm_vpn_service_plugin_{get,set}_state()
78f263a libnm/vpn-service-plugin: quit when the peer we watch disconnects
9f15abb libnm/vpn-service-plugin: add watch-peer property
1bb5537 libnm/vpn-service-plugin: add a missing return
0650b0b libnm-core: fix documentation for DHCP_TIMEOUT ifcfg-rh variable

Note that this not only needs support of VPN plugins, but there's the 1.2.0 libnm (C) api breakage with the master versions of the plugins. Plugin updates forthcoming.
Comment 19 Lubomir Rintel 2015-10-13 16:31:09 UTC
Reopening this. Had a mid-air collision with the last comment when I merged it; will look into addressing that one.
Comment 20 Lubomir Rintel 2016-05-31 15:16:24 UTC
17:10 < klubko> thaller: i think there's no more work left there -- will close it. the suggestion to replace vpn[46]_config list with a hash would mean that the configurations are no longer applied in a stable order, which would be bad i think. i also think the separate 
                dbus instance is a bad idea in general, since that sort of defeats the purpose of the system bus and makes debugging harder.
17:11 < klubko> thaller: also, +1 for the required packages list
17:14 < dcbw> klubko: my comments are probably out-of-date by this point
17:14 < dcbw> I think we can probalby close and open new bugs for any additional improvements/issues