Table of Contents

Load Balancing with X2Go

Preparations

The X2Go load balancing setup requires several installation steps.

  1. Install more than one X2Go Servers
  2. Install all X2Go Servers identically (FAI and/or puppet are good tools here)
  3. Hook them together:
    • central LDAP server with user accounts as authentication backend and user base (PAM, libnss)
    • central NFS server for provisioning of home directories
    • make sure DNS works well and all X2Go Servers resolve and reverse resolve fine
  4. Install PostgreSQL on a non-X2Go Server (i.e. on the machine that runs the LDAP service)
  5. Hook all X2Go Servers' session databases into the PostgreSQL database server

You should now be able to log into each X2Go Server separately by using their IP addresses or (local) DNS names.

If you are logged into several of your X2Go Servers under the same user account and then run 

<user>@<x2goserverN>:~$ x2golistsessions --all-servers

you should get all current active/suspended X2Go sessions listed.

X2Go Session Broker Daemon / WSGI

Install X2Go Session Broker as described. Use a non-X2Go Server for this as installation host (e.g. the central LDAP server). Choosing the right machine on your network for providing X2Go session brokerage heavily depends on your site setup.

You certainly want to make use of SSL (https protocol) if the session broker can be accessed from the internet or if you share your network with non-trusted machines. For large scale deployments the WSGI implementation of the broker is recommended (package: x2gobroker-wsgi). For small companies the standalone daemon should probably be fine (package: x2gobroker-daemon).

After you have installed the session broker, additionally run the script x2gobroker-keygen as super-user root: 

$ sudo x2gobroker-keygen

This script will (if the defaults are not touched) create an RSA public/private SSH key pair in ~x2gobroker/.ssh/authorized_keys.

X2Go Session Broker Agent

On every X2Go Server install the package x2gobroker-agent. This agent has to be handled with much care, as it gets installed setuid root. Be aware of that and read its code before you deploy it. If you find any bugs or security issues with it, please contact the X2Go developers immediately (by sending a bug report) so that we can get things fixed for all as soon as possible.

To give the session broker access to your X2Go Servers, you have to run (as root) 

$ sudo x2gobroker-pubkeyauthorizer --broker-url http(s)://<broker-server>:<port>/<basepath>/pubkeys/
<basepath> typically is empty, unless the front- and backends were moved to a specific subdirectory as part of a WSGI deployment.

X2Go Session Profile for Load Balanced Sites

In the session profile configuration of the session broker (e.g. /etc/x2go/x2gobroker-sessionprofiles.conf) you now simply have to list all your X2Go Servers in a comma separated list with the host= option of that session profile.

Example: 

[pool-C-XFCE]
user=
host=s-1.pool-e.local (10.0.2.11),s-2.pool-e.local (10.0.2.12),s-3.pool-e.local (10.0.2.13),s-4.pool-e.local (10.0.2.14),s-5.pool-e.local (10.0.2.15)
name=XFCE - pool-C
command=XFCE
broker-session-autologin=true

It may happen that the broker contacts the X2Go servers under a different address compared to the address that the X2Go Clients have to use for connecting the X2Go Servers. For such cases, every hostname can be written in a special format (as seen in the examples above and below): 

host=s-1.works-with-broker.local (s-1.works-with-client.extern), s-2.works-with-broker.local (s-2.works-with-client.extern)

The hostnames (no IP addresses allowed here) that work with the broker should identically match the hostnames of the X2Go Servers as found in /etc/hostname of each individual machine. The hostname also appear in the output of the x2golistsessions command. It is important that hostname patterns (FQDN, short hostnames) match here!!!

The hostnames (or maybe IP addresses) that work with the clients must resolve via DNS. IP addresses are allowed here.