x2go-dev

x2go-dev@lists.x2go.org

5399 discussions

Bug#678: X2Go issue (in src:x2goserver) has been marked as pending for release
by Mike Gabriel 22 Nov '14

22 Nov '14

tag #678 pending fixed #678 4.0.1.19 thanks Hello, X2Go issue #678 (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=93bcf85 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 93bcf8568a2b347bcc1e142e4315c9ba455c7e6f Author: Matthew L. Dailey <matthew.l.dailey(a)dartmouth.edu> Date: Sat Nov 22 15:24:16 2014 +0100 x2gocleansessions: Redirect stdin, stdout and stderr to /dev/null, test for the existence of the file descriptor before issuing the close, only capture the file descriptor backreference in the regex and send any close failures to syslog. (Fixes: #678). diff --git a/debian/changelog b/debian/changelog index c0e4300..31a351e 100644 --- a/debian/changelog +++ b/debian/changelog @@ -79,6 +79,13 @@ x2goserver (4.0.1.19-0x2go1) UNRELEASED; urgency=medium "x2gouser". + Add to BR: findutils. + [ Matthew L. Dailey ] + * New upstream version (4.0.1.19): + - x2gocleansessions: Redirect stdin, stdout and stderr to /dev/null, test + for the existence of the file descriptor before issuing the close, + only capture the file descriptor backreference in the regex and + send any close failures to syslog. (Fixes: #678). + -- Mike Gabriel <mike.gabriel(a)das-netzwerkteam.de> Tue, 07 Oct 2014 15:35:38 +0200 x2goserver (4.0.1.18-0x2go1) unstable; urgency=medium

2 1

Git access for Mihai Moldovan / new bin:package x2goserver-xsettingsd
by Mike Gabriel 22 Nov '14

22 Nov '14

Hi all, I have just granted Git commit access to Mihai Moldovan. Mihai has just found a very elegant solution for running Eclipse based applications inside X2Go rootless sessions. The problem is that rootless X2Go sessions lack a so-called settings-daemon (like gnome-settings-daemon, mate-settings-daemon, etc.). We have stumbled over a generic non-DE settings daemon (xsettingsd) that we will start deploying with X2Go Server (as package x2goserver-xsettingsd). 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#654: java application missing icons on menus
by Marco Bastianello 21 Nov '14

21 Nov '14

Package: x2goclient Version: 4.0.3.0 Running an eclipse-rcp application there are no icons on menus and popup-menus (right click) The problem occurs when using the x2go "single application" session tye, it doesn't happen on full desktop client: windows, linux, osx server: fedora 20 3.15.10-201.fc20.ppc64p7 xfce

2 1

Bug#678: File handles not closed properly in x2gocleansessions
by Matthew L. Dailey 20 Nov '14

20 Nov '14

Package: x2goserver Version: 4.0.1.18 Greetings, When x2gocleansessions starts up and forks, it is not properly closing stdin and stdout. This can lead to problems with upstream programs/scripts. For example, if a script calls apt-get upgrade to upgrade the x2goserver package, the postinst script loads x2gocleansessions and since stdin/stdout are not closed, the call will not finish properly. Looking through bug reports and commits, it looks like there was a bug #441 to fix a similar problem, but this fix looks like it wasn’t correct. Then, commit 336917af0dc087e4540fb3d55eb501d2fa4349be in 4.0.1.15 implemented a more comprehensive fix, but specifically excluded closing stdin and stout. Attached is a patch to fix a couple of things in this bit of the code: * Redirect stdin, stdout and stderr to /dev/null - as far as I know, this is best practice for perl daemons and what I have used for years in my own projects * Test for the existence of the file descriptor before issuing the close - this fixes a race condition where glob opens its own file descriptor to get the list, so this descriptor is gone when the script attempts to close it * Only capture the file descriptor backreference in the regex * Send any close failures to syslog I hope this all makes sense and that this can be incorporated into the code. Let me know if you have any questions or need any other information. Thanks for all your great work on X2Go!! -- Matthew L. Dailey Senior Systems Engineer Thayer School of Engineering Dartmouth College --- x2gocleansessions.orig 2014-10-07 00:05:56.000000000 -0400 +++ x2gocleansessions 2014-11-20 10:21:56.312590068 -0500 @@ -130,23 +130,21 @@ # close any open file descriptor left open by our parent before the fork my $fd; for (glob "/proc/$$/fd/*") { - if ($_ =~ m/\/proc\/(\d+)\/fd\/(\d+)/) { - $fd = $2; - if ( $fd == 0 ) { next; } - if ( $fd == 1 ) { next; } - if (POSIX::close($fd)) { - print ""; - #print "Closed:II$_\n"; - } else { - print ""; - #print "Error Closing:I$_\n"; + if ( ! -e $_ ) { next; } + if ($_ =~ m/\/proc\/\d+\/fd\/(\d+)/) { + $fd = $1; + if ( $fd < 3 ) { next; } + if (! POSIX::close($fd)) { + syslog('warning', "Error Closing $_: $!"); } - } else { - print ""; - #print "ERROR: $_\n"; } } + # redirect stdin, stdout and stderr + open *STDIN, q{<}, '/dev/null'; + open *STDOUT, q{>>}, '/dev/null'; + open *STDERR, q{>>}, '/dev/null'; + $SIG{TERM}=\&catch_term; $SIG{CHLD} = sub { wait };

1 0

Automated testing plan x2go
by cwe 19 Nov '14

19 Nov '14

To Automated testing team, I saw my setup for QA testing being bounced back to me from your mailserver, Kjetil. So I will try a different sender mailaddress. Hope the plan will reach you now. It is the same plan Mike already reviewed. Mike, thanks for your very good critics on my QA proposal! I read your correspondence with Mike regarding the QA setup plan. One of the foundations of my plan was to ask user permission to send over log data, in order to receive as much information as possible concerning operating system use, machinery, client connections and so on. Mike and you mentioned the privacy issue that aggregates from "calling-home". I think that is an important subject. Asking permission could indeed lower user acceptance, so I agree with you to leave this part of the plan. I'm no QA tester myself, as you know. At this moment I can't think of a way to speed up QA. I think the setup on which Mike and you did some brainstorms, involves lots of work. If there is anything I can do to help with trapping code (I can do some ruby, python and bash) in order to generate logging messages, let me know! If you agree, I will try to contact a QA testing consultant from my LinkedIn netwerk. Maybe she's a willing to co-operate or even join x2go and willing to hand over some QA suggestions to us. But I can't garantuee she is receptive to this. So do not be dissappointed when it fails! Kind regards, Kees Epema -- OSmigratie: deel wat u weet, weet wat u deelt osmigratie.nl

1 0

Bug#675: KDE and Gnome sessions fail on launch, standalone apps work fine
by Jasmin Lévesque 17 Nov '14

17 Nov '14

Package: x2goserver Version: 4.0.1.18-3 Hi, When I try to open a Gnome or KDE remote session, the client window opens and close immediately. No error message appears in the "detail windows" of the client. No logs are found on in the home of the user on the server. If I try to open a specific app instead of a full session, x2go works fine. The behavior seems similar to bug #671 but on CentOS 7 instead of SLES. I haven't tried older versions, this is a new deployment to replace an aging server. I tried to install the nighly build but I got a RPM dependency error that I will post as a separate bug. Best regards, Jasmin Lévesque Senior system analyst Vlan! Technologie

2 1

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

14 Nov '14

Package: x2goserver Version: 4.0.1.18 This bug report is about keyboard configuration issues: it is very challenging to have a custom keyboard configuration over x2go, while it is running perfectly on the local machine. With a Linux X2Go client the keyboard configuration could be entirely transparent, like an ssh-session with X11-forwarding is. But it isn’t. Background: In X11, the keycodes (numbers, e.g. 98) are sent by the X11-keyboard driver to the X11-core. These numbers also get reported to the applications. The applications in turn ask the X-server what they should make out of those keycodes (e.g. 'a', called “symbols”). The "final" problem I’m describing here is independent of the ‘keyboard settings’ of the x2go client. Nevertheless I describe here only the effects as seen with a configuration of "leave keyboard settings alone and don’t do anything about it”. With this kind of configuration the X-clients on the X2Go-server get the same answer to for keycodes → symbols requests as they get local, but they get it from the X2Go-server (nxagent or something). It seems that these settings get copied over to the X2Go-server and are left alone. I call those settings the “XKB configuration”. A different X2Go-client keyboard configuration (e.g. auto), by the way, would only reconfigure that XKB configuration, which can also be done by hand with xkbcomp or setxkbmap. —But the keycodes coming from the X2Go-client do not get sent over as is. The are “mangled” or “translated” in between, especially on any Linux client with evdev input device drivers. There is no X11 way to reconfigure those keycodes, as they normally come from the driver and are fixed for each key. Three questions came to my mind: 1) Why are the keycodes translated? 2) What logic does this translation follow? 3) How can I influence it? To the first question: it might be an artifact which is needed for other platforms. Second question: It turned out that the keycodes received by the applications on the X2Go-server are exactly those that an old pre-evdev Linux machine would generate. Those codes are written down and shipped with Xorg (X-Server) in the file keycodes/xfree86. The file used these days with the evdev driver is keycodes/evdev, where those known values are recorded. After changing my XKB configuration, completely “faking” a key on my keyboard to be something else, the X2Go server (or nxagent or whatever) still knew how to translate the keycode of it. After some trial and error I found out that the translation instance knowns about my original keyboard with the help of the some X property on the root window: $ xprop -root _XKB_RULES_NAMES _XKB_RULES_NAMES(STRING) = "evdev", "pc104", "us", "altgr-intl", "" The first string, here "evdev" dicts the rules file to use for XKB configuration changes. Note: this X property is not part of the XKB configuration, but setxkbmap read and records those five strings, which guide XKB configuration composition so to say. (Those five strings are rules, model, layout, variant and options, and they only guide which XKB configuration pieces to load. Those pieces are named keycodes, types, compat, symbols and geometry.) I don’t know if X2Go actually reads and parses the rules file and the XKB snippets or if the mappings are hardcoded, but changing the first string in _XKB_RULES_NAMES (which dictates which rules file to use) influences how the translation is done. the following rules files dictate which keycodes to use: evdev → evdev xfree86 → xfree86 base → xfree86 When starting or resuming an X2Go session, the _XKB_RULES_NAMES property is initially set to "xfree86", "null", "null", ... in the nxagent. It really looks like that this X11 intermediary wants to fake “xfree86 hardware” (i.e. old PC hardware + kernel). As my current setup has no “xfree86 settings” nowhere, I assume that this is fixed. In effect: changing _XKB_RULES_NAMES to something where the rules is set to “xfree86” or “base”, no translation takes place (or the translation is 1:1). This has to be configured before X2Go session resume or startup. Note that this does not change the XKB configuration (it would only influence the next setxkbmap run). Once no real keycode translation takes place, no XKB keyboard (re-)configuration is necessary as the copied local setup is probably exactly what you want.

3 2

Does x2goagent need x2goserver?
by Orion Poplawski 13 Nov '14

13 Nov '14

I see that in debian, x2goagent suggests x2goserver. Is there a usecase for x2goagent without x2goserver? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com

2 2

Processed: X2Go Bug #205 not an issue anymore, right?
by owner＠bugs.x2go.org 13 Nov '14

13 Nov '14

Processing control commands: > tag -1 moreinfo Bug #205 [nx-libs] Patch for fix cairo issue Added tag(s) moreinfo. -- 205: http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=205 X2Go Bug Tracking System Contact owner(a)bugs.x2go.org with problems

1 0

Bug#205: X2Go Bug #205 not an issue anymore, right?
by Mike Gabriel 13 Nov '14

13 Nov '14

Control: tag -1 moreinfo Hi Nicolas, I have recently reopened X2Go bug#205. It has been stated by Ulrich Sibiller that faking the X11 version has also been a practice performed by NoMachine (in nxagent-3.5.0-8). So I thougt to look at your bug report #205 [1] once more, but my impression is that the reported problem has meanwhile been fixed and it is sufficient to announce NX as X.Org 7.0 (not 7.1). Could you please shortly comment on this? Thanks, Mike (from X2Go upstream, one of the maintainers of NX-redistributed) [1] http://bugs.x2go.org/205 -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

x2go-dev