1 Nov
2009
1 Nov
'09
11:21 a.m.
Patrick Shirkey <pshirkey(a)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
through ssh.
The first one is to start socat[1] at both sides and use tcp for
connecting them:
dbus app <-> unix socket <-> socat <-> tcp over ethernet <-> socat
<-> unix socket <-> dbus daemon <-> dbus app
The other one is to use gabriel [2] at client side. Gabriel uses libssh
[3] to setup socat remotely and tunnels the dbus traffic over ssh
tunnel:
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.
[1] http://www.dest-unreach.org/socat/
[2] http://gabriel.sourceforge.net/
[3] http://www.libssh.org/
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>