x2go-dev

x2go-dev@lists.x2go.org

5399 discussions

Bug#705: client sends password to http broker without percent encoding special characters such as &
by Jason Alavaliant 16 Dec '14

16 Dec '14

Package: x2goclient Version: 4.0.3.1 Severity: grave Tags: patch I've just setup an x2go load balanced setup using x2gobroker (http connection - x2goclient --broker-url=http://server:8080/plain/inifile), after putting it into production we found a number of our users had their passwords rejected when trying to sign into the x2go client to access the broker. Tracing through the traffic/logs we found that the problem is that password values were being set unencoded to the broker, so for example if there was an & present in a password the form data was submitted in the form of task=listsessions&user=user&password=mypass&word&authid= which resulted in the data being read by the server as the pasword being mypass rather than mypass&word The attached patch in my testing (done on Linux) fixes the client so data is correctly escaped so the above example would be submitted as task=listsessions&user=user&password=mypass%26word&authid= which is correctly parsed as the password being mypass&word and allows the login to work. If we could get an indication of when this fix is likely to make a client release it would appreciated since we currently don't have Windows and OSX builds with the patch and are trying to workout if it's worth the time of setting up development workstations to be able to compile the client for those platforms vs just waiting for the next client release. Thanks for your time. Jason

1 0

Bug#702: X2Go Client / NX proxy window disappear when printing/viewing a CUPS-X2Go print job
by Klaus Ade Johnstad 16 Dec '14

16 Dec '14

I see this as well. I have just recently started looking at x2go-printing, and have no idea when it used to work, if at all. -- Klaus Ade Johnstad klaus(a)linuxavdelingen.no Mobil:938 69 567 67E61D18B2C44F8A3DA35C6D849F9F5F 26FA477D

2 3

Bug#674: Fwd: Bug#674: Acknowledgement (keycode -> keycode translation harmful (makes configuration complex))
by Ulrich Sibiller 16 Dec '14

16 Dec '14

On Sat, Dec 13, 2014 at 1:45 AM, Robert Siemer <Robert.Siemer(a)backsla.sh> wrote: > If the translation is on, you get a skewed setup. > > Note that the x2go (with the setting of “do nothing”) does a non-perfect > copy with the same effect: if the translation is effective, the keyboard is > skewed and you are force to load at least “something” to fix XKB. If the > translation is off, you “only” need to load XKB configuration if that > non-perfect copy annoys you... > Thanks for the pointer! I had a look at it. As I suspected: the translation > is “bad”. Sometimes two different keycodes are translated to the same > keycode. How are you supposed to tell them apart on the remote side? You > can’t. > >> It seems some kind of translation from evdev to pc105 is done. > > The naming is a little funny: the keycodes generated by the kernel before > evdev were not called like that, were they? I don't think so. >> Do we need to disable setting >> up the translation within the nx code to make that work? > > That would be great as a first step. I was wondering why this translations had been introduced. It emerged between nxagent 3.2.0-10 and 3.3.0-9. The changelog between these releases contains (among others) these changes: nxagent-3.3.0-9 - Changed Keyboard initialization and reset. This change should fix TR11F02129, TR11F02131, TR11F02132. nxagent-3.3.0-4 - Fix the XKB map load in the case of 64 bit server. nxagent-3.3.0-3 - Fixed TR10F02119. If the remote X display is using evdev keyboard then copy maps from remote. nxagent-3.2.0-12 - Fixed TR08E01814. Added shadow keymap initialization in order to enable nxcompshad to translate keycodes across different layouts. So it MIGHT have been introduced mainly for shadow sessions. The TR10F02119 refers to Ubuntu 8.10, which - according to some other posts I found - is the version that introduced evdev. So the fix that solved evdev problems is causing problems when evdev is enabled. I also looked at the source and found that clearing the property seems to be the only way to disable the translation. (apart from disabling XKB completely). Uli

2 1

Bug#653: Incorrect rendering in java applications
by Александр Демидов 15 Dec '14

15 Dec '14

I use PHPStorm. For me that bug is actual. Some time x2go-session is freezes. After reconnect i view incorrect rendering for java app PHPStorm (gray blocks). Permanent problem - some graphics elements in java app PHPStorm rendering incorrectly (word without one letter, some gui-figures (icons) not viewed) I can attach screenshots to email?

1 0

Bug#702: X2Go Client / NX proxy window disappear when printing/viewing a CUPS-X2Go print job
by Mike Gabriel 15 Dec '14

15 Dec '14

Package: x2goclient Severity: grave Testing with various X2Go Servers (with PostgreSQL / SQLite3 sessions DB, with CUPS+X2GoServer on the same machine / on different machines). Testing on the client-side (Linux only) with X2Go Client / PyHoca-GUI (nightly builds as of today). What I observe with X2Go Client (Linux version): o I print something on the server o the X2Go Client print dialog pops up o I choose my preferred action (print to a printer, view as PDF) (a) PDF comes up in a viewer/gets printed, session stays intact (4 of 10 attempts) (b) nothing happens with the print job, X2Go Client / NX proxy vanish (no segfault) Thus, X2Go Client's client-side printing feature is currently not reliable, thus not really usable. The crashes are more producible on large PDF/print jobs. It would be good to hear from others that use this feature, as well. Does it work for you? Did it work for you? When did it stop working? I tested this with server-side setups that have been working in the past already. Package upgrade + test + see above. Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabriel(a)das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.x…

1 0

Bug#701: We need to talk about, and document, which options are overridable in which way
by Stefan Baur 14 Dec '14

14 Dec '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Package: x2goclient Hi, This was inspired by Mike#2's question on how to make microphone input configurable in X2GoClient. The real issue goes way deeper, IMO. Basically, we have three places where an option (not only the microphone input) could be set: 1) command line option 2) "forced" config from broker 3) sessions file (which may be on a read-only network share) a) We need to define an order of precedence for each option; also, how to deal with conflicting options. Example 1: For the microphone to be enabled, both the command line option as well as the sessions file/broker config should match. If the command line option says --mic=off, and the sessions file/broker config says "mic=on", then the mic should be *off*. Also, if the the sessions file/broker config says "mic=off", then the command line option should *not* be able to override that. Only if one side indicates that it doesn't care (by lacking the option), or if all sides agree, the microphone should be turned on. This is a security/privacy-related issue. Example 2: The sessions file or the broker may specify cinerama=off, and now the user attaches a second screen. So being able to pass a cinerama=on on the command line would be nice. Also, this has no security/privacy implications (as far as I can tell - but feel free to prove me wrong), so an agreement between all sides (command line vs. sessions file/broker) would not be neccessary, as long as we agree on an order of precedence and document that properly. b) The broker should be able to offer forced options as well as user-selectable options. Think of it like the Firefox preferences configuration: Admins may, e.g., force the use of a proxy using a "lockPref", but they can also set a default home page that still *can* be overriden by the user ("user_pref"). Similarly, the broker should be able to deliver a config (and the client should be able to parse it) that contains markers as to which settings are "locked" and which settings may still be changed by the user. Of course, this doesn't protect against "rogue" clients that have this feature disabled, so it's not a security measure, but it would allow an admin to, e.g., specify that sound is off by default, but the user may turn it on if so desired. Mike#1: Feel free to clone this bug for the broker part. - -Stefan - -- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUjhA4AAoJEG7d9BjNvlEZHbgH/1jzw3GOkDuMVV83RfEVMTPi h+pYBcifUYF/XUG+rGmiTAwvlmoUzgDNlOkbMhfuWJTP9ZwEMtGu3b6mbjEq5af6 5xB5OThtfgryF4DepfoRDeqyVzfLEH7/l43aP8IH08OJVtkiumNSfPvCoflP+IrM dZzufEYdxPF1lazWInXb8cqtcGMB3pNGQSqenWTXDSYdh9hEK0quHv/8F23eo4gg Wgu3FZumBQ5ZsmKIuYzzUJARDK+d8Qf1iW79rm9sMy239gCIdRiJ5Deq3rnHPEcS 2a4/1YwstCTMt/bCBwnl4CwssexWBj1vN3emvFhmz8cgGOgs6FXj3BnRX8Pf/G4= =y3d1 -----END PGP SIGNATURE-----

1 0

Bug#546: Unable to create SSL tunnel: Global request tcpip-forward failed
by Michael DePaulo 14 Dec '14

14 Dec '14

Package: x2goclient Version: 4.0.2.1-pre05 On Windows, doing the following steps 1. Connect to a session. 2. Disconnect from the session (click the X) 3. Connect to the session again. Causes the session to connect, but you receive both an error dialog and a warning dialog with the following text: Unable to create SSL tunnel: Global request tcpip-forward failed If you X out of or click OK to the error, nothing happens. If you X out of or click OK to the warning, the session ends and you get the message: Title Bar: X2Go - 211 The connection with the remote server was shut down. Please check the state of your network connection. It is safe to assume that if I build x2goclient for windows from the official source release of 4.0.2.1, it wold have this problem. Most, if not all earlier 4.0.2.1 preview builds are affected too.

2 1

Bug#526: Included PulseAudio consumes too much CPU when launched with high priority
by Nable 80 14 Dec '14

14 Dec '14

Package: x2goclient Version: 4.0.2.0 When I use sound forwarding and launch inside X2Go session some application with sound support, pulseaudio.exe at client side starts consuming ~100% CPU. By default, X2Go Client starts pulseaudio.exe with high priority (13). When I set priority to "Above Normal (10)" PA's CPU load drops to 10-20%. With "Normal (8)" it drops to almost 0%, although sound is still played stable, without any additional delays. I'm using WinXP SP3 (32-bit) on my laptop with single core CPU. This issue seems to be "PulseAudio 5.0 && WinXP"-specific.

4 5

Bug#700: x2goserver conflicts with current x2godesktopsharing version 3.1.1.2-0
by Alexey Murz Korepov 13 Dec '14

13 Dec '14

Package: x2goserver Version: 4.1.0.0-0~1206~ubuntu14.10.1 Package installed from Ubuntu ppa:x2go/ppa After last upgrade try I see that package manager want to remove x2godesktopsharing package via line: The following packages have unmet dependencies: x2goserver : Conflicts: x2godesktopsharing (< 3.1.1.2) but 3.1.1.2-0~154~ubuntu14.10.1 is to be installed. I see that x2goserver add dependency: Conflicts: x2godesktopsharing (< 3.1.1.2) Maybe 3.1.1.2-0 version is recognized less than 3.1.1.2? How can we fix this problem? -- Best regards, Alexey Murz Korepov. Email, Jabber: murznn(a)gmail.com

1 0

Bug#674: Acknowledgement (keycode -> keycode translation harmful (makes configuration complex))
by Robert Siemer 13 Dec '14

13 Dec '14

> I really think we should get evdev support into NX. What do you think? No, for keyboard configuration no special evdev support is needed. > But for now... so that I get a deeper feeling for this... Could you > provide a recipe for setting the correct / transparent keyboard > setup in the X2Go Session? For the commands see below. – At the moment I remove _XKB_RULES_NAMES from the root window property before starting/resuming x2go. > Wouldn't [running xkbcomp on the client] bypass all this setxkbmap > names and files altogether? I do already run xkbcomp on the client (and local as well) already, but it has no influence on keycode translation. – I’m not sure why you mentioned it... I believe I know the reasoning behind this keycode translation: in a heterogeneous environment, where you resume an x2go session from different workstations, there exists only one way to represent the different keyboards as an unchanging virtual keyboard. Yes: with keycode translation. The alternative would be to reconfigure XKB on each session resume, which I believe is perfectly reasonable. – This is what I (would) do. Allow me to draw a little ascii diagram here (look at it with fixed width font): local Xserver local Xclients x2go Xserv x2go Xclients [1] |==================xterm |==================chromium |==================xlsclients [3] |==================setxkbmap |==================xkbcomp [7] | [2] |------------------------------------|==============xterm |------------------------------------|==============gnome-do [6] |------------------------------------|==============xlsclients [4] |------------------------------------|==============setxkbmap |------------------------------------|==============xkbcomp [8] This is about the X11 protocol level view of an x2go setup. There are two Xservers running: the local one [1] and that x2go Xserver (that is called nxagent?) [2]. Both are drawn as lines made of | The x2go Xserver [2] represents its clients to the real local Xserver [1] as X11 clients, but draws them in a different way (still X11 protocol, though). An xlsclients [4] executed on the x2go server will be run against [2] and show only the x2go Xclients. On the local Xserver [1] an execution of xlsclients [3] lists all Xclients: the local ones and the remote ones. Unfortunately the x2go Xserver [2] does not relay all and everything to the local Xserver [1]. Examples: the X properties of the root window (some kind of “global” storage for X clients) exist twice (in [1] and [2]) and can differ. Also global hotkeys (“passive keygrabs”) of the x2go Xclients will be stored in [2] and have no influence on [1]. The launcher gnome-do [5] registers a hotkey: it will only be delivered to [5] if the local Xserver [1] has no local Xclient waiting for it _and_ any of the x2go client windows is in focus. Otherwise [2] will not even see the key event. Back to XKB. As far as I could observe, the XKB setup consists of an XKB configuration (which can be read and written with xkbcomp [7][8]) and the root window property _XKB_RULES_NAMES (can be read with xprop and setxkbmap and is written as a side effect of setxkbmap). Note that both things exist twice, stored in [1] and [2]. Command line examples: # dump current XKB configuration into one file $ xkbcomp $DISPLAY full.xkb # load full single-file XKB configuration $ xkbcomp full.xkb $DISPLAY # load from multiple files (xkbcomp will read more than one file): # main keymap file triggers inclusion of files from system X11 files $ xkbcomp keymap.xkb $DISPLAY # example keymap.xkb file xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete+my" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+inet(evdev)+eurosign(e)" }; xkb_geometry { include "pc(pc104)" }; }; # load from multiple files and have those searched for in your own tree # otherwise they will be looked for in XKB root /usr/share/X11/xkb $ xkbcomp -I/home/blabla/xkb mykeymap.xkb $DISPLAY # read _XKB_RULES_NAMES $ xprop -root _XKB_RULES_NAMES _XKB_RULES_NAMES(STRING) = "evdev", "pc104", "us,us", "altgr-intl,", "eurosign:e,caps:backspace,compose:rctrl" # interpreted version of the above $ setxkbmap -query rules: evdev model: pc104 layout: us,us variant: altgr-intl, options: eurosign:e,caps:backspace,compose:rctrl # delete _XKB_RULES_NAMES property (and then read it) $ xprop -root -remove _XKB_RULES_NAMES $ xprop -root _XKB_RULES_NAMES _XKB_RULES_NAMES: not found. $ setxkbmap -query Couldn't interpret _XKB_RULES_NAMES property Use defaults: rules - 'base' model - 'pc105' layout - 'us' rules: base model: pc105 layout: us # set _XKB_RULES_NAMES only(!) # I wrote a tool for that (xprop can’t set STRING arrays) # https://github.com/siemer/xproperty $ ./xproperty.py _XKB_RULES_NAMES evdev pc104 us altgr-intl <class 'Xlib.protocol.request.QueryExtension'> _XKB_RULES_NAMES evdev pc104 us altgr-intl # let setxkbmap read this property, override a part of it # and ask which keymap it would load $ setxkbmap -layout de -print xkb_keymap { xkb_keycodes { include "evdev+aliases(qwertz)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+de+inet(evdev)" }; xkb_geometry { include "pc(pc104)" }; }; # without “-print” setxkbmap will write the updated property _and_ # instruct the X11 server to load the resulting configuration # with the help of xkbcomp # → setxkbmap can’t just update the property alone On x2go session startup, the x2go Xserver [2] does a superficial investigation of what keyboard is used on the local Xserver [1] and sets up an incomplete keycode translation to a keyboard known as “xfree86”. It further creates an imperfect copy of the XKB configuration from [1] to [2]. The _XKB_RULES_NAMES property on [2] is set to rules=xfree86, model = pc???, layout = us(?) [I forgot the details]. Why is it a superficial investigation? – It takes the rules name from _XKB_RULES_NAMES and deducts the resulting keycodes directly from that (I believe). Even though in a common setup rules name “evdev” results in one specific set of keycodes and rules name “xfree86” in another specific set of keycodes, this is not a must. Why is the keycode translation incomplete? – As far as I observed it, “unusual” or unknown keycodes are not translated and passed as-is. Why is the XKB configuration copy imperfect? – I did a XKB dump on the local Xserver [1] and the x2go Xserver [2] after starting a new session. Keys with four levels of symbols turned into two-level-keysyms. – _Loading_ (i.e. xkbcomp/setxkbmap) a four-level configuration is no problem, though. Note: the imperfect copy of the XKB configuration is almost always useless, because the copied configuration does not match the new (translated) keycodes! Resuming an x2go session triggers the same superficial keyboard investigation, the translation kicks in again, but the XKB configuration is not touched (i.e. is not copied from [1] to [2]). Deleting the _XKB_RULES_NAMES property before session startup/resume or setting the first part (that is the “rules” part) to some unknown string results in untranslated keycodes. Please pardon me for repeating myself in some instances. Robert

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

x2go-dev