From antoine at nagafix.co.uk Sun Jul 1 11:08:30 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 1 Jul 2018 17:08:30 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 1.0.12 LTS: many minor fixes Message-ID: Hi, This update to the LTS branch catches up with the fixes already applied to the newer branches. There is nothing major here. Updating is recommended for those stuck on this branch. (ie: CentOS 6.x) Release notes: * fix memoryview paint error with non-opengl Python 2.6 clients * fix spurious errors and warnings during window cleanup * fix macos keyboard initialization * fix key shortcut command line handling * fix potential X11 related crashes due to missing synchronization * fix read-only mode pointer move bypass * fix shadow servers xinerama corruption for child commands * fix client failure connecting to servers without a valid desktop size * fix client launcher not exiting on close * fix parsing of display strings in connection URLs * fix pyobjc api deprecation warning * fix debug logging via environment variables * fix errors when XShm is not available * fix invalid clipboard toggle requests not ignored * fix missing context handler for keymap setup (crash possible) * fix building CUDA kernels with GCC 8.1 * fix tray menu setup error when the clipboard is disabled * fix clipboard token send error when there are no targets * fix putty plink PATH lookup issue * correctly disable desktop-scaling when mmap is enabled * send missing exception details to server with remote-logging * make python 2.6 warning less scary * prevent authenticated users from shutting down proxy servers * don't prompt for the ssh password if we already have it * support newer nvidia driver versions with nvenc * remove duplicated encoding * show another possible reason for connection failures * abort tests if build fails * increase test timeout * recommend the dbus-x11 with the DEB package Links: https://xpra.org/trac/wiki/Source https://xpra.org/trac/wiki/Download Cheers Antoine From pierre.wulles at gmail.com Tue Jul 3 14:21:51 2018 From: pierre.wulles at gmail.com (Pierre Wulles) Date: Tue, 3 Jul 2018 15:21:51 +0200 Subject: [winswitch] Modal Window Message-ID: Hello, I need xpra for screen forwarding software that use the framework Qt, but it appears that modal window are not treated as modal window, you can move them wherever you want. So I was wondering if you are aware of bugs that might appear while using Qt with xpra and if this bug was known of you. Thank you very much to take care of my message Kind regards, Pierre From antoine at nagafix.co.uk Tue Jul 3 14:46:41 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 3 Jul 2018 20:46:41 +0700 Subject: [winswitch] Modal Window In-Reply-To: References: Message-ID: <209e36ed-f41d-0801-2928-ff495ed87333@nagafix.co.uk> On 03/07/18 20:21, Pierre Wulles via shifter-users wrote: > Hello, > I need xpra for screen forwarding software that use the framework Qt, but > it appears that modal window are not treated as modal window, you can move > them wherever you want. So I was wondering if you are aware of bugs that > might appear while using Qt with xpra and if this bug was known of you. This is a known issue: most desktop environments do not allow xpra to set a modal window for a group of windows, only for all the windows it forwards at once, so xpra does not honour modal windows to prevent one window from standing in the way of other windows which may not be related. If you feel strongly about this, feel free to create a ticket so we can at least add an option that will allow you to override this behaviour. Cheers Antoine > Thank you very much to take care of my message > Kind regards, > Pierre > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From matteo.ipri at arpm.co Wed Jul 4 23:32:23 2018 From: matteo.ipri at arpm.co (Matteo Ipri) Date: Thu, 5 Jul 2018 00:32:23 +0200 Subject: [winswitch] [xpra] HTML5 client bugs Message-ID: Hi all, I wrote a couple of Dockerfiles to test the latest stable (xpra X11 version 2.3.2-r19729 64-bit as of this writing) and the latest beta version (xpra X11 version 2.4-r19803 64-bit as of this writing) and I found some bugs when comparing the HTML5 client to the Xpra desktop client I use on my Arch Linux running PC. The Docker images are based on Ubuntu 17.10 artful and I attach the Dockerfiles so that my experiments can be reproduced. To build the images, I run the following commands: sudo docker build -t xpra -f path/to/xpra/Dockerfile path/to/xpra/ sudo docker build -t xpra:beta -f path/to/xpra/Dockerfile-beta path/to/xpra/ To run the containers, I enter the following: sudo docker run --interactive --tty --rm -p 8080:8080 xpra sudo docker run --interactive --tty --rm -p 8080:8080 xpra:beta Once a container is running, I open my web browser (Firefox or Chormium) and navigate to http://localhost:8080. Once xpra is loaded I have an xterm window in my browser. So far, so good. Once I am in xterm I run the command "xdg-open https://xpra.org". With the stable version of xpra I only get a message in my local terminal (the one in which I launched the docker container) that says (as expected): "2018-07-04 21:04:57,471 New unix-domain connection received on /home/matteo/.xpra/62b2edcf1139-0 2018-07-04 21:04:57,473 Warning: remote end does not accept URLs" If I connect to the container with the desktop client, I get the pop-up asking me where to open the link. With the beta version, using the HTML5 client, Firefox in the container is launched. It seems like the xdg-open-forwarding for URLs is broken in the current beta. If I connect to xpra beta with the desktop client, I get the pop-up as with the stable version of xpra. I can add that xdg-open-forwarding for URLs was working in version v2.4-r19581 I installed as beta in a container some week ago. There are two more bugs, that are present in both version of xpra and only in HTML5 client. If I run "firefox https://xpra.org" in the remote xterm terminal window, Firefox launches regularly and the web page loads fine. If I ctrl+click on a link, for example on About, the link is opened in the same tab instead of a new one. If I use the desktop client, the ctrl+click opens the link in a new tab as expected. The second bug I found is about some keyboard keys. If I try to type the "less than" character (<) pressing "shift+," when using the HTML5 client, I get the "greater than" character (>). This happens on both stable and beta HTML5 clients, but not with the desktop client. My keyboard has the US layout and has 104 keys. In the logs I see that the "us" layout is chosen by xpra and that the ctrl key press is recognized by xpra. Other keys with issues are the 4 in the top right corner of the keyboard (top right corner of the numpad): /, *, - and +. These four are mapped to the similar keys in the main part of the keyboard, thus when I press "*" I get "8" and I have to press "shift+*" to get the "*". Please, let me know if I can help any further in debugging these issues. Thank you very for your attention, Matteo Ipri From antoine at nagafix.co.uk Thu Jul 5 05:31:25 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 5 Jul 2018 11:31:25 +0700 Subject: [winswitch] [xpra] HTML5 client bugs In-Reply-To: References: Message-ID: <5e021d25-8e1f-30f3-2bf2-161c61e880c7@nagafix.co.uk> On 05/07/18 05:32, Matteo Ipri via shifter-users wrote: > Hi all, > I wrote a couple of Dockerfiles to test the latest stable (xpra X11 version > 2.3.2-r19729 64-bit as of this writing) and the latest beta version (xpra > X11 version 2.4-r19803 64-bit as of this writing) and I found some bugs > when comparing the HTML5 client to the Xpra desktop client I use on my Arch > Linux running PC. > > The Docker images are based on Ubuntu 17.10 artful and I attach the > Dockerfiles so that my experiments can be reproduced. Without the docker files, this cannot be reproduced by others. Can you share them? > To build the images, I run the following commands: > > sudo docker build -t xpra -f path/to/xpra/Dockerfile path/to/xpra/ > > sudo docker build -t xpra:beta -f path/to/xpra/Dockerfile-beta > path/to/xpra/ > > To run the containers, I enter the following: > > sudo docker run --interactive --tty --rm -p 8080:8080 xpra > > sudo docker run --interactive --tty --rm -p 8080:8080 xpra:beta > > Once a container is running, I open my web browser (Firefox or Chormium) > and navigate to http://localhost:8080. > Once xpra is loaded I have an xterm window in my browser. > So far, so good. > > Once I am in xterm I run the command "xdg-open https://xpra.org". > > With the stable version of xpra I only get a message in my local terminal > (the one in which I launched the docker container) that says (as expected): > "2018-07-04 21:04:57,471 New unix-domain connection received on > /home/matteo/.xpra/62b2edcf1139-0 > 2018-07-04 21:04:57,473 Warning: remote end does not accept URLs" > If I connect to the container with the desktop client, I get the pop-up > asking me where to open the link. > > With the beta version, using the HTML5 client, Firefox in the container is > launched. > It seems like the xdg-open-forwarding for URLs is broken in the current > beta. > If I connect to xpra beta with the desktop client, I get the pop-up as with > the stable version of xpra. The current beta version should forward "xdg-open" to the html5 client, which will display the link in the top bar, as per: https://xpra.org/trac/ticket/1862 I've just tried it again and it worked fine here. > I can add that xdg-open-forwarding for URLs was working in version > v2.4-r19581 I installed as beta in a container some week ago. > > There are two more bugs, that are present in both version of xpra and only > in HTML5 client. > > If I run "firefox https://xpra.org" in the remote xterm terminal window, > Firefox launches regularly and the web page loads fine. > If I ctrl+click on a link, for example on About, the link is opened in the > same tab instead of a new one. > If I use the desktop client, the ctrl+click opens the link in a new tab as > expected. Looks like a bug with keyboard modifiers (control, shift, etc) not being synchronized correctly during pointer events. > The second bug I found is about some keyboard keys. > If I try to type the "less than" character (<) pressing "shift+," when > using the HTML5 client, I get the "greater than" character (>). > This happens on both stable and beta HTML5 clients, but not with the > desktop client. My keyboard has the US layout and has 104 keys. In the logs > I see that the "us" layout is chosen by xpra and that the ctrl key press is > recognized by xpra. > Other keys with issues are the 4 in the top right corner of the keyboard > (top right corner of the numpad): /, *, - and +. These four are mapped to > the similar keys in the main part of the keyboard, thus when I press "*" I > get "8" and I have to press "shift+*" to get the "*". Keyboard event support in Javascript is challenging: it isn't always possible to distinguish the numpad keys from other keys with the same label. At least not with all the different combinations of browsers, OS and input language settings. > Please, let me know if I can help any further in debugging these issues. Please file tickets here: https://xpra.org/trac/newticket Cheers, Antoine > > Thank you very for your attention, > > Matteo Ipri From antoine at nagafix.co.uk Thu Jul 5 15:01:00 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 5 Jul 2018 21:01:00 +0700 Subject: [winswitch] Xpra 2.3.2 - CentOS 7 packaging conflicts In-Reply-To: <8a79b16c-5a8d-37b0-f15e-b12e67e7486e@nagafix.co.uk> References: <8a79b16c-5a8d-37b0-f15e-b12e67e7486e@nagafix.co.uk> Message-ID: Hi, Due to a packaging error on our side (*), an Epoch tag meant to workaround a Fedora 27 packaging conflict from downstream ended up in the CentOS 7 package metadata. The offending packages have now been purged and I have replaced them with a 2.3.3 pre-release. This applies to CentOS 7 only. If you have already downloaded the 2.3.2 packages, you may want to follow these instructions to ensure that the packages do not stay locked on this version forever and to prevent future repo dependency errors: yum remove "*xpra*" -y yum clean all yum install xpra -y This may also be necessary in the future when upgrading from Fedora 27 to a newer release. We do not want to ever be using this tag, but we are forced into this situation by the Fedora downstream package. Sorry for the inconvenience, Antoine (*) the mistake comes from this line which evaluates to true on CentOS7: %if 0%{?fedora}<28 On 27/06/18 03:30, Antoine Martin wrote: > Hi, > > This update fixes a large number of issues, mostly cosmetic ones, none > of them are really critical. There is no urgency to update. > > The buffer overflow sounds scary, but it only affects the GTK3 builds > and those aren't the default on any platforms yet, it only triggers when > OpenGL rendering is disabled and it is unlikely to be exploitable. > > The bandwidth-limit bypass can cause problems for those with budgeted > bandwidth allocations on their servers. > > Release notes: > * fix notification actions support with shadow servers > * fix paint errors with reformatted images using outdated stride value > * fix control commands that call window refresh > * fix broken pipe error when the browser cancels downloading 'noicon' > * fix spurious refresh events > * fix missing bug report data due to path errors > * fix XAUTHORITY environment variable getting clobbered > * fix html5 window refresh not throttled when document is not invisible > * fix non-opengl painting of windows with a padding area > * fix rgb paint of mmap data with the python2 cairo backend > * fix invalid clipboard toggle requests not ignored > * fix missing context handler for keymap setup (crash possible) > * fix proxy server test to use a signal to stop the test instance > * fix invalid exception value in X11 atom bindings > * fix bandwidth limit client bypass and connection errors > * fix building CUDA kernels with GCC 8.1 > * fix tray menu setup error when the clipboard is disabled > * fix GTK3 buffer overflow with non-opengl backend > * fix startup errors with pulseaudio if XDG_RUNTIME_DIR is missing > * fix clipboard token send error when there are no targets > * don't overwrite the dynamic system tray icon with default on startup > * correctly disable desktop-scaling when mmap is enabled > * skip repainting pointer overlay when the position is unchanged > * prevent authenticated users from shutting down proxy servers > * don't turn off notifications when we don't have a forwarder instance > * don't try to log an exception that does not exist > * allow the user to disable all video encoders and csc modules > * send missing exception details to server with remote-logging > * avoid RFB errors if screen capture fails > * avoid further errors when shadow capture fails > * recommend the dbus-x11 with the DEB package > > The source: > https://xpra.org/src/ > Downloads: > https://xpra.org/trac/wiki/Download > > Cheers > Antoine > From anto.trande at gmail.com Thu Jul 5 15:43:53 2018 From: anto.trande at gmail.com (Antonio Trande) Date: Thu, 5 Jul 2018 16:43:53 +0200 Subject: [winswitch] Xpra 2.3.2 - CentOS 7 packaging conflicts In-Reply-To: References: <8a79b16c-5a8d-37b0-f15e-b12e67e7486e@nagafix.co.uk> Message-ID: <716bcbd3-f6a9-6239-b765-edc6fd9d74e7@fedoraproject.org> Are you building xpra for CentOS7 starting from xpra-src package on Fedora 27? On 05/07/2018 16:01, Antoine Martin via shifter-users wrote: > Hi, > > Due to a packaging error on our side (*), an Epoch tag meant to > workaround a Fedora 27 packaging conflict from downstream ended up in > the CentOS 7 package metadata. > > The offending packages have now been purged and I have replaced them > with a 2.3.3 pre-release. This applies to CentOS 7 only. > > If you have already downloaded the 2.3.2 packages, you may want to > follow these instructions to ensure that the packages do not stay locked > on this version forever and to prevent future repo dependency errors: > yum remove "*xpra*" -y > yum clean all > yum install xpra -y > > This may also be necessary in the future when upgrading from Fedora 27 > to a newer release. We do not want to ever be using this tag, but we are > forced into this situation by the Fedora downstream package. > > Sorry for the inconvenience, > Antoine > > > (*) the mistake comes from this line which evaluates to true on CentOS7: > %if 0%{?fedora}<28 > > > > On 27/06/18 03:30, Antoine Martin wrote: >> Hi, >> >> This update fixes a large number of issues, mostly cosmetic ones, none >> of them are really critical. There is no urgency to update. >> >> The buffer overflow sounds scary, but it only affects the GTK3 builds >> and those aren't the default on any platforms yet, it only triggers when >> OpenGL rendering is disabled and it is unlikely to be exploitable. >> >> The bandwidth-limit bypass can cause problems for those with budgeted >> bandwidth allocations on their servers. >> >> Release notes: >> * fix notification actions support with shadow servers >> * fix paint errors with reformatted images using outdated stride value >> * fix control commands that call window refresh >> * fix broken pipe error when the browser cancels downloading 'noicon' >> * fix spurious refresh events >> * fix missing bug report data due to path errors >> * fix XAUTHORITY environment variable getting clobbered >> * fix html5 window refresh not throttled when document is not invisible >> * fix non-opengl painting of windows with a padding area >> * fix rgb paint of mmap data with the python2 cairo backend >> * fix invalid clipboard toggle requests not ignored >> * fix missing context handler for keymap setup (crash possible) >> * fix proxy server test to use a signal to stop the test instance >> * fix invalid exception value in X11 atom bindings >> * fix bandwidth limit client bypass and connection errors >> * fix building CUDA kernels with GCC 8.1 >> * fix tray menu setup error when the clipboard is disabled >> * fix GTK3 buffer overflow with non-opengl backend >> * fix startup errors with pulseaudio if XDG_RUNTIME_DIR is missing >> * fix clipboard token send error when there are no targets >> * don't overwrite the dynamic system tray icon with default on startup >> * correctly disable desktop-scaling when mmap is enabled >> * skip repainting pointer overlay when the position is unchanged >> * prevent authenticated users from shutting down proxy servers >> * don't turn off notifications when we don't have a forwarder instance >> * don't try to log an exception that does not exist >> * allow the user to disable all video encoders and csc modules >> * send missing exception details to server with remote-logging >> * avoid RFB errors if screen capture fails >> * avoid further errors when shadow capture fails >> * recommend the dbus-x11 with the DEB package >> >> The source: >> https://xpra.org/src/ >> Downloads: >> https://xpra.org/trac/wiki/Download >> >> Cheers >> Antoine >> > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x5E212EE1D35568BE GPG key server: https://keys.fedoraproject.org/ From antoine at nagafix.co.uk Thu Jul 5 16:04:38 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 5 Jul 2018 22:04:38 +0700 Subject: [winswitch] Xpra 2.3.2 - CentOS 7 packaging conflicts In-Reply-To: <716bcbd3-f6a9-6239-b765-edc6fd9d74e7@fedoraproject.org> References: <8a79b16c-5a8d-37b0-f15e-b12e67e7486e@nagafix.co.uk> <716bcbd3-f6a9-6239-b765-edc6fd9d74e7@fedoraproject.org> Message-ID: On 05/07/18 21:43, Antonio Trande via shifter-users wrote: > Are you building xpra for CentOS7 starting from xpra-src package on > Fedora 27? No, we have been using a unified spec file for all RPM distros for about 7 or 8 years now. Cheers, Antoine > > On 05/07/2018 16:01, Antoine Martin via shifter-users wrote: >> Hi, >> >> Due to a packaging error on our side (*), an Epoch tag meant to >> workaround a Fedora 27 packaging conflict from downstream ended up in >> the CentOS 7 package metadata. >> >> The offending packages have now been purged and I have replaced them >> with a 2.3.3 pre-release. This applies to CentOS 7 only. >> >> If you have already downloaded the 2.3.2 packages, you may want to >> follow these instructions to ensure that the packages do not stay locked >> on this version forever and to prevent future repo dependency errors: >> yum remove "*xpra*" -y >> yum clean all >> yum install xpra -y >> >> This may also be necessary in the future when upgrading from Fedora 27 >> to a newer release. We do not want to ever be using this tag, but we are >> forced into this situation by the Fedora downstream package. >> >> Sorry for the inconvenience, >> Antoine >> >> >> (*) the mistake comes from this line which evaluates to true on CentOS7: >> %if 0%{?fedora}<28 >> >> >> >> On 27/06/18 03:30, Antoine Martin wrote: >>> Hi, >>> >>> This update fixes a large number of issues, mostly cosmetic ones, none >>> of them are really critical. There is no urgency to update. >>> >>> The buffer overflow sounds scary, but it only affects the GTK3 builds >>> and those aren't the default on any platforms yet, it only triggers when >>> OpenGL rendering is disabled and it is unlikely to be exploitable. >>> >>> The bandwidth-limit bypass can cause problems for those with budgeted >>> bandwidth allocations on their servers. >>> >>> Release notes: >>> * fix notification actions support with shadow servers >>> * fix paint errors with reformatted images using outdated stride value >>> * fix control commands that call window refresh >>> * fix broken pipe error when the browser cancels downloading 'noicon' >>> * fix spurious refresh events >>> * fix missing bug report data due to path errors >>> * fix XAUTHORITY environment variable getting clobbered >>> * fix html5 window refresh not throttled when document is not invisible >>> * fix non-opengl painting of windows with a padding area >>> * fix rgb paint of mmap data with the python2 cairo backend >>> * fix invalid clipboard toggle requests not ignored >>> * fix missing context handler for keymap setup (crash possible) >>> * fix proxy server test to use a signal to stop the test instance >>> * fix invalid exception value in X11 atom bindings >>> * fix bandwidth limit client bypass and connection errors >>> * fix building CUDA kernels with GCC 8.1 >>> * fix tray menu setup error when the clipboard is disabled >>> * fix GTK3 buffer overflow with non-opengl backend >>> * fix startup errors with pulseaudio if XDG_RUNTIME_DIR is missing >>> * fix clipboard token send error when there are no targets >>> * don't overwrite the dynamic system tray icon with default on startup >>> * correctly disable desktop-scaling when mmap is enabled >>> * skip repainting pointer overlay when the position is unchanged >>> * prevent authenticated users from shutting down proxy servers >>> * don't turn off notifications when we don't have a forwarder instance >>> * don't try to log an exception that does not exist >>> * allow the user to disable all video encoders and csc modules >>> * send missing exception details to server with remote-logging >>> * avoid RFB errors if screen capture fails >>> * avoid further errors when shadow capture fails >>> * recommend the dbus-x11 with the DEB package >>> >>> The source: >>> https://xpra.org/src/ >>> Downloads: >>> https://xpra.org/trac/wiki/Download >>> >>> Cheers >>> Antoine >>> >> >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> > From anto.trande at gmail.com Thu Jul 5 16:10:45 2018 From: anto.trande at gmail.com (Antonio Trande) Date: Thu, 5 Jul 2018 17:10:45 +0200 Subject: [winswitch] Xpra 2.3.2 - CentOS 7 packaging conflicts In-Reply-To: References: <8a79b16c-5a8d-37b0-f15e-b12e67e7486e@nagafix.co.uk> <716bcbd3-f6a9-6239-b765-edc6fd9d74e7@fedoraproject.org> Message-ID: <0ce14a7a-1189-cca7-9e8f-3905f81eb13d@fedoraproject.org> I'm seeing that xpra-2.3.2 cannot be built on CentOS7 because of a compiling error: Error compiling Cython file: ------------------------------------------------------------ ... cdef const void *get_mem(self): return self.p def __getbuffer__(self, Py_buffer *view, int flags): PyBuffer_FillInfo(view, self, self.p, self.l, 1, flags) ^ ------------------------------------------------------------ xpra/buffers/membuf.pyx:84:25: Call with wrong number of arguments (expected 5, got 6) Build log: https://kojipkgs.fedoraproject.org//work/tasks/5031/28035031/build.log If everything goes fine, i can include xpra in EPEL7 repository too. On 05/07/2018 17:04, Antoine Martin wrote: > On 05/07/18 21:43, Antonio Trande via shifter-users wrote: >> Are you building xpra for CentOS7 starting from xpra-src package on >> Fedora 27? > No, we have been using a unified spec file for all RPM distros for about > 7 or 8 years now. > > Cheers, > Antoine > > >> >> On 05/07/2018 16:01, Antoine Martin via shifter-users wrote: >>> Hi, >>> >>> Due to a packaging error on our side (*), an Epoch tag meant to >>> workaround a Fedora 27 packaging conflict from downstream ended up in >>> the CentOS 7 package metadata. >>> >>> The offending packages have now been purged and I have replaced them >>> with a 2.3.3 pre-release. This applies to CentOS 7 only. >>> >>> If you have already downloaded the 2.3.2 packages, you may want to >>> follow these instructions to ensure that the packages do not stay locked >>> on this version forever and to prevent future repo dependency errors: >>> yum remove "*xpra*" -y >>> yum clean all >>> yum install xpra -y >>> >>> This may also be necessary in the future when upgrading from Fedora 27 >>> to a newer release. We do not want to ever be using this tag, but we are >>> forced into this situation by the Fedora downstream package. >>> >>> Sorry for the inconvenience, >>> Antoine >>> >>> >>> (*) the mistake comes from this line which evaluates to true on CentOS7: >>> %if 0%{?fedora}<28 >>> >>> >>> >>> On 27/06/18 03:30, Antoine Martin wrote: >>>> Hi, >>>> >>>> This update fixes a large number of issues, mostly cosmetic ones, none >>>> of them are really critical. There is no urgency to update. >>>> >>>> The buffer overflow sounds scary, but it only affects the GTK3 builds >>>> and those aren't the default on any platforms yet, it only triggers when >>>> OpenGL rendering is disabled and it is unlikely to be exploitable. >>>> >>>> The bandwidth-limit bypass can cause problems for those with budgeted >>>> bandwidth allocations on their servers. >>>> >>>> Release notes: >>>> * fix notification actions support with shadow servers >>>> * fix paint errors with reformatted images using outdated stride value >>>> * fix control commands that call window refresh >>>> * fix broken pipe error when the browser cancels downloading 'noicon' >>>> * fix spurious refresh events >>>> * fix missing bug report data due to path errors >>>> * fix XAUTHORITY environment variable getting clobbered >>>> * fix html5 window refresh not throttled when document is not invisible >>>> * fix non-opengl painting of windows with a padding area >>>> * fix rgb paint of mmap data with the python2 cairo backend >>>> * fix invalid clipboard toggle requests not ignored >>>> * fix missing context handler for keymap setup (crash possible) >>>> * fix proxy server test to use a signal to stop the test instance >>>> * fix invalid exception value in X11 atom bindings >>>> * fix bandwidth limit client bypass and connection errors >>>> * fix building CUDA kernels with GCC 8.1 >>>> * fix tray menu setup error when the clipboard is disabled >>>> * fix GTK3 buffer overflow with non-opengl backend >>>> * fix startup errors with pulseaudio if XDG_RUNTIME_DIR is missing >>>> * fix clipboard token send error when there are no targets >>>> * don't overwrite the dynamic system tray icon with default on startup >>>> * correctly disable desktop-scaling when mmap is enabled >>>> * skip repainting pointer overlay when the position is unchanged >>>> * prevent authenticated users from shutting down proxy servers >>>> * don't turn off notifications when we don't have a forwarder instance >>>> * don't try to log an exception that does not exist >>>> * allow the user to disable all video encoders and csc modules >>>> * send missing exception details to server with remote-logging >>>> * avoid RFB errors if screen capture fails >>>> * avoid further errors when shadow capture fails >>>> * recommend the dbus-x11 with the DEB package >>>> >>>> The source: >>>> https://xpra.org/src/ >>>> Downloads: >>>> https://xpra.org/trac/wiki/Download >>>> >>>> Cheers >>>> Antoine >>>> >>> >>> _______________________________________________ >>> shifter-users mailing list >>> shifter-users at lists.devloop.org.uk >>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>> >> > -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x5E212EE1D35568BE GPG key server: https://keys.fedoraproject.org/ From antoine at nagafix.co.uk Thu Jul 5 16:27:05 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 5 Jul 2018 22:27:05 +0700 Subject: [winswitch] Xpra 2.3.2 - CentOS 7 packaging conflicts In-Reply-To: <0ce14a7a-1189-cca7-9e8f-3905f81eb13d@fedoraproject.org> References: <8a79b16c-5a8d-37b0-f15e-b12e67e7486e@nagafix.co.uk> <716bcbd3-f6a9-6239-b765-edc6fd9d74e7@fedoraproject.org> <0ce14a7a-1189-cca7-9e8f-3905f81eb13d@fedoraproject.org> Message-ID: <744e0497-ad5d-5669-182f-3dccf7bc27f2@nagafix.co.uk> On 05/07/18 22:10, Antonio Trande wrote: > I'm seeing that xpra-2.3.2 cannot be built on CentOS7 because of a > compiling error: > > Error compiling Cython file: > ------------------------------------------------------------ > ... > cdef const void *get_mem(self): > return self.p > def __getbuffer__(self, Py_buffer *view, int flags): > PyBuffer_FillInfo(view, self, self.p, self.l, 1, flags) > ^ > ------------------------------------------------------------ > xpra/buffers/membuf.pyx:84:25: Call with wrong number of arguments > (expected 5, got 6) Your version of Cython is well out of date, use a supported version and it will compile fine. > Build log: > https://kojipkgs.fedoraproject.org//work/tasks/5031/28035031/build.log > > If everything goes fine, i can include xpra in EPEL7 repository too. I wish I could be more enthusiastic about this prospect but I am scarred by past packaging conflicts and invalid bug reports from end users. Let's hope that I am wrong this time. Cheers, Antoine > > On 05/07/2018 17:04, Antoine Martin wrote: >> On 05/07/18 21:43, Antonio Trande via shifter-users wrote: >>> Are you building xpra for CentOS7 starting from xpra-src package on >>> Fedora 27? >> No, we have been using a unified spec file for all RPM distros for about >> 7 or 8 years now. >> >> Cheers, >> Antoine >> >> >>> >>> On 05/07/2018 16:01, Antoine Martin via shifter-users wrote: >>>> Hi, >>>> >>>> Due to a packaging error on our side (*), an Epoch tag meant to >>>> workaround a Fedora 27 packaging conflict from downstream ended up in >>>> the CentOS 7 package metadata. >>>> >>>> The offending packages have now been purged and I have replaced them >>>> with a 2.3.3 pre-release. This applies to CentOS 7 only. >>>> >>>> If you have already downloaded the 2.3.2 packages, you may want to >>>> follow these instructions to ensure that the packages do not stay locked >>>> on this version forever and to prevent future repo dependency errors: >>>> yum remove "*xpra*" -y >>>> yum clean all >>>> yum install xpra -y >>>> >>>> This may also be necessary in the future when upgrading from Fedora 27 >>>> to a newer release. We do not want to ever be using this tag, but we are >>>> forced into this situation by the Fedora downstream package. >>>> >>>> Sorry for the inconvenience, >>>> Antoine >>>> >>>> >>>> (*) the mistake comes from this line which evaluates to true on CentOS7: >>>> %if 0%{?fedora}<28 >>>> >>>> >>>> >>>> On 27/06/18 03:30, Antoine Martin wrote: >>>>> Hi, >>>>> >>>>> This update fixes a large number of issues, mostly cosmetic ones, none >>>>> of them are really critical. There is no urgency to update. >>>>> >>>>> The buffer overflow sounds scary, but it only affects the GTK3 builds >>>>> and those aren't the default on any platforms yet, it only triggers when >>>>> OpenGL rendering is disabled and it is unlikely to be exploitable. >>>>> >>>>> The bandwidth-limit bypass can cause problems for those with budgeted >>>>> bandwidth allocations on their servers. >>>>> >>>>> Release notes: >>>>> * fix notification actions support with shadow servers >>>>> * fix paint errors with reformatted images using outdated stride value >>>>> * fix control commands that call window refresh >>>>> * fix broken pipe error when the browser cancels downloading 'noicon' >>>>> * fix spurious refresh events >>>>> * fix missing bug report data due to path errors >>>>> * fix XAUTHORITY environment variable getting clobbered >>>>> * fix html5 window refresh not throttled when document is not invisible >>>>> * fix non-opengl painting of windows with a padding area >>>>> * fix rgb paint of mmap data with the python2 cairo backend >>>>> * fix invalid clipboard toggle requests not ignored >>>>> * fix missing context handler for keymap setup (crash possible) >>>>> * fix proxy server test to use a signal to stop the test instance >>>>> * fix invalid exception value in X11 atom bindings >>>>> * fix bandwidth limit client bypass and connection errors >>>>> * fix building CUDA kernels with GCC 8.1 >>>>> * fix tray menu setup error when the clipboard is disabled >>>>> * fix GTK3 buffer overflow with non-opengl backend >>>>> * fix startup errors with pulseaudio if XDG_RUNTIME_DIR is missing >>>>> * fix clipboard token send error when there are no targets >>>>> * don't overwrite the dynamic system tray icon with default on startup >>>>> * correctly disable desktop-scaling when mmap is enabled >>>>> * skip repainting pointer overlay when the position is unchanged >>>>> * prevent authenticated users from shutting down proxy servers >>>>> * don't turn off notifications when we don't have a forwarder instance >>>>> * don't try to log an exception that does not exist >>>>> * allow the user to disable all video encoders and csc modules >>>>> * send missing exception details to server with remote-logging >>>>> * avoid RFB errors if screen capture fails >>>>> * avoid further errors when shadow capture fails >>>>> * recommend the dbus-x11 with the DEB package >>>>> >>>>> The source: >>>>> https://xpra.org/src/ >>>>> Downloads: >>>>> https://xpra.org/trac/wiki/Download >>>>> >>>>> Cheers >>>>> Antoine >>>>> >>>> >>>> _______________________________________________ >>>> shifter-users mailing list >>>> shifter-users at lists.devloop.org.uk >>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>> >>> >> > From berserker.troll at yandex.com Sun Jul 8 22:32:52 2018 From: berserker.troll at yandex.com (Troll Berserker) Date: Mon, 9 Jul 2018 00:32:52 +0300 Subject: [winswitch] [xpra] Xpra and JupyterHub Message-ID: <901206d5-d6b9-4145-a8f5-a1939d4214b2@yandex.com> Hi, I was working on a local JupyterHub deployment (if you don't know what Jupyter and JupyterHub is, you may get a rough idea what is it from the first 8 minutes of this https://www.youtube.com/watch?v=gSVvxOchT8Y video) and once thought that it would be great to run X11 displays in Jupyter signle-user notebook server about the same way it is possible to start terminal emulators inside it. While googling I've found the project named nbserverproxy and the issue about proxying noVNC with it (https://github.com/jupyterhub/nbserverproxy/issues/24) nbserverproxy is a Jupyter notebook extension which enables one to access a HTTP service running inside Jupyter single-user server, see example in the readme https://github.com/jupyterhub/nbserverproxy/blob/master/README.md#example I've tried to run Xpra and discovered a bug in the nbserverproxy websocket proxying logic, the fix will be merged sooner or later. There is also a request to make nbserverproxy a standalone service (https://github.com/jupyterhub/nbserverproxy/issues/1) Having websocket issue solved, I've tried to use nbserverproxy without the Jupyter Notebook app running and it was possible, the JupyterHub package provides classes which make it easy to authenticate against the Hub. A day ago I finally got a working container with Xpra and the proxy in front of it running without Jupyter notebook server. JupyterHub supports a bunch of different Authenticators and Spawners (for example, we are using KubeSpawner to spawn single-user containers in a Kubernetes cloud) I don't know any other remote desktop project which could be as flexible as JupyterHub+Xpra combination. AFAIK x2go and Apache Guacamole support some sort of load balancing, but I don't think they support, for example, Kubernetes. The disadvantage is that the only way to access Xpra is its HTML5 client. I'm attaching the Dockerfile and the entry script I'm using. This is the first version which is not ideal and has some workarounds and dirty hacks I had to use to make it working. I've found that Xpra became kinda rebellious: it ignores the orders I give it not to launch dbus and pulseaudio and not to put sockets in an original HOME directory (which is a network-mounted FS which doesn't seem to support sockets and pipes) so I had to install nss-sssd connector to map UIDs to usernames so that the dbus-launch doesn't refuse to start and I had to override the HOME variable. -------------- next part -------------- FROM ubuntu:18.04 ARG TERM=linux ARG DEBIAN_FRONTEND=noninteractive RUN echo 'APT::Install-Recommends "false";' > /etc/apt/apt.conf.d/norecommendsplease \ && apt-get update \ && apt-get install -y curl gnupg patch ca-certificates RUN curl https://xpra.org/gpg.asc | apt-key add - \ && echo "deb https://xpra.org/beta bionic main" > /etc/apt/sources.list.d/xpra.list \ && apt-get update \ && apt-get install -y xpra python-websockify libjs-jquery RUN apt-get install -y python3-pip git python3-setuptools \ && pip3 install jupyterhub git+https://github.com/BerserkerTroll/nbserverproxy.git at patch-1 RUN apt-get install -y libnss-sss xterm ADD proxyxpra.py / ENTRYPOINT '/proxyxpra.py' From matteo.ipri at arpm.co Mon Jul 9 09:15:22 2018 From: matteo.ipri at arpm.co (Matteo Ipri) Date: Mon, 9 Jul 2018 10:15:22 +0200 Subject: [winswitch] [xpra] HTML5 client bugs In-Reply-To: <5e021d25-8e1f-30f3-2bf2-161c61e880c7@nagafix.co.uk> References: <5e021d25-8e1f-30f3-2bf2-161c61e880c7@nagafix.co.uk> Message-ID: Hi, I attached the Dockerfiles, but something went wrong, maybe attachments are stripped from the emails to the mailing list. I copy and paste the Dockerfile for the beta version here and I will open tickets for the individual bugs. The Dockerfile for the stable version is the same file without the line which adds the beta repository. Thanks Dockerfile-beta FROM ubuntu:artful-20180524 ENV DEBIAN_FRONTEND noninteractive # Set up locales RUN apt-get update \ && apt-get -y install \ locales \ && localedef -i en_US -c -f UTF-8 -A /usr/share/locale/locale.alias en_US.UTF-8 \ && locale-gen \ && apt-get clean \ && rm -rf /var/lib/apt/lists/* ENV LC_ALL=en_US.UTF-8 ENV LANG=en_US.UTF-8 ENV LANGUAGE=en_US.UTF-8 # install various dependencies RUN apt-get update \ && apt-get -y install \ software-properties-common \ && add-apt-repository universe \ && apt-get update \ && apt-get -y dist-upgrade \ && apt-get -y install \ bash \ bzip2 \ ca-certificates \ curl \ dbus-x11 \ dirmngr \ fonts-liberation \ language-pack-en-base \ lsb \ software-properties-common \ websockify \ wget \ x11-xserver-utils \ xdg-utils \ xterm \ && apt-get clean \ && rm -rf /var/lib/apt/lists/* # install additional software RUN apt-get update \ && apt-get -y install \ firefox \ gedit \ kate \ && apt-get clean \ && rm -rf /var/lib/apt/lists/* # install xpra RUN curl https://xpra.org/gpg.asc | apt-key add - \ && curl -o /etc/apt/sources.list.d/xpra.list "https://xpra.org/repos/artful/xpra.list" \ && curl -o /etc/apt/sources.list.d/xpra-beta.list "https://xpra.org/repos/artful/xpra-beta.list" \ && apt-get update \ && apt-get -y install \ xpra \ && apt-get clean \ && rm -rf /var/lib/apt/lists/* # set up non-root user ENV MY_USER=matteo ENV MY_UID=1988 ENV MY_GID=1988 RUN useradd --create-home --shell /bin/bash --user-group --groups lpadmin,xpra --uid $MY_UID $MY_USER USER $MY_UID ENV HOME=/home/matteo ENV XDG_RUNTIME_DIR=/home/matteo ENV XPRA_DEFAULT_VFB_RESOLUTION=1600x900 EXPOSE 8080 WORKDIR $HOME CMD xpra start \ --daemon=no \ --bind-tcp=0.0.0.0:8080 \ --html=on \ --ssl=off \ --bell=no \ --pulseaudio=no \ --webcam=no \ --mdns=no \ --system-tray=no \ --clipboard-direction=both \ --file-transfer=yes \ --forward-xdg-open=yes \ --start=xterm Matteo Ipri - Information Technologies ARPM - Advanced Risk and Portfolio Management (R) https://www.arpm.co https://www.linkedin.com/company-beta/10452441/ https://www.facebook.com/ARPM.co/ https://twitter.com/ARPM_co On Thu, Jul 5, 2018 at 6:31 AM, Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> wrote: > On 05/07/18 05:32, Matteo Ipri via shifter-users wrote: > > Hi all, > > I wrote a couple of Dockerfiles to test the latest stable (xpra X11 > version > > 2.3.2-r19729 64-bit as of this writing) and the latest beta version (xpra > > X11 version 2.4-r19803 64-bit as of this writing) and I found some bugs > > when comparing the HTML5 client to the Xpra desktop client I use on my > Arch > > Linux running PC. > > > > The Docker images are based on Ubuntu 17.10 artful and I attach the > > Dockerfiles so that my experiments can be reproduced. > Without the docker files, this cannot be reproduced by others. > Can you share them? > > > To build the images, I run the following commands: > > > > sudo docker build -t xpra -f path/to/xpra/Dockerfile path/to/xpra/ > > > > sudo docker build -t xpra:beta -f path/to/xpra/Dockerfile-beta > > path/to/xpra/ > > > > To run the containers, I enter the following: > > > > sudo docker run --interactive --tty --rm -p 8080:8080 xpra > > > > sudo docker run --interactive --tty --rm -p 8080:8080 xpra:beta > > > > Once a container is running, I open my web browser (Firefox or Chormium) > > and navigate to http://localhost:8080. > > Once xpra is loaded I have an xterm window in my browser. > > So far, so good. > > > > Once I am in xterm I run the command "xdg-open https://xpra.org". > > > > With the stable version of xpra I only get a message in my local terminal > > (the one in which I launched the docker container) that says (as > expected): > > "2018-07-04 21:04:57,471 New unix-domain connection received on > > /home/matteo/.xpra/62b2edcf1139-0 > > 2018-07-04 21:04:57,473 Warning: remote end does not accept URLs" > > If I connect to the container with the desktop client, I get the pop-up > > asking me where to open the link. > > > > With the beta version, using the HTML5 client, Firefox in the container > is > > launched. > > It seems like the xdg-open-forwarding for URLs is broken in the current > > beta. > > If I connect to xpra beta with the desktop client, I get the pop-up as > with > > the stable version of xpra. > The current beta version should forward "xdg-open" to the html5 client, > which will display the link in the top bar, as per: > https://xpra.org/trac/ticket/1862 > I've just tried it again and it worked fine here. > > > I can add that xdg-open-forwarding for URLs was working in version > > v2.4-r19581 I installed as beta in a container some week ago. > > > > There are two more bugs, that are present in both version of xpra and > only > > in HTML5 client. > > > > If I run "firefox https://xpra.org" in the remote xterm terminal window, > > Firefox launches regularly and the web page loads fine. > > If I ctrl+click on a link, for example on About, the link is opened in > the > > same tab instead of a new one. > > If I use the desktop client, the ctrl+click opens the link in a new tab > as > > expected. > Looks like a bug with keyboard modifiers (control, shift, etc) not being > synchronized correctly during pointer events. > > > The second bug I found is about some keyboard keys. > > If I try to type the "less than" character (<) pressing "shift+," when > > using the HTML5 client, I get the "greater than" character (>). > > This happens on both stable and beta HTML5 clients, but not with the > > desktop client. My keyboard has the US layout and has 104 keys. In the > logs > > I see that the "us" layout is chosen by xpra and that the ctrl key press > is > > recognized by xpra. > > Other keys with issues are the 4 in the top right corner of the keyboard > > (top right corner of the numpad): /, *, - and +. These four are mapped to > > the similar keys in the main part of the keyboard, thus when I press "*" > I > > get "8" and I have to press "shift+*" to get the "*". > Keyboard event support in Javascript is challenging: it isn't always > possible to distinguish the numpad keys from other keys with the same > label. > At least not with all the different combinations of browsers, OS and > input language settings. > > > Please, let me know if I can help any further in debugging these issues. > Please file tickets here: > https://xpra.org/trac/newticket > > Cheers, > Antoine > > > > Thank you very for your attention, > > > > Matteo Ipri > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From matteo.ipri at arpm.co Mon Jul 9 09:33:16 2018 From: matteo.ipri at arpm.co (Matteo Ipri) Date: Mon, 9 Jul 2018 10:33:16 +0200 Subject: [winswitch] [xpra] Xpra and JupyterHub In-Reply-To: <901206d5-d6b9-4145-a8f5-a1939d4214b2@yandex.com> References: <901206d5-d6b9-4145-a8f5-a1939d4214b2@yandex.com> Message-ID: On Sun, Jul 8, 2018 at 11:32 PM, Troll Berserker via shifter-users < shifter-users at lists.devloop.org.uk> wrote: > A day ago I finally got a working container with Xpra and the > proxy in front of it running without Jupyter notebook server. > > JupyterHub supports a bunch of different Authenticators and Spawners > (for example, we are using KubeSpawner to spawn single-user > containers in a Kubernetes cloud) > I don't know any other remote desktop project which could be > as flexible as JupyterHub+Xpra combination. > AFAIK x2go and Apache Guacamole support some sort of load balancing, > but I don't think they support, for example, Kubernetes. > The disadvantage is that the only way to access Xpra is its HTML5 client. > > I'm attaching the Dockerfile and the entry script I'm using. > This is the first version which is not ideal and has some workarounds and > dirty hacks I had to use to make it working. > I've found that Xpra became kinda rebellious: it ignores the orders I > give it > not to launch dbus and pulseaudio and not to put sockets in an original > HOME directory > (which is a network-mounted FS which doesn't seem to support sockets and > pipes) > so I had to install nss-sssd connector to map UIDs to usernames so that > the dbus-launch doesn't refuse to start and I had to override the HOME > variable. > The python script is not attached to the mailing list, only the Dockerfile has been delivered embedded in the email. Can you share again the entrypoint script? I am curious of the solution you found for the home folder and the unix socket file. I also run JupyterHub which spwans docker containers running xpra. I shared my Dockerfile in another thread here on the mailing list (I just sent it again copy and pasted in an email since the attachment did not get through). I just run that Dockerfile with vanilla JupyterHub, without nbserverproxy and things works, although on the slow side. The javascript proxy is too slow for websockets and adds too much latency. At least this is my impression, but I can not be sure that the culprit is only the javascript reverse proxy contained in JupyterHub. Thanks From berserker.troll at yandex.com Mon Jul 9 15:05:00 2018 From: berserker.troll at yandex.com (Troll Berserker) Date: Mon, 9 Jul 2018 17:05:00 +0300 Subject: [winswitch] [xpra] Xpra and JupyterHub In-Reply-To: References: <901206d5-d6b9-4145-a8f5-a1939d4214b2@yandex.com> Message-ID: <9211e18b-d199-7f23-4c6f-ddacebf58264@yandex.com> On 09/07/18 11:33, Matteo Ipri via shifter-users wrote: > On Sun, Jul 8, 2018 at 11:32 PM, Troll Berserker via shifter-users < > shifter-users at lists.devloop.org.uk> wrote: > >> A day ago I finally got a working container with Xpra and the >> proxy in front of it running without Jupyter notebook server. >> >> JupyterHub supports a bunch of different Authenticators and Spawners >> (for example, we are using KubeSpawner to spawn single-user >> containers in a Kubernetes cloud) >> I don't know any other remote desktop project which could be >> as flexible as JupyterHub+Xpra combination. >> AFAIK x2go and Apache Guacamole support some sort of load balancing, >> but I don't think they support, for example, Kubernetes. >> The disadvantage is that the only way to access Xpra is its HTML5 client. >> >> I'm attaching the Dockerfile and the entry script I'm using. >> This is the first version which is not ideal and has some workarounds and >> dirty hacks I had to use to make it working. >> I've found that Xpra became kinda rebellious: it ignores the orders I >> give it >> not to launch dbus and pulseaudio and not to put sockets in an original >> HOME directory >> (which is a network-mounted FS which doesn't seem to support sockets and >> pipes) >> so I had to install nss-sssd connector to map UIDs to usernames so that >> the dbus-launch doesn't refuse to start and I had to override the HOME >> variable. >> > > The python script is not attached to the mailing list, only the Dockerfile > has been delivered embedded in the email. > Can you share again the entrypoint script? Trying to attach to this message. If it fails see https://gist.github.com/BerserkerTroll/4f579ada6429dc4b576b996bc786d898 > I am curious of the solution you found for the home folder and the unix > socket file. I mount an empty volume at /scratch and point HOME to this directory. Xpra seem to ignore --socket-dir[s] options... > I also run JupyterHub which spwans docker containers running xpra. > I shared my Dockerfile in another thread here on the mailing list (I just > sent it again copy and pasted in an email since the attachment did not get > through). BTW, you don't have to run `apt-get clean` each time, see /etc/apt/apt.conf.d/docker-clean in the Ubuntu Docker images. > I just run that Dockerfile with vanilla JupyterHub, without nbserverproxy > and things works, although on the slow side. So you are just running Xpra without anything in front of it and you don't require authentication to access it? From Ben.Jackson at fidessa.com Fri Jul 13 12:39:28 2018 From: Ben.Jackson at fidessa.com (Ben Jackson) Date: Fri, 13 Jul 2018 11:39:28 +0000 Subject: [winswitch] Unable to connect from Windows client to RHEL 7.4 xpra server using SSH (v2.3.2-r19729) Message-ID: Hi, I'm completely new to Xpra, so please forgive me if I'm not providing the right diagnostics ;) Quick summary: when trying to connect xpra from Windows 7 to RHEL 7.4 over SSH, the connection fails with the following message: 2018-07-13 12:21:02,765 Error: failed to receive anything, not an xpra server? 2018-07-13 12:21:02,765 could also be the wrong protocol, username, password or port The client and server versions are the same, and the ssh connection appears to work in any other context I can try it. Detail: My setup is: - Server: - RHEL 7.4 - Xpra 2.3.2-v19729 using the yum repo (I tried the latest 2.3.3-..., but downgraded to ensure the client/serer were same version for testing) - Python 2.7.5 - public key in authorized_keys - Client: - Windows 7 Pro - Xpra 2.3.2-v19729 (latest MSI on website) - Python 2.7.9 (not sure if the windows package uses python from my path) - Pageant running with private ssh key I have installed Xpra as above and started the server successfully with "xpra start --start=xterm :1002". However, when I attempt to connect from windows to the server using "Xpra_Cmd attach ssh://ash at ukwok-pc1385-vpc7/1002" it fails to connect and I get the following. 2018-07-13 12:20:59,173 Xpra gtk2 client version 2.3.2-r19729 64-bit 2018-07-13 12:20:59,179 running on Microsoft Windows 7 2018-07-13 12:20:59,363 Warning: failed to import opencv: 2018-07-13 12:20:59,363 DLL load failed: Invalid access to memory location. 2018-07-13 12:20:59,363 webcam forwarding is disabled 2018-07-13 12:21:00,192 GStreamer version 1.14.1 for Python 2.7.15 64-bit 2018-07-13 12:21:00,593 OpenGL_accelerate module loaded 2018-07-13 12:21:00,627 Using accelerated ArrayDatatype 2018-07-13 12:21:01,296 Warning: vendor 'Intel' is greylisted, 2018-07-13 12:21:01,296 you may want to turn off OpenGL if you encounter bugs 2018-07-13 12:21:01,357 OpenGL enabled with Intel(R) HD Graphics 2018-07-13 12:21:01,428 desktop size is 3000x1920 with 1 screen: 2018-07-13 12:21:01,428 Default (793x508 mm - DPI: 96x96) 2018-07-13 12:21:01,428 DISPLAY1 1920x1200 at 0x381 (677x423 mm - DPI: 72x72) workarea: 1920x1200 2018-07-13 12:21:01,428 DISPLAY2 1080x1920 at 1920x0 (381x677 mm - DPI: 72x72) workarea: 1080x1920 2018-07-13 12:21:01,442 keyboard settings: layout=gb 2018-07-13 12:21:02,765 Error: failed to receive anything, not an xpra server? 2018-07-13 12:21:02,765 could also be the wrong protocol, username, password or port 2018-07-13 12:21:02,765 Connection lost (Full client and server log output with debug can be found in this gist: https://gist.github.com/puremourning/36d6beb1d0baefe3cb0b79ec7cbfe3dd). The server log does not change during the process (tailing /var/user//:1002.log). I'm looking for some advice on how to debug this. It looks like an environment issue (xpra doesn't seem to be getting any data back from plink?), but I'm a bit stuck. Some things I have tried/confirmed: - Using unauthenticated TCP _does_ work, but is not allowable in corporate env due to infosec. - Using PuTTY to connect to the host works (ditto using putty's plink to echo hello). No password is required (pageant is working) (command putty\plink.exe -ssh ash at ukwok-pc1385-vpc7 echo hello). Hello is echo'd. - Using the bundled plink.exe (tortoise?) to connect to the account/host in question, no password is requested, but "hello" is *not* printed (command: plink -ssh ash at ukwok-pc1385-vpc7 echo hello) - Before setting up pageant (i.e. ssh-agent), all the above were tested while entering the account password manually, with the same results. - Using a proprietary windows x-server, I am able to connect to xpra from the server (i.e. to itself) with xpra attach. (i.e. start an xterm with display pointed at windows X server, attach to xpra, see xterm) Many thanks for any advice you may be able to provide. Naturally if there is any further information I can provide, just shout! Cheers, Ben This message is intended only for the stated addressee(s) and may be confidential. Access to this email by anyone else is unauthorised. Any opinions expressed in this email do not necessarily reflect the opinions of Fidessa. Any unauthorised disclosure, use or dissemination, either whole or in part is prohibited. If you are not the intended recipient of this message, please notify the sender immediately. Fidessa plc registered in England and Wales no. 3781700. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK Fidessa buy-side ltd registered in England and Wales no. 3656437. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK Fidessa group plc registered in England and Wales no. 3234176. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK From antoine at nagafix.co.uk Fri Jul 13 20:43:43 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 14 Jul 2018 02:43:43 +0700 Subject: [winswitch] Unable to connect from Windows client to RHEL 7.4 xpra server using SSH (v2.3.2-r19729) In-Reply-To: References: Message-ID: On 13/07/18 18:39, Ben Jackson via shifter-users wrote: > Hi, > > I'm completely new to Xpra, so please forgive me if I'm not providing the right diagnostics ;) > > Quick summary: > > when trying to connect xpra from Windows 7 to RHEL 7.4 over SSH, the connection fails with the following message: > > 2018-07-13 12:21:02,765 Error: failed to receive anything, not an xpra server? > 2018-07-13 12:21:02,765 could also be the wrong protocol, username, password or port > > The client and server versions are the same, and the ssh connection appears to work in any other context I can try it. > > Detail: > > My setup is: > - Server: > - RHEL 7.4 > - Xpra 2.3.2-v19729 using the yum repo (I tried the latest 2.3.3-..., but downgraded to ensure the client/serer were same version for testing) > - Python 2.7.5 > - public key in authorized_keys > - Client: > - Windows 7 Pro > - Xpra 2.3.2-v19729 (latest MSI on website) > - Python 2.7.9 (not sure if the windows package uses python from my path) It doesn't. > - Pageant running with private ssh key > > I have installed Xpra as above and started the server successfully with "xpra start --start=xterm :1002". Does the server respond if you run: xpra info :1002 > However, when I attempt to connect from windows to the server using "Xpra_Cmd attach ssh://ash at ukwok-pc1385-vpc7/1002" it fails to connect and I get the following. > > 2018-07-13 12:20:59,173 Xpra gtk2 client version 2.3.2-r19729 64-bit > 2018-07-13 12:20:59,179 running on Microsoft Windows 7 > 2018-07-13 12:20:59,363 Warning: failed to import opencv: > 2018-07-13 12:20:59,363 DLL load failed: Invalid access to memory location. > 2018-07-13 12:20:59,363 webcam forwarding is disabled > 2018-07-13 12:21:00,192 GStreamer version 1.14.1 for Python 2.7.15 64-bit > 2018-07-13 12:21:00,593 OpenGL_accelerate module loaded > 2018-07-13 12:21:00,627 Using accelerated ArrayDatatype > 2018-07-13 12:21:01,296 Warning: vendor 'Intel' is greylisted, > 2018-07-13 12:21:01,296 you may want to turn off OpenGL if you encounter bugs > 2018-07-13 12:21:01,357 OpenGL enabled with Intel(R) HD Graphics > 2018-07-13 12:21:01,428 desktop size is 3000x1920 with 1 screen: > 2018-07-13 12:21:01,428 Default (793x508 mm - DPI: 96x96) > 2018-07-13 12:21:01,428 DISPLAY1 1920x1200 at 0x381 (677x423 mm - DPI: 72x72) workarea: 1920x1200 > 2018-07-13 12:21:01,428 DISPLAY2 1080x1920 at 1920x0 (381x677 mm - DPI: 72x72) workarea: 1080x1920 > 2018-07-13 12:21:01,442 keyboard settings: layout=gb > 2018-07-13 12:21:02,765 Error: failed to receive anything, not an xpra server? > 2018-07-13 12:21:02,765 could also be the wrong protocol, username, password or port > 2018-07-13 12:21:02,765 Connection lost > > (Full client and server log output with debug can be found in this gist: https://gist.github.com/puremourning/36d6beb1d0baefe3cb0b79ec7cbfe3dd). > > The server log does not change during the process (tailing /var/user//:1002.log). This usually means that the xpra proxy process fails to locate the socket. > I'm looking for some advice on how to debug this. It looks like an environment issue (xpra doesn't seem to be getting any data back from plink?), but I'm a bit stuck. This sounds very similar to this ticket: http://xpra.org/trac/ticket/1892 You may want to try the latest beta 2.4 build you can find. > Some things I have tried/confirmed: > > - Using unauthenticated TCP _does_ work, but is not allowable in corporate env due to infosec. Maybe SSL mode would be allowed? > - Using PuTTY to connect to the host works (ditto using putty's plink to echo hello). No password is required (pageant is working) (command putty\plink.exe -ssh ash at ukwok-pc1385-vpc7 echo hello). Hello is echo'd. Can you run "xpra list" from there and see the server? > - Using the bundled plink.exe (tortoise?) to connect to the account/host in question, no password is requested, but "hello" is *not* printed (command: plink -ssh ash at ukwok-pc1385-vpc7 echo hello) > - Before setting up pageant (i.e. ssh-agent), all the above were tested while entering the account password manually, with the same results. > - Using a proprietary windows x-server, I am able to connect to xpra from the server (i.e. to itself) with xpra attach. (i.e. start an xterm with display pointed at windows X server, attach to xpra, see xterm) > > Many thanks for any advice you may be able to provide. Naturally if there is any further information I can provide, just shout! >From your log output, I see that your sockets are in an unusual location: created unix domain socket: /var/lib/ash/.xpra/ukwok-pc1385-vpc7-1002 Why is that? Is your $HOME in /var/lib ? When connecting over ssh, CentOS fails to set XDG_RUNTIME_DIR correctly, so this other default socket location may not be found either. We have code to try to workaround this problem, but this makes me think that maybe you want to try specifying --socket-dirs=/tmp at both ends to see if that helps. Cheers, Antoine > > Cheers, > Ben > > > > This message is intended only for the stated addressee(s) and may be confidential. Access to this email by anyone else is unauthorised. Any opinions expressed in this email do not necessarily reflect the opinions of Fidessa. Any unauthorised disclosure, use or dissemination, either whole or in part is prohibited. If you are not the intended recipient of this message, please notify the sender immediately. > Fidessa plc registered in England and Wales no. 3781700. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK > Fidessa buy-side ltd registered in England and Wales no. 3656437. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK > Fidessa group plc registered in England and Wales no. 3234176. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From pierre.wulles at gmail.com Mon Jul 16 15:45:09 2018 From: pierre.wulles at gmail.com (Pierre Wulles) Date: Mon, 16 Jul 2018 16:45:09 +0200 Subject: [winswitch] Proxy Message-ID: Hello, I'm trying to use xpra with a proxy but I have an error when I try to connect: https://justpaste.it/5clwy I did: xpra start :100 --start=xterm xpra proxy :100 --auth=allow --bind-tcp=127.0.0.1:14501 xpra attach tcp://foo:bar at 127.0.0.1:14501/100 It is probably some little mistake but I can't figure it out what. Thank you in advance, Pierre From Ben.Jackson at fidessa.com Mon Jul 16 18:23:02 2018 From: Ben.Jackson at fidessa.com (Ben Jackson) Date: Mon, 16 Jul 2018 17:23:02 +0000 Subject: [winswitch] Unable to connect from Windows client to RHEL 7.4 xpra server using SSH (v2.3.2-r19729) Message-ID: Antoine, Thankyou kindly for getting back to me via the list. Apologies, my company mail system blocked your reply, but I saw the digest. In response to your queries: >> I have installed Xpra as above and started the server successfully with "xpra start --start=xterm :1002". >Does the server respond if you run: >xpra info :1002 It does: [ash at ukwok-pc1385-vpc7 ~]$ xpra info :1002 | wc -l 714 I can post the full output if you think it is useful. >> - Using unauthenticated TCP _does_ work, but is not allowable in corporate env due to infosec. >Maybe SSL mode would be allowed? I expect so, thought the setup and certificate management could be painful at scale. >> - Using PuTTY to connect to the host works (ditto using putty's plink to echo hello). No password is required (pageant is working) (command >putty\plink.exe -ssh ash at ukwok-pc1385-vpc7 echo hello). Hello is echo'd. >Can you run "xpra list" from there and see the server? Sure, so on the client: C:\Program Files\Xpra>Xpra_Cmd list Found the following xpra sessions: Xpra: Via PuTTY: C:\Program Files\Xpra>"C:\Program Files (x86)\PuTTY\plink.exe" -ssh -l ash -T uk wok-pc1385-vpc7 xpra list Found the following xpra sessions: /run/user/16095/xpra: LIVE session at :1002 /var/lib/ash/.xpra: LIVE session at :1002 Using plink bundled with Xpra: C:\Program Files\Xpra>plink -ssh ash at ukwok-pc1385-vpc7 xpra list C:\Program Files\Xpra> On the server: [ash at ukwok-pc1385-vpc7 ~]$ xpra list Found the following xpra sessions: /run/user/16095/xpra: LIVE session at :1002 /var/lib/ash/.xpra: LIVE session at :1002 >>From your log output, I see that your sockets are in an unusual location: >created unix domain socket: /var/lib/ash/.xpra/ukwok-pc1385-vpc7-1002 >Why is that? Is your $HOME in /var/lib ? >When connecting over ssh, CentOS fails to set XDG_RUNTIME_DIR correctly, >{so this other default socket location may not be found either. >We have code to try to workaround this problem, but this makes me think >that maybe you want to try specifying --socket-dirs=/tmp at both ends to >see if that helps. Good spot, but yes, the user's home directory is actually /var/lib/ash in this case (for complex and uninteresting reasons!). [ash at ukwok-pc1385-vpc7 ~]$ echo $HOME /var/lib/ash So I tried using --socket-dirs, as follows, with the same result: Server: [ash at ukwok-pc1385-vpc7 ~]$ xpra stop :1002 server requested disconnect: server shutdown xpra at :1002 has exited. [ash at ukwok-pc1385-vpc7 ~]$ xpra start --start=xterm --socket-dirs=/tmp :1002 seamless session now available on display :1002 [ash at ukwok-pc1385-vpc7 ~]$ Client: C:\Program Files\Xpra>Xpra_Cmd attach ssh://ash at ukwok-pc1385-vpc7/1002 --socket- dirs=/tmp 2018-07-16 18:11:28,344 Xpra gtk2 client version 2.3.2-r19729 64-bit 2018-07-16 18:11:28,350 running on Microsoft Windows 7 2018-07-16 18:11:31,992 Warning: failed to import opencv: 2018-07-16 18:11:31,993 DLL load failed: Invalid access to memory location. 2018-07-16 18:11:31,993 webcam forwarding is disabled 2018-07-16 18:11:32,953 GStreamer version 1.14.1 for Python 2.7.15 64-bit 2018-07-16 18:11:34,890 OpenGL_accelerate module loaded 2018-07-16 18:11:35,004 Using accelerated ArrayDatatype 2018-07-16 18:11:35,884 Warning: vendor 'Intel' is greylisted, 2018-07-16 18:11:35,885 you may want to turn off OpenGL if you encounter bugs 2018-07-16 18:11:36,003 OpenGL enabled with Intel(R) HD Graphics 2018-07-16 18:11:36,061 desktop size is 3000x1920 with 1 screen: 2018-07-16 18:11:36,062 Default (793x508 mm - DPI: 96x96) 2018-07-16 18:11:36,062 DISPLAY1 1920x1200 at 0x381 (677x423 mm - DPI: 72x72 ) workarea: 1920x1200 2018-07-16 18:11:36,062 DISPLAY2 1080x1920 at 1920x0 (381x677 mm - DPI: 72x7 2) workarea: 1080x1920 2018-07-16 18:11:36,129 keyboard settings: layout=gb 2018-07-16 18:11:37,273 Error: failed to receive anything, not an xpra server? 2018-07-16 18:11:37,274 could also be the wrong protocol, username, password o r port 2018-07-16 18:11:37,274 Connection lost Traceback (most recent call last): File "./xpra/client/mixins/tray.py", line 54, in reset_icon AttributeError: 'NoneType' object has no attribute 'icon_timestamp' >> I'm looking for some advice on how to debug this. It looks like an environment issue (xpra doesn't seem to be getting any data back from plink?), but I'm a bit stuck. >This sounds very similar to this ticket: >http://xpra.org/trac/ticket/1892 >You may want to try the latest beta 2.4 build you can find. It really does sound similar. Pretty much identical! Many apologies for not finding that before reporting a dup! I know how frustrating that can be. I will try the latest beta builds from https://xpra.org/beta/windows/ and report back. Thanks again for your rapid response! Cheers, Ben -----Original Message----- From: Ben Jackson Sent: 13 July 2018 12:39 To: 'shifter-users at lists.devloop.org.uk' Subject: Unable to connect from Windows client to RHEL 7.4 xpra server using SSH (v2.3.2-r19729) Importance: High Hi, I'm completely new to Xpra, so please forgive me if I'm not providing the right diagnostics ;) Quick summary: when trying to connect xpra from Windows 7 to RHEL 7.4 over SSH, the connection fails with the following message: 2018-07-13 12:21:02,765 Error: failed to receive anything, not an xpra server? 2018-07-13 12:21:02,765 could also be the wrong protocol, username, password or port The client and server versions are the same, and the ssh connection appears to work in any other context I can try it. Detail: My setup is: - Server: - RHEL 7.4 - Xpra 2.3.2-v19729 using the yum repo (I tried the latest 2.3.3-..., but downgraded to ensure the client/serer were same version for testing) - Python 2.7.5 - public key in authorized_keys - Client: - Windows 7 Pro - Xpra 2.3.2-v19729 (latest MSI on website) - Python 2.7.9 (not sure if the windows package uses python from my path) - Pageant running with private ssh key I have installed Xpra as above and started the server successfully with "xpra start --start=xterm :1002". However, when I attempt to connect from windows to the server using "Xpra_Cmd attach ssh://ash at ukwok-pc1385-vpc7/1002" it fails to connect and I get the following. 2018-07-13 12:20:59,173 Xpra gtk2 client version 2.3.2-r19729 64-bit 2018-07-13 12:20:59,179 running on Microsoft Windows 7 2018-07-13 12:20:59,363 Warning: failed to import opencv: 2018-07-13 12:20:59,363 DLL load failed: Invalid access to memory location. 2018-07-13 12:20:59,363 webcam forwarding is disabled 2018-07-13 12:21:00,192 GStreamer version 1.14.1 for Python 2.7.15 64-bit 2018-07-13 12:21:00,593 OpenGL_accelerate module loaded 2018-07-13 12:21:00,627 Using accelerated ArrayDatatype 2018-07-13 12:21:01,296 Warning: vendor 'Intel' is greylisted, 2018-07-13 12:21:01,296 you may want to turn off OpenGL if you encounter bugs 2018-07-13 12:21:01,357 OpenGL enabled with Intel(R) HD Graphics 2018-07-13 12:21:01,428 desktop size is 3000x1920 with 1 screen: 2018-07-13 12:21:01,428 Default (793x508 mm - DPI: 96x96) 2018-07-13 12:21:01,428 DISPLAY1 1920x1200 at 0x381 (677x423 mm - DPI: 72x72) workarea: 1920x1200 2018-07-13 12:21:01,428 DISPLAY2 1080x1920 at 1920x0 (381x677 mm - DPI: 72x72) workarea: 1080x1920 2018-07-13 12:21:01,442 keyboard settings: layout=gb 2018-07-13 12:21:02,765 Error: failed to receive anything, not an xpra server? 2018-07-13 12:21:02,765 could also be the wrong protocol, username, password or port 2018-07-13 12:21:02,765 Connection lost (Full client and server log output with debug can be found in this gist: https://gist.github.com/puremourning/36d6beb1d0baefe3cb0b79ec7cbfe3dd). The server log does not change during the process (tailing /var/user//:1002.log). I'm looking for some advice on how to debug this. It looks like an environment issue (xpra doesn't seem to be getting any data back from plink?), but I'm a bit stuck. Some things I have tried/confirmed: - Using unauthenticated TCP _does_ work, but is not allowable in corporate env due to infosec. - Using PuTTY to connect to the host works (ditto using putty's plink to echo hello). No password is required (pageant is working) (command putty\plink.exe -ssh ash at ukwok-pc1385-vpc7 echo hello). Hello is echo'd. - Using the bundled plink.exe (tortoise?) to connect to the account/host in question, no password is requested, but "hello" is *not* printed (command: plink -ssh ash at ukwok-pc1385-vpc7 echo hello) - Before setting up pageant (i.e. ssh-agent), all the above were tested while entering the account password manually, with the same results. - Using a proprietary windows x-server, I am able to connect to xpra from the server (i.e. to itself) with xpra attach. (i.e. start an xterm with display pointed at windows X server, attach to xpra, see xterm) Many thanks for any advice you may be able to provide. Naturally if there is any further information I can provide, just shout! Cheers, Ben This message is intended only for the stated addressee(s) and may be confidential. Access to this email by anyone else is unauthorised. Any opinions expressed in this email do not necessarily reflect the opinions of Fidessa. Any unauthorised disclosure, use or dissemination, either whole or in part is prohibited. If you are not the intended recipient of this message, please notify the sender immediately. Fidessa plc registered in England and Wales no. 3781700. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK Fidessa buy-side ltd registered in England and Wales no. 3656437. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK Fidessa group plc registered in England and Wales no. 3234176. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK From Ben.Jackson at fidessa.com Tue Jul 17 11:03:56 2018 From: Ben.Jackson at fidessa.com (Ben Jackson) Date: Tue, 17 Jul 2018 10:03:56 +0000 Subject: [winswitch] Unable to connect from Windows client to RHEL 7.4 xpra server using SSH (v2.3.2-r19729) Message-ID: For the list: I tracked this down to the remote user using a non-bourne-compatible shell: http://xpra.org/trac/ticket/1892#comment:13 -----Original Message----- From: Ben Jackson Sent: 16 July 2018 18:23 To: 'antoine at nagafix.co.uk' Cc: 'shifter-users at lists.devloop.org.uk' Subject: RE: Unable to connect from Windows client to RHEL 7.4 xpra server using SSH (v2.3.2-r19729) Antoine, Thankyou kindly for getting back to me via the list. Apologies, my company mail system blocked your reply, but I saw the digest. In response to your queries: >> I have installed Xpra as above and started the server successfully with "xpra start --start=xterm :1002". >Does the server respond if you run: >xpra info :1002 It does: [ash at ukwok-pc1385-vpc7 ~]$ xpra info :1002 | wc -l 714 I can post the full output if you think it is useful. >> - Using unauthenticated TCP _does_ work, but is not allowable in corporate env due to infosec. >Maybe SSL mode would be allowed? I expect so, thought the setup and certificate management could be painful at scale. >> - Using PuTTY to connect to the host works (ditto using putty's plink to echo hello). No password is required (pageant is working) (command >putty\plink.exe -ssh ash at ukwok-pc1385-vpc7 echo hello). Hello is echo'd. >Can you run "xpra list" from there and see the server? Sure, so on the client: C:\Program Files\Xpra>Xpra_Cmd list Found the following xpra sessions: Xpra: Via PuTTY: C:\Program Files\Xpra>"C:\Program Files (x86)\PuTTY\plink.exe" -ssh -l ash -T uk wok-pc1385-vpc7 xpra list Found the following xpra sessions: /run/user/16095/xpra: LIVE session at :1002 /var/lib/ash/.xpra: LIVE session at :1002 Using plink bundled with Xpra: C:\Program Files\Xpra>plink -ssh ash at ukwok-pc1385-vpc7 xpra list C:\Program Files\Xpra> On the server: [ash at ukwok-pc1385-vpc7 ~]$ xpra list Found the following xpra sessions: /run/user/16095/xpra: LIVE session at :1002 /var/lib/ash/.xpra: LIVE session at :1002 >>From your log output, I see that your sockets are in an unusual location: >created unix domain socket: /var/lib/ash/.xpra/ukwok-pc1385-vpc7-1002 >Why is that? Is your $HOME in /var/lib ? >When connecting over ssh, CentOS fails to set XDG_RUNTIME_DIR correctly, >{so this other default socket location may not be found either. >We have code to try to workaround this problem, but this makes me think >that maybe you want to try specifying --socket-dirs=/tmp at both ends to >see if that helps. Good spot, but yes, the user's home directory is actually /var/lib/ash in this case (for complex and uninteresting reasons!). [ash at ukwok-pc1385-vpc7 ~]$ echo $HOME /var/lib/ash So I tried using --socket-dirs, as follows, with the same result: Server: [ash at ukwok-pc1385-vpc7 ~]$ xpra stop :1002 server requested disconnect: server shutdown xpra at :1002 has exited. [ash at ukwok-pc1385-vpc7 ~]$ xpra start --start=xterm --socket-dirs=/tmp :1002 seamless session now available on display :1002 [ash at ukwok-pc1385-vpc7 ~]$ Client: C:\Program Files\Xpra>Xpra_Cmd attach ssh://ash at ukwok-pc1385-vpc7/1002 --socket- dirs=/tmp 2018-07-16 18:11:28,344 Xpra gtk2 client version 2.3.2-r19729 64-bit 2018-07-16 18:11:28,350 running on Microsoft Windows 7 2018-07-16 18:11:31,992 Warning: failed to import opencv: 2018-07-16 18:11:31,993 DLL load failed: Invalid access to memory location. 2018-07-16 18:11:31,993 webcam forwarding is disabled 2018-07-16 18:11:32,953 GStreamer version 1.14.1 for Python 2.7.15 64-bit 2018-07-16 18:11:34,890 OpenGL_accelerate module loaded 2018-07-16 18:11:35,004 Using accelerated ArrayDatatype 2018-07-16 18:11:35,884 Warning: vendor 'Intel' is greylisted, 2018-07-16 18:11:35,885 you may want to turn off OpenGL if you encounter bugs 2018-07-16 18:11:36,003 OpenGL enabled with Intel(R) HD Graphics 2018-07-16 18:11:36,061 desktop size is 3000x1920 with 1 screen: 2018-07-16 18:11:36,062 Default (793x508 mm - DPI: 96x96) 2018-07-16 18:11:36,062 DISPLAY1 1920x1200 at 0x381 (677x423 mm - DPI: 72x72 ) workarea: 1920x1200 2018-07-16 18:11:36,062 DISPLAY2 1080x1920 at 1920x0 (381x677 mm - DPI: 72x7 2) workarea: 1080x1920 2018-07-16 18:11:36,129 keyboard settings: layout=gb 2018-07-16 18:11:37,273 Error: failed to receive anything, not an xpra server? 2018-07-16 18:11:37,274 could also be the wrong protocol, username, password o r port 2018-07-16 18:11:37,274 Connection lost Traceback (most recent call last): File "./xpra/client/mixins/tray.py", line 54, in reset_icon AttributeError: 'NoneType' object has no attribute 'icon_timestamp' >> I'm looking for some advice on how to debug this. It looks like an environment issue (xpra doesn't seem to be getting any data back from plink?), but I'm a bit stuck. >This sounds very similar to this ticket: >http://xpra.org/trac/ticket/1892 >You may want to try the latest beta 2.4 build you can find. It really does sound similar. Pretty much identical! Many apologies for not finding that before reporting a dup! I know how frustrating that can be. I will try the latest beta builds from https://xpra.org/beta/windows/ and report back. Thanks again for your rapid response! Cheers, Ben -----Original Message----- From: Ben Jackson Sent: 13 July 2018 12:39 To: 'shifter-users at lists.devloop.org.uk' Subject: Unable to connect from Windows client to RHEL 7.4 xpra server using SSH (v2.3.2-r19729) Importance: High Hi, I'm completely new to Xpra, so please forgive me if I'm not providing the right diagnostics ;) Quick summary: when trying to connect xpra from Windows 7 to RHEL 7.4 over SSH, the connection fails with the following message: 2018-07-13 12:21:02,765 Error: failed to receive anything, not an xpra server? 2018-07-13 12:21:02,765 could also be the wrong protocol, username, password or port The client and server versions are the same, and the ssh connection appears to work in any other context I can try it. Detail: My setup is: - Server: - RHEL 7.4 - Xpra 2.3.2-v19729 using the yum repo (I tried the latest 2.3.3-..., but downgraded to ensure the client/serer were same version for testing) - Python 2.7.5 - public key in authorized_keys - Client: - Windows 7 Pro - Xpra 2.3.2-v19729 (latest MSI on website) - Python 2.7.9 (not sure if the windows package uses python from my path) - Pageant running with private ssh key I have installed Xpra as above and started the server successfully with "xpra start --start=xterm :1002". However, when I attempt to connect from windows to the server using "Xpra_Cmd attach ssh://ash at ukwok-pc1385-vpc7/1002" it fails to connect and I get the following. 2018-07-13 12:20:59,173 Xpra gtk2 client version 2.3.2-r19729 64-bit 2018-07-13 12:20:59,179 running on Microsoft Windows 7 2018-07-13 12:20:59,363 Warning: failed to import opencv: 2018-07-13 12:20:59,363 DLL load failed: Invalid access to memory location. 2018-07-13 12:20:59,363 webcam forwarding is disabled 2018-07-13 12:21:00,192 GStreamer version 1.14.1 for Python 2.7.15 64-bit 2018-07-13 12:21:00,593 OpenGL_accelerate module loaded 2018-07-13 12:21:00,627 Using accelerated ArrayDatatype 2018-07-13 12:21:01,296 Warning: vendor 'Intel' is greylisted, 2018-07-13 12:21:01,296 you may want to turn off OpenGL if you encounter bugs 2018-07-13 12:21:01,357 OpenGL enabled with Intel(R) HD Graphics 2018-07-13 12:21:01,428 desktop size is 3000x1920 with 1 screen: 2018-07-13 12:21:01,428 Default (793x508 mm - DPI: 96x96) 2018-07-13 12:21:01,428 DISPLAY1 1920x1200 at 0x381 (677x423 mm - DPI: 72x72) workarea: 1920x1200 2018-07-13 12:21:01,428 DISPLAY2 1080x1920 at 1920x0 (381x677 mm - DPI: 72x72) workarea: 1080x1920 2018-07-13 12:21:01,442 keyboard settings: layout=gb 2018-07-13 12:21:02,765 Error: failed to receive anything, not an xpra server? 2018-07-13 12:21:02,765 could also be the wrong protocol, username, password or port 2018-07-13 12:21:02,765 Connection lost (Full client and server log output with debug can be found in this gist: https://gist.github.com/puremourning/36d6beb1d0baefe3cb0b79ec7cbfe3dd). The server log does not change during the process (tailing /var/user//:1002.log). I'm looking for some advice on how to debug this. It looks like an environment issue (xpra doesn't seem to be getting any data back from plink?), but I'm a bit stuck. Some things I have tried/confirmed: - Using unauthenticated TCP _does_ work, but is not allowable in corporate env due to infosec. - Using PuTTY to connect to the host works (ditto using putty's plink to echo hello). No password is required (pageant is working) (command putty\plink.exe -ssh ash at ukwok-pc1385-vpc7 echo hello). Hello is echo'd. - Using the bundled plink.exe (tortoise?) to connect to the account/host in question, no password is requested, but "hello" is *not* printed (command: plink -ssh ash at ukwok-pc1385-vpc7 echo hello) - Before setting up pageant (i.e. ssh-agent), all the above were tested while entering the account password manually, with the same results. - Using a proprietary windows x-server, I am able to connect to xpra from the server (i.e. to itself) with xpra attach. (i.e. start an xterm with display pointed at windows X server, attach to xpra, see xterm) Many thanks for any advice you may be able to provide. Naturally if there is any further information I can provide, just shout! Cheers, Ben This message is intended only for the stated addressee(s) and may be confidential. Access to this email by anyone else is unauthorised. Any opinions expressed in this email do not necessarily reflect the opinions of Fidessa. Any unauthorised disclosure, use or dissemination, either whole or in part is prohibited. If you are not the intended recipient of this message, please notify the sender immediately. Fidessa plc registered in England and Wales no. 3781700. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK Fidessa buy-side ltd registered in England and Wales no. 3656437. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK Fidessa group plc registered in England and Wales no. 3234176. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK From antoine at nagafix.co.uk Tue Jul 17 11:09:06 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 17 Jul 2018 12:09:06 +0200 Subject: [winswitch] Proxy In-Reply-To: References: Message-ID: <2470d162-7965-4fa0-9861-7ee69e6bc75c@nagafix.co.uk> On 16/07/18 16:45, Pierre Wulles via shifter-users wrote: > Hello, > I'm trying to use xpra with a proxy but I have an error when I try to > connect: https://justpaste.it/5clwy I hope this paste never times out. In any case, here are the most noteworthy excerpts: > Warning: missing sound module This points towards a custom installation where you installed individual packages rather than just "yum install xpra". This is not a problem in itself, but worth mentioning. For more guidance see: http://xpra.org/trac/wiki/ReportingBugs > Xpra gtk2 client version 2.4-r19930 64-bit This is a beta build. It should work, but you may want to try the stable release when you hit problems. > server failure: disconnected before the session could be established > server requested disconnect: session not found error (no sessions found) There could be a number of reasons for this error. You need to make sure the session exists, with "xpra list" for example. If it does, then you need to figure out why the proxy can't find it. You may want to run the proxy with "-d proxy" to get more debug log messages. > I did: > xpra start :100 --start=xterm > xpra proxy :100 --auth=allow --bind-tcp=127.0.0.1:14501 Don't use the same display number for the proxy and the start command. Also, make sure to post the output from those server commands, either by running with --daemon=no or by pasting the log file. > xpra attach tcp://foo:bar at 127.0.0.1:14501/100 > > It is probably some little mistake but I can't figure it out what. > Thank you in advance, Always keep an eye on the server log files when debugging things. The answer is usually there. Cheers, Antoine > Pierre > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From pierre.wulles at gmail.com Mon Jul 23 14:50:42 2018 From: pierre.wulles at gmail.com (Pierre Wulles) Date: Mon, 23 Jul 2018 15:50:42 +0200 Subject: [winswitch] How to setup a proxy with different computer Message-ID: Hello, I need your help because I don't know how to use a proxy with xpra. I have three machines on my network, let's call them server (ip = 1.2.3.4) , proxy (ip = 5.6.7.8) and client (ip = 9.9.9.9). If I want to start an app, le's say xterm on the first one and using the second one as a proxy, what should I do ? I have tried a lot of command on every machine but everytime it fails with error message as xpra initialization error: failed to connect to '5.6.7.8:14501': [Errno 113] No route to host Also I wonder if I am suppose to open port that I want to use before ? Thank you ! From pierre.wulles at gmail.com Tue Jul 24 16:11:57 2018 From: pierre.wulles at gmail.com (Pierre Wulles) Date: Tue, 24 Jul 2018 17:11:57 +0200 Subject: [winswitch] Bug with dbus Message-ID: Hello, I,m still trying to set up an architecture with xpra over 3 machines, client, server and proxy, when I use: xpra proxy :13 --bind-tcp=0.0.0.0:10000 --tcp-auth=allow --daemon=no to set up the proxy, I have the following error: 2018-07-24 16:37:02,764 dbus server error Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/server/dbus/dbus_common.py", line 12, in dbus_exception_wrap v = fn() File "/usr/lib64/python2.7/site-packages/xpra/server/proxy/proxy_server.py", line 92, in make_dbus_server return Proxy_DBUS_Server(self) File "/usr/lib64/python2.7/site-packages/xpra/server/proxy/proxy_dbus_server.py", line 24, in __init__ bus = init_session_bus() File "/usr/lib64/python2.7/site-packages/xpra/dbus/common.py", line 22, in init_session_bus _session_bus = dbus.SessionBus(private=private) File "/usr/lib64/python2.7/site-packages/dbus/_dbus.py", line 211, in __new__ mainloop=mainloop) File "/usr/lib64/python2.7/site-packages/dbus/_dbus.py", line 100, in __new__ bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop) File "/usr/lib64/python2.7/site-packages/dbus/bus.py", line 122, in __new__ bus = cls._new_for_bus(address_or_type, mainloop=mainloop) DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: /usr/bin/dbus-launch terminated abnormally with the following error: Autolaunch error: X11 initialization failed. 2018-07-24 16:37:02,767 Error setting up server dbus instance: 2018-07-24 16:37:02,767 org.freedesktop.DBus.Error.Spawn.ExecFailed 2018-07-24 16:37:02,767 /usr/bin/dbus-launch terminated abnormally with the following error 2018-07-24 16:37:02,767 Autolaunch error 2018-07-24 16:37:02,767 X11 initialization failed. What does that mean ? Thank you very much, Pierre From antoine at nagafix.co.uk Tue Jul 24 22:36:26 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 24 Jul 2018 23:36:26 +0200 Subject: [winswitch] How to setup a proxy with different computer In-Reply-To: References: Message-ID: On 23/07/18 15:50, Pierre Wulles via shifter-users wrote: > Hello, > I need your help because I don't know how to use a proxy with xpra. I have > three machines on my network, let's call them server (ip = 1.2.3.4) , proxy > (ip = 5.6.7.8) and client (ip = 9.9.9.9). > If I want to start an app, le's say xterm on the first one and using the > second one as a proxy, what should I do ? I have tried a lot of command on > every machine but everytime it fails with error message as > xpra initialization error: > failed to connect to '5.6.7.8:14501': > [Errno 113] No route to host > Also I wonder if I am suppose to open port that I want to use before ? You haven't included enough information for someone to reproduce your problem, please see: http://xpra.org/trac/wiki/ReportingBugs And consider filing a ticket with the details. Cheers, Antoine > Thank you ! > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Tue Jul 24 22:43:01 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 24 Jul 2018 23:43:01 +0200 Subject: [winswitch] Bug with dbus In-Reply-To: References: Message-ID: <25b4559a-581f-25a8-e3dd-9c132dab343a@nagafix.co.uk> On 24/07/18 17:11, Pierre Wulles via shifter-users wrote: > Hello, I,m still trying to set up an architecture with xpra over 3 > machines, client, server and proxy, when I use: > xpra proxy :13 --bind-tcp=0.0.0.0:10000 --tcp-auth=allow --daemon=no > to set up the proxy, I have the following error: > 2018-07-24 16:37:02,764 dbus server error > Traceback (most recent call last): > File > "/usr/lib64/python2.7/site-packages/xpra/server/dbus/dbus_common.py", line > 12, in dbus_exception_wrap > v = fn() > File > "/usr/lib64/python2.7/site-packages/xpra/server/proxy/proxy_server.py", > line 92, in make_dbus_server > return Proxy_DBUS_Server(self) > File > "/usr/lib64/python2.7/site-packages/xpra/server/proxy/proxy_dbus_server.py", > line 24, in __init__ > bus = init_session_bus() > File "/usr/lib64/python2.7/site-packages/xpra/dbus/common.py", line 22, > in init_session_bus > _session_bus = dbus.SessionBus(private=private) > File "/usr/lib64/python2.7/site-packages/dbus/_dbus.py", line 211, in > __new__ > mainloop=mainloop) > File "/usr/lib64/python2.7/site-packages/dbus/_dbus.py", line 100, in > __new__ > bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop) > File "/usr/lib64/python2.7/site-packages/dbus/bus.py", line 122, in > __new__ > bus = cls._new_for_bus(address_or_type, mainloop=mainloop) > DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: > /usr/bin/dbus-launch terminated abnormally with the following error: > Autolaunch error: X11 initialization failed. > > 2018-07-24 16:37:02,767 Error setting up server dbus instance: > 2018-07-24 16:37:02,767 org.freedesktop.DBus.Error.Spawn.ExecFailed > 2018-07-24 16:37:02,767 /usr/bin/dbus-launch terminated abnormally with > the following error > 2018-07-24 16:37:02,767 Autolaunch error > 2018-07-24 16:37:02,767 X11 initialization failed. > What does that mean ? The xpra proxy is trying to setup a dbus service that you can use to interact with it, the dbus bindings try to execute "dbus-launch" which is failing to execute due to the X11 initialization error. Either fix your environment so that the user running the proxy can run "dbus-launch" without getting those errors, or use: --dbus-launch=no --dbus-control=no Cheers, Antoine > Thank you very much, > Pierre > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From pierre.wulles at gmail.com Tue Jul 31 13:08:31 2018 From: pierre.wulles at gmail.com (Pierre Wulles) Date: Tue, 31 Jul 2018 14:08:31 +0200 Subject: [winswitch] server requested 'xor' digest, cowardly... Message-ID: Hello, I've recently succeeded in having a server running xterm, a proxy and a machine connecting to the proxy. I used for this what is described in https://xpra.org/trac/wiki/ProxyServer at the section Remote Hosts. What I want to do now is launching the pplication from the client, so what I did is: {{{ xpra start :100 --bind-tcp=0.0.0.0:10100 }}} on the server. Then {{{ xpra proxy :100 --bind-tcp=0.0.0.0:14501 --tcp-auth=allow,filename=./xpra-auth.sdb --socket-dir=/tmp --daemon=no }}} On the proxy and there is "foo bar nobody nobody ip" in xpra-auth because I didn't know how to indicate where the server is, the problem that I guess here is that if you put --tcp-auth=allow the file xpra-auth is ignored because when I go to the client: {{{ xpra start --tcp-auth=allow tcp://vml-xprabetatest/14501 xterm }}} I have the following error: {{{ 2018-07-31 13:50:22,161 Error: authentication failed: 2018-07-31 13:50:22,161 server requested 'xor' digest, cowardly refusing to use it without encryption }}} What can I do ? Thank you, Pierre