On 06/08/18 11:29, Pierre Wulles via shifter-users wrote:
> Hello,
>> And when asking questions, make sure to include what commands you are
> using, what you have tried, the log output, etc.
> The thing is that I don't know what command I am supposed to use! What I
> want is to start a session remotely, let assume that I want to start a
> graphical software remotely but I don't know which one, then what should I
> type on server/proxy/client to do so ?
> I've succeeded to start a session like this:
> {{{
> xpra start :100 --bind-tcp=0.0.0.0:10100 --start=xterm #on server
> xpra proxy :100 --bind-tcp=0.0.0.0:14501
> --tcp-auth=sqlite,filename=./xpra-auth.sdb --socket-dir=/tmp #on proxy
> xpra attach tcp://foo:bar@$PROXYHOST:14501/ #on client
> }}}
> But I need to say on the first command "xterm", what I want is something
> like:
> {{{
> xpra start? :100 --bind-tcp=0.0.0.0:10100 --start? #on server
> xpra proxy :100 --bind-tcp=0.0.0.0:14501
> --tcp-auth=sqlite,filename=./xpra-auth.sdb --socket-dir=/tmp #on proxy
> xpra start tcp://foo:bar@$PROXYHOST:14501/ --start=xterm #on client
> }}}
> WIth this the client can choose what software he wants to start.
You can already start new sessions via the proxy server with:
xpra start ssl://foo:bar@proxyhost:14501/ --start=whatever
With one important limitation: the sessions will be started on the same
host where the proxy is running, the proxy just executes an "xpra start"
for you.
Regarding the proxy authentication configuration, since the session will
be a local session it will need an account to run:
* if using "sys" auth, "foo" must be a valid user account on proxyhost
* if using "sqlite" auth, you must configure the mapping to user
accounts (uid, gid) yourself when creating the authentication databaseUntil now, it wasn't possible for the client request commands to be executed on the server after the connection is established (it was only possible manually through the system tray menu: Server -> Run Command) This feature has now been added for "attach" in xpra 2.4: http://xpra.org/trac/ticket/1931 So now you can do: xpra attach --start=xterm Or for a remote host: xpra attach ssl://foo:bar@proxyhost/ --start=xterm This will work for your use-case as long as the backend session is started in advance, and you will need to populate the sqlite database to point to it as before. If you want to use --exit-with-children in this way, you still can, here's a hackish solution which you can adapt: xpra start --start-new-commands=yes --start-child="sleep 9999999" --exit-with-children xpra attach --start-child="xterm" --start="killall sleep" Allowing the proxy server to start sessions on remote servers (via ssh or through a second proxy server) would be possible, but this would be much more difficult to implement properly. This should probably tie in with load balancing and session accounting features. Feel free to create a ticket for it. Cheers, Antoine > Thank you, I hope it's clear enough. > Pierre > > Le sam. 4 août 2018 à 17:33, Antoine Martin <anto...@nagafix.co.uk> a > écrit : > >> Please always use the mailing list. >> And when asking questions, make sure to include what commands you are >> using, what you have tried, the log output, etc. >> http://xpra.org/trac/wiki/ReportingBugs >> >> Antoine >> >> On 04/08/18 15:41, Pierre Wulles wrote: >>> Hello, >>> Thank you for your answer! I finally succeded in connecting with >>> encryption, my question now is " is it possible to start a session >>> remotely and attach to it ? >>> Best regards, >>> Pierre >>> >>> Le sam. 4 août 2018 15:30, Antoine Martin via shifter-users >>> <shifter-users@lists.devloop.org.uk >>> <mailto:shifter-users@lists.devloop.org.uk>> a écrit : >>> >>> On 31/07/18 14:08, Pierre Wulles via shifter-users wrote: >>> > Hello, >>> > I've recently succeeded in having a server running xterm, a proxy >>> and a >>> > machine connecting to the proxy. I used for this what is described >> in >>> > https://xpra.org/trac/wiki/ProxyServer at the section Remote >>> Hosts. What I >>> > want to do now is launching the pplication from the client, so >>> what I did >>> > is: >>> > {{{ >>> > xpra start :100 --bind-tcp=0.0.0.0:10100 <http://0.0.0.0:10100> >>> > }}} >>> You said you wanted to launch from the client, but here you are >>> launching a session in advance. >>> Did you mean "connect from the client" instead? >>> >>> > on the server. Then >>> > {{{ >>> > xpra proxy :100 --bind-tcp=0.0.0.0:14501 <http://0.0.0.0:14501> >>> > --tcp-auth=allow,filename=./xpra-auth.sdb --socket-dir=/tmp >>> --daemon=no >>> > }}} >>> The "allow" authentication module does not use any arguments. >>> Certainly not the database file which is meant to be used by the >> sqlite >>> auth module. >>> >>> > On the proxy and there is "foo bar nobody nobody ip" in xpra-auth >>> because I >>> > didn't know how to indicate where the server is, >>> Specifying remote hosts is documented for the sqlite backend on the >>> proxy wiki page: >>> https://xpra.org/trac/wiki/ProxyServer#RemoteHosts >>> ie: >>> sqlite_auth.py ./auth.sdb add foo bar nobody nobody >>> tcp://1.1.1.1:10100/ <http://1.1.1.1:10100/> >>> >>> > the problem that I guess >>> > here is that if you put --tcp-auth=allow the file xpra-auth is >> ignored >>> > because when I go to the client: >>> > {{{ >>> > xpra start --tcp-auth=allow tcp://vml-xprabetatest/14501 xterm >>> > }}} >>> FYI: tcp-auth here would apply to the session you end up starting. >>> That's usually a bad idea for anything but testing. >>> And in this case, it is very unlikely to be needed since you will be >>> connected to the session when you start it anyway. >>> >>> > I have the following error: >>> > {{{ >>> > 2018-07-31 13:50:22,161 Error: authentication failed: >>> > 2018-07-31 13:50:22,161 server requested 'xor' digest, cowardly >>> refusing >>> > to use it without encryption >>> > }}} >>> xpra will refuse to send password unencrypted over the network. >>> >>> > What can I do ? >>> Like it says, use encryption. >>> https://xpra.org/trac/wiki/Encryption >>> >>> Cheers, >>> Antoine >>> >>> > Thank you, >>> > Pierre >>> > _______________________________________________ >>> > shifter-users mailing list >>> > shifter-users@lists.devloop.org.uk >>> <mailto:shifter-users@lists.devloop.org.uk> >>> > http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>> > >>> >>> _______________________________________________ >>> shifter-users mailing list >>> shifter-users@lists.devloop.org.uk >>> <mailto:shifter-users@lists.devloop.org.uk> >>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>> >> >> > _______________________________________________ > shifter-users mailing list > shifter-users@lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > _______________________________________________ shifter-users mailing list shifter-users@lists.devloop.org.uk http://lists.devloop.org.uk/mailman/listinfo/shifter-users
