Rocky 8.10 installation

[thomase00]

In my organization, I'm not allowed super-user permissions for my VDI, but I can a request that an admin install packages. I pointed to the installation instructions here https://github.com/Xpra-org/xpra/wiki/Download#-for-rpm-distributions, which they followed apparently, but I only have version 4.4, while it looks like Rocky Linux 8.x should support the latest version (currently 6.2).

Anyone have any idea why I wouldn't have the latest version?

[totaam]

Anyone have any idea why I wouldn't have the latest version?

Without the log of the installation attempt, no.
My guess is that the gpg key was not imported properly, so you end up with the downstream version instead of the one from xpra.org.

[thomase00]

Ok, I got them to install the latest, but I'm observing a few issues that I don't recall running into in the past, or if I did, what the solution was. 1.) X clients running on hosts other than the one running the xpra server can't open the xpra display, EVEN after running 'xhost +' on the xpra server. 2.) avif and vp9 codecs are missing on the server according to session info 3.) The "Graphs" tab in session info is not showing anything. 4.) Before I got the admin to install the latest xpra packages, I did my own install with the following steps: - Download all the latest rpms from https://xpra.org/dists/rockylinux/8/x86_64/. - Extract all files to my own user-writable directory. - set PATH, PYTHONPATH, LD_LIBRARY_PATH, AND MANPATH env variables to point to my local "install". From what I can see, this also works, with the exception that X application taskbar icons (on my Windows 10 client) are displaying the generic xpra 'X' icon rather than the appropriate icon for the application. Not sure what is different in my local install that would explain this.

…

On Mon, Oct 21, 2024 at 11:14 AM Antoine Martin ***@***.***> wrote: Anyone have any idea why I wouldn't have the latest version? Without the log of the installation attempt, no. My guess is that the gpg key was not imported properly, so you end up with the downstream version instead of the one from xpra.org. — Reply to this email directly, view it on GitHub <#4399 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJDB37ZAP24CT7QCWULCTYLZ4UK7DAVCNFSM6AAAAABQKMZUPCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMBQGY4DOMI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[totaam]

X clients running on hosts other than the one running the xpra server
can't open the xpra display, EVEN after running 'xhost +' on the xpra
server.

I have never seen that for seamless or desktop sessions.
Something must be wrong with the paths, perhaps $XDG_RUNTIME_DIR and friends.

avif and vp9 codecs are missing on the server according to session info

Bad installation.

The "Graphs" tab in session info is not showing anything.

Could be a bug, very likely a different issue.

From what I can see, this also works, with the exception that X application
taskbar icons

There is an open ticket to do with system tray icons - which could be the same issue: #4401

[thomase00]

I haven't found a solution for X clients on other hosts not being able to open the display. xpra is unusable for me unless I solve this because most X client applications are running on different hosts via lsf. Is it the Xorg process itself that determines which X clients can and cannot connect to it? I'm specifying a custom Xorg command with the `--xvfb` switch because I want to allow tcp connections (the default has nolisten tcp). Could that be related? Here's my xvfb command: ``` /usr/libexec/Xorg -noreset -novtswitch +extension GLX +extension RANDR \ +extension RENDER -logfile ${HOME}/.xpra/$1/Xorg.log -config \ ${HOME}/.config/xpra/xorg.conf ```

[totaam]

Have you tried allowing access using xhost ?
xpra will add an xauth entry:

xpra/xpra/scripts/server.py

Lines 1203 to 1248 in 754774b

	if POSIX and not OSX and (start_vfb or clobber or (shadowing and display_name.startswith(":"))) and display_name.find("wayland") < 0:
	# XAUTHORITY
	from xpra.x11.vfb_util import get_xauthority_path, valid_xauth, xauth_add
	xauthority = valid_xauth((load_session_file("xauthority")).decode(), uid, gid)
	if not xauthority:
	# from here on, we need to save the `xauthority` session file
	# since there is no session file, or it isn't valid
	if SHARED_XAUTHORITY:
	# re-using the value from the environment may not always be safe
	# as the file may be removed when the X11 session that created it is closed,
	# but users expect things to "just work" in most cases,
	# and be able to run commands such as `DISPLAY=:10 xterm`,
	# so this is enabled by default
	xauthority = os.environ.get("XAUTHORITY", "")
	if shadowing and not valid_xauth(xauthority, uid, gid):
	# look for xauth files in magic directories (yuk)
	# matching this user, see ticket #3917
	xauth_time = 0.0
	candidates = [
	"/tmp/xauth*",
	"/tmp/.Xauth*",
	"/var/run/*dm/xauth*",
	"/var/run/lightdm/$USER/xauthority",
	"$XDG_RUNTIME_DIR/xauthority",
	"$XDG_RUNTIME_DIR/Xauthority",
	"$XDG_RUNTIME_DIR/gdm/xauthority",
	"$XDG_RUNTIME_DIR/gdm/Xauthority",
	]
	for globstr in candidates:
	for filename in glob.glob(osexpand(globstr, actual_username=username, uid=uid, gid=gid)):
	if not os.path.isfile(filename):
	continue
	try:
	stat_info = os.stat(filename)
	except OSError:
	continue
	if not ROOT and stat_info.st_uid != uid:
	continue
	if xauth_time == 0.0 or stat_info.st_mtime > xauth_time:
	xauthority = filename
	xauth_time = stat_info.st_mtime
	if not valid_xauth(xauthority, uid, gid):
	# we can choose the path to use:
	xauthority = get_xauthority_path(display_name)
	xauthority = osexpand(xauthority, actual_username=username, uid=uid, gid=gid)
	assert xauthority

Since your installation is a bit different, maybe the XAUTHORITY path used is unexpected.
I believe that starting your server with -d server would show some xauth related debug logging, including the path used:

xpra/xpra/scripts/server.py

Line 1262 in 754774b

log(f"using XAUTHORITY file {xauthority!r}")

I don't think you would need this, but here it is for completeness:

xpra/xpra/scripts/server.py

Line 63 in 754774b

SHARED_XAUTHORITY = envbool("XPRA_SHARED_XAUTHORITY", True)

[thomase00]

I've tried "xhost +" if that is what you are asking.

[totaam]

If it was me, I would:

• verify that the Xorg process is listening on a TCP socket
• verify that I can connect to it using telnet, then an xterm
• verify that my firewall isn't blocking this port to the outside
• verify that I can connect to it from the outside

This has nothing to do with xpra.

[thomase00]

Figured it out. I guess the version of Xorg on Rocky8 defaults to NOT listening on TCP ports. Therefore, rather than removing '-nolisten tcp' from the Xorg command line, I changed it to '-listen tcp'.

…

On Fri, Nov 1, 2024 at 4:59 AM Antoine Martin ***@***.***> wrote: If it was me, I would: - verify that the Xorg process is listening on a TCP socket - verify that I can connect to it using telnet, then an xterm - verify that my firewall isn't blocking this port to the outside - verify that I can connect to it from the outside This has nothing to do with xpra. — Reply to this email directly, view it on GitHub <#4399 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJDB376DTNNUA7MTN34UTBDZ6M7IVAVCNFSM6AAAAABQKMZUPCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMJSGAYDGMY> . You are receiving this because you authored the thread.Message ID: ***@***.***>