[opensuse-factory] xauth and now gone ~/.Xauthority
Hi, what's the canonical way to run scripts (eg. from crontab), that want to access the X session, (eg. xprop, wmctrl), now that xauth is a random file in /run/user/$UID? Before the switch, it was possible to run such scripts from crontab, using the pattern: XAUTHORITY=~/.Xauthority DISPLAY=:0 ~/bin/script Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Donnerstag, 3. September 2020, 20:45:30 CEST schrieb Hans-Peter Jansen:
Hi,
what's the canonical way to run scripts (eg. from crontab), that want to access the X session, (eg. xprop, wmctrl), now that xauth is a random file in /run/user/$UID?
Before the switch, it was possible to run such scripts from crontab, using the pattern:
XAUTHORITY=~/.Xauthority DISPLAY=:0 ~/bin/script
Scratch that. Florian provided the magic spell: "xhost +si:localuser:$USER" does the trick. Sorry for disturbance. Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hans-Peter Jansen wrote:
Hans-Peter Jansen wrote:
Before the switch, it was possible to run such scripts from crontab, using the pattern:
XAUTHORITY=~/.Xauthority DISPLAY=:0 ~/bin/script Scratch that.
Florian provided the magic spell: "xhost +si:localuser:$USER" does the trick. You can also use this command line. It takes the newest xauth_* file for XAUTHORITY
XAUTHORITY=$(ls -1t /run/user/$(id -u)/xauth_*|head -n1) DISPLAY=:0 ~/bin/script Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Sep 3, 2020 at 5:14 PM Bjoern Voigt
XAUTHORITY=$(ls -1t /run/user/$(id -u)/xauth_*|head -n1) DISPLAY=:0 ~/bin/script
Yes, but you should not do this, the xhost...solution is the correct one, the location of this file is an implementation detail. Note that this change implies that the real possible lifetime of the file changed from "possibly forever" to "gone after the user session ends" ..the latter is certainly what the desired and expected behaviour was in the first place... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hans-Peter Jansen wrote:
Am Donnerstag, 3. September 2020, 20:45:30 CEST schrieb Hans-Peter Jansen:
Hi,
what's the canonical way to run scripts (eg. from crontab), that want to access the X session, (eg. xprop, wmctrl), now that xauth is a random file in /run/user/$UID?
Before the switch, it was possible to run such scripts from crontab, using the pattern:
XAUTHORITY=~/.Xauthority DISPLAY=:0 ~/bin/script
Scratch that.
Florian provided the magic spell: "xhost +si:localuser:$USER" does the trick.
Would that possibly help with the x11vnc issues, too? See boo#1174493 Are you having that xhost line as default somewhere in your profile(s)? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Montag, 7. September 2020, 10:40:42 CEST schrieb Peter Suetterlin:
Hans-Peter Jansen wrote:
Am Donnerstag, 3. September 2020, 20:45:30 CEST schrieb Hans-Peter Jansen:
Hi,
what's the canonical way to run scripts (eg. from crontab), that want to access the X session, (eg. xprop, wmctrl), now that xauth is a random file in /run/user/$UID?
Before the switch, it was possible to run such scripts from crontab, using the pattern:
XAUTHORITY=~/.Xauthority DISPLAY=:0 ~/bin/script
Scratch that.
Florian provided the magic spell: "xhost +si:localuser:$USER" does the trick. Would that possibly help with the x11vnc issues, too? See boo#1174493
Are you having that xhost line as default somewhere in your profile(s)?
From ~/.profile:
# allow the local user to execute X dependent programs test -n "$DISPLAY" && xhost +si:localuser:$USER &>/dev/null Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, On Thu, Sep 03 2020, Hans-Peter Jansen wrote:
Am Donnerstag, 3. September 2020, 20:45:30 CEST schrieb Hans-Peter Jansen:
Hi,
what's the canonical way to run scripts (eg. from crontab), that want to access the X session, (eg. xprop, wmctrl), now that xauth is a random file in /run/user/$UID?
Before the switch, it was possible to run such scripts from crontab, using the pattern:
XAUTHORITY=~/.Xauthority DISPLAY=:0 ~/bin/script
Scratch that.
Florian provided the magic spell: "xhost +si:localuser:$USER" does the trick.
This week I installed a new Tumbleweed desktop (snapshot 20201002) where I use lightdm and fluxbox window manager. Each X application (xeyes, xterm, Firefox) seemed to work fine but complained to stderr with error message "No protocol specified" sometimes several times ...until I added the above xhost command to the fluxbox startup script. After doing that the message is gone. Is this anything to be concerned about? Can anyone guess what the problem is/was? The applications working but not having permission to access some protocol specification? Thanks, Martin -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, Am Mittwoch, 7. Oktober 2020, 12:52:02 CEST schrieb Martin Jambor:
Hi,
On Thu, Sep 03 2020, Hans-Peter Jansen wrote:
Am Donnerstag, 3. September 2020, 20:45:30 CEST schrieb Hans-Peter Jansen:
Hi,
what's the canonical way to run scripts (eg. from crontab), that want to access the X session, (eg. xprop, wmctrl), now that xauth is a random file in /run/user/$UID?
Before the switch, it was possible to run such scripts from crontab, using the pattern:
XAUTHORITY=~/.Xauthority DISPLAY=:0 ~/bin/script
Scratch that.
Florian provided the magic spell: "xhost +si:localuser:$USER" does the trick.
This week I installed a new Tumbleweed desktop (snapshot 20201002) where I use lightdm and fluxbox window manager. Each X application (xeyes, xterm, Firefox) seemed to work fine but complained to stderr with error message "No protocol specified" sometimes several times ...until I added the above xhost command to the fluxbox startup script. After doing that the message is gone.
The .Xauthority entry contains the hostname used for the X11 connection. So if the local hostname changes, it would no longer find the correct entry. To work around that, DMs and libxcb are patched to set and read the $XAUTHLOCALHOSTNAME environment variable, which is used as a fallback. In case the first try with the current hostname doesn't work, it prints the error message and tries again with the fallback.
Is this anything to be concerned about? Can anyone guess what the problem is/was? The applications working but not having permission to access some protocol specification?
This is harmless and works as intended, though you can avoid that by making the hostname fixed. You can compare the value of $XAUTHLOCALHOSTNAME with the output of "hostname". The "modern" way is to use FamilyWild as wildcard entry which matches anything, but those only really work if the $XAUTHORITY file is temporary per session. Cheers, Fabian
Thanks,
Martin
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 9/3/20 1:45 PM, Hans-Peter Jansen wrote:
what's the canonical way to run scripts (eg. from crontab), that want to access the X session, (eg. xprop, wmctrl), now that xauth is a random file in /run/user/$UID?
There isn't a canonical way, because there is no guarantee that there is an X-session at the time the crontab script runs. My old scripts are still working (but I don't run them from crontab). I use: XAUTHORITY=${XAUTHORITY:-$HOME/.Xauthority} I've been using that incantation for 20 years. The change you are seeing appears to be a change to SDDM. If you are using GDM, it is still /run/user/uid/gdm/Xauthority and if you are using "lightdm" it is still $HOME/.Xauthority -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
04.09.2020 05:10, Neil Rickert пишет:
On 9/3/20 1:45 PM, Hans-Peter Jansen wrote:
what's the canonical way to run scripts (eg. from crontab), that want to access the X session, (eg. xprop, wmctrl), now that xauth is a random file in /run/user/$UID?
There isn't a canonical way, because there is no guarantee that there is an X-session at the time the crontab script runs.
My old scripts are still working (but I don't run them from crontab).
I use:
XAUTHORITY=${XAUTHORITY:-$HOME/.Xauthority}
I've been using that incantation for 20 years.
The change you are seeing appears to be a change to SDDM.
If you are using GDM, it is still /run/user/uid/gdm/Xauthority
No. I have GNOME+Wayland and Xwayland $XAUTHORITY has random name under /run/user/$UID. Oh, and by the way, and what this script does under Wayland? :)
and if you are using "lightdm" it is still $HOME/.Xauthority
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 9/4/20 12:54 AM, Andrei Borzenkov wrote:
04.09.2020 05:10, Neil Rickert пишет:
I use:
XAUTHORITY=${XAUTHORITY:-$HOME/.Xauthority}
I've been using that incantation for 20 years.
The change you are seeing appears to be a change to SDDM.
If you are using GDM, it is still /run/user/uid/gdm/Xauthority
No. I have GNOME+Wayland and Xwayland $XAUTHORITY has random name under /run/user/$UID.
With Gnome-Wayland, I get /run/user/1001/.mutter-Xwaylandauth.3HPMQ0 and yes, part of that is random. But I think Xwayland is started in the Gnome session, rather than by GDM. Using GDM, if I login to Gnome-X11 or to Plasma or to Icewm, I get XAUTHORITY=/run/user/uid/gdm/Xauthority (where the "uid" is a number), as previously indicated. If I try Plasma-Wayland with Leap 15.2, I get the same as what SDDM is now doing in Tumbleweed -- namely /run/user/uid/xauth_random
Oh, and by the way, and what this script does under Wayland? :)
I'm not sure who you are asking. But if you are asking about that script fragment that I gave: XAUTHORITY=${XAUTHORITY:-$HOME/.Xauthority} that just uses $XAUTHORITY if it is already defined, and otherwise uses $HOME/.Xauthority -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Freitag, 4. September 2020, 18:17:19 CEST schrieb Neil Rickert:
On 9/4/20 12:54 AM, Andrei Borzenkov wrote:
Oh, and by the way, and what this script does under Wayland? :)
I'm not sure who you are asking. But if you are asking about that script fragment that I gave: XAUTHORITY=${XAUTHORITY:-$HOME/.Xauthority}
that just uses $XAUTHORITY if it is already defined, and otherwise uses $HOME/.Xauthority
Hmm, I guess, Andrei wanted to point out, that such scripts are rather pointless on Wayland, and probably even wanted to scrutinize, why we are sticking with X still.. We are, Andrei. Do we have a decent remote desktop option for Wayland available? Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
04.09.2020 20:41, Hans-Peter Jansen пишет:
Do we have a decent remote desktop option for Wayland available?
There are implementations for at least GNOME and KDE; how decent they are I cannot say. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Sep 04, 2020 at 10:36:17PM +0300, Andrei Borzenkov wrote:
04.09.2020 20:41, Hans-Peter Jansen пишет:
Do we have a decent remote desktop option for Wayland available?
There are implementations for at least GNOME and KDE; how decent they are I cannot say. So none for Wayland.
Niether GNOME nor KDE is Wayland. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/7/20 9:37 PM, Michal Suchánek wrote:
On Fri, Sep 04, 2020 at 10:36:17PM +0300, Andrei Borzenkov wrote:
04.09.2020 20:41, Hans-Peter Jansen пишет:
Do we have a decent remote desktop option for Wayland available?
There are implementations for at least GNOME and KDE; how decent they are I cannot say. So none for Wayland.
Niether GNOME nor KDE is Wayland.
I believe that due to wayland's "more secure" design, any remote desktop setup needs to be integrated into the compositor (KDE/Gnome). Wayland apps can't see other application windows or send or read other applications key / mouse events. This means that things like remote desktop / synergy etc need to be intergrated into the compositor so the compositor handles sending events and rendering application windows. (Unless the protocol has been extended since I last looked in which case not all desktops may support it anyway). -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Thu, Oct 08, 2020 at 07:27:27PM +1030, Simon Lees wrote:
On 10/7/20 9:37 PM, Michal Suchánek wrote:
On Fri, Sep 04, 2020 at 10:36:17PM +0300, Andrei Borzenkov wrote:
04.09.2020 20:41, Hans-Peter Jansen пишет:
Do we have a decent remote desktop option for Wayland available?
There are implementations for at least GNOME and KDE; how decent they are I cannot say. So none for Wayland.
Niether GNOME nor KDE is Wayland.
I believe that due to wayland's "more secure" design, any remote desktop setup needs to be integrated into the compositor (KDE/Gnome). Wayland apps can't see other application windows or send or read other applications key / mouse events. This means that things like remote desktop / synergy etc need to be intergrated into the compositor so the compositor handles sending events and rendering application windows. (Unless the protocol has been extended since I last looked in which case not all desktops may support it anyway).
It could be provided in libwayland rather than reimplemented from scratch in each and every desktop creating dozens different remote desktop implemenations, each with different usability and security issues, and none of them applicable to my destop of choice. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Donnerstag, 8. Oktober 2020, 14:54:46 CEST schrieb Michal Suchánek:
On Thu, Oct 08, 2020 at 07:27:27PM +1030, Simon Lees wrote:
On 10/7/20 9:37 PM, Michal Suchánek wrote:
On Fri, Sep 04, 2020 at 10:36:17PM +0300, Andrei Borzenkov wrote:
04.09.2020 20:41, Hans-Peter Jansen пишет:
Do we have a decent remote desktop option for Wayland available?
There are implementations for at least GNOME and KDE; how decent they are I cannot say.
So none for Wayland.
Niether GNOME nor KDE is Wayland.
I believe that due to wayland's "more secure" design, any remote desktop setup needs to be integrated into the compositor (KDE/Gnome). Wayland apps can't see other application windows or send or read other applications key / mouse events. This means that things like remote desktop / synergy etc need to be intergrated into the compositor so the compositor handles sending events and rendering application windows. (Unless the protocol has been extended since I last looked in which case not all desktops may support it anyway).
It could be provided in libwayland rather than reimplemented from scratch in each and every desktop creating dozens different remote desktop implemenations, each with different usability and security issues, and none of them applicable to my destop of choice.
Now let's build a bridge from libwayland to RDP, and be done, more or less. Well, with vnc, I'm able to control another KDE much in the same way as being sitting in front of it (including login), as long as: - forcing the compositor to use XRender - controlling sddm blindly or use kdm, xdm, gdm, hrmpf (due to sddm's missing XDMCP protocol support) But this solution is still superior to most other remote desktop solutions, since it also allows *collaboration*. I've given full training courses this way and do support my users on a daily base, but yes, my users have to trust me. (They do). RDP lacks this collaboration feature with native windows desktops (AFAIK), but is much more capable/efficient protocol wise. Anybody using RDP as a remote X desktop solution, and would like to share his setup? Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/8/20 11:24 PM, Michal Suchánek wrote:
On Thu, Oct 08, 2020 at 07:27:27PM +1030, Simon Lees wrote:
On 10/7/20 9:37 PM, Michal Suchánek wrote:
On Fri, Sep 04, 2020 at 10:36:17PM +0300, Andrei Borzenkov wrote:
04.09.2020 20:41, Hans-Peter Jansen пишет:
Do we have a decent remote desktop option for Wayland available?
There are implementations for at least GNOME and KDE; how decent they are I cannot say. So none for Wayland.
Niether GNOME nor KDE is Wayland.
I believe that due to wayland's "more secure" design, any remote desktop setup needs to be integrated into the compositor (KDE/Gnome). Wayland apps can't see other application windows or send or read other applications key / mouse events. This means that things like remote desktop / synergy etc need to be intergrated into the compositor so the compositor handles sending events and rendering application windows. (Unless the protocol has been extended since I last looked in which case not all desktops may support it anyway).
It could be provided in libwayland rather than reimplemented from scratch in each and every desktop creating dozens different remote desktop implemenations, each with different usability and security issues, and none of them applicable to my destop of choice.
That would still likely require some level of integration in the compositor and desktop and whether or not thats easier then having just a say librdp that all compositors can choose to use I don't know but oneday when I have spare time i'll probably try and answer that question for barrier / synergy. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
participants (10)
-
Andrei Borzenkov -
Bjoern Voigt -
Cristian Rodríguez -
Fabian Vogt -
Hans-Peter Jansen -
Martin Jambor -
Michal Suchánek -
Neil Rickert -
Peter Suetterlin -
Simon Lees