X2go Server on Ubuntu 15.04

X2go is a great way of remotely connecting to a headless Ubuntu server (assuming you’re the type of person that wants to manage Ubuntu graphically). In my case my headless Ubuntu is just a hobbyist’s server and I think it’s cheaper to have one hosted for me, than to pay for the electricity and with the added fire risk of hosting a physical server myself. (Except for disk space considerations).
I’ve been using DigitalOcean droplets and I think their control panel is great.

I’m just writing up the steps here, because I’m sure to forget if I need to create another one sometime in the future,

Ubuntu 15.04 now uses systemd. (well that could be another post, because it’s a bit of a kludge it seems to me. But it might be a stepping stone).

1. Create the Ubuntu 15.04 droplet.

2. Ensure you can connect with PuTTY (ssh) or equivalent.

3. Update the droplet with apt-get as per normal.

4. Install Lubuntu. I installed lubuntu.desktop and then removed it as I thought I had problems. I’m sure lubuntu.core is sufficient. [TBA]

5. Now reboot. You’ll see that a graphical login is shown in the DigitalOcean’s console. But it is unusable as the mouse cursor does not align properly.
DigitalOcean’s support don’t help here if you ask, as they say they don’t support graphical droplets.
You can now see why PuTTY must be working! This means SSH is working too.

6. Go to /etc/default and edit grub with nano to this
this puts the droplet into a non-graphical mode on the next reboot.
[TBA. I did a few other things while testing this, but I think this is the key change. I’ll need to update once I’ve repeated this procedure once again]

7. You might as well reboot to see the effect.
Once logged back in again, ps –ef will show the parameters passed to init
root         1     0  0 19:05 ?        00:00:01 /sbin/init 4 4
This run level 4 is supposed to be a custom level same as 3, where 5 is the graphical level we don’t want.

8. Install X2goserver, as follows
     sudo add-apt-repository ppa:x2go/stable
     sudo apt-get update
     sudo apt-get install x2goserver x2goserver-xsession

9. The install process has started the x2goserver already. You can check with
     systemctl –l status x2goserver.
But this is where a pure Arch system and Ubuntu differ.
A startup file has been put in /etc/init.d, x2goserver, and Ubuntu’s handling has created a x2goserver.service.
I did a
     systemctl enable x2goserver.service
to be consistent and sure!

10. Now try and connect using the X2goclient. I bet it will fail with a “kex error”.
It seems it can be fixed with adding the below to /etc/sshd_config, and restarting sshd or rebooting.
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
PuTTY has the great feature of a right click paste into nano to avoid typing all this!

11. Set your X2goclient to LXDE of course, and you should be in.


Nginx, PHP FPM, try_files and path_info

In the post, http://wiki.nginx.org/PHPFcgiExample, the author gives an URL example for testing various parameters, especially PATH_INFO and $fastcgi_path_info.

This URL is, http://lemp.test/test.php/foo/bar.php?v=1 (this URL is not a hyperlink and does not work, of course)

I was interested to find what Location clause would be necessary to test this on my own server.

In my case, I wanted to test in a separate sub-directory, so the test string becomes:-

http://mydomain.co.uk/mytest/test.php/foo/bar.php?v=1 (this URL does not work either. It’s intended you construct a test on your own server)

As the article says, the test.php file is:-


I’m the type of person that fears Regex. I don’t know why, but with a lot of patience and a late night, I’ve got this:-

location ~* ^/mytest/(.+\.php)(/.*)?$

and the steps are:-

“~*” the nginx command for case insensitive matching.
”^/mytest/” the sub-directory off the site’s root where the test.php file is present.
”(.+\.php)” the regex specification that will match one or more characters before the .php extension of the filename, where \. escapes the dot. This protects against a file, “.php” being processed.
“(/.*)?” the regex specification that will match zero or more characters after a slash, where the ? makes this optional.
”$” and finally the $ marks the end of the string. Note that the “?v=1” is never considered by the location matching.

If you think that two php filenames in the URL is a bit odd, various authors suggest it’s a possible construct and give OwnCloud as an example (I’ve not investigated this).

Now we have got the Location sorted, we need to consider whether try_files being included in the location block where fastcgi_split_path_info is also used.
It would appear there is a bug/feature, that PATH_INFO will not be correct if both are present.
And it’s true – I’m using version 1.8.0 when writing this.
Seems it won’t be fixed – see http://trac.nginx.org/nginx/ticket/321

My complete but minimalistic Location block I’ve used to test and correct the issue is as follows:-

    #At least one char before the .php, then an optional / with 0 or more chars after
    location ~* ^/mytest/(.+\.php)(/.*)?$
        index index.php;       
        try_files $uri $uri/ /mytest/index.php$args; #You can comment this out, and PATH_INFO will be same
        include fastcgi_params; #Put here first so we can override
        fastcgi_split_path_info ^(.+\.php)(/.*)$; #Slightly different from others, and matches my Location regex command
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_index index.php;
        set $real_script_name $fastcgi_script_name;
        if ($document_uri ~* "^(.+?\.php)(/.*)$") #Note using $document_uri as this avoids including the query string in the test
            set $real_script_name $1;
            set $path_info $2;
        fastcgi_param SCRIPT_FILENAME $document_root$real_script_name;
        fastcgi_param SCRIPT_NAME $real_script_name;
        fastcgi_param PATH_INFO $path_info;
        #Check to see if the file does really exist
        if (!-f $document_root$real_script_name)
            return 404;

DigitalOcean droplet without X running on Console

Since my Ubuntu DigitalOcean droplet is for non-serious use I find it useful to have X running so I can use graphical tools to manage it, and I’ve installed LXDE.

It works really well. With X2GoServer installed and X2GoClient on my Windows 8.1 laptop, server maintenance is very convenient.

Unfortunately, once I installed LXDE, the Console window available via the DigitalOcean web control panel also showed the X server and the lightdm login prompt.

This couldn’t be used successful. There were two offset cursors and the click points didn’t coincide. Since I mainly use Windows as the client I could kill X running on the console with Ctrl-Alt-F1, but it was annoying me.

What I really wanted was X not to start on the DigitalOcean console and X to only start for the X2GoClient logins.

I eventually got this to work as follows:-

1. /etc/default/grub
edit the lines to this


2. run update-grub

3. run systemctl set-default multi-user.target
this sets a symbolic link

Now the DigitalOcean console does not run X, and can be used in emergencies to log into the server when might not have my laptop available.
X2Go starts it’s own startlxde session.
No more tty7!

The downside, is that TeamViewer now does not work, as there is no “display” for TeamViewer to connect to. But since there is no phyiscal display, TeamViewer gave such a limited screen  resolution, that it’s probably not much of a problem.
X2Go is great as the screen resolution can be maximised to my laptops’s screen resolution.
Hope this helps you.