xpra icon
Bug tracker and wiki

Opened 6 days ago

Last modified 40 hours ago

#1621 assigned defect

ssh start on centos7 server

Reported by: Alexander Owned by: Antoine Martin
Priority: critical Milestone: 2.2
Component: client Version: 2.1.x
Keywords: Cc:

Description

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

Attachments (3)

1.txt (46.2 KB) - added by Alexander 4 days ago.
2.txt (24.8 KB) - added by Alexander 4 days ago.
xpra_error_audit.txt (461.1 KB) - added by Alexander 3 days ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 6 days ago by Antoine Martin

Owner: changed from Antoine Martin to Alexander

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.

comment:2 Changed 6 days ago by 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.

Last edited 6 days ago by Alexander (previous) (diff)

comment:3 Changed 6 days ago by Antoine Martin

Owner: changed from Alexander to Antoine Martin
Priority: majorcritical
Status: newassigned

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

comment:4 in reply to:  3 Changed 6 days ago by 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

Last edited 6 days ago by Alexander (previous) (diff)

comment:5 Changed 5 days ago by Antoine Martin

Owner: changed from Antoine Martin to Alexander
Status: assignednew
Summary: Not work 'start' from Windosssh start on centos7 server

(..) 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
Last edited 5 days ago by Antoine Martin (previous) (diff)

comment:6 Changed 4 days ago by 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: http://xpra.org/trac/ticket/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.

comment:7 Changed 4 days ago by Antoine Martin

Sorry, I meant:

XPRA_ALL_DEBUG=1 ....

Changed 4 days ago by Alexander

Attachment: 1.txt added

Changed 4 days ago by Alexander

Attachment: 2.txt added

comment:8 Changed 3 days ago by 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.

comment:9 Changed 3 days ago by 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

Last edited 3 days ago by Alexander (previous) (diff)

comment:10 Changed 3 days ago by 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

Changed 3 days ago by Alexander

Attachment: xpra_error_audit.txt added

comment:11 Changed 3 days ago by 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.

Last edited 3 days ago by Alexander (previous) (diff)

comment:12 Changed 40 hours ago by Antoine Martin

Owner: changed from Alexander to Antoine Martin
Status: newassigned

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.

Note: See TracTickets for help on using tickets.