Xpra: Ticket #1621: ssh start on centos7 server

Hi!

I'm trying to run a Windows Xpra-server on CentOS from a Windows client.

Xpra version 2.0.3 (Windows 32 bit). Being in the Windows enter the command:

xpra start ssh/user3@IP/90 --start-child=firefox --exit-with-client --exit-with-children

Working.

Xpra version 2.1.1 (Windows 32 bit). Being in the Windows enter the command:

xpra start ssh/user3@IP/90 --start-child=firefox --exit-with-client --exit-with-children

Not working. Server not start



Fri, 11 Aug 2017 16:51:24 GMT - Antoine Martin: owner changed

Please specify the server environment: full OS version, xpra version details, etc. Does the session start if you run it directly on the centos host using just:

xpra start

Please use "xpra_cmd.exe" not just "xpra" as this will show the messages, which may include the cause of the problem. If not, try adding "-d all" to this command and post the output.


Fri, 11 Aug 2017 17:52:05 GMT - Alexander:

Please specify the server environment: full OS version, xpra version details, etc.

[root@srvusi08 user3@abc.domain.loc]# xpra --version
xpra v2.1.1-r16657
[root@srvusi08 user3@abc.domain.loc]# uname -r
3.10.0-514.26.2.el7.x86_64
[root@srvusi08 user3@abc.domain.loc]# cat /etc/*-release
CentOS Linux release 7.3.1611 (Core)
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"
CentOS Linux release 7.3.1611 (Core)
CentOS Linux release 7.3.1611 (Core)

xpra start

[user3@srvusi08 ~]$ xpra start
2017-08-11 22:44:16,283 server failure: disconnected before the session could be established
2017-08-11 22:44:16,283 server requested disconnect: server error (failed to start a new session)
Warning: cannot use the system proxy for 'start' subcommand,
 FAILURE
[user3@srvusi08 ~]$ Entering daemon mode; any further errors will be reported to:
  /run/user/1498401148/xpra/S23845.log
Actual display used: :10
Actual log file name is now: /run/user/1498401148/xpra/:10.log
xpra list
Found the following xpra sessions:
/run/user/1498401148/xpra:
        LIVE session at :10
/home/user3@abc.domain.loc/.xpra:
        LIVE session at :10
[user3@srvusi08 ~]$

Though he swears, but still works.

I use command on Windows 7 32 bit and Windows 10 64 bit (xpra for windows 2.1.1):

xpra_cmd start ssh/user3@srvusi08.abc.domain.loc/90 --start-child=firefox --exit-with-client --exit-with-children

I enter the correct password.

C:\Program Files\Xpra>xpra_cmd start ssh/user3@srvusi08.abc.domain.loc/90 --start-child=firefox --exit-with-client --exit-with-children
** (xpra_cmd.EXE:21328): WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags'
** (xpra_cmd.EXE:21328): WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'
** (xpra_cmd.EXE:21328): WARNING **: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
2017-08-11 22:48:15,023 Xpra gtk2 client version 2.1.1-r16657 64-bit
2017-08-11 22:48:15,027  running on Microsoft Windows 10
2017-08-11 22:48:15,213 GStreamer version 1.12.1 for Python 2.7.13 64-bit
2017-08-11 22:48:16,619 OpenGL_accelerate module loaded
2017-08-11 22:48:16,666 OpenGL enabled with GeForce GTX 1080/PCIe/SSE2
2017-08-11 22:48:16,701  keyboard settings: layout=us
2017-08-11 22:48:16,703  desktop size is 1920x1080 with 1 screen:
2017-08-11 22:48:16,703   Default (508x285 mm - DPI: 96x96) workarea: 1920x1040
2017-08-11 22:48:16,703     DISPLAY1 (598x336 mm - DPI: 81x81)
2017-08-11 22:48:16,721 keyboard layouts: us,ru
2017-08-11 22:48:38,115 Error: failed to receive anything, not an xpra server?
2017-08-11 22:48:38,117   could also be the wrong protocol, username, password or port
2017-08-11 22:48:38,117 Connection lost

If I use the key "-d all",

xpra_cmd start ssh/user3@srvusi08.abc.domain.loc/90 --start-child=firefox --exit-with-client --exit-with-children -d all

then it works! But there is a lot of debugging information and you have to end the session through the task manager.


Fri, 11 Aug 2017 18:04:39 GMT - Antoine Martin: owner, priority, status changed

I'm seeing the problem with centos7 servers over ssh, even from a Fedora Linux client.


Sat, 12 Aug 2017 09:53:10 GMT - Alexander:

Replying to Antoine Martin:

I'm seeing the problem with centos7 servers over ssh, even from a Fedora Linux client.

Ok. I will use version 2.0.3 for Windows. Please can you tell me how to run a tcp session on a CentOS server from a Windows client? Tried combinations like

xpra_cmd start ssh/user3@remoteIP/90 --bind-tcp=remoteIP:9000 --start-child=firefox --exit-with-client --exit-with-children

does not work. Thanks


Sun, 13 Aug 2017 14:28:57 GMT - Antoine Martin: owner, status, summary changed

(..) does not work

Please always provide enough details, "does not work" is almost never the right description of a problem.

Can you tell me how to run a tcp session on a CentOS server from a Windows client?

With versions before 2.1, you cannot pass arguments like "exit-with-client" when using remote ssh start. Unfortunately, this ticket is preventing you form using 2.2 ..

I was seeing the problem but it turns out that I had a broken local installation (partial source install done for testing). Re-installing the 2.1.1 RPM fixed the issue. How did you install? Please post the full package list: rpm -qa | grep xpra

Try re-installing: yum reinstall python2-xpra-server. If that doesn't help, attach the output of (from the server):

XPRA_ALL_DEBUG xpra version socket:/run/xpra/system
XPRA_ALL_DEBUG xpra start :100

Mon, 14 Aug 2017 13:12:22 GMT - Alexander:

Try re-installing: yum reinstall python2-xpra-server.

Not help.

If that doesn't help, attach the output of (from the server):

XPRA_ALL_DEBUG xpra version socket:/run/xpra/system

XPRA_ALL_DEBUG xpra start :100

[user3@srvusi08 xpra]$ XPRA_ALL_DEBUG xpra version socket:/run/xpra/system       bash: XPRA_ALL_DEBUG: command not found

Found: the server starts from the Windows 2.1.1 client, if the user is local. If the domain user - it does not start. I've already asked about this: https://github.com/Xpra-org/xpra/issues/1616#comment:3 The reinstallation of CentOS7.3 and the connection to the domain using sssd instead of winbind helped. If start xpra with CentOS, then it starts. If start using the Windows client (domain user), it does not start. I can not understand what the domain users do not like.


Mon, 14 Aug 2017 13:13:41 GMT - Antoine Martin:

Sorry, I meant:

XPRA_ALL_DEBUG=1 ....

Mon, 14 Aug 2017 13:47:08 GMT - Alexander: attachment set


Mon, 14 Aug 2017 13:47:20 GMT - Alexander: attachment set


Mon, 14 Aug 2017 17:29:55 GMT - Antoine Martin:

The version command worked but the start command failed:

send_hello() packet={'randr_notify': False, ..., 'python.version': (2, 7, 5), 'build.version': '2.1.1'}
write_format_thread_loop starting
add_packet_to_queue(hello ...)
io_thread_loop(read, <bound method Protocol._read of Protocol(unix-domain loop starting
io_thread_loop(write, <bound method Protocol._write of Protocol(unix-domain socket:  <- /run/xpra/system)>) loop starting
read_parse_thread_loop starting
processing packet disconnect
server failure: disconnected before the session could be established

The server disconnects immediately after receiving the hello start packet. Please post the system proxy server log, which can be seen with systemctl status xpra.service or you can view it live with journactl -f. If there aren't enough details there, you may need to enable DEBUG=all in /etc/sysconfig/xpra and then restart the service: systemctl restart xpra.service. In that proxy log, the proxy service may refer you to a server instance log file if it thinks it executed the real server command.


Mon, 14 Aug 2017 17:32:26 GMT - Alexander:

Mmm. I disabled SELinux and xpra worked from domain users! =) Result: xpra worked from domain users CentOS7.3: join to domain using sssd (not winbind) and disabled selinux. Before I use disabled selinux in CentOS 7.3 and winbind - not worked


Mon, 14 Aug 2017 17:35:10 GMT - Antoine Martin:

Very good! Please just attach the selinux policy violation to this ticket and we can fix the policy and make it all work. You should not need to disable selinux.

grep xpra /var/log/audit/audit.log

Mon, 14 Aug 2017 18:12:01 GMT - Alexander: attachment set


Mon, 14 Aug 2017 18:14:02 GMT - Alexander:

Added file. Last question: how to use "--system-tray=no"? Not work in Windows 10, 7 (xpra 2.0.3 and 2.1.1):

xpra --system-tray=no start ssh/alex3@srvusi08.abc.domain.loc/9 --start-child=firefox --exit-with-client --exit-with-children

PS: Found out how not to show xpra in the tray:

--tray=no

At http://www.xpra.org/manual, this key is not listed at the very beginning of the document. Mention of it is only closer to the end of the document.


Wed, 16 Aug 2017 11:25:40 GMT - Antoine Martin: owner, status changed

The tray option has been added to the man page header in r16699.

I am keeping this ticket open because I would like to reproduce the problem and update the selinux policy.

In the future, again please use a better description than "not work". I would have told you that "system-tray" is for system tray forwarding and "tray" is for xpra's tray.


Sun, 03 Sep 2017 08:55:21 GMT - Antoine Martin: status changed; resolution set

I am unable to reproduce the problem, so closing.

The selinux policy also looks fine, these updates look invalid to me:

#============= unconfined_t ==============
allow unconfined_t ldconfig_exec_t:file entrypoint;
allow unconfined_t pulseaudio_exec_t:file entrypoint;
allow unconfined_t xauth_exec_t:file entrypoint;
#============= xpra_t ==============
allow xpra_t xpra_conf_t:sock_file getattr;

We don't run unconfined, and the even if the sock_file in ~/.xpra was mislabelled, the one in XDG_RUNTIME_DIR should be ok.


Sat, 23 Jan 2021 05:29:20 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1621