[winswitch] HTML Client - howto and problems

[Antoine Martin]

On 15/06/2022 19:47, xpra--- via shifter-users wrote:
> 
> Quoting Antoine Martin via shifter-users 
> <shifter-users at lists.devloop.org.uk>:
> 
> 
>> Can you please specify the wiki page so that I can amend it?
> 
> I used about 10 so or web sites from the GitHub to the xpra.org site, to 
> piece together what should be used...
Most of the web sites out there contain instructions that are either 
completely out of date (ie: using `DISPLAY=:7 xterm`) or just plain wrong.

>> That's because the xpra package runs a proxy server on port 14500 so 
>> you cannot start another server on the same port.
> 
> Is this documented??? Its defeinitely is not something I was aware of 
> that XPRA started this "proxy"
https://github.com/Xpra-org/xpra/blob/master/docs/Usage/Proxy-Server.md

> And all the other sites around various search results all point to use 
> 14500 and theres even a results which says XPRA got a NANA port 
> officially of 14500, so I take that to mean that the HTML server 
> defaults to 14500, and the tcp bind fails as it starts automaticly...  
> so I remove it from the startup
14500 has been the default port for the xpra service since 2016:
https://github.com/Xpra-org/xpra/issues/731#issuecomment-765427947

(..)
>> But if the proxy server doesn't see the server you started, it is 
>> unlikely to work.
> 
> Ok... I have perfect storm where things collide on me using this setup 
> and some changes with that setup... but.. any way...
> 
> I use:
> 
> xpra start --bind-tcp=0.0.0.0:10000 --html=on --env=XPRA_VAAPI=0 
> --env=CUTTER_THRESHOLD=0 :100 --start=/home/TheProgram
> 
> Start up works.. its running...
> xpra connect via my xpra_launcher on my desktop -- GOOD!
> XPRA HTML ---- SUCESS!
> Glitch... no SSL!
> 
> Ok... looking at the /var/log... it needs something else for SSL
> 
> " no certificate paths specified
> 2022-06-14 13:47:36,069  you must specify an 'ssl-cert' file to use ssl 
> sockets
> "
> 
> OK... I don't remember seeing that listed on the HTML examples....no 
> biggie...
No, it is not listed.
The examples given are designed to be as simple as possible.
(and SSL generally isn't really "simple")

> so based on some digging I think that this startup then would be
> 
> xpra start --bind-tcp=0.0.0.0:10000 --ssl-cert=/etc/xpra/ssl-cert.pem 
> --ssl=on --html=on --env=XPRA_VAAPI=0 --env=CUTTER_THRESHOLD=0 :100 
> --start=/home/TheProgram
This should not work as the SSL key installed with the packages should 
only be readable by root. (see next reply)

>> Sounds like a bug.
>> The "xpra start" session on ":100" should have shown up in the 
>> "connect" list, not in the "shadow" list.
> 
> Connecting to the PROXY on 14500 only thing I get is the list in the 
> SHADOW list.. the CONNECT shows: no connections found... I guess I 
> should file a issue/bug at the github on it???? I don't want to file a 
> bug, if there is more a issue with the user as in the startup command....
Any session started should be visible to the proxy server and should be 
exposed through the html5 UI.

(..)
>> shadow servers don't re-spawn, perhaps it is the proxy server that 
>> you're killing - this one is managed as a systemd service and will be 
>> re-spawned.
> 
> pgrep gives me two processes when I connect via that proxy.. and after 
> disconnection its still there... I get kill happy when I close out a 
> program and it still has lingering processes... so thats likely the 
> case... it won't be an issue since I know the proxy exists... and I 
> won't be using it any way...
Then you may want to just turn it off.

The proxy server is a socket activated process which will remain 
available once it is stated.
The other is likely to be the proxy instance for the connection you're 
making. It should terminate when the connection is closed.

>>> e) Password entry issues
>>>
> 
> I think that is related to the whole proxy thing... using the HTML 
> client things connect... takes the user/pass .. PLBKC
> 
> Just curious... does the whole AUDIO MISSING pass through to the HTML 
> client from that bug that is fixed in 4.4??? I enabled it in the 
> ADVANCED OPTIONS.. webm:opus... I will play with it some more if should 
> be coming through in the HTML V5.0 client.. maybe I need to find the 
> right codex to use.. I just used the default real quick..... opus, as 
> that I know was used in the regular client...
There is an audio bug in the 4.3.x series which is fixed in the upcoming 
4.3.4 release.
Perhaps try the 4.4 or 4.3.4 builds from the beta channel.

> 
> THANKS FOR THE REPLY!
> 
> Biggest thing is the conflicting info I got.. and use conflated to wrong 
> setup command.. ok... resolved...
Sadly, this is not the first time people get misled by invalid instructions.

Cheers,
Antoine

> I can't touch this too much now (MY ISSUE) so I will restart it to 
> enforce SSL use later with the command above... as once I do that, I can 
> forward through the firewall and to the client to access this remotely 
> since I don't have X11 on that one setup I want to use... and I've yet 
> to find any X11 server that is worth anything for Android sadly...
> 
> 
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> https://lists.devloop.org.uk/mailman/listinfo/shifter-users