version: Xpra gtk2 client version 2.1.3-r17247 64-bit platform: Linux 4.9.0-4-amd64 x86_64 Debian
When starting a server as follows:
xpra start --start="gksu /usr/sbin/gparted"
Attaching a client gives no error messages to STDERR or anything of interest in the log (ie. only lines that exist in a normal properly operating connection).
However, what actually happens is awful and stressful:
1] The client grabs control of the entire screen space instead of 800x600, and paints it all black
2] The lower right hand corner of the display does offer the gksu dialog, with a blinking cursor in the input field.
3] No input is echoed to the input field.
4] Input keystrokes are sent to the environment that spawned the client, ie. keystrokes that would go to the spawning terminal are sent there, and keystrokes that would be intercepted by the window manager would be intercepted there.
4.1] However, the xpra client would not release control of the entire visible display (I think in X11 terminology it's called the 'seat').
4.2] Because C-c is being sent to the spawning environment, which was the terminal that issued the xpra attach command, it closes the client and restores the X11 seat's display.
4.3] During experimentation, it was possible to regain control of the display by switching to a different virtual terminal, ie. C-M-F1.
1] The client grabs control of the entire screen space instead of 800x600, and paints it all black
Why would it only use 800x600?
2] The lower right hand corner of the display does offer the gksu dialog, with a blinking cursor in the input field.
Can you take a screenshot?
Is your vfb configured correctly? (does the current server resolution as shown with xrandr
match your client's?)
My distro (Fedora) doesn't support gksu (see https://fedoraproject.org/wiki/Features/gksudo), so I can't test this right now.
In any case, to get applications like gksu to work properly, it is likely that you will need to use a dedicated seat for each xpra session.
See start-via-proxy=yes
and the system wide proxy server.
1] The client grabs control of the entire screen space instead of 800x600, and paints it all black
Why would it only use 800x600?
Probably because my window manager (i3wm) is set up to display all unexpected windows that way.
2] The lower right hand corner of the display does offer the gksu dialog, with a blinking cursor in the input field.
Can you take a screenshot?
Done.
Is your vfb configured correctly? (does the current server resolution as shown with xrandr match your client's?)
The output of xrandr matches the resolution listed in the xpra logs.
In any case, to get applications like gksu to work properly, it is likely that you will need to use a dedicated seat for each xpra session.
See start-via-proxy=yes and the system wide proxy server.
I do have gksudo (I think the interface is actually identical to gksu. They do share the same man page), just I don't have anyone configured with sudo privileges.
What I can easily try is to gksu to another unprivileged user account to, say, open an xterm as that second user. To temporarily set up sudo would be something I'm not happy about diving into, but its not impossible.
In any case, to get applications like gksu to work properly, it is likely that you will need to use a dedicated seat for each xpra session. See
start-via-proxy=yes
and the system wide proxy server.
If I'm looking in the correct place on the wiki, it says
Your init system should start the service on xpra's default port
But I don't see any init script in /etc/init.d
, nor when I perform dpkg -L xpra | grep "/etc"
But I don't see any init script in
/etc/init.d
, nor when I performdpkg -L xpra | grep "/etc"
We ship systemd unit files, though an init script is also available in the source: browser/xpra/trunk/src/service.
I have no idea how we would ship both or how we to ensure that the package also works with non-systemd installs.
We ship systemd unit files, though an init script is also available in the source: browser/xpra/trunk/src/service. I have no idea how we would ship both or how we to ensure that the package also works with non-systemd installs.
Well, then, I might be the guinea pig.
1] The init script should be copied to /etc/init.d/
with 755 permissions. Steps 2 & 3 are optional, and is commonly done by the person packaging the program for a specific distribution, but see my comments later for a few minor gotchas I discovered, that would be you to address.
2] The install should run update-rc.d xpra defaults
to build the symlinks to the init script from the default run-level directories.
3] If you want the install procedure to automatically start the service, then the command would be: service xpra start
, but that's a debate between those who want services started upon install, and those who feel its over-reach and presumptuous.
In my case, I have followed my own instructions and have hit a snag in a config file /etc/default/xpra: Syntax error: "(" unexpected
. The offending line reads: XPRA_LOG_FORMAT=%(message)s
.
What is happening is that line 23 of the init script, [ -e /etc/default/xpra ] && . /etc/default/xpra
is 'source'ing
/etc/default/xpra
expecting it to be in a shell-script compatible format, but the idion%(...)s
isn't a/bin/sh
form.
What I did was put the idiom in double-quotes.
The good news is that the small change succeeded in starting the service and outputting a log to /var/log/xpra/log
. Is that change systemd-compatible?
The bad news is the log's output, at this point:
$cat /var/log/xpra.log 14500 2017-12-13 12:51:25,748 Warning: failed to create socket directory '/root/.xpra/E15-2016-/root' 2017-12-13 12:51:25,749 [Errno 2] No such file or directory: '/root/.xpra/E15-2016-/root' 2017-12-13 12:51:25,749 Error: failed to create socket '/root/.xpra/E15-2016-/root/.xpra': 2017-12-13 12:51:25,749 [Errno 2] No such file or directory xpra initialization error: failed to create socket /root/.xpra/E15-2016-/root/.xpra 2017-12-13 12:51:25,750 closing tcp socket 0.0.0.0:14500 close failed in file object destructor: IOError: [Errno 9] Bad file descriptor
I then added to line 29 of the init script: --socket-dir=/tmp
, but it seems that xpra isn't creating sub-directories (maybe what's missing is something like the -p
option to mkdir
?):
#cat /var/log/xpra.log 14500 2017-12-13 13:00:55,470 Warning: failed to create socket directory '/tmp/E15-2016-/root' 2017-12-13 13:00:55,471 [Errno 2] No such file or directory: '/tmp/E15-2016-/root' 2017-12-13 13:00:55,471 Error: failed to create socket '/tmp/E15-2016-/root/.xpra': 2017-12-13 13:00:55,471 [Errno 2] No such file or directory xpra initialization error: failed to create socket /tmp/E15-2016-/root/.xpra 2017-12-13 13:00:55,472 closing tcp socket 0.0.0.0:14500 close failed in file object destructor: IOError: [Errno 9] Bad file descriptor
The init script should be copied...
I think that's the easy part, ensuring that this plays nice with systems that have systemd as init system is harder, and the packaging of it all is likely to be a nightmare (from past experience with all the hidden magic in the debian-helper scripts).
What I did was put the idiom in double-quotes.
Please supply a patch or just the updated file so I don't make mistakes applying the change.
The good news is that the small change succeeded in starting the service and outputting a log to /var/log/xpra/log. Is that change systemd-compatible?
I don't understand the question. systemd doesn't use that file.
The bad news is the log's output, at this point: (..)
r17620 should help.
I think that's the easy part, ensuring that this plays nice with systems that have systemd as init system is harder, and the packaging of it all is likely to be a nightmare (from past experience with all the hidden magic in the debian-helper scripts).
Yeah, been there. Leave that all to the people doing the packaging for each distro.
What I did was put the idiom in double-quotes.
Please supply a patch or just the updated file so I don't make mistakes applying the change.
Here you go:
TCP_AUTH=sys AUTH=peercred #DEBUG=auth,proxy DEBUG= #skip datetime prefix since the log goes to a system logger: XPRA_LOG_FORMAT="%(message)s"
r17620 should help.
I just now manually applied the patch, and it seems like a success ...
#cat /var/log/xpra.log 14500 2017-12-13 13:44:28,962 created unix domain socket: /run/xpra/system 2017-12-13 13:44:30,694 serving html content from: /usr/share/xpra/www 2017-12-13 13:44:30,724 xpra proxy version 2.3-r17613 64-bit 2017-12-13 13:44:30,725 uid=0 (root), gid=0 (root) 2017-12-13 13:44:30,725 running with pid 3120 on Linux Devuan 1.0 jessie 2017-12-13 13:44:30,759 xpra is ready.
but now ...
$xpra start --start="gksu /usr/sbin/gparted" --start-via-proxy=yes xpra initialization error: failed to start-via-proxy: failed to connect to '/run/xpra/system': [Errno 13] Permission denied
No new entries in /var/log/xpra.log and no new logs in ~/.xpra
The directory /run/xpra has 700 permissions, for some reason! I manually changed it to 755, and after a long wait ...
$xpra start --start="gksu /usr/sbin/gparted" --start-via-proxy=yes 2017-12-13 13:55:02,363 server failure: disconnected before the session could be established 2017-12-13 13:55:02,363 server requested disconnect: server error (failed to start a new session) xpra initialization error: failed to start-via-proxy: FAILURE
Here`s a re-cap of the ENTIRE /var/log at this point, including a repeat of the above:
$cat /var/log/xpra.log 14500 2017-12-13 13:44:28,962 created unix domain socket: /run/xpra/system 2017-12-13 13:44:30,694 serving html content from: /usr/share/xpra/www 2017-12-13 13:44:30,724 xpra proxy version 2.3-r17613 64-bit 2017-12-13 13:44:30,725 uid=0 (root), gid=0 (root) 2017-12-13 13:44:30,725 running with pid 3120 on Linux Devuan 1.0 jessie 2017-12-13 13:44:30,759 xpra is ready. 2017-12-13 13:54:36,800 New unix-domain connection received on /run/xpra/system 2017-12-13 13:54:42,727 Error: pam_open_session failed: 6 2017-12-13 13:54:42,727 Permission denied xpra initialization error: cannot open log file '${HOME}/.xpra/S6794.log': [Errno 2] No such file or directory: '${HOME}/.xpra/S6794.log' 2017-12-13 13:54:47,336 Error: displayfd failed 2017-12-13 13:54:47,338 did not provide a display number using displayfd 2017-12-13 13:55:02,358 Error: failed to start server subprocess: 2017-12-13 13:55:02,358 failed to identify the new server display!
No new log at ~/.xpra
XPRA_LOG_FORMAT="%(message)s"
Thanks, applied in r17624.
The directory /run/xpra has 700 permissions, for some reason! I manually changed it to 755, and after a long wait ...
Normally, this directory is created with another systemd component: browser/xpra/trunk/src/tmpfiles.d/xpra.conf. This sets the correct permission. No idea how we're supposed to do that without tmpfiles.d.
Error: pam_open_session failed: 6
Permission denied
We use pam to login as that user. Maybe the pam configuration file needs tweaking for your non-systemd setup. It does work on a stock "stretch" distro, I've tried it again just yesterday.
cannot open log file '${HOME}/.xpra/S6794.log': [Errno 2] No such file or directory: '${HOME}/.xpra/S6794.log'
This could be the problem.
Maybe $HOME
is not being substituted or something.
We normally place those log files in $XDG_RUNTIME_DIR
.
The directory /run/xpra has 700 permissions...
Try r17625.
cannot open log file '${HOME}/.xpra/S6794.log': [Errno 2] No such file or directory: '${HOME}/.xpra/S6794.log'
Try r17626.
Just stumbled upon this: pam_ck_connector. (see CKCON_X11_DISPLAY
)
I believe that when we start via the proxy, pam login will take care of this. (the pam configuration files are a mess and vary widely from distro to distro)
So, it looks like ConsoleKit won't let you register without privileges? So we're back to using the system wide proxy server. (it runs as root and takes care of those things before changing uid)
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1710