Difference between revisions of "X2Go"

From ArchWiki
Jump to: navigation, search
(created page)
 
(simplification and beautification of wikilinks, fixed section fragments (interactive))
(Tag: wiki-scripts)
 
(98 intermediate revisions by 41 users not shown)
Line 1: Line 1:
[[Category:HOWTOs (English)]]
+
[[Category:Remote desktop]]
[[Category:Software (English)]]
+
[[ja:X2Go]]
== x2go Server and Client ==
+
[[zh-hans:X2Go]]
With x2go you can access your desktop using another computer -- that means both using LAN or internet connections. The transmmission is done using ssh protocol, so it is encrypted. By relying on the free nx libraries (nomachine) a very acceptable permformance in both speed of the transmission and reaction on user's input is archieved. Also a ISDN-connection allows to work satisfyingly.
+
[http://wiki.x2go.org X2Go] enables you to access a graphical desktop of a computer over the network. The transmission is done using the [[Secure Shell]] protocol, so it is encrypted.
 +
{{Note|X2Go isn't compatible with all desktop environments. You can check [http://wiki.x2go.org/doku.php/doc:de-compat X2Go desktop environment compatibility] first, especially if you want to shadow your current desktop.}}
  
So it is possible to connect with your laptop to your desktop at home, with all the environments, applications and performance of the remote desktop. Also it is possible to have a bunch of computers to connect to one computer (terminal-server, thin-client).
+
== Installation ==
  
The package includes a server (x2goserver together with x2goagent) and
+
Two parts are available in [[official repositories]]. They can be [[Pacman|installed]] with the following packages:
the client software. On the server the postgresql SQL-server has to
+
* {{Pkg|x2goserver}} - X2Go server
be up and running. Clients are available for Linux (at the moment a
+
* {{Pkg|x2goclient}} - X2Go client based on Qt4
QT4-based one, another one for GTK is supposded to follow) and
 
Windows, the latter can be downloaded at the x2go homepage.
 
  
Last but not least an SSH daemon has to be installed and must be available from the clients.
+
== Server configuration ==
  
=== x2go and Archlinux ===
+
=== Configure Secure Shell daemon ===
Alle needed packages are available in AUR. At the moment the needed
 
libraries, the server/agent and the qt based client available. Not yet
 
finished is the LDAP based usermanagement suite.
 
  
Also not finished are packages for some tools, that make x2go more
+
X2Go uses [[Secure Shell]] in order to work, so you need to configure sshd daemon to allow X11 forwarding and then start it first. Follow the instructions at [[Secure Shell#X11 forwarding]] and [[Secure Shell#Daemon management]].
convenient for use in schools and thin client environments. But work
 
is going on.
 
  
=== Installation and configuration ===
+
If you are using other than POSIX (C) locale, you may want to add the following line to [[Secure_Shell#Server_usage|configuration file]]
Packages needed from AUR: x2goserver and x2goclient and their
+
# Allow client to pass locale environment variables
dependencies, the latter (nxcomp, nxproxy) have to be build first.
+
AcceptEnv LANG LC_*
  
* Hint for nxcomp: Due to a bug in AUR this package is not available on the normal way via AUR. The PKGBUILD code has to be pasted from the AUR comment page of nxcompext.
+
=== Load fuse kernel module ===
* Hint for x2goagent: This package builds from the complete xorg sources, but uses only parts of them. The build process lasts long.
 
* Another hint for x2goagent: A build time the sources of the dependencies nxcomp, nxcompext and nxcompshad have to be accessible in a local directory tree. As these are dependencies, they are already there at build time, but you may not delete the trees afterwards, using makepkg or the like. x2goagent's PKGBUILD creates symbolic links to the required directories. Therefore the following directory structure is needed:
 
./nxcomp/src
 
./nxcompext/src
 
./nxcompshad/src
 
./x2goagent (this is the one you build at the moment)
 
If all packages are successfully built, you install the following:<br>
 
'''on the server(ex. your pc at home):''' x2goserver (plus dependencies)<br>
 
'''on the client, e.g. laptop:''' x2goclient (plus dependencies)
 
  
'''Configuration Server'''<br>
+
In order for the server to be able to access files on the client computer you should load a {{ic|fuse}} [[kernel module]].
Given a working X-server plus Desktop-Environment (e.g. KDE) or window
 
manager, you have to do the following:
 
  
a) Install the ssh-daemon using
+
=== Setup SQLite database ===
  pacman -Sy openssh
+
Run the following command on the server to initialize the SQLite database (which is required in order for the x2go server to work):
/etc/rc.d/sshd start
+
  # x2godbadmin --createdb
  
If the TCP-wrapper is active (see /etc/hosts.deny or
+
=== Start X2Go server daemon ===
/etc/hosts.allow), you have to include sshd there. To have sshd
 
started at boot time, you also have to put it into the daemeons line in
 
/etc/rc.conf, e.g.
 
  
DAEMONS=(... network ... sshd ...)
+
Now all you need to do is [[start]] {{ic|x2goserver.service}}.
  
b) Load the fuse modul to let the client access the directory in read
+
== Desktop Shadowing ==
and write mode on the server.
 
  
modeprobe fuse
+
To gain access to the "local desktop" (as opposed to a unique session/desktop environment) you need to install {{Aur|x2godesktopsharing}} from the [[AUR]]. Then, launch {{ic|x2godesktopsharing}}.
  
To have this module loaded at boot time, you also have to put it into
+
Note, you do not need x2godesktopsharing to access "local desktop" of user "foo" by user "foo". x2godesktopsharing is for accessing "foo"'s desktop by "foo2" user. Just choose "Connection to local desktop" in "session type" in x2goclient.
the MODULES line in /etc/rc.conf, e.g.
 
  
c) Some users or groups have to get the right to run a program as
+
== Client configuration ==
root.
 
  
pacman -Sy sudo
+
Make sure you can open a ssh-session from the client to the server
  visudo
+
  ssh username@host
  
An example for an entry in this file for all members of the group
+
Then run X2Go client itself
users:
+
x2goclient
 +
 
 +
You can now create several sessions, which then appear on the right side and can be selected by a mouse click. Each entry consists of your username, hostname, IP, and port for SSH-connection. Furthermore you can define several speed profiles (coming from modem up to LAN) and the desktop environment you want to start remotely.
 +
 
 +
'''Common mistakes:'''
 +
Do not simply choose the defaults of KDE or Gnome, since the executables startkde or startgnome are usually not in the PATH when logging in using ssh. Use full paths to startkde or
 +
startgnome. You can also start openbox or another window manager.
 +
 
 +
You should be asked for your password for your user at the server now and after login you will see the X2Go logo for a short time, and -- voila -- the desktop.
 +
 
 +
'''Exchange data between client and server(desktop)'''
 +
On the x2goclient (e.g. laptop) local directories could be shared. The server will use fuse and sshfs to access this directory and mount it to a subdirectory media
 +
of your home directory on the server. This enables you to have access to laptop data on your server or to exchange files. It is also possible to mount these shares
 +
automatically at each session start.
 +
 
 +
'''To leave a session temporarily'''
 +
Another special feature of X2Go is the possibility of suspending a session. This means you can leave a session on one client and reopen
 +
it  even from another client  at the same point. This can be used to to start a session in the LAN and to reopen it later on a laptop.
 +
The session data are stored and administered in a postgres database on the server in the meanwhile. The state of the sessions is protocolled
 +
by a process named x2gocleansessions.
 +
 
 +
== Various ==
 +
 
 +
'''Workaround for failing compositing window manager for remote session'''
 +
 
 +
This is useful for situations, when the computer running x2goserver is used also for local sessions with e.g. compiz as the window manager. For remote connections with x2goclient, compiz fails to load and metacity should be used instead. The following is for GNOME, but could be modified for other desktop environments. (Getting compiz ready is not part of this how-to.)
 +
 
 +
Create /usr/local/share/applications/gnome-wm-test.desktop:
 +
 
 +
[Desktop Entry]
 +
Type=Application
 +
Encoding=UTF-8
 +
Name=gnome-wm-test
 +
Exec=/usr/local/bin/gnome-wm-test.sh
 +
NoDisplay=true
 +
 
 +
Create script /usr/local/bin/gnome-wm-test.sh:
  
  %users ALL=(ALL) NOPASSWD: /usr/bin/x2gopgwrapper
+
  #!/bin/sh
 +
# Script for choosing compiz when possible, otherwise metacity
 +
# Proper way to use this script is to set the key to mk-gnome-wm
 +
# /desktop/gnome/session/required_components/windowmanager
 +
xdpyinfo 2> /dev/null | grep -q "^ *Composite$" 2> /dev/null
 +
IS_X_COMPOSITED=$?
 +
if [ $IS_X_COMPOSITED -eq 0 ] ; then
 +
    gtk-window-decorator &
 +
    WM="compiz ccp --indirect-rendering --sm-client-id $DESKTOP_AUTOSTART_ID"
 +
else
 +
    WM="metacity --sm-client-id=$DESKTOP_AUTOSTART_ID"
 +
fi
 +
exec bash -c "$WM"
  
d) Initialize the SQL database and start the SQL server
+
Modify the following gconf key to start the session with gnome-wm-test window manager:
  
  /etc/rc.d/postgresql start
+
  $ gconftool-2 --type string --set /desktop/gnome/session/required_components/windowmanager "gnome-wm-test"
  
This creates internally used tables of PostgreSQL. Now the x2go database
+
== Troubleshooting ==
and its tables are created this way:
 
  
cd /usr/lib/x2go
+
=== Authentication error ===
./x2gocreatebase.sh
 
  
The SQL-server and the x2goserver have to be restarted:
+
If the following error appears:
  
  /etc/rc.d/postgresql restart
+
  Authentification Failed:
  /etc/rc.d/x2goserver start
+
The host key for this server was not found but an othertype of key exists.
 +
  An Attacker might change the default server key to confuse 
 +
your client into thinking the key does not exist
  
And again: If you want to have this services started at boot time,,
+
Delete the servers entry from {{ic|~/.ssh/known_hosts}} file and retry to authenticate.
include them in the DAEMONS line in /etc/rc.conf
 
  
DAEMONS=(... network ... sshd ... postgresql ... x2goserver)
+
=== No selection screen in x2goclient ===
  
'''Configuration of the Client'''<br>
+
A regression in {{Pkg|iproute2}} causes ''ss'' to show no result when specifying the {{ic|-u}} flag, as done in {{ic|/usr/bin/x2golistdesktops}}. [https://marc.info/?l=linux-netdev&m=143018447007958&w=2]
Convince yourself that you can open a ssh-session from the client to
 
the server (host).  
 
  
ssh YourUsername_onServer@yourhost_or_ip
+
See [http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=799], [https://bbs.archlinux.org/viewtopic.php?pid=1541035] for more information.
  
Within the local network this should not be a problem. The way you
+
=== Sessions do not logoff correctly ===
connect from beyond your network, lets say the internet, to your
 
comuter at home is a question of how your network is build up. This
 
would go beyond the scope of this article. Therefore here only a few
 
items:
 
* A port has to be opened at the router resp. gateway which forwards requests to your server, and there especially to the sshd-port (which normally is 22). To prevent a big part of the portscan attacks it is probably better to have 222 as publicly reachable port.
 
* To prevent you from having the need to keep your public IP address in mind (especially if this changes dynamically) it is advisable to use a dynamic DNS-Service (DynDNS, DynIP). Many routers are preconfigured to be reachable under a name rather than an IP address.
 
  
Enough preliminaries! Now to the x2goclient. Run
+
Due to [http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=914 this bug] the X2Go sessions might not logoff correctly. The script that initiates the session spits out many log lines that might confuse X2go. A simple workarround is to create a custom session script and redirect the log output either to a file or to {{ic|/dev/null}} and then point your X2Go-client to this custom script.
x2goclient
 
This opens the client application. Now you can create several sessions,
 
which then appears on the right side and can be selected by a mouseclick. Each entry consists
 
of your username on the server, hostname and IP and the port for
 
ssh-connection. Furthermore you can define several speed profiles
 
(coming from modem up to LAN) and the desktop environment you want to
 
start remotely.
 
  
'''Easy made mistakes:''' Do not simply choose the defaults of KDE or Gnome,
+
Here is a sample script for an XFCE session:
since the executables startkde or startgnome are usually not in the
 
PATH when logging in using ssh. Use full paths to startkde or
 
startgnome. You can also start openbox or another window manager.
 
  
You should be asked for your password for your user at the server now
+
  #!/bin/sh
and after login you will see the x2go logo for a short time, and --
+
  #
voila -- the desktop.
+
  #xfce4-session spits out quite a bit of text during logout, which I guess
 +
  #confuses x2go so we would get a black screen and session hang.
 +
  #adding redirect to a logfile like "~/logfile" or "/dev/null" nicely solved it
 +
  # see http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=914
 +
  /usr/bin/xfce4-session > /dev/null
  
=== Exchange data between client and server(desktop) ===
+
=== Shared folders do not mount (Windows Clients) ===
On the x2goclient (e.g. laptop) a lacal directory will be created and
+
The ssh-daemon used by the X2go windows client uses depreceated ssh-dss keys by default and because Arch does not accept them your shared folders will not mount. Check out this [http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1009 bug report] for more information.
opened for to be accessed by the server. The server will use fuse and
 
sshfs to access this directory and mount it to a subdirectory media
 
of your home directory on the server. This enables you to hav access
 
to laptop data using your server. It is also possible mount them
 
automatically at each session
 
  
=== To leave a session temorarily ===
+
This can be solved on the windows side by generating different type of key:
Another special feature of x2go is the possibility of suspending a
 
session. This means you can leave a session on one client and reopen
 
it  even from another client  at the same point. This can be used
 
to to start a session in the LAN and to reopen it later on a laptop.
 
The session data are stored and administrated in a potges databse on
 
the server in the meanwhile. The state of the sessions is protocolled
 
by a process named x2gocleansessions.
 
  
== Outlook ==
+
  C:\Program Files (x86)\x2goclient\ssh-keygen -b 2048 -t rsa
At the moment the package consists mainly of the x2goserver and the
 
x2goclient. It is planned to add in near future:
 
*LDAP-Integration. This allow the administration of users, sessions and logins using LDAP. This is an interesting feature for schols or companys. For this purpose there are control programs which integrate themselves into the KDE Control Center.
 
* The GTK-x2goclient and the client for the command line. Furtermore the option to use x2goclient as an login screen for thin clients.
 
* the possibility to use locale devices (CD, floppy, USB-stick) remotely and transparently.
 
  
Questions and problems? You could contact me also directly.
+
And simply replace {{ic|c:\Users\User\.x2go\etc\ssh_host_dsa_key}} and {{ic|c:\Users\User\.x2go\etc\ssh_host_dsa_key.pub}} with the newly generated key files.
[http://wiki.archlinux.org/index.php/Special:Emailuser/Gerbra GerBra]
 
  
(Many thanks to Stefan Husmann for translation from archlinux.de wiki)
+
Other workarrounds from [http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1009] might help, too.
  
 
== Links ==
 
== Links ==
[http://wiki.archlinux.de/?title=Bild:X2go-1.png Screenshot KDE-Session]
 
 
[http://wiki.archlinux.de/?title=Bild:X2go-2.png Screenshot configuration dialog]
 
  
[http://x2go.berlios.de Project page]
+
* [http://wiki.archlinux.de/?title=Bild:X2go-1.png Screenshot KDE-Session]
 +
* [http://wiki.archlinux.de/?title=Bild:X2go-2.png Screenshot configuration dialog]
 +
* [http://x2go.org Project page]

Latest revision as of 14:42, 30 March 2017

X2Go enables you to access a graphical desktop of a computer over the network. The transmission is done using the Secure Shell protocol, so it is encrypted.

Note: X2Go isn't compatible with all desktop environments. You can check X2Go desktop environment compatibility first, especially if you want to shadow your current desktop.

Installation

Two parts are available in official repositories. They can be installed with the following packages:

Server configuration

Configure Secure Shell daemon

X2Go uses Secure Shell in order to work, so you need to configure sshd daemon to allow X11 forwarding and then start it first. Follow the instructions at Secure Shell#X11 forwarding and Secure Shell#Daemon management.

If you are using other than POSIX (C) locale, you may want to add the following line to configuration file

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Load fuse kernel module

In order for the server to be able to access files on the client computer you should load a fuse kernel module.

Setup SQLite database

Run the following command on the server to initialize the SQLite database (which is required in order for the x2go server to work):

# x2godbadmin --createdb

Start X2Go server daemon

Now all you need to do is start x2goserver.service.

Desktop Shadowing

To gain access to the "local desktop" (as opposed to a unique session/desktop environment) you need to install x2godesktopsharingAUR from the AUR. Then, launch x2godesktopsharing.

Note, you do not need x2godesktopsharing to access "local desktop" of user "foo" by user "foo". x2godesktopsharing is for accessing "foo"'s desktop by "foo2" user. Just choose "Connection to local desktop" in "session type" in x2goclient.

Client configuration

Make sure you can open a ssh-session from the client to the server

ssh username@host

Then run X2Go client itself

x2goclient

You can now create several sessions, which then appear on the right side and can be selected by a mouse click. Each entry consists of your username, hostname, IP, and port for SSH-connection. Furthermore you can define several speed profiles (coming from modem up to LAN) and the desktop environment you want to start remotely.

Common mistakes: Do not simply choose the defaults of KDE or Gnome, since the executables startkde or startgnome are usually not in the PATH when logging in using ssh. Use full paths to startkde or startgnome. You can also start openbox or another window manager.

You should be asked for your password for your user at the server now and after login you will see the X2Go logo for a short time, and -- voila -- the desktop.

Exchange data between client and server(desktop) On the x2goclient (e.g. laptop) local directories could be shared. The server will use fuse and sshfs to access this directory and mount it to a subdirectory media of your home directory on the server. This enables you to have access to laptop data on your server or to exchange files. It is also possible to mount these shares automatically at each session start.

To leave a session temporarily Another special feature of X2Go is the possibility of suspending a session. This means you can leave a session on one client and reopen it even from another client at the same point. This can be used to to start a session in the LAN and to reopen it later on a laptop. The session data are stored and administered in a postgres database on the server in the meanwhile. The state of the sessions is protocolled by a process named x2gocleansessions.

Various

Workaround for failing compositing window manager for remote session

This is useful for situations, when the computer running x2goserver is used also for local sessions with e.g. compiz as the window manager. For remote connections with x2goclient, compiz fails to load and metacity should be used instead. The following is for GNOME, but could be modified for other desktop environments. (Getting compiz ready is not part of this how-to.)

Create /usr/local/share/applications/gnome-wm-test.desktop:

[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=gnome-wm-test
Exec=/usr/local/bin/gnome-wm-test.sh
NoDisplay=true

Create script /usr/local/bin/gnome-wm-test.sh:

#!/bin/sh
# Script for choosing compiz when possible, otherwise metacity
# Proper way to use this script is to set the key to mk-gnome-wm
# /desktop/gnome/session/required_components/windowmanager
xdpyinfo 2> /dev/null | grep -q "^ *Composite$" 2> /dev/null
IS_X_COMPOSITED=$?
if [ $IS_X_COMPOSITED -eq 0 ] ; then
    gtk-window-decorator &
    WM="compiz ccp --indirect-rendering --sm-client-id $DESKTOP_AUTOSTART_ID"
else
    WM="metacity --sm-client-id=$DESKTOP_AUTOSTART_ID"
fi
exec bash -c "$WM"

Modify the following gconf key to start the session with gnome-wm-test window manager:

$ gconftool-2 --type string --set /desktop/gnome/session/required_components/windowmanager "gnome-wm-test"

Troubleshooting

Authentication error

If the following error appears:

Authentification Failed:
The host key for this server was not found but an othertype of key exists.
An Attacker might change the default server key to confuse  
your client into thinking the key does not exist

Delete the servers entry from ~/.ssh/known_hosts file and retry to authenticate.

No selection screen in x2goclient

A regression in iproute2 causes ss to show no result when specifying the -u flag, as done in /usr/bin/x2golistdesktops. [1]

See [2], [3] for more information.

Sessions do not logoff correctly

Due to this bug the X2Go sessions might not logoff correctly. The script that initiates the session spits out many log lines that might confuse X2go. A simple workarround is to create a custom session script and redirect the log output either to a file or to /dev/null and then point your X2Go-client to this custom script.

Here is a sample script for an XFCE session:

 #!/bin/sh
 #
 #xfce4-session spits out quite a bit of text during logout, which I guess
 #confuses x2go so we would get a black screen and session hang.
 #adding redirect to a logfile like "~/logfile" or "/dev/null" nicely solved it
 # see http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=914
 /usr/bin/xfce4-session > /dev/null

Shared folders do not mount (Windows Clients)

The ssh-daemon used by the X2go windows client uses depreceated ssh-dss keys by default and because Arch does not accept them your shared folders will not mount. Check out this bug report for more information.

This can be solved on the windows side by generating different type of key:

 C:\Program Files (x86)\x2goclient\ssh-keygen -b 2048 -t rsa

And simply replace c:\Users\User\.x2go\etc\ssh_host_dsa_key and c:\Users\User\.x2go\etc\ssh_host_dsa_key.pub with the newly generated key files.

Other workarrounds from [4] might help, too.

Links