Am 27.06.2018 um 09:58 schrieb al...@libero.it: >> This sounds like a rather weird setup. If the PCs are only used as >> ThinClients, with no local windows applications that you need, then >> running Windows on them is just unneccessary ballast. >> I would strongly recommend switching to our X2Go ThinClient image - it >> can be installed into an existing Windows installation, if you don't >> want to/cannot use network booting. Both the network booting as well as >> the local installation offer an easy way back to Windows if something >> goes wrong, as you do _not_ need to delete Windows/repartition/reformat. >> > > Yes, it may sound weird but it's not: there are a lot of setups like our > classroom which is based on devices like the "Wyse" from Dell. The main > reason why at that moment we chose them was a better support for the RDPv10 > protocol and yes, why not, a nice centralized management support. All > opinable, I understand, but now that they are there we are trying to get the > better experience from them; at the moment we wanted replace the > "OpenNX/Nomachine" client with something newer and "x2go" seemed to be a nice > option.
Well, X2Go-TCE offers RDP support via its FreeRDP and rdesktop backends, and we have users on Wyse/Dell hardware. So that's not a problem per se if you wanted to move away from Windows. (A word of warning, though: if you're using DisplayPort outputs, there is a known issue with certain Dell TFTs. This seems to affect not only X2Go-TCE, but all Linux versions past a certain Kernel version - the actual bug, though, is in the TFT's firmware, from what we can tell. See <https://wiki.x2go.org/doku.php/wiki:advanced:tce:tested-hardware> for more.) >>> At the welcome screen there are the options to use "windows" or >>> "linux" and each with a specific configration set, call it "session". So >>> when I press "Linux" it calls the MYSESSION only with its settings.Now, I >>> wanted to keep this welcome interface as clean and easy possible. The good >>> was pyHoca-gui with its "username/password" window, but again, it's too >>> slow to start once a user press "Linux" >>> >>> then I saw that x2goclient can accept many parameters if run by >>> command line and infact it works nice with the ones I specified in the >>> previous message. Only the GUI is not "clean": it's split vertically in two >>> parts and "worst", on the right, one can still see the name of the session. >>> Well, it's not a drama, but it's not so clean as the pyHoca interface. >>> >>> > >> The clean way to solve this would be the X2Go Session Broker. >> In broker mode, X2GoClient prompts you for your login credentials first, >> and determines which session tiles should be shown depending on the user >> name, group membership, or IP range. You'd probably want to use user >> name or group membership for your use case. >> That way, each user is only shown the tile they are supposed to see. >> >> A hackish solution would be to specify different "sessions" files. >> You'd have to create two Desktop Shortcuts, each specifying --portable, >> and also --session-conf= - with two different "sessions" files, one per >> Shortcut, and each only containing one single session configuration. >> Then you'd use --session= to make them default to the one tile they >> should actually use to connect. >> (Using --portable on Windows will also cause a "sessions" file to be >> created, rather than storing the session information in the registry.) >> > > yes, that is what we are doing right now: a welcome screen with many > "connectors", where each X2Go shortcut points to its own -notEditable- > "session" profile. Unfortunately after one clicks it happens what I described > before. Not quite. You are using several session profiles, but in one and the same "sessions" file. That's the key difference. Once you start specifying separate "sessions" files, where each file contains exactly one session, you will only see one tile. >> Before going that route, I'd seriously consider anX2Go-ThinClientEditon >> + X2GoBroker solution, though. >> >> In case you're afraid that it would take you too long to figure >> everything out yourself, the TCE build scripts are documented here >> (<https://wiki.x2go.org/doku.php/doc:howto:tce>), there is a demo broker >> environment you can install on a few virtual machines to try things out >> (see <https://wiki.x2go.org/doku.php/doc:howto:x2gobroker>), and if that >> still isn't enough, there's also the commercial support option: >> > > I hoped that a compact interface was much easier than setting up another > piece of software.. well, honestly THAT sounds weird to me too :-) but Ok, I > may give it a try, even if and in our current setup is much more than useless > :-) Well, the answer is two-fold. The Broker suggestion remains, even if you cannot move away from Windows on the client side. It will make life easier for you, once you're past the initial setup phase. And if you don't need loadbalancing (always connecting to the same X2Go server), you don't even need the "big" broker, but can use a rather simple one (which we intend to ship as a sample script in a future release, we just haven't gotten around to packaging it yet). [commercial support] > thank you for the kind replay and SORRY if it seemed I wanted to take profit > of this list instead of going directly to the commercial support: before > subscribing I read it can be used for asking help and so I did. You're always welcome to ask here - the only catch is that free support may take several days or weeks - or in the worst case, you might not get a reply at all (especially if you're asking about some edge case, particularly weird setup, or it's a holiday season). Also, free support usually comes in the form of enabling you to help yourself - pointers to documentation, suggestions to change certain configs, etc. - so you need to be willing and able to invest some of your time in learning X2Go and doing things yourself. Which might not be what you want to base your support on in a scenario where you're running your productions systems on X2Go, and where a failed setup means financial losses or has similar undesired effects. With paid support, professional help is usually only a phone call or E-Mail away, and you basically turn your problem into someone else's problem, paying with money instead of your own time. Especially if you allow the support company remote access to your systems, your part of the problem solving ends at telling the supporter "Here's the broken machine, here's the money, now you go fix it." So it's not that you _have_ to contact one of the commercial support vendors - it's just a question of whether you'd like to have more free time in exchange for paying some money. Some people actually prefer throwing money against a problem until it disappears, rather than learning new things. ;-) I know, that concept is hard to grasp for die-hard open source folks. ;-) Kind Regards, Stefan Baur -- 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 _______________________________________________ x2go-user mailing list x2go-user@lists.x2go.org https://lists.x2go.org/listinfo/x2go-user
