[winswitch] server requested 'xor' digest, cowardly...

pwulles pierre.wulles at gmail.com
Tue Aug 7 13:25:51 BST 2018 

Hello,

Well I've tried to install the latest version, so i'm now runnning with 
xpra v2.4-r20056 but I have now a new bug when executing:

xpra attach ssl://foo:bar@proxyhost/ --start=xterm

xpra main error:
Traceback (most recent call last):
   File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 
78, in main
     return run_mode(script_file, err, options, args, mode, defaults)
   File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 
384, in run_mode
     return run_client(error_cb, options, args, mode)
   File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 
1161, in run_client
     app = get_client_app(error_cb, opts, extra_args, mode)
   File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 
1237, in get_client_app
     from xpra.platform.gui import init as gui_init
   File "/usr/lib64/python2.7/site-packages/xpra/platform/gui.py", line 
278, in <module>
     "get_info")
   File "/usr/lib64/python2.7/site-packages/xpra/platform/__init__.py", 
line 159, in platform_import
     platform_module = __import__(module, {}, {}, imports)
   File 
"/usr/lib64/python2.7/site-packages/xpra/platform/xposix/gui.py", line 
23, in <module>
     from xpra.gtk_common.gtk_util import get_xwindow
   File 
"/usr/lib64/python2.7/site-packages/xpra/gtk_common/gtk_util.py", line 
12, in <module>
     gtk     = import_gtk()
   File 
"/usr/lib64/python2.7/site-packages/xpra/gtk_common/gobject_compat.py", 
line 111, in import_gtk
     return  _try_import(import_gtk3, import_gtk2)
   File 
"/usr/lib64/python2.7/site-packages/xpra/gtk_common/gobject_compat.py", 
line 55, in _try_import
     imported = trygtk3()
   File 
"/usr/lib64/python2.7/site-packages/xpra/gtk_common/gobject_compat.py", 
line 44, in trygtk3
     return import_method_gtk3()
   File 
"/usr/lib64/python2.7/site-packages/xpra/gtk_common/gobject_compat.py", 
line 105, in import_gtk3
     import gi
   File "/usr/lib64/python2.7/site-packages/gi/__init__.py", line 33, in 
<module>
     raise ImportError('When using gi.repository you must not import 
static '
ImportError: When using gi.repository you must not import static modules 
like "gobject". Please change all occurrences of "import gobject" to 
"from gi.repository import GObject".

What can I do ?

Pierre


On 06/08/2018 17:20, Antoine Martin via shifter-users wrote:
> 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 at 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 <antoine at 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 at lists.devloop.org.uk
>>>>>> <mailto:shifter-users at 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 at lists.devloop.org.uk
>>>>>>      <mailto:shifter-users at lists.devloop.org.uk>
>>>>>>      > http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>>>>>      >
>>>>>>
>>>>>>      _______________________________________________
>>>>>>      shifter-users mailing list
>>>>>>      shifter-users at lists.devloop.org.uk
>>>>>>      <mailto:shifter-users at lists.devloop.org.uk>
>>>>>>      http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> shifter-users mailing list
>>>> shifter-users at lists.devloop.org.uk
>>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>>>
>>> _______________________________________________
>>> shifter-users mailing list
>>> shifter-users at lists.devloop.org.uk
>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>>
>> _______________________________________________
>> shifter-users mailing list
>> shifter-users at lists.devloop.org.uk
>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users

More information about the shifter-users mailing list