Re: [X2Go-Dev] [X2Go-Commits] [x2goclient] 01/01: Add new brocker feature. Broker can send to client some configuration in the section START_CLIENT_CONFIG - END_CLIENT_CONFIG. For the moment is suppor
Hi Alex, On Mi 22 Aug 2018 09:01:15 CEST, Oleksandr Shneyder wrote: Hi Mike, this feature is activated by broker. If broker is not supporting it, there are no changes in X2Go Client behavior. I never putting in master branch commits that supposed to break compatibility with previous versions. best regards Alex I have been looking into the events handling stuff once more and wonder what use case scenario you had in mind when adding the ability to TERMINATE or SUSPEND sessions from the broker via the client side? The broker can suspend/terminate sessions server-side and the X2Go Client will follow automatically. I understand that retrieving status information from the client is a nice thing to have, but what problem did you solve with the effort of adding the events code to X2Go Client? Thanks+Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpV73jgK2AfM.pgp Description: Digitale PGP-Signatur ___ x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
Re: [X2Go-Dev] [X2Go-Commits] [x2goclient] 01/01: Client now sends "login" parameter to the broker when executing task "selectsession". Before client just sent a username on the broker and it was impo
Hi Mike, My customers have different brokers. Some of them giving back sessions, depending on broker login, other on x2go server login. One of the examples: I'm logged on the broker as "Alex", you logged on the broker as "Mike". Both of us logged on the one of the servers in server pool "Lab-1" as user "labuser". We suspending our sessions. When we are logging to broker next time, I'll get my session and you yours. In the server pool "Lab-2", however, I want that broker user "Alex" could resume all sessions started by X2Go user "labuser". And maybe user "admin" could resume all sessions, doesn't matter who started them. And so on. Different customers have different use cases. I'm creating the brokers for the customers to perfectly fit into their infrastructure. All brokers are different. It's like a tailor suite. This is why I never supported a "legacy" broker. "Legacy" broker means that customers supposed to adapt their infrastructure to our solution. And it's exactly the opposite of what I wanted to achieve with X2Go broker. regards Alex Am 14.12.18 um 10:02 schrieb Mike Gabriel: > Hi Alex, > > On Mi 28 Nov 2018 17:03:52 CET, Oleksandr Shneyder wrote: > >> Hi Mike, >> >> this parameter is needed for the case if brokeruser and x2gouser are not >> same. Until this commit X2Go client only sent broker login to the >> broker, and not login name on x2go server. >> So if you are connecting to broker with name user1 and after this you >> want to connect to x2go server as user2, it was impossible to find out >> the list of sessions running for user2 on x2go server. Now X2Go client >> sends both logins (on broker and on x2go server). >> There are plenty use cases, where this information can be used. Another >> case when several broker users sharing same accounts on x2go servers. In >> this case you can track connection between X2Go Users and Broker Users. >> >> Anyway this should not brake any previous setups. X2Go Broker should >> just ignore arguments which are not supported. >> >> Regards >> Alex > > I have added the login feature now to the X2Go Session Broker. > > I encountered one corner case: > > * login into broker with X2Go Client for user A > * the broker sends over one session profile that has > broker agent support and can query the X2Go Server > in the profile for running/suspended sessions > * if there are sessions running/suspended for the broker > user, then it reports that there is a session running > or suspended (for the broker user) > > * if I now login with a user B (so another user as the > broker user), I get (of course) a new session > > Do you have a concept for this behaviour? Or do you simply deactivate > session resuming for setups where broker user != server user? > > Greets, > Mike -- --- Oleksandr Shneyder| Email: o.shney...@phoca-gmbh.de phoca GmbH| Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461 Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973 --- signature.asc Description: OpenPGP digital signature ___ x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
Re: [X2Go-Dev] [X2Go-Commits] [x2goclient] 01/01: Client now sends "login" parameter to the broker when executing task "selectsession". Before client just sent a username on the broker and it was impo
Hi Alex, On Mi 28 Nov 2018 17:03:52 CET, Oleksandr Shneyder wrote: Hi Mike, this parameter is needed for the case if brokeruser and x2gouser are not same. Until this commit X2Go client only sent broker login to the broker, and not login name on x2go server. So if you are connecting to broker with name user1 and after this you want to connect to x2go server as user2, it was impossible to find out the list of sessions running for user2 on x2go server. Now X2Go client sends both logins (on broker and on x2go server). There are plenty use cases, where this information can be used. Another case when several broker users sharing same accounts on x2go servers. In this case you can track connection between X2Go Users and Broker Users. Anyway this should not brake any previous setups. X2Go Broker should just ignore arguments which are not supported. Regards Alex I have added the login feature now to the X2Go Session Broker. I encountered one corner case: * login into broker with X2Go Client for user A * the broker sends over one session profile that has broker agent support and can query the X2Go Server in the profile for running/suspended sessions * if there are sessions running/suspended for the broker user, then it reports that there is a session running or suspended (for the broker user) * if I now login with a user B (so another user as the broker user), I get (of course) a new session Do you have a concept for this behaviour? Or do you simply deactivate session resuming for setups where broker user != server user? Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpAKHoio7ckB.pgp Description: Digitale PGP-Signatur ___ x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
Re: [X2Go-Dev] [X2Go-Commits] [x2goclient] 01/01: Add new brocker feature. Broker can send to client some configuration in the section START_CLIENT_CONFIG - END_CLIENT_CONFIG. For the moment is suppor
Hi Mike, unfortunately it's not always possible to get the session state from X2Go server. One simple example - direct RDP session. Another use case, sometimes (for example because of security reasons), you can't have access from X2Go Broker to X2Go Server. Anyway if you are running the network with many clients, different kinds of sessions (X2GO, XDMCP, RDP, DRDP), you'll appreciate the information that you can collect from X2Go Clients. regards Alex Am 14.12.18 um 10:05 schrieb Mike Gabriel: > Hi Alex, > > On Mi 22 Aug 2018 09:01:15 CEST, Oleksandr Shneyder wrote: > >> Hi Mike, >> >> this feature is activated by broker. If broker is not supporting it, >> there are no changes in X2Go Client behavior. I never putting in master >> branch commits that supposed to break compatibility with previous >> versions. >> >> best regards >> Alex > > I have been looking into the events handling stuff once more and wonder > what use case scenario you had in mind when adding the ability to > TERMINATE or SUSPEND sessions from the broker via the client side? > > The broker can suspend/terminate sessions server-side and the X2Go > Client will follow automatically. > > I understand that retrieving status information from the client is a > nice thing to have, but what problem did you solve with the effort of > adding the events code to X2Go Client? > > Thanks+Greets, > Mike > -- --- Oleksandr Shneyder| Email: o.shney...@phoca-gmbh.de phoca GmbH| Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461 Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973 --- signature.asc Description: OpenPGP digital signature ___ x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
[X2Go-Dev] Bug#1313: Bug#1313: Bug#1313: there is still a problem in getting a correct value for loadavgXX with loadchecker
Control: close -1 On Do 13 Sep 2018 15:19:19 CEST, Mike Gabriel wrote: Hi Walid, On Mo 13 Aug 2018 12:34:00 CEST, Walid MOGHRABI wrote: package: x2gobroker-agent version: 0.0.4.0-0~1038~ubuntu16.04.1 priority: bug I don't have a "0" value anymore since latest fixes so the loadchecker process don't crash anymore but still, there is something strange. Here is a fragment of my loadchecker logs from this morning. Just to give you the context, I have 22 servers which are all automaticaly started at 6 AM (wake on lan) and they are absolutely the same (blade servers with same CPU, memory amount, bios version, ...). I checked our monitoring to see if users were correctly distributed over the farm and at 7:30AM, I had about 7 or 8 users connected but 4 of them were on tce-server-21 where I should have had 1 user on 8 servers. Have you seen this issues more often? Does it hop from one server to another or occur on more than one server at a time? Here is the loadchecker log fragment : root@tce-manager-01 [~] # grep -B 1 'loadavgXX:1;' /var/log/x2gobroker/loadchecker.log ... 2018-07-24 07:15:01,200 - loadchecker - INFO - Executing agent command on remote host tce-server-21 (10.50.0.221): sh -c '/usr/lib/x2go/x2gobroker-agent foo checkload' 2018-07-24 07:15:01,622 - loadchecker - INFO - Broker agent answered: OK; loadavgXX:1; memAvail:23684; myMemAvail:23810; numCPU:16; typeCPU:2400; -- 2018-07-24 07:17:50,354 - loadchecker - INFO - Executing agent command on remote host tce-server-21 (10.50.0.221): sh -c '/usr/lib/x2go/x2gobroker-agent foo checkload' 2018-07-24 07:17:50,779 - loadchecker - INFO - Broker agent answered: OK; loadavgXX:1; memAvail:23686; myMemAvail:23812; numCPU:16; typeCPU:2400; -- 2018-07-24 07:20:32,550 - loadchecker - INFO - Executing agent command on remote host tce-server-21 (10.50.0.221): sh -c '/usr/lib/x2go/x2gobroker-agent foo checkload' 2018-07-24 07:20:32,964 - loadchecker - INFO - Broker agent answered: OK; loadavgXX:1; memAvail:23683; myMemAvail:23809; numCPU:16; typeCPU:2400; -- 2018-07-24 07:23:21,610 - loadchecker - INFO - Executing agent command on remote host tce-server-21 (10.50.0.221): sh -c '/usr/lib/x2go/x2gobroker-agent foo checkload' 2018-07-24 07:23:22,034 - loadchecker - INFO - Broker agent answered: OK; loadavgXX:1; memAvail:23685; myMemAvail:23811; numCPU:16; typeCPU:2400; -- 2018-07-24 07:26:03,872 - loadchecker - INFO - Executing agent command on remote host tce-server-21 (10.50.0.221): sh -c '/usr/lib/x2go/x2gobroker-agent foo checkload' 2018-07-24 07:26:04,286 - loadchecker - INFO - Broker agent answered: OK; loadavgXX:1; memAvail:23684; myMemAvail:23809; numCPU:16; typeCPU:2400; -- 2018-07-24 07:28:52,917 - loadchecker - INFO - Executing agent command on remote host tce-server-21 (10.50.0.221): sh -c '/usr/lib/x2go/x2gobroker-agent foo checkload' 2018-07-24 07:28:53,338 - loadchecker - INFO - Broker agent answered: OK; loadavgXX:1; memAvail:23684; myMemAvail:23809; numCPU:16; typeCPU:2400; -- 2018-07-24 07:31:35,252 - loadchecker - INFO - Executing agent command on remote host tce-server-21 (10.50.0.221): sh -c '/usr/lib/x2go/x2gobroker-agent foo checkload' 2018-07-24 07:31:35,670 - loadchecker - INFO - Broker agent answered: OK; loadavgXX:1; memAvail:23685; myMemAvail:23811; numCPU:16; typeCPU:2400; -- 2018-07-24 07:34:24,424 - loadchecker - INFO - Executing agent command on remote host tce-server-21 (10.50.0.221): sh -c '/usr/lib/x2go/x2gobroker-agent foo checkload' 2018-07-24 07:34:24,842 - loadchecker - INFO - Broker agent answered: OK; loadavgXX:1; memAvail:23683; myMemAvail:23809; numCPU:16; typeCPU:2400; The log message "Broker agent answered:" comes directly from X2Go Broker Agent. It is basically its raw output. This means, that the flaw must be in x2gobroker-agent.pl on the remote X2Go Server. Or that the loadchecker stops querying the broker agent and re-uses old data. Looking at x2gobroker-agent.pl: If we focus on the loadavgXX for now, we come to the conclusion, that the load was really "0" or it was negative (both gives us a loadavgXX value of "1". The value should normally be greater (system load of 1.0 brings a loadavgXX of 100). Looking at x2gobroker.agent.py: As the values always change slightly, we can't say that Python provides us the same return result string all the time. The query to the broker agent must have happened. We need to do more debugging if this issue reoccurs: * run '/usr/lib/x2go/x2gobroker-agent foo checkload' on the affected X2Go Server and see if the reported values match with what the load checker sees. * check if it is reoccuring on the same X2Go Server * if /usr/lib/x2go/x2gobroker-agent returns a load of zero, look at /proc/loadavg * and /proc/sys/vm/min_free_kbytes, /proc/meminfo /proc/cpuinfo ... and report all back here... As you can see, there is only 1
[X2Go-Dev] Processed: Re: Bug#1313: Bug#1313: there is still a problem in getting a correct value for loadavgXX with loadchecker
Processing control commands: > close -1 Bug #1313 [x2gobroker-agent] there is still a problem in getting a correct value for loadavgXX with loadchecker Marked Bug as done -- 1313: http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1313 X2Go Bug Tracking System Contact ow...@bugs.x2go.org with problems ___ x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
