Patrick Shirkey <pshirkey@xxxxxxxxxxxxxxxxx> 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>
Attachment:
pgpeCeHvrjB4o.pgp
Description: PGP signature
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
