On 06/08/18 16:34, Pierre Wulles via shifter-users wrote: > Hello, > Well this is good news! I'm happy you added it in the last version, as soon > as I've received your email I've upgraded (xpra v2.4-r20042) This r200042 build is too old, the feature you want was added in: http://xpra.org/trac/changeset/20046
> and tried what > you said. But I have now a major error when starting xpra: (..) > Is is because of the new version? Did I upgraded it bad? That's fixed: http://xpra.org/trac/changeset/20048 > It was working well before. Wait for a newer beta build, or patch your installation with the changeset above. Cheers, Antoine > Thank you, > Pierre > > Le lun. 6 août 2018 à 15:03, Antoine Martin via shifter-users < > shifter-users@lists.devloop.org.uk> a écrit : > >> 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 database >> >> Until 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 >> > _______________________________________________ > 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
