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 < [email protected]> 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 > [email protected] > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > _______________________________________________ shifter-users mailing list [email protected] https://lists.devloop.org.uk/mailman/listinfo/shifter-users
