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@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
_______________________________________________
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
