[X2Go-Dev] Processed: Re: Bug#693: domain users can't open sessions
Processing control commands: tag -1 + moreinfo Bug #693 [x2goserver] domain users can't open sessions Added tag(s) moreinfo. -- 693: http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=693 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
If you make a x2goclient connection to each farm server, then time will be increased by seconds for such connection. And if the server farm consist of more then 2-3 servers, then connection time will increase strongly. - Исходное сообщение - Plus, I still think, that X2Go Client should request another machine, if the provided server was offline and more than one server is configured in the broker's session profile. ___ 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
Why not introduce a datastore which holds the current state of all the servers in the server farm? Then the broker could query that one for information to choose server from. One could either use a separate database server for this or use something like sqlite (or mysql / postgresql / other) on each server host with some sort of replication (redundancy and avoids the need to contact one specific server - all can reply to the queries) or caching of the central datastore contents. On how to update this information in the datastore there's two ways I'm thinking of right now: 1. Each server in the server farm writes to the datastore it's current status at regular intervals 2. One, or several (backup role if the master should fail) server(s) have been given the responsibility to query the servers in the farm for their status at regular intervals Regardless of the chosen implementation from one of those solutions would IMO: * Make the broker-role easier to implement with regard to advanced setups * Removes the wait for / time issue at connection, or selection, process - just contact the datastore * Makes it possible to write a simple and central management app/webapp which one could administer the entire server farm * other possibilites Regards, Terje 2014-12-08 14:06 GMT+01:00 Sergey Savko sa...@tophouse.ru: If you make a x2goclient connection to each farm server, then time will be increased by seconds for such connection. And if the server farm consist of more then 2-3 servers, then connection time will increase strongly. - Исходное сообщение - Plus, I still think, that X2Go Client should request another machine, if the provided server was offline and more than one server is configured in the broker's session profile. ___ x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev ___ x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev
Re: [X2Go-Dev] Bug#684: Bug#684: Bug#684: select_session offers offline servers to X2Go Client
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 08.12.2014 um 22:48 schrieb Terje Andersen: Why not introduce a datastore which holds the current state of all the servers in the server farm? Then the broker could query that one for information to choose server from. snip Welcome to Citrix MetaFrame Presentation Server, ca. 2003-2004. While doing it that way may be an option, I think we should take a look what Citrix et al. have learned in the last ten years. ;-) Of course, if they still happen to do it that way for Citrix XenApp (the current incarnation of MetaFrame), then it probably means there is no better solution. - -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) iQEcBAEBAgAGBQJUhibyAAoJEG7d9BjNvlEZywsIAJymqWdJ4bkAmiE6s1CxPcJZ SvFT6zqD2jSRpxubnThTi5q3ycF8AG6j7M7N/E5mJlMzhul2VcAWwMDt+0aerOlI kzK5d4tFVQomVSs7CV6vOAuLU8/5hURtpUHHmd4298nQzqvaBn1vHAHnzCuDzj+V j6X34PtLlHzGMtPcxQqYz2cP9YMX0nFmYysCI+C3aBqAJe3EVv3095xpDzeYmfL9 o93R8v12/akuDwSar3FpHkF9o9dxew9Igd5wY0SDlKpXtm9TEDOyDUpcTgsguA2g wmlqIihukKYJqlOLsCHGRL9hC+tENbJndcKjh++stZaHrCikEB9Lk5tG1zFwmEU= =cm95 -END PGP SIGNATURE- ___ x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev
Re: [X2Go-Dev] Bug#684: Bug#684: Bug#684: select_session offers offline servers to X2Go Client
HI Stefan, hi Terje, On Mo 08 Dez 2014 23:32:18 CET, Stefan Baur wrote: Am 08.12.2014 um 22:48 schrieb Terje Andersen: Why not introduce a datastore which holds the current state of all the servers in the server farm? Then the broker could query that one for information to choose server from. snip Welcome to Citrix MetaFrame Presentation Server, ca. 2003-2004. While doing it that way may be an option, I think we should take a look what Citrix et al. have learned in the last ten years. ;-) Of course, if they still happen to do it that way for Citrix XenApp (the current incarnation of MetaFrame), then it probably means there is no better solution. - -Stefan Mr Lee and I have something similar in mind for X2Go next generation. The ideal form maybe is: o all servers individually check their current load status regularly o the servers in a farm exchange session states and load status among each other in regular intervals o a broker machine simply is part of such a farm (but not offering the remote desktop/application service), so it know everything already and doesn't have to query it o nothing gets written to a DB, if a machine goes down it looses its memory. If it comes up it joins back into the circle of servers and learns about the others anew (and provides info about itself to the others) o all information is stored in RAM by a permanent daemon process, no extra storage backend should be necessary (the information becomes useless immediately when a machine goes down, so why keep it in a DB?) Greets, 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 pgpW89sxbEklr.pgp Description: Digitale PGP-Signatur ___ x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev
[X2Go-Dev] Bug#694: CUPS 1.7.x remounts /tmp and breaks cups-x2go
Package: cups-x2go Severity: important The workaround provided below can be applied to x2goprint from x2goserver-printing package. But my gut feelings tell me, we need to review cups-x2go. Maybe this bug gets reassigned to x2goserver-printing later, if my gut feelings get proven wrong. Mike - Weitergeleitete Nachricht von Роман in...@yandex.ru - Datum: Mon, 01 Dec 2014 10:59:36 +0300 Von: Роман in...@yandex.ru Betreff: [X2Go-User] X2Go Linux Server. Virtual print issue workaround An: x2go-u...@lists.x2go.org For those who can't print to redirected printer here my workaround. On X2Go Server do following (by root): -- cd /usr/bin mv x2goprint x2goprint.orig cat EOF x2goprint #!/bin/bash umount /tmp x2goprint.orig $@ EOF chmod a+x x2goprint --- The problem is that CUPS remounts /tmp during print process. Therefore temporary x2go directories have become unavailable. Best regards, Inpos. - Ende der weitergeleiteten Nachricht - -- 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 pgpyoT9fMJz2n.pgp Description: Digitale PGP-Signatur ___ x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev
