On 15/06/2022 19:47, xpra--- via shifter-users wrote:
Quoting Antoine Martin via shifter-users
<shifter-users@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@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
