[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

sdwdate and sdwdate-gui development thread


#241

I guess it’s about https://github.com/QubesOS/qubes-gui-agent-linux/commit/1ddc9
While the file (/etc/X11/Xsession.d/98qubes-session) isn’t included in new package, it isn’t cleaned up on upgrade.


#242

marmarek:

I guess it’s about https://github.com/QubesOS/qubes-gui-agent-linux/commit/1ddc9
While the file (/etc/X11/Xsession.d/98qubes-session) isn’t included in new package, it isn’t cleaned up on upgrade.

So it would be sane to run

sudo rm /etc/X11/Xsession.d/98qubes-session

in the TemplateVM?


#243

That seems to have helped getting DBUS_SESSION_BUS_ADDRESS. Done in a test vm.

user@debian-8-standalone:~$ env | grep -i dbus
KONSOLE_DBUS_SERVICE=:1.14
KONSOLE_DBUS_WINDOW=/Windows/1
KONSOLE_DBUS_SESSION=/Sessions/1
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-bmHLGmCr9H,guid=673004c114b203e2a6fe5e4e5651065a

#244

It’already there in sys-whonix

user@host:~$ env | grep -i dbus KONSOLE_DBUS_SERVICE=:1.15 KONSOLE_DBUS_WINDOW=/Windows/1 KONSOLE_DBUS_SESSION=/Sessions/1 DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-nRS4BEcwDz,guid=ba968a50e2ec413f852b2eb65650f160


#245

On Sun, Nov 22, 2015 at 12:07:06AM +0000, Patrick wrote:


#246

So it would be sane to run

sudo rm /etc/X11/Xsession.d/98qubes-session

in the TemplateVM?

Yes.


#247

In the TemplateVM.

sudo rm /etc/X11/Xsession.d/98qubes-session

And reboot. (This is a bug to be fixed.)

Now, starting sdwdate-gui as user sdwdate works in a Qubes Debian VM.

kdesudo -u sdwdate /usr/bin/sdwdate-gui
kdesudo(1748) KDESu::KDESuPrivate::KCookie::getXCookie: No X authentication info set for display  ":0"

This is probably good enough now for sdwdate-gui’s purposes. @troubadour

However, the message kdesudo(1748) KDESu::KDESuPrivate::KCookie::getXCookie: No X authentication info set for display ":0" is apparently exclusive to Qubes. It isn’t shown in Non-Qubes-Whonix. Is this a known issue? Something we understand? Something that should be fixed? @marmarek


#248

Created https://github.com/marmarek/qubes-gui-agent-linux/pull/13 for it.


#249

The file does not exist in the templates whonix-gw or whonix-ws (and sys-whonix / whonix).


#250

This is good. It’s only a legacy leftover from old template versions.


#251

Not sure. I guess it’s about not using X auth cookies. Shouldn’t matter on a single-user system, I think.


#252

But still getting

[code]user@host:~$ kdesudo -u sdwdate sdwdate-gui
kdesudo(5697) KDESu::KDESuPrivate::KCookie::getXCookie: No X authentication info set for display “:0”

(process:5704): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Failed to connect to socket /tmp/dbus-1bNVKAWlWy: Connection refused
[/code]


#253

Me too. So in summary. The latest update… Qubes-Whonix issue… Using Qubes-Whonix 12.0.0.3.2.

kdesudo -u sdwdate /usr/bin/sdwdate-gui 
kdesudo(6970) KDESu::KDESuPrivate::KCookie::getXCookie: No X authentication info set for display  ":0" 


(process:6977): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Failed to connect to socket /tmp/dbus-pWnJI6dVn6: Connection refused

sdwdate-gui starts. The systray is fully functional. So this should be good enough for sdwdate-gui’s purposes. @troubadour

However, any idea where the dbus error is coming from? @marmarek


#254

DBUS_SESSION_BUS_ADDRESS is there.

env | grep -i dbus
KONSOLE_DBUS_SERVICE=:1.12
KONSOLE_DBUS_WINDOW=/Windows/1
KONSOLE_DBUS_SESSION=/Sessions/2
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-NYh5rp7Ed5,guid=98ade53e1ddf6dd8344bff0a56510b58

#255

Not fully functional. There is a few seconds lapse to open the gui message after clicking the icon, showing the dbus connection error every time.


#256

Guess kdesudo clears that environment. Is that really needed? What is the reason for starting it as a different user?


#257

Originally, I was wary of giving permission to the `rm’ command without password (in /etc/sudoers.d/sdwdate-gui). Now, it’s there in Qubes.
@patrick Otherwise, any other reason?


#258

In any case, you can allow in sudo a single rm including its parameter - which will work also on non-Qubes then.


#259

I am not sure anymore why we started sdwdate-gui as user sdwdate. Was probably convenient because of file permissions. Can surely be implemented some other way. Now what’s missing is something like sudo’s parameter -E (preserve environment). Doesn’t seem to exist for kdesudo. Perhaps for some other tool.


#260

It sdwdate-gui would be running as user, sudo -E will not be necessary. Anyway since that sudo call is password-less, standard sudo can be used instead of kdesudo, can’t be?