Custom Query (2683 matches)

• It would be a convenience for users to be able to perform command-line actions such as xpra attach or xpra stop by referring to a session-name instead of a display-id.

• It would also be convenient to be able to specify more than one session-name or display-id for a command, and for such commands to fork asynchronously (multi-core micro-processors and all that), eg. xpra attach :1 :2 :3

• It would also be convenient to be able to refer to all sessions, eg. xpra stop all

version: Xpra gtk2 client version 2.1.3-r17247 64-bit platform: Linux 4.9.0-4-amd64 x86_64 Debian

I'm not sure if I'm using the authentication feature correctly, but here's one scenario of recent trouble:

xpra start --bind=auto --auth=pam --start=xfce4-terminal

So far, seems so good ...

xpra attach :1

No opportunity to enter a password, but reasonably quickly the following error messages appeared

2017-11-26 20:07:57,294 Error: authentication failed:
2017-11-26 20:07:57,295  this server requires authentication, please provide a password
2017-11-26 20:07:57,338 Connection lost

The tail of the log file offered some more detail:

Failed to connect to session manager: Failed to connect to the session manager: SESSION_MANAGER environment variable not defined
2017-11-26 20:15:44,686 New unix-domain connection received on /home/me/.xpra/E15-2016-1[0m
2017-11-26 20:15:44,789 New unix-domain connection received on /home/me/.xpra/E15-2016-1[0m
[33m2017-11-26 20:15:45,171 Warning: unused keyword arguments for PAM authentication:[0m
[33m2017-11-26 20:15:45,172  {'exec_cwd': '/home/me', 'connection': unix-domain socket:/home/me/.xpra/E15-2016-1, 'name': 'me'}[0m
2017-11-26 20:15:45,172 Authentication required by PAM authenticator module[0m
2017-11-26 20:15:45,172  sending challenge for username 'me' using xor digest[0m
2017-11-26 20:15:47,548 client has requested disconnection: no password available[0m
2017-11-26 20:15:47,548 Disconnecting client /home/me/.xpra/E15-2016-1:[0m
2017-11-26 20:15:47,549  client request[0m

2017-11-26 20:15:55,312 got signal SIGTERM, exiting[0m
2017-11-26 20:15:55,334 killing xvfb with pid 11355[0m
2017-11-26 20:15:55,334 removing socket /home/me/.xpra/E15-2016-1[0m
Terminated
(II) Server terminated successfully (0). Closing log file.

I then tried an alternative:

xpra start --bind=auto --auth=password:value=me --start=xfce4-terminal
xpra attach :2 --auth=password:value=me

with the same output to STDERR...

2017-11-26 20:39:44,134 Error: authentication failed:
2017-11-26 20:39:44,134  this server requires authentication, please provide a password
2017-11-26 20:39:44,169 Connection lost

And this to the log...

Failed to connect to session manager: Failed to connect to the session manager: SESSION_MANAGER environment variable not defined
2017-11-26 20:39:41,250 New unix-domain connection received on /home/me/.xpra/E15-2016-2[0m
2017-11-26 20:39:41,353 New unix-domain connection received on /home/me/.xpra/E15-2016-2[0m
2017-11-26 20:39:42,023 Authentication required by password authenticator module[0m
2017-11-26 20:39:42,023  sending challenge for username 'me' using hmac+sha512 digest[0m
2017-11-26 20:39:44,136 client has requested disconnection: no password available[0m
2017-11-26 20:39:44,136 Disconnecting client /home/me/.xpra/E15-2016-2:[0m
2017-11-26 20:39:44,136  client request[0m

A third very different scenario that I tried had a very different failure, so I'll post it in another ticket.

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.