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) and tried what
you said. But I have now a major error when starting xpra:
{{{
➜ ~ xpra start :100 --bind-tcp=0.0.0.0:10100 --start=xterm
xpra main error:
Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 72,
in main
options, args = do_parse_cmdline(cmdline, defaults)
File "/usr/lib64/python2.7/site-packages/xpra/scripts/parsing.py", line
1114, in do_parse_cmdline
fixup_options(options, defaults)
File "/usr/lib64/python2.7/site-packages/xpra/scripts/config.py", line
1365, in fixup_options
fixup_packetencoding(options)
File "/usr/lib64/python2.7/site-packages/xpra/scripts/config.py", line
1303, in fixup_packetencoding
from xpra.net import packet_encoding
File "/usr/lib64/python2.7/site-packages/xpra/net/packet_encoding.py",
line 9, in <module>
from numpy import isin
ImportError: cannot import name isin
}}}
Is is because of the new version? Did I upgraded it bad?
It was working well before.
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
