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
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.
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.
I'm seeing the problem with centos7 servers over ssh, even from a Fedora Linux client.
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
(..) 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
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.
Sorry, I meant:
XPRA_ALL_DEBUG=1 ....
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.
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
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
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.
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.
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.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1621