[X2Go-Dev] Bug#664: X2Go issue (in src:x2goserver) has been marked as pending for release
tag #664 pending fixed #664 4.0.1.19 thanks Hello, X2Go issue #664 (src:x2goserver) reported by you has been fixed in X2Go Git. You can see the changelog below, and you can check the diff of the fix at: http://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=7be656c The issue will most likely be fixed in src:x2goserver (4.0.1.19). light+love X2Go Git Admin (on behalf of the sender of this mail) --- commit 7be656cd888024baba6df01d06e7ed93258dfc35 Author: Mike Gabriel mike.gabr...@das-netzwerkteam.de Date: Sat Dec 6 22:46:08 2014 +0100 Handle AD domain users gracefully when X2Go is used with SQLite DB backend. (Fixes: #664). diff --git a/debian/changelog b/debian/changelog index 5c71034..84cdd56 100644 --- a/debian/changelog +++ b/debian/changelog @@ -50,6 +50,8 @@ x2goserver (4.0.1.19-0x2go1) UNRELEASED; urgency=medium clipboard mode feature (and probably other code changes). - Document session startup / resumption failures (and their reasons) in server-side log output. +- Handle AD domain users gracefully when X2Go is used with SQLite DB + backend. (Fixes: #664). * debian/control: + Add D (x2goserver): libfile-which-perl. + Add C (x2goserver: x2godesktopsharing ( 3.1.1.2). ___ x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev
[X2Go-Dev] Processed: X2Go issue (in src:x2goserver) has been marked as pending for release
Processing commands for cont...@bugs.x2go.org: tag #664 pending Bug #664 [x2goserver] Domain\User notation for fails due to missing quotation of \ Added tag(s) pending. fixed #664 4.0.1.19 Bug #664 [x2goserver] Domain\User notation for fails due to missing quotation of \ There is no source info for the package 'x2goserver' at version '4.0.1.19' with architecture '' Unable to make a source version for version '4.0.1.19' Marked as fixed in versions 4.0.1.19. thanks Stopping processing here. Please contact me if you need assistance. -- 664: http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=664 X2Go Bug Tracking System Contact ow...@bugs.x2go.org with problems ___ x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev
[X2Go-Dev] Bug#684: Bug#684: select_session offers offline servers to X2Go Client
Control: clone -1 -2 -3 Control: reassign -2 x2goclient Control: reassign -3 python-x2go Control: retitle -1 add exclude-hosts parameter to selectsession task Control: retitle -2 request another server from broker provided server is down Control: retitle -3 request another server from broker provided server is down Control: severity -1 wishlist Control: severity -2 wishlist Control: severity -3 wishlist Control: block -2 by -1 Control: block -3 by -1 Control: tag -1 - patch Hi Sergey, On Fr 05 Dez 2014 17:14:51 CET, Sergey Savko wrote: This patch work after patch from http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=686 After thinking this through a little, I come to the conclusion that the broker cannot decide if a machine is down or not. We have to think very generically. There may be a scenario where the broker machine may be on an network segment where it cannot ping/reach the X2Go Servers. The X2Go Clients can reach the X2Go Broker. The broker provides an X2Go Server address on the selectsession broker task to the X2Go Client. Then the X2Go Client should test if that X2Go Server address works (via a simple ping6/ping command, machines should always be pingable!!!). If the ping fails, X2Go Client should go back to the broker and say: hey, that server failed for me, give me another one (but not the one you already gave me). I fear we need to do four things for this bug to get fixed: 1. extend broker/client communication protocol (second/third/... selectsession call with a list of hosts that did not work on previous attempts) 2. extend X2Go Session Broker with an exclude-hosts (or so) parameter for the selectsession task 3. Adapt X2Go Client: ping X2Go Server, go back to the broker if server is down and request another server 4. Adapt Python X2Go: dito Regards, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpm3tHfEX52N.pgp Description: Digitale PGP-Signatur ___ x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev
[X2Go-Dev] Bug#684: Bug#684: Bug#684: select_session offers offline servers to X2Go Client
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 06.12.2014 um 23:56 schrieb Mike Gabriel: Then the X2Go Client should test if that X2Go Server address works (via a simple ping6/ping command, machines should always be pingable!!!) Chiming in here: Even if they aren't pingable - Port 22 (or whichever you've set in the config as SSH port to be used) must be accepting connections. You can test that on Linux with nc -z ip.goes.he.re port_goes_here echo is reachable ... and I'm sure there are ways to do that inside the client code, too. Check if you can get a TCP handshake going within a set time frame (1 second? 2 seconds? 5 seconds?), then disconnect and proceed depending on the result. Actually ... simply lowering the timeout value for the currently existing code that handles the connection, when called in broker client mode, might already work. - -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) iQEcBAEBAgAGBQJUg46CAAoJEG7d9BjNvlEZAhIIAJA21I9lvk3hY6R3eAiCO2MG YSNlsUy/ShyhwB37UCNyCLOtEJ9j14xS73UNjbTiRkIFRE12kdtS8vyAPAdZJYqi 2+vbiVjg+TZ31rvk7RrkPyEepJ3+0UfRkfFPDm07sTP47DiBx+zYOyie2qVdrw1U GXJtQrylZRlzhVUi7rbAmNSp1HYaQ+B5yRX1ApmvNrZ+1+GZFybyZO2+eDM6ClHI QBmCePp5DPfN5bE9d+GvxWArkWQe5sgNT1USz7r64F5DOgB09M8f6vkuW3ygq4cW 8dDBhPnJv4PKs7IxLNnM+K1OnPopcKs1/EmkD5nbcNCvGSRW93nV4ic6RoZSD7g= =8x/F -END PGP SIGNATURE- ___ x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev
[X2Go-Dev] Bug#684: Bug#684: select_session offers offline servers to X2Go Client
If the server will give the address to which it can not connect, there will be no load balancing works. Since the server is connected to receive the coefficient of loading. - Исходное сообщение - От: Mike Gabriel mike.gabr...@das-netzwerkteam.de Кому: Sergey Savko sa...@tophouse.ru, 6...@bugs.x2go.org Отправленные: Воскресенье, 7 Декабрь 2014 г 1:56:05 Тема: Re: [X2Go-Dev] Bug#684: select_session offers offline servers to X2Go Client Control: clone -1 -2 -3 Control: reassign -2 x2goclient Control: reassign -3 python-x2go Control: retitle -1 add exclude-hosts parameter to selectsession task Control: retitle -2 request another server from broker provided server is down Control: retitle -3 request another server from broker provided server is down Control: severity -1 wishlist Control: severity -2 wishlist Control: severity -3 wishlist Control: block -2 by -1 Control: block -3 by -1 Control: tag -1 - patch Hi Sergey, On Fr 05 Dez 2014 17:14:51 CET, Sergey Savko wrote: This patch work after patch from http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=686 After thinking this through a little, I come to the conclusion that the broker cannot decide if a machine is down or not. We have to think very generically. There may be a scenario where the broker machine may be on an network segment where it cannot ping/reach the X2Go Servers. The X2Go Clients can reach the X2Go Broker. The broker provides an X2Go Server address on the selectsession broker task to the X2Go Client. Then the X2Go Client should test if that X2Go Server address works (via a simple ping6/ping command, machines should always be pingable!!!). If the ping fails, X2Go Client should go back to the broker and say: hey, that server failed for me, give me another one (but not the one you already gave me). I fear we need to do four things for this bug to get fixed: 1. extend broker/client communication protocol (second/third/... selectsession call with a list of hosts that did not work on previous attempts) 2. extend X2Go Session Broker with an exclude-hosts (or so) parameter for the selectsession task 3. Adapt X2Go Client: ping X2Go Server, go back to the broker if server is down and request another server 4. Adapt Python X2Go: dito Regards, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb ___ x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev
[X2Go-Dev] Bug#674: Acknowledgement (keycode - keycode translation harmful (makes configuration complex))
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 Xserverlocal Xclientsx2go Xservx2go 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
