Ubuntu 13.10 server with VNC

Hi all,

Back from the brink with a few new blog posts. I’ve recently migrated my server from RHEL to Ubuntu – given i dont have an active subscription anymore, and for the ‘home user’ the packages available (repos, to be precise) for Ubuntu are far better than RHEL/Centos.

I made a bit of a booboo in installing Ubuntu 13.10 which installs headless by default – and i do like to have a VNC for that odd occassion you just cant get something working – KVM networking, for example! *Grumble grumble*.

So, what i did – install MATE (Gnome 2, i pine for the good old days), installed VNC, and then configure VNC to use MATE on a new session.

1. Install MATE:

This installs the MATE desktop, ready for use (note, if you want to convert your server into a desktop you’ll need to install some sort of login/display manager – gdm, for example). I’m only using MATE from a VNC invocation so i dont need that.

2. Install VNC Server

This simply installs a VNC server – not much to explain here really!

3. Configure new VNC sessions to use MATE

VNC stores its config file (xstartup) in the “~/.vnc/” folder. Therefore you need to navigate to that directory first:

Then you will need to create a new file, or edit one (if its there already) called ‘xstartup’:

.. and paste the following into it:

The key line is ‘mate-session &’ – this tells your VNC server to create a new ‘desktop’ using mate, instead of X, Gnome, or any other desktop you have.

4. Wrap-up

Next, start up a VNC server and open up the firewall:

iptables -I INPUT 3 -s -p udp –dport 5900:5904 -j ACCEPT

In my example, i’m going to be running 4 VNC servers – on port 5901, 5902, 5903 and 5904. We can create these 4 sessions using the colon-number approach:

(Im sure those of you who are of that mindset could do a ‘for i in..’, but im too lazy). 

Finally, get yourself a VNC client, i.e. RealVNC – connect to your server – ipaddress:5901, and voila, your desktop is alive!

File age monitoring with Opsview

Hello all,

No I am not dead – I have just moved into management… I’ll let you come up with the jokes!

Today I’m going to write a technical document on how to monitor the age of a file to ensure that it is newer than a certain criteria – i.e. make sure that file ‘X’ is newer than ’5 days’ for example. This came up during my day as I wanted to make sure that my diary that I use at home (running on WordPress) is backed up to a remote location successfully once a week – so it pays to be in monitoring today!


Firstly, I setup my crontab entry:

Here we are essentially running a mysqldump against the MySQL DB that is running my wordpress installation (wpblog), and storing it on a remote NFS mount point as a .gz file, with a date modified file name (so i can roll back if needed).

Also, I am creating a new file in /var/log called ‘diary-backup’ – why? Because my plugin will be executed by the nagios user, and i dont really want to give it access to my nfs2 share (Plus, it is a hassle that i dont have time to play with) – so i’m creating a file in /var/log that im going to chmod 755, so that nagios can access it and scrutinize the file age -which, as the file is created after the backup job – will be a real world representation of the .gz file created.

Opsview plugin

For this exercise, I used the ‘check_file_age’ plugin that ships with Opsview – however the standard output was rather annoying and not very humanised – for example:

This isnt very useful to me – as I am not a computer and cant work out if 425,000 seconds is a good thing or a bad thing :) So, i modified the check_file_age plugin using the help of this guide here - http://www.krzywanski.net/archives/429 – essentially, replace the line:


So that we output  ’days’ instead of seconds. So, next I tested my command locally on my wordpress server:

(If your curious, 691200 seconds is 8 days). So here we can see, the nagios user has access to the file in question – and we are getting data in a usable format i.e. days, not seconds.

Next, we need to create the NRPE entry, so this ^^ command can be executed remotely by the Opsview monitoring server. Doing this is very simple – just add a line similar to the below in your /usr/local/nagios/etc/nrpe_local/overrides.cfg file (if this doesnt exist, just create one):

The ‘diary_backup’ element is the command we will be executing from Opsview. Finally, give the opsview-agent a bounce to apply the changes:

We can now test this locally:

Voila, its working.

Bring it all together in the GUI

So lastly, we need to login to the Opsview GUI and bring this all together. Firstly, create a new service check with the plugin as ‘check_nrpe’ and the arguments as ‘-H $HOSTADDRESS$ -c diary_backup’. Then, add this to your host (wordpress server in my example). Finally, give it a reload and it will now be running and monitoring your backup:

There are then hundreds of things you can do – for example be notified when it goes critical or warning (ignore the warning above, i didnt set a -w flag, whoops) – or show it in a keyword (Monitoring > Keywords) as i have done at home:


So there you have it – i am now monitoring my Diary backup cronjob to make sure it completes every week using Opsview. You can use this for anything – logs, files, logins, you name it. Happy hunting!

Windows add persistent route

A very brief note here – I recently setup  a network virt-network on my KVM setup at home on the network – that all my VM’s connect to, and then route out via eth0 ( – but naturally I cannot access them from my laptop here at work via the VPN because I dont have a route to that subnet.

So, after some poking around on the CLI on Windows (gulp), I finally added a route:

I come into the work the next day, and nope – cant access it again. A “route print” shows that the route has dissappeared!  What we need to do it use a persistent flag:

This will keep the route after reboots, DHCP/Route table updates, etc so you dont have to mess around with .bat files!

Hope this helps someone.


Change eth0 to eth1

I recently re-did my server, upgrading the board and adding more memory – which went very smoothly (although one of the RAID cards wasnt fully fitted, meaning my RAID-5 threw a wobbler thinking a disk had died – took 8 hours to re-add after seating the card correctly, doh!).

One of the issues I did run into was the ethernet ports. Obviously my original board has 2 NIC’s, and their MAC’s are registered in the OS as eth0 and eth1 respectively  - so when i powered the OS up on a new mobo, my default NIC came up as eth2 – ponderous!

Firstly, I tried changing my /etc/sysconfig/network-scripts/ifcfg-eth0 to reflect the new MAC addresses – after a ‘service network restart’, nope – same issue!

Turns out that what you need to do is edit  /etc/udev/rules.d/70-persistent-net.rules:

Comment out the original line:

And add a new line with your new MAC:

Reload the network:

And voila – its fixed and now running as eth0. The reason I had to change this was KVM was expecting an interface on eth0, rather than eth2, and i couldnt find for love nor money anywhere to change it – not in the NIC against the VM, not in connection settings, not anywhere! But this method fixed it – so try this if your having the same issues!