I guess it’s about debian: use more proper way to call qubes-session · QubesOS/qubes-gui-agent-linux@1ddc9e6 · GitHub
While the file (/etc/X11/Xsession.d/98qubes-session) isn’t included in new package, it isn’t cleaned up on upgrade.
marmarek:
I guess it’s about debian: use more proper way to call qubes-session · QubesOS/qubes-gui-agent-linux@1ddc9e6 · GitHub
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?
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=673004c114b203e2a6fe5e4e5651065aIt’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
On Sun, Nov 22, 2015 at 12:07:06AM +0000, Patrick wrote:
So it would be sane to run
sudo rm /etc/X11/Xsession.d/98qubes-sessionin the TemplateVM?
Yes.
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
The file does not exist in the templates whonix-gw or whonix-ws (and sys-whonix / whonix).
This is good. It’s only a legacy leftover from old template versions.
Not sure. I guess it’s about not using X auth cookies. Shouldn’t matter on a single-user system, I think.
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]
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
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=98ade53e1ddf6dd8344bff0a56510b58Not fully functional. There is a few seconds lapse to open the gui message after clicking the icon, showing the dbus connection error every time.
Guess kdesudo clears that environment. Is that really needed? What is the reason for starting it as a different user?
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?
In any case, you can allow in sudo a single rm including its parameter - which will work also on non-Qubes then.
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.
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?