[winswitch] server only?

[Thomas Esposito]

I only connect via tcp and don't use any kind of encryption. This is all
going on inside the corporate VPN. I also don't need audio.

On Thu, May 21, 2020, 10:32 PM Antoine Martin via shifter-users <
shifter-users at lists.devloop.org.uk> wrote:

> On 22/05/2020 04:02, Thomas Esposito via shifter-users wrote:
> > I have been using using my Windows 10 laptop as a client to connect to an
> > xpra server running on a virtual desktop instance (VDI) of RHEL6 at
> work. I
> > don't have root access on my VDI (company security policy) in order to
> > install the xpra packages, but I was able to work around this by
> extracting
> > ALL of the required rpms manually and updating my ENV accordingly to
> point
> > to my "installation".
> You may want to look into these projects that make it easier to manage
> prefixed installations:
> http://modules.sourceforge.net/
> https://lmod.readthedocs.io/en/latest/
>
> Whatever you do, make sure to set this environment variable to tell xpra
> to only use paths within your prefixed installation:
> XPRA_INSTALL_PREFIX=/path/to/v3.0.9/usr
>
> > The company is very slow to upgrade to new versions of RHEL/CentOS
> because
> > of EDA tool compatibility issues and a conservative "if it isn't broke,
> > don't fix it" philosophy.
> And rightly so. (though there are also security considerations with
> running systems that don't receive updates..)
>
> > Therefore, I anticipate being stuck on xpra
> > version 1.x for a while. In the meantime, I imagine that there have been
> > performance improvements and bug fixes in 2.x and beyond that are not
> being
> > back-ported to 1.x.
> Correct. There are many.
>
> > It is possible that we MIGHT move to CentOS 7.3
> > relatively soon, but even that has been YEARS in the making, and the
> latest
> > version of xpra isn't supported on CentOS 7.3 anyway.
> Even the 3.0.x branch requires 7.4 or later now.
> Something broke on 7.3 builds a while back and I never bothered to fix
> it, it should be fixable but you may not get all the features (IIRC: no
> audio?).
>
> > As another workaround, I've been playing around with the idea of
> compiling
> > xpra from the source. I do have a recent version of python installed
> > (3.7.1), and have been able to install many of the dependencies by
> creating
> > a virtual environment and installing packages with pip. However, the fact
> > that RHEL3 does not support gtk3 is kind of a show stopper. I haven't yet
> > attempted to build gtk3 from source.
> That's very hard to do and maintain (we do that for MacOS). See:
> https://unix.stackexchange.com/questions/242074/
>
> > This has got me thinking about the fact that xpra is monolithic package
> > with both client and server together,
> That's not true: in v3, you get split RPM packages that allow you to
> install the client and server separately, and even mix versions for
> python2 and python3 on the same system.
> The Debian packaging is still mostly monolithic: only the html5 client
> is split up in the DEBs.
>
> > and I suspect that the gtk3
> > dependencies relate mostly (or maybe only) to the client.
> Unfortunately that's not the case: GTK3 is also used on the server.
> (though we would like to get rid of it eventually)
>
> > In my use case
> > however, I'll NEVER be running the client directly on the VDI, but only
> > from my remote Windows 10 laptop, on which I can install the latest xpra
> > client version. Is there some way to build xpra with ONLY server support?
> > I'm guessing not, but its something to think about.
> ./setup.py --without-client
> There are many other optional components, for more information:
> ./setup.py --help
>
> Cheers,
> Antoine
>
> > I'm sure there are other use cases out there like mine.
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> https://lists.devloop.org.uk/mailman/listinfo/shifter-users
>