[winswitch] server requested 'xor' digest, cowardly...
pwulles
pierre.wulles at gmail.com
Tue Aug 7 13:59:20 BST 2018
Hello,
Thanks for your fast answer,
Os version is Centos 7.5, I installed xpra with "sudo yum install xpra"
and before I added the winswitch-beta.repo: in /etc/yum.repos.d/ with
curl -O, content of the file:
{{{
[winswitch]
name=Winswitch $releasever - $basearch
enabled=1
metadata_expire=1d
gpgcheck=1
gpgkey=http://winswitch.org/gpg.asc
baseurl=http://winswitch.org/dists/CentOS/$releasever/$basearch/
[winswitch-beta]
name=Winswitch Beta $releasever - $basearch
enabled=1
metadata_expire=1d
gpgcheck=1
gpgkey=http://winswitch.org/gpg.asc
baseurl=http://winswitch.org/beta/CentOS/$releasever/$basearch/
skip_if_unavailable = 1
}}}
I tried:
{{{
sudo yum install pygtk2
}}}
but it says:
{{{
Package pygtk2-2.24.0-9.el7.x86_64 already installed and latest version
Nothing to do
}}}
So it seems to be installed.
Cheers,
Pierre
On 07/08/2018 14:32, Antoine Martin via shifter-users wrote:
> On 07/08/18 14:25, pwulles via shifter-users wrote:
>> 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:
> (..)
>> 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 ?
> Judging from the stacktrace line numbers, you don't have pygtk
> installed, which should be impossible if you have installed the packages
> properly.
> Without knowing more about your distro, version, installation,
> environment, etc. It's difficult to tell you more.
>
> Cheers,
> Antoine
>
>
>> 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
>> _______________________________________________
>> 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