Carlos E. R. wrote:
On 2014-03-29 07:01, Linda Walsh wrote:
Carlos E. R. wrote: I am getting a bit farther, but I still get a connection timeout.
Could you tell me what you get when you type: echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n'
in the local client before 'ssh', and then the same on the remote client. +++······························· cer@Telcontar:~> echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n' unix:abstract=/tmp/dbus-jaontsAgqI,guid=4ce03300a65d0c645e8d245a533036b7 cer@Telcontar:~> ssh -X cer@AmonLanc.valinor Password: Last login: Sat Mar 29 22:14:34 2014 from telcontar.valinor Have a lot of fun... cer@AmonLanc:~> echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n' cer@AmonLanc:~> ······························· So on Telcontar, you have only the DBUS_SESSION_BUS_ADDRESS set, but when you login, you don't get anything passwd..
That's a laptop without gnome nor kde installed, because it is old and I use LXDE. It has some gtk and qt libraries, as required by dependencies by other packages - like meld, the qt flavour of yast, gkrellm...
---- That meaning 'AmonLack.valinor?
An this my relatively modern laptop, with both gnome and kde installed, I think. Gnome is installed, I tried it recently. KDE I don't remember:
······························· cer@Telcontar:~> ssh -X cer@minas-tirith.valinor Password: Last login: Sat Mar 29 22:22:22 2014 from elessar.valinor Have a lot of fun... cer@minas-tirith:~> echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n'
I.e minas-tirith is a newer laptop you are logging into? (sounds a bit topsy turvy -- i.e. normally one logs in from laptops to a server, but you are loggin from ??something to 2 different laptops -- assume for testing?
cer@minas-tirith:~> ·······························++- On both machines meld works remotely. Both have Intel graphics.
--- AFAIK, meld doesn't try to use 3D graphics, so that shouldn't matter... what's happening is meld on the remote machine is trying to contact or register with the session manager of the "you" who is logging into the machine (at least that what it appears to be doing in my situation.
In my case, I have: law.Bliss> echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n' tcp:host=Athenae.hs.tlinx.org,port=47000,guid=94e7aeae46abdf95e9562eea53362166
Curious, mine says "unix:abstract".
---- unix:abstrict is "sorta" the default. The above is partly from /etc/dbus-1/session.conf -- where you specify the address for it to listen on. Since I want Athenae to hear Ishtar's request, I setup a tcp host+port for it to connect to -- that's what the 'conversation' I looked at with Wireshark was going to/from.
1808 12582913 law.Bliss> ssh ishtar
But it will not work that way, you need -X or -Y.
---- Those -X is enabled in my /etc/ssh/sshd_config file... as it's something I always want. #AllowAgentForwarding yes #AllowTcpForwarding yes #GatewayPorts no X11Forwarding yes #X11DisplayOffset 10 --- Though it doesn't matter too much, since my DISPLAY!=localhost:xxxx, but DISPLAY=athenae.hs.tlinx.org:0 So it doesn't go through ssh anyway (it's a secure line -- I mean it's a direct connect from my computer to the other (no routers/switches... just card->card). And the other "-Y", is in my /etc/ssh/ssh_config file...for similar reasons: ForwardX11Trusted yes # RhostsRSAAuthentication no
Ishtar:law> echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n' tcp:host=Athenae.hs.tlinx.org,port=47000,guid=94e7aeae46abdf95e9562eea53362166
1808 12582913 i.e. -- they show the same. But in the console, I see: (minus the python tracebacks) (meld:8431): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Because you are not using -X nor -Y, and it appears you have a dbus active, meld tries to use it, and fails, of course, it is on a different machine.
---- Well.. both are in effect, actually, BUT it should make no difference, as they should be able to go direct -- which is what I see on the wire. I.e. ishtar(remote) sends some security 'auth' question to the local machine -- and local machine sends back authorization denied.
In my case, I do not have a dbus on that session, so meld does not try.
--- On which sess...oooo....*blink*....OOOOOO.... so meld doesn't need a session to run. *lightbulb* ARG!... I had read the manpage for dbus and it told me to put code in my bashrc to have it set... So for this util it doesn't need setting!
Look: ...
Well, I do not get a dbus, but you see meld fails completely if I don't use the "-X" option to ssh. A different reason, thoug, it doesn't say anything about dbus.
Both machines behave the same.
Yah... my case was cuz I read in the manpage that I needed to have it set when I logged in. Also, an "icing on the cake thing" would be if I had an app running on a remote desktop that tried to lauch a browser, ideally it would launch it locally from my local machine rather than brining up firefox over X... But just getting things to working some... Hey... was able to bring up plasma desktop. Yips .. 1st time in ~ 3 years... Though my 'X' server kept crashing when I tried to drag the activities bar at the bottom off to the side. But wallpaper had fade-in/fade-out, Bouncy ball bounced around... it was only slightly "laggy" for the little testing I did... but for a remote desktop... not be... this is progress... Tried to download new widgets and they would just 'fail'... not sure why. That one's sorta annoying -- remember that working at one point as well.. But progress was had and there was much rejoicing in the land!... ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org