[LAD] remote dbus and ladish. Was: gets confused when used through ssh -X
nedko at arnaudov.name
Sun Nov 1 15:20:22 UTC 2009
Patrick Shirkey <pshirkey at boosthardware.com> writes:
> I don't see much point of storing a local copy of a ssh tunneled config
> file. If you are tunnelling the config file should be accessed from the
> remote machine. It's different if you are using multiple qjackctls on
> the same desktop and connecting to local jackd instance/s as well as
> netjack'd instances on remote machines. That seems like a heavy deal and
> as Nedko has mentioned previously it can actually be managed by the LADI
> tools now although that requires running dbus too which is not to
> everyones liking.
Yesterday, I've booted my wife`s windows machine from an Ubuntu LiveCD
and made some remote dbus tests. There are two options to initiate this
The first one is to start socat at both sides and use tcp for
dbus app <-> unix socket <-> socat <-> tcp over ethernet <-> socat <-> unix socket <-> dbus daemon <-> dbus app
The other one is to use gabriel  at client side. Gabriel uses libssh
 to setup socat remotely and tunnels the dbus traffic over ssh
dbus app <-> unix socket <-> gabriel <-> ssh over ethernet <-> socat <-> unix socket <-> dbus daemon <-> dbus app
Gabriel`s approach is of course better in long term, because dbus
traffic is encrypted and because it sets remote part automatically. Bad
news about gabriel is that last commit is from February 2007, it needs a
patch to work with latest libssh (0.3.4) and it allows only one client
to use the local unix socket.
Both approaches have restriction because of the EXTENRAL dbus
authentication mechanism. That mechanism sends unix user id and it is
matched remotely. So in order remote dbus to work, uids should be
same. Of course this is lame and I already have plan for this: the
client side (gabriel/ladish), can get the remote uid through ssh and
change the uid "token".
Plan for the remote capable ladish is to take the gabriel`s
approach. Requirements for the remote (aux) hosts will be - ssh server,
dbus, jackdbus and socat. Requirements for the local (central) host will
be ssh client, libssh, dbus, jackdbus, ladish. ladish will provide dbus
service that will act as manager for remote dbus connections. Such
service could be reused for other remote dbus purposes and as such could
be a separate project (or could be made as part of gabriel).
Multihost ladish is planned for the 2.0 release and wont happen anytime
soon unless someone with high motivation steps to work on this.
I'd like to ask users of multiple-jack-servers-on-same-host (Fons?) to
explain what it is used for and how it works. As I personally dont use
such setup I can't make ladish suitable for such setups without
feedback. Same applies for remote jack management and netjack but I've
gathered some knowledge because of the obvious netjack popularity.
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 188 bytes
Desc: not available
More information about the Linux-audio-dev