HOWTO: Intercomunicate processes in different(remote) machines through DBus


Introduction

In this post I’m going to try to connect two processes in different machines through DBus. The method is a little bit complex, so be patient if you try.
Also is to advert that this has been the result of 3 days of tests (reference1). So maybe this method may be improved with time and use reference2.

Tools (The actors)

Debian official packages are dbus libssh-2 socat
gabriel is not part of Debian yet (but I’ve build one for myself)

Knowledge (Actors curriculum)

In this section I will describe the basics about the tools we are going to use.

DBus. Extracted from DBus page:

D-Bus is a message bus system, a simple way for applications to talk to one another. In addition to interprocess communication, D-Bus helps coordinate process lifecycle; it makes it simple and reliable to code a “single instance” application or daemon, and to launch applications and daemons on demand when their services are needed.

D-Bus supplies both a system daemon (for events such as “new hardware device added” or “printer queue changed”) and a per-user-login-session daemon (for general IPC needs among user applications). Also, the message bus is built on top of a general one-to-one message passing framework, which can be used by any two apps to communicate directly (without going through the message bus daemon). Currently the communicating applications are on one computer, or through unencrypted TCP/IP suitable for use behind a firewall with shared NFS home directories.

Gabriel is a simple utility to enable D-Bus clients to connect to a D-Bus daemon running on a remote machine, through SSH.
This is the main piece of this puzzle. If you are interested in understanding how it works you should take a look at socat and libssh.

Extracted from socat man page:

socat - Multipurpose relay (SOcket CAT)
socat is a command line based utility that establishes two bidirectional byte streams and transfers data between them. Because the streams can be constructed from a large set of different types of data sinks and sources (see address types), and because lots of address options may be applied to the streams, socat can be used for many different purposes. It might be one of the tools that one ‘has already needed´.

Libssh. Extracted from libssh page:

The SSH library was designed to be used by programmers needing a working SSH implementation by the mean of a library. The complete control of the client is made by the programmer. With libssh, you can remotely execute programs, transfer files, use a secure and transparent tunnel for your remote programs. With its Secure FTP implementation, you can play with remote files easily, without third-party programs others than libcrypto (from openssl).

You should know about SSH and about your application.

Architecture

Local host will run gabriel and your application.
Remove host will need a running SSH server, a running dbus server and will need socat installed and ready to use.
We need to run gabriel, that will act as a server that will connect our host to the remote host through SSH. After that gabriel will use this SSH connection to intercommunicate our local application with remote DBus applications by using socat.

Remote DBus communication

Remote DBus communication

Howto (Main action)

At the moment I’ve only achieved to connect a process using session-bus, I’m still testing until I get connection through system-bus which was my initial purpose.
After reading next information, you will be able to connect using session bus and system bus.

As I commented somewhere else, I’ve made some modifications on gabriel code. I needed some common parameters as SSH port (my virtualbox testing environment ), better help explanations or add a verbose output.
Gabriel establish a connection with the remote SSH and by socat commands it communicates with the remote DBus “environment”. You should administrate SSH parameters and Dbus parameters to gabriel.

user@machine:~/svn/gabriel/gabriel$ src/gabriel –help
Usage:
gabriel [OPTION...] - Gabriel
Help Options:
-?, –help Show help options
Application Options:
-h, –host=HOSTNAME Hostname or IP of the remote host
-p, –port-ssh=PORT-SSH SSH port on the remote host
-u, –username=USERNAME SSH username on the remote host
-w, –password=PASSWORD SSH password on the remote host
-m, –method=DBUS_TRANSPORT_METHOD The D-Bus transport method to use (TCP, UNIX, abstract-UNIX)
-b, –bind=HOSTNAME The bind-address to listen for D-Bus client connections on
-d, –bus-address=BUS_ADDRESS The DBus session bus address of the remote D-Bus daemon
-t, –port-tcp=PORT-TCP The TCP port to listen for DBus client connections on
-v, –verbose=VERBOSE Set verbosity level (3, 2, 1, 0, -1)=(packet,protocol,functions,important,none)

We have to put special attention to -d, –bus-address=BUS_ADDRESS because this info must be gotten from the REMOTE machine.
That address is the one used by processes to communicate through DBUS. It’s something “internal” and automatically done when you use DBus API/library. I’m going to show you where to get it.

DBUS_SESSION_BUS_ADDRESS, DBUS_SYSTEM_BUS_ADDRESS, DBUS_SYSTEM_BUS_DEFAULT_ADDRESS

Again, this info should be gotten from REMOTE machine.
At the moment I don’t know any nice command where to get this info.
We have two main options of DBus buses. System and Session (more info in DBus page).
If you need SESSION bus address, you can choose what it better fits you:

If you need SYSTEM bus address, you can choose what it better fits you:

Examples:

// C++ code
#include <stdio.h>
#include <stdlib.h>
char * env;
// env = getenv (”DBUS_SESSION_BUS_ADDRESS”);
env = getenv (”DBUS_SYSTEM_BUS_ADDRESS”);
if (env!=NULL){
cout << env << endl;
}

user@REMOTE-machine:~ $ grep -z BUS_ADDRESS /proc/2047/environ
HALD_RUNNER_DBUS_ADDRESS=unix:abstract=/var/run/hald/dbus-bonbZtoykd,guid=8b5aff565de0dc7c467fef414832dd98

This command gives you a dbus-daemon in your session with the one you can contact.

user@REMOTE-machine:~ $ dbus-daemon –session –print-address
unix:abstract=/tmp/dbus-j2npbTXDwD,guid=d69f66d43e354de5733e4a1a48335bd6

user@REMOTE-machine:~ $ grep unix /etc/dbus-1/system.conf
<listen>unix:path=/var/run/dbus/system_bus_socket</listen>

Howto (Main action): Back to local host

Those ugly unix:stri:ngs/asdkaj/numbers we have seen is what we need for -d, –bus-address=BUS_ADDRESS.
See a session example:

user@machine:~/svn/gabriel/gabriel$ src/gabriel -h localhost -p 2222 -d unix:abstract=/tmp/dbus-j2npbTXDwD,guid=d69f66d43e354de5733e4a1a48335bd6
Listening to D-Bus clients on: “unix:abstract=/tmp/gabriel”
bla ble blu bla

See a system example:

user@machine:~/svn/gabriel/gabriel$ src/gabriel -h localhost -p 2222 -d unix:path=/var/run/dbus/system_bus_socket
Listening to D-Bus clients on: “unix:abstract=/tmp/gabriel”
bla ble blu bla

The moment we have or gabriel server running we (may have nothing) need to set DBUS_XXX_BUS_ADDRESS. Many apps would use, or have, this environment variable to connect to a DBus instance and intercommunicate with other process.
This is is easy, DBUS_XXX_BUS_ADDRESS should be the address gabriel shows few instants after being launched.
When we have defined this environment variable (in command line) we can execute our app, and it will happily communicate with the remote DBus world.
Example:

user@machine:~/svn/dbusmm/trunk/examples/glib$ export DBUS_SESSION_BUS_ADDRESS=”unix:abstract=/tmp/gabriel”
user@machine:~/svn/dbusmm/trunk/examples/glib$ ./dbus-browser

dbus-browser is a program that uses a session bus.

Links and references
This page was originally created by El Demonio Negro and is distributed under a Creative Commons License