[X2Go-User] Python3-x2go

Sat Mar 4 00:10:15 CET 2017

I've been playing with this a bit the last couple of days and have a 
working PXE boot using your pre-built images (thanks for sharing). My 
plan is to replace XDMCP entirely with X2go native client, and it looks 
like I can setup custom immutable connections for that and my RDP 
sessions use the TCE. The end result will not be all that different from 
what we have now, so user training should not be an issue.

I'd like to customize or brand the client workspace. It looks like this 
isn't possible with OOTB configuration, so I dove into the code and 
found where the graphics are set and where the resource files are in the 
source tree. Making my changes are trivial enough (I think), so I plan 
to hack in my changes and replace the binaries in the squashfs image to 
deploy to my clients. Right now I'm trying to build the client with my 
changes and am running into problems.

I'm trying to follow 
http://wiki.x2go.org/doku.php/wiki:development:build-howto-linux:x2goclient 
and getting stuck. I can clone the x2goclient git repo just fine (step 
2a), but am unable to clone the nxproxy repo (step 1). I get "access 
denied or repository not exported". I was able to clone the nx-libs 
repos, but am not finding documentation on how to build that. I also 
looked at http://wiki.x2go.org/doku.php/wiki:development:deb-buildguide 
to setup my build environment.

Could I get some help getting my dev environment setup? If there's a 
better way to accomplish what I want to do with branding, or a better 
list/forum to inquire, please let me know.

Thanks.
Seth

On 03/01/2017 12:13 PM, Stefan Baur wrote:
> Am 01.03.2017 um 18:30 schrieb Seth Galitzer:
>> Long story short: In my thin client lab, we use an RDP client to connect
>> to Windows Remote Desktop Servers and have been using XDMCP to connect
>> to Linux X desktops. I want to use X2go for the superior performance,
>> reliability, and security over XDMCP, but am unable to do so due to
>> limitations by the thin client platform vendor. The hardware is
>> apparently ordinary x86 so I'm working on rolling my own minimal image
>> to accomplish this.
>
> Save for that vendor's lock-in stupidity, it sounds straightforward enough.
>
>
>> With the current platform, we have desktop shortcuts that to run the
>> RDP/XDMCP clients to various hosts. I'd like to try and duplicate that
>> with my new image so I don't have to retrain my users.
>
> Well, it depends how bad that "retraining" would be.
> X2Go in TCE mode can serve as a frontend to xfreerdp for RDP and also to
> Xephyr for XDMCP (that feature isn't in the stable release yet, but an
> image based on a recent nightly build is available).
>
> That way, when starting X2GoClient in fullscreen mode (as is the default
> with TCE) there's just a few white tiles on the right that list the
> various connections. No matter if they're X2Go, RDP, or XDMCP - all
> share the same look.
>
> You can deploy configuration (i.e. which tiles appear and which not)
> either static via HTTP(S)/FTP, or using a simple server-side script for
> TTP(S), or you can use the full-fledged session broker, which allows you
> to define tile/session visibility depending on user name, group
> membership, and IP range (plus the broker also does load balancing).
>
> However, this frontend-only mode doesn't involve X2GoServer at all for
> RDP and XDMCP connections, so there's no performance increase for these.
>
> If you want to accelerate things for RDP and XDMCP, you need an
> X2GoServer inbetween.
>
> You could proceed just as described above, with individual tiles for
> each remote server (now using the X2GoServer as an accelerating proxy
> instead of connecting directly), or offer a minimal desktop (say, LXDE
> or XFCE, or a trimmed-down MATE) from the X2GoServer machine, with the
> desired connections as desktop shortcuts.
>
>
>> I'm scripting
>> freerdp-x11 for RDP connections (with NLA). After trying various ways to
>> script x2goclient, I finally discovered pyhoca-cli and it works exactly
>> the way I want it to.
>>
>> So that's why I hope it stays available in some form for a while. If
>> there's a better way to run x2goclient completely "headless" or
>> transparent to the user, I'd be happy to hear it. I've been searching
>> through documentation and haven't found a way yet to do it the way that
>> I want.
>
> To get started, use a regular Linux machine (not a ThinClient), install
> X2GoClient, configure a session. Make sure to use Public Key
> authentication, run an SSH-agent, load your keyfile into it (don't
> specify the actual keyfile in the session configuration, just check the
> box that X2GoClient should attempt auto-login via SSH-Agent or Key). Try
> if it works (clicking on the tile should then connect you to your
> server, without asking for credentials).
> If that works, log out of the session again. If you now see a login box
> that prompts for username and password, click cancel. If not, just read on.
> Look at the tile of the session you just configured. Depending on which
> X2GoClient version you use, there's either a small grey
> downward-pointing triangle or a "hamburger icon" like on an Android
> smartphone in the lower left corner of the tile. Click "Create Session
> Icon on Desktop". Note the little checkbox in the lower left corner of
> that message.
>
> If you examine the desktop link afterwards, you will see that X2GoClient
> is called with
> --hide --sessionid=20110913020213584
> and optionally --tray-icon as well, if you checked the box mentioned
> earlier. The sessionid number corresponds to the session in your
> sessions file.  You can also use --session=SessionName instead.
>
> (Double-)Click that desktop link and see if it does what you are looking
> for - it should.
>
> Now that you've got a working setup, you can deploy the sessions config
> file and the "--"parameters to your clients.
>
>
>> I already have my PXE server setup, but haven't decided yet if I'm going
>> to boot from a network image, or push the image down to the clients to
>> pre-load for booting. My minimal debian image with all necessary tools
>> is currently just over 2GB uncompressed.
>
> Our TCE image - which does nothing more than fire up X2GoClient in
> fullscreen mode, and some background stuff for audio and removable media
> automounting - is currently about 200 Megabytes in size, rather than
> 2GB.  It uncompresses into a RAM disk when booting over the network.
> With local storage, you don't need to load the entire image into RAM.
>
>
>> I'm not opposed to TCE, but I'd like to be able to at least customize the skin with our own branding.
>
> Well, with a fullscreen X2GoClient, there isn't much "skin" to brand -
> you'd brand the desktop on the X2GoServer instead.
>
>
>> I'd love to hear anyone's thoughts on this. I'm relatively new to X2go,
>> so I'm sure there are ways to use it to help with this project I haven't
>> thought of yet.
>
> If all of the above still didn't convince you and you'd still prefer a
> minimal desktop environment running directly on the ThinClient (again, I
> would recommend against this as it means *zero* performance increase if
> you run RDP or XDMCP sessions from desktop shortcuts starting xfreerdp
> or "Xephyr -query", rather than through an X2GoServer acting as a proxy)
> - "stay tuned".  We're working on reviving Mike#1's "minidesktop" for
> X2Go-TCE. Currently, that's only a hobby project of mine, but hey, Linus
> Torvalds wrote something similar when he started working on Linux, so
> who knows. ;-)
>
> As always, if you have a budget for X2Go deployment, we can speed up
> development by working on it during office hours, rather than in our
> free time.
>
> <shameless plug>
> X2Go also has a commercial side, where various companies - including
> my own - offer support contracts with guaranteed response times as
> well as consultancy and paid-for development work if someone wants to
> see a bug fixed or a new feature added in a certain time frame.
>
> What makes my company special is, IMHO:
> 1) I'm the current X2Go Project/Community Coordinator, so the
>    development lead and the developers tend to listen to me.
> 2) As far as I know, we are the only company providing X2Go support
>    that isn't a one-man-show.  Oh, and we already have US customers.
> 3) We sub-contract other developers from the X2Go community on demand,
>    so you only have one person you need to talk to - me - and you will
>    only receive one invoice, even if the task involved several freelance
>    or part-time X2Go developers.
>
> Our hourly rate for consultancy work and fixing issues outside of a
> support contract is 110 EUR.
> With a support contract, you get guaranteed response times (starting at
> 400 EUR/month for 24h response time during business hours in the
> CET/CEST time zone from Monday to Friday, German holidays excluded)
> and lower hourly rates if you buy a certain amount of hours in advance.
> </shameless plug>
>
> Kind Regards,
> Stefan Baur
>
>
>
> _______________________________________________
> x2go-user mailing list
> x2go-user at lists.x2go.org
> http://lists.x2go.org/listinfo/x2go-user
>

-- 
Seth Galitzer
Systems Coordinator
Computing and Information Sciences
Kansas State University
http://www.cis.ksu.edu/~sgsax
sgsax at ksu.edu
785-532-7790