On 07/06/2022 12:18, xpra--- via shifter-users wrote:
Using Xpra 4.3.3 on Kubuntu 20.04....both server and client.
I am testing out the HTML client to possibly allow for use case when SSH
and X11 is not available, but a web browser is... but I run into some
issues
1) Proper server startup ??
Following the wiki, man page and numerous sites adding
Can you please specify the wiki page so that I can amend it?
--bind-tcp=0.0.0.0:14500 --html=on should do the trick, correct?
The html5 client documentation uses port 10000, which is usually free:
https://github.com/Xpra-org/xpra-html5#usage
No joy, UNLESS I REMOVE the --bind-tcp option... then the Xpra server
will start. otherwise get an error about already in use on 0.0.0.0 ...
That's because the xpra package runs a proxy server on port 14500 so you
cannot start another server on the same port.
Connecting via the proxy is possible and it should work, but you may
want to skip it altogether to simplify things - especially when
encountering issues.
So has this changed and the bind is automatic by default????? Or????
So I add --html=on to the startup
That doesn't make any difference, it is the default.
xpra start --html=on --env=XPRA_VAAPI=0 --env=CUTTER_THRESHOLD=0 :100
--start=/home/theprogramIstartup
"--env=XPRA_VAAPI=0" is also the default.
That works.... everything starts... I can use xpra-connect and connect..
good to go on my normal mode...
2) Access THE SESSION ABOVE VIA THE HTML5 client
goto https://1.2.3.4:14500/connect.html
OK.. get the login box....ok..
a) First issue:
Connect option: "NO SESSIONS FOUND" in red
I am taking this "connect" option would be what I do via the
xpra_connect setup I have, already, connect up to the running XPRA on
:100 let me see what its doing, etc., disconnect come back to it as
needed.. Thats my use case mostly, check up on a program that runs long
term...
Is that correct for this connect option???????
This option is similar to what can be done via "xpra sessions".
But if the proxy server doesn't see the server you started, it is
unlikely to work.
b) Second issue:
Using the SHADOW OPTION and it gives a drop down, :0, obviously the
desktop thats there.. and then :100 which is the session I STARTED
ABOVE... OK... select shadow and :100 from the drop down...
Connects up, and after the initial transfer, I get session :0, NOT
:100.. Doesn't matter how many times I change the dropdown from :0 to
:100 it will NOT CONNECT TO THAT :100 session in shadow
UMMMM????????
Sounds like a bug.
The "xpra start" session on ":100" should have shown up in the "connect"
list, not in the "shadow" list.
c) Infinite loop connection
IF you try the connection LOCALLY ON THE SAME BOX as the server via
HTML5 client in browser, because it is shadowing :0 it just causes an
infinite loop where the browser window just shows that toolbar and just
keeps redrawing it infinitely
I'm not 100% sure I understand, but shadowing your own local display
does create a sort of nested paint loop. That's expected.
d) The process that won't die!
This shadow connection starts another xpra server for :0, and it just
WON'T DIE! You can tell it to shutdown via the HTML5 client option, it
doesn't shut down, and when you disconnect you will have 2 XPRA
processes running, the original :100 and this new :0 process, and sudo
kill -9 pid will kill it and then it RESPAWNS... the only way to kill
that is to HARD REBOOT the box!
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.
e) Password entry issues
Seems to get things to connect the first time, I have to enter the
password twice, even if its saved and auto entered by the browser, and
hitting the eye to show it, it is correct, will connect, FAIL
VALIDATION, and then enter it again, or let browser fill in again, and
2nd time works. shrug
It isn't clear what command lines / port / (no?)proxy configuration
triggers this, but I haven't seen this particular problem.
Connections via the proxy do usually require authentication and the
default is to use system authentication.
After that, the session itself may also require authentication depending
on how you configured it, but I can't remember if those authentication
requests can be forwarded through the proxy.
Comments, insights, welcome... Thanks!
Cheers,
Antoine
_______________________________________________
shifter-users mailing list
shifter-users@lists.devloop.org.uk
https://lists.devloop.org.uk/mailman/listinfo/shifter-users
_______________________________________________
shifter-users mailing list
shifter-users@lists.devloop.org.uk
https://lists.devloop.org.uk/mailman/listinfo/shifter-users