Mailinglist Archive: opensuse (929 mails)

< Previous Next >
[opensuse] we don't need no stinkin' dbus...(was Re: progs failing due dbus dependency additions;)
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups