Rocky 8.10 installation #4399

thomase00 · 2024-10-21T15:06:44Z

thomase00
Oct 21, 2024

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?

Answered by thomase00

Nov 4, 2024

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'.

View full answer

totaam · 2024-10-21T15:14:35Z

totaam
Oct 21, 2024
Maintainer

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.

0 replies

thomase00 · 2024-10-24T15:49:11Z

thomase00
Oct 24, 2024
Author

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: ***@***.***>

0 replies

totaam · 2024-10-24T16:07:30Z

totaam
Oct 24, 2024
Maintainer

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

0 replies

thomase00 · 2024-10-30T19:09:31Z

thomase00
Oct 30, 2024
Author

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 ```

0 replies

totaam · 2024-10-31T06:38:25Z

totaam
Oct 31, 2024
Maintainer

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)

0 replies

thomase00 · 2024-10-31T17:24:08Z

thomase00
Oct 31, 2024
Author

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

0 replies

totaam · 2024-11-01T08:59:34Z

totaam
Nov 1, 2024
Maintainer

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.

0 replies

thomase00 · 2024-11-04T23:15:05Z

thomase00
Nov 4, 2024
Author

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: ***@***.***>

0 replies

xpra.org

Rocky 8.10 installation #4399

Uh oh!

Uh oh!

thomase00 Oct 21, 2024

Replies: 8 comments

Uh oh!

totaam Oct 21, 2024 Maintainer

Uh oh!

thomase00 Oct 24, 2024 Author

Uh oh!

totaam Oct 24, 2024 Maintainer

Uh oh!

Uh oh!

thomase00 Oct 30, 2024 Author

Uh oh!

totaam Oct 31, 2024 Maintainer

Uh oh!

Uh oh!

thomase00 Oct 31, 2024 Author

Uh oh!

totaam Nov 1, 2024 Maintainer

Uh oh!

thomase00 Nov 4, 2024 Author

thomase00
Oct 21, 2024

totaam
Oct 21, 2024
Maintainer

thomase00
Oct 24, 2024
Author

totaam
Oct 24, 2024
Maintainer

thomase00
Oct 30, 2024
Author

totaam
Oct 31, 2024
Maintainer

thomase00
Oct 31, 2024
Author

totaam
Nov 1, 2024
Maintainer

thomase00
Nov 4, 2024
Author