Version 0.33 alpha

October 25th, 2007

Apologies for the long delay releasing this one – I’ve been improving my own version gradually but not bothering to update the release version. However there’s been a bit more outside interest in the project during the past week or two so here it is.

Download latest version

Thanks,
Chris

Changes in this version:

The most important item for this release is that DNS failover is tested and (for me at least) working. Other notable improvements include:

  • Simultaneous display and storage (for later error checking) of rsync output – avoids giving the impression of a stall on the long initial sync.
  • Option to use alternative SSH ports
  • Status handling now uses 4 levels: Green (all ok), Amber (failing), Red (failed) and Cyan (recovered from a failure). Allows for more options on handling failover actions and timing.
  • Added DNS update method for DirectAdmin control panel
  • Also stacks of minor improvements and bugfixes.

Upgrading

If you haven’t fully set up your previous version of clonepanel, or if there are problems with it then create a complete new installation by following the installation instructions. The new version will install into a directory “cp0.33″ by default.

If you have an existing working system you’d like to upgrade, please follow these additional instructions:

  1. Backup everything!
  2. If you have modified your scripts/config file, copy your changed settings and add them to the system/config file – as a general rule, make configuration changes in the system directory if they apply by default or in the individual host / account directory if they are specific to a host / account. No config changes should ever be made in the scripts directory, because the next version will overwrite them.
  3. Download and extract the new archive (by default to directory cp0.33).
  4. (modified) Copy all files from the system, hosts, accounts and CPanel directories of your old clonepanel system into the new one. eg. upgrading from a default 0.32 install to 0.33:
    cp -r cp0.32/system/* cp0.33/system/

    etc.
  5. If you’ve set up a shortcut link to clonepanel then remove it and create a new link to the new version.
  6. Remove any old clonepanel cron jobs: crontab -r to remove all jobs or crontab -e to be selective if you have other jobs set up for this user.
  7. Generate replacement cron-jobs for the new version: scripts/setcron (or you may want to start with scripts/setcron -n all to check that everything is working – this will send an e-mail message for every job that runs).

As always, feedback is more than welcome. To make your comments, please join the forum or add a comment here.

Latest version should always be at: clonepanel.com/latest/

This version is at: clonepanel.com/downloads/clonepanel_0.33.tar.gz

Please see the installation instructions.

Installation on hosts without SSH access

August 23rd, 2007

I’ve been hearing good things about HSphere as a platform for a reseller account – clustered services, fully integrated billing and ticketing and the ability to resell both Windows and Linux hosting (not that I really want to offer Windows but it could be useful at some stage). But there’s a catch: I’ve yet to find a HSphere provider who’s willing to offer SSH access. This is rarely a problem for CPanel or DirectAdmin – most hosts using these panels seem to offer it on request, presumably having accepted that some users have a legitimate need for it and that any additional security risks are minimal (above the risks associated with allowing users to run PHP, perl and shell scripts via CGI or cron). But perhaps the situation is different for HSphere – I read somewhere that SSH is used for internal communications within the cluster and allowing user SSH could compromise this. In any event, the reality seems to be, if you want SSH access don’t choose an HSphere reseller account.

Now I’ve always considered SSH access a prerequisite for ClonePanel. The backup server uses an SSH connection to transfer files using rsync. But could it be done any other way? I thought this could be an interesting challenge (masochist that I am) so I signed up for a reseller account with a popular HSphere host and set out to discover what was possible.

Of course there are always other ways to do backup and restore. Most common is to tar and zip all files into a single backup, transfer that using ftp and unzip and untar at the other end. But I really want to avoid this if I can – rsync is just so much more efficient and I don’t want these regular backups to cause any perceptible load on the servers. So I started looking at how to use rsync without being able to make an SSH connection to the hosting server. If I can’t connect in, what about having the server connect out? I can run shell scripts through cron, the system gives me access to the usual linux / bash commands including ssh and rsync, so what’s to stop me connecting from the hosting server to my backup VPS?

Well, as it turns out the first thing stopping me is a firewall! They have it sewn up pretty tight, including outgoing connections on several high-numbered ports that I tried – it makes sense from the security point of view (don’t open up anything unless you have to) but it makes things tricky for me. But it turns out that there are at least two ports open, 80 and 443, allowing scripts on the server to connect to external web sites – this seems like a requirement for any hosting server where the clients may need to fetch information from the web or communicate with a payment gateway.

So if I set up the VPS to run sshd on one of these ports, the hosting server can connect to it. Of course this means that it’s not possible to run a regular webserver on the VPS (on the standard ports) but I don’t want it to be web-accessible anyway. So I set up the ssh private key and known_hosts file on the hosting server (normally ssh will update known_hosts with the other server’s RSA key on the first interactive connection, after prompting to ask whether you want to connect, but in this case it must be done manually – there is no interactive connection!) and after a few attempts managed a simple ‘ls’ command on the backup server.

So it is possible: an outbound SSH connection from a hosting server where inbound SSH isn’t allowed. The use of a non-standard port is a little inconvenient but not a major problem. However we are talking about passwordless remote access to the backup server from a web-server… This is something I’ve always tried to avoid – the webserver is relatively insecure (ie. accessible to anyone who wants to connect to it, and running scripts which, even if kept updated, just might contain a zero-day exploit). This is a tough call – something I’d prefer not to do but against that I really would like to extend the functionality of ClonePanel to hosting servers without SSH access.

My compromise is this: a separate install of ClonePanel under a different user, with the new install used only for accounts connecting to this hosting server. Still not ideal perhaps but at least all other accounts are kept totally separate by file permissions on each user’s home directory. In the worst-case scenario where the hosting server gets hacked the attacker could use this connection to the backup VPS to read anything from the user’s filesystem, but this is mostly what’s already available to him in the web-directories of the compromised server, and the open-source ClonePanel system itself. There is one potential issue: the private keys allowing access to the corresponding accounts on other servers, but since these keys are restricted to use from the ClonePanel system’s IP address even that doesn’t allow the attack to go any further.

So that’s how it works. All that remains is to set up a simple rsync transfer script on the hosting server similar to the sync script on the ClonePanel system and run it at intervals with a cron job. Here’s what I ended up with:

#!/bin/sh
# This program is intended to sync a slave server to the backup
# where SSH connections to the slave are not allowed.
# The program runs on the slave server (via cron)
# and connects from the slave to the backup server to sync the files.

# After syncing the databases are restored.

# Several constant values need to be filled in below.
# ClonePanel - Manages duplicate accounts on two or more webservers,
# including snapshot backups, monitoring and failover dns.
# Copyright (C)2006 Chris Cheers, Internet Lynx.
# Contact chris[at]clonepanel[dot]com.
# Internet Lynx, PO Box 7117, Mannering Park, NSW 2259, Australia
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.

# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

exec 2>&1
# Display errors

set -u
# Be strict about variable declaration

unset PATH
#avoid use of $PATH - limit script to system commands we choose

#start of constant definitions
RSYNC=/usr/bin/rsync
SSH=/usr/bin/ssh
MYSQL=/usr/bin/mysql
#most likely won't need to change these

REMOTEUSER=username
REMOTEHOST=backup.clonepanel.example.com
REMOTEPORT=443
REMOTEWEB=path/to/public_html
REMOTEDB=path/to/cp0.30_db
#details for backup server - change as required

AUTH=/hsphere/local/home/username/.ssh/private.key
#private key file giving access for REMOTEUSER to REMOTEHOST

HOMEDB=/hsphere/local/home/username/cp_db
HOMEWEB=/hsphere/local/home/username/example.com
#directories for local server - change as required

EXCLUDES=excludes.txt
#name of file containing filenames to exclude - one per line
#filenames of all files modified to suit this server

NUM_DATABASES=2
DATABASES=(username_db1 username_db2)
DATABASE_USERS=(username_dbuser1 username_dbuser2)
DATABASE_PASSWORDS=(secret1 secret2)
DATABASE_HOSTS=(dbhost1 dbhost2)
DATABASE_FILES=(username_db1 username_db2)

#end of constant definitions (stop editing here!)

#sync from backups

$RSYNC -avz --delete --exclude-from="$EXCLUDES" -e "$SSH -p $REMOTEPORT -i $AUTH" $REMOTEUSER@$REMOTEHOST:$REMOTEWEB/* $HOMEWEB/

#sync web files

$RSYNC -avz -e "$SSH -p $REMOTEPORT -i $AUTH" $REMOTEUSER@$REMOTEHOST:$REMOTEDB/* $HOMEDB/

#sync database dump files

#restore databases
for (( i = 0 ; i < $NUM_DATABASES ; i++ ))
do
  db=${DATABASES[$i]}
  db_user=${DATABASE_USERS[$i]}
  db_pass=${DATABASE_PASSWORDS[$i]}
  db_host=${DATABASE_HOSTS[$i]}
  db_file=${DATABASE_FILES[$i]}
  $MYSQL -u$db_user -h$db_host -p$db_pass $db <$HOMEDB/$db_file.sql
done

Conclusion: It seems to be possible, with some minor compromises. With more development the process could be better integrated into ClonePanel – perhaps using a similar technique to transfer a directory of special scripts which could then be run by the ClonePanel system as cgi.

More to follow as I find the time…

Hosts: FutureHosting.biz

April 12th, 2007

This is a new-ish VPS host that’s gathering a number of good reviews on WebHostingTalk, and offering deep discounts particularly on their small unmanaged plans – ideal for a ClonePanel backup server. At one point they were offering OpenVZ accounts with 128Mb memory (256Mb burst) and 10Gb disk space for $10 per month. The current offer is the same but with 5Gb space, and this has been available repeatedly for the past few months, although there’s no telling how long much longer it will continue to be available – regular price is $20.

In my experience they’ve been near perfect – a very reliable, well-managed server; great uptime (both server and network); extremely quick and effective response to tickets on the few occasions when there were problems. So based on the first 3 months: highly recommended!

Web interface roadmap

March 14th, 2007

ClonePanel has up to now been purely command-driven through SSH. This is ok for me – after spending time developing it – but hard for anyone coming to it fresh, particularly if they’re also new to the Linux shell prompt. So I’m very grateful to those who’ve struggled to give it a try(!) but I’m also aware that to gain wider acceptance there should be an easier way to drive it.

So, a web interface then, but how best to implement it for optimum performance and security? These are my thoughts:

I don’t want to lose the command-line functionality and I don’t want to maintain two sets of scripts, so rather than rewriting what’s there now I see the web interface as just that – an interface between the user’s browser and the existing shell scripts.

In terms of performance, the web interface should run on the same machine as the clonepanel scripts themselves so it can execute them directly. But considering security I’ve always believed that the machine running ClonePanel should NOT run other services (eg. a publicly-available webserver) because if this were exploited then the ClonePanel system and all remote hosts it controls could be at risk. Tricky…

One could also argue that even if the web interface ran on a different server, logging in to the ClonePanel system to execute scripts, this would be an almost equal security risk since any credentials (eg. SSH key) allowing the web interface to pass instructions to ClonePanel would also give access to an attacker.

I think the way to resolve this conflict may be to consider the needs of different user-groups and provide different solutions to each.

Admin (full access) – Run the webserver and interface on the ClonePanel server, but block public access. For a home / office-based server on a local network behind a firewall (or at least NAT) this would require no additional setup – the web interface would automatically be available only via the local network. For a remote server this could be achieved by NOT opening ports 80 / 443 in the firewall and instead accessing the server through a VPN or port-forwarding on an SSH connection.

Public (read access to certain information eg. monitor data) – ClonePanel server writes this data out to a hosting account at intervals. This is already in place.

User (limited access to own account eg. backup, restore, list snapshots) – This would be the most difficult since we don’t want to impose a complicated setup (VPN / SSH tunnelling) on a regular user. My preferred solution is to copy relevant information (snapshot directory listings) to user’s own account, run the web interface there and have the ClonePanel server poll the remote servers at intervals to find and execute user requests (backup or restore). However this is compromising performance to a degree – the user can expect to see something like “Restore request received. Your files / directories will be restored within 30 minutes”. So, no instant gratification but probably acceptable considering that most backup systems don’t give users any kind of access!

Have I missed anything vital? Questions and comments welcome, as usual, here or on the forum.

Chris

Application updates

March 5th, 2007

This site is now running on WordPress 2.1.2 with integrated Vanilla 1.1.2 forum. The integration (documented here) is still experimental – what isn’t on this site?! – so if you find any unusual behaviour please let me know.

Edit: It turns out that the update wasn’t quite as simple as I thought. In the new version of Vanilla the authenticator code (library/People/People.Class.Authenticator.php) has been changed to allow for the new security patch. The alternative People.Class.WordpressAuthenticator.php used for WordPress integration needs to be modified in the same way.

In detail, I edited the file library/People/People.Class.WordpressAuthenticator.php and replaced:

function GetIdentity() {
    $this->GetWordpressSettings();

with this:

function GetIdentity() {
    if (!session_id()) {
        session_set_cookie_params(0,
                $this->Context->Configuration['COOKIE_PATH'],
                $this->Context->Configuration['COOKIE_DOMAIN']);
        session_start();
    }
    $this->GetWordpressSettings();

from the new People.Class.Authenticator.php.

Hope this helps someone…

Edit 2: Make that Vanilla 1.1.1 – just once I get in really quick with an upgrade and look what happens… ;)

Edit 3: Hmm, now Vanilla 1.1.2… At least the above still works with no new changes.

Version 0.32 alpha

March 5th, 2007

Another work-in-progress release, still alpha status but should be increasingly reliable with continuing minor bug-fixes.

Download latest version

Thanks,
Chris

Changes in this version:

  • Most bug fixes at this stage involved monitoring and error logging / accounting functions
  • Monitoring now checks initially from the clonepanel server itself, then from a host server setup to act as a monitor proxy, then from another host server (if available) giving verification of downtime from three different locations.
  • Modified sync script to allow for jailshell failing to correctly return exit status of remote scripts
  • Added “backup” script (similar to the first part of sync but more flexible)

Upgrading

If you haven’t fully set up your previous version of clonepanel, or if there are problems with it then create a complete new installation by following the installation instructions. The new version will install into a directory “cp0.32″ by default.

If you have an existing working system you’d like to upgrade, please follow these additional instructions:

  1. Backup everything!
  2. If you have modified your scripts/config file, copy your changed settings and add them to the system/config file – as a general rule, make configuration changes in the system directory if they apply by default or in the individual host / account directory if they are specific to a host / account. No config changes should ever be made in the scripts directory, because the next version will overwrite them.
  3. Download and extract the new archive (by default to directory cp0.32).
  4. (modified) Copy all files from the system, hosts, accounts and CPanel directories of your old clonepanel system into the new one. eg. upgrading from a default 0.31 install to 0.32:
    cp -r cp0.31/system/* cp0.32/system/

    etc.
  5. If you’ve set up a shortcut link to clonepanel then remove it and create a new link to the new version.
  6. Remove any old clonepanel cron jobs: crontab -r to remove all jobs or crontab -e to be selective if you have other jobs set up for this user.
  7. Generate replacement cron-jobs for the new version: scripts/setcron (or you may want to start with scripts/setcron -n all to check that everything is working – this will send an e-mail message for every job that runs).

As always, feedback is more than welcome. To make your comments, please join the forum or add a comment here.

Latest version should always be at: clonepanel.com/latest/

This version is at: clonepanel.com/downloads/clonepanel_0.32.tar.gz

Please see the installation instructions.

Simple WordPress anti-spam for shared hosting

December 21st, 2006

I hate spam! The e-mail based stuff is bad enough (and much worse for the past few months) but it’s also invading web sites. WordPress, being such a popular package, is a major target for referrer and comment spam. In case you haven’t already come across these, they’re both techniques by which spammers attempt to place links on your site to their grimy porn / pharma / small caps or whatever sites.


Now at the simplest level these attempts are easy to block by ensuring that logs are not published and all comments must be approved before publication. But comment moderation can become a chore if you’re trying to sort one genuine message from among hundreds of fake ones, so there are some nice WordPress plugins available to help – notably Akismet, Spam Karma 2 and Bad Behavior. These three plugins each take a different approach to dealing with the problem, and they all seem to be effective. I’ve only tested Akismet and SK2 so far – both work well.

So I was reasonably comfortable with the situation (complacent?!) until I saw this thread on WHT titled Drummed out by spambots. Here’s someone with a small WordPress blog and similar anti-spam measures in place, and the sheer volume of spam requests has caused the host to suspend the web site. Now I don’t blame the host for this – if a single site is overloading the server you have to shut it down for the sake of all the other customers – but that’s not much consolation for the innocent victim of the spammers. Remember, nothing was fundamentally wrong with the blog – the spam was not published, the site was not exploited, the anti-spam system was working correctly but the server was simply overloaded by the job of handling comment-posts at an average rate of about 1 every second! In effect, it’s an amplified DoS (denial of service) attack.

For me, it’s an early warning. I run several WordPress blogs, both for my own projects and for client web sites and I really don’t want this to happen to any of them. Fortunately the discussions in that thread led to a participant “extras” proposing what looks to me like a viable solution. This post describes the implementation.

What’s wrong with existing solutions?

Generally, not much at all, but in this situation the processing power required was too great. I’m looking for a simple solution that takes minimum processing power – so no PHP.

Principles of the new system

In wordpress, visitor comments are posted to the PHP script wp-comments-post.php. Writers of evil comment-spam-bots know this and will generally go there directly, unlike real visitors who wish to comment on a post – they will always view the page first. So the aim is to change the name of that script (for genuine visitors), detect all bots going to the original script and ban them!

Implementation

So step 1 is to send real visitors to a different script – I’ll call it “my-wp-comments-post.php” but if you try this yourself choose a name of your own.

So I’ll make a copy of wp-comments-post.php called my-wp-comments-post.php in the main wordpress directory, and in my template (usually comments.php and comments-popup.php) I’ve changed the line:

<form action="<?php echo get_settings('siteurl'); ?>/wp-comments-post.php" etc.

to this:

<form action="<?php echo get_settings('siteurl'); ?>/my-wp-comments-post.php" etc.

Now, I might allow people a day or so to refresh their cache but after that I’m going to assume that anyone using the original script is an evil spammer and block them. To do this, using the idea suggested by extras in the post linked above, I’ll replace wp-comments-post.php with a new script that records the visitors IP address and then sends them an error page (403 Forbidden). I’m going to record the visitor’s IP address by creating an empty file, for reasons that will become apparent later. Here’s the simple code:

<?php
$blockdir = 'my-blocked-ips';
$ip = preg_replace('/[^d.]/','',$_SERVER['REMOTE_ADDR']);
$file = "$blockdir/$ip";
if ( $h = fopen($file, 'x') ) fclose($h);
header('HTTP/1.0 403 Forbidden');
exit;
?>

I’ve also created a directory called my-blocked-ips (again choose a different name if you want to do this) and made it writable by PHP – chmod 777 for a mod_php system. So, each hit on the old comment script records the visitor’s IP address. Now to do something with it…

.htaccess modifications

What we want to do is find the visitor’s IP address, look for a file of that name in the my-blocked-ips directory and if it’s found, block all access to the site. Here’s the mod_rewrite black magic to do it:

RewriteEngine On
RewriteBase /
#Use simple html error document in place of shtml standard
Errordocument 403 /403.html
# Ban blocked IPs (recorded as files in blocked directory)
RewriteCond %{REQUEST_URI} !^/403.html
RewriteCond /full/path/to/my-blocked-ips/%{REMOTE_ADDR} -f
RewriteRule . - [F,L]
# Prevent direct access to blocked directory
RewriteCond %{REQUEST_URI} ^/my-blocked-ips/
RewriteRule . - [F,L]

First I’ve set up a special error page for 403 errors – one that requires very little processing, so just a simple very small HTML page. Then the redirect, based on finding the visitor’s IP in the block list, and specifically excluding our new error page. Finally, just as a precaution I’ve blocked direct access to the blocked-ip directory (as it’s server-writable I don’t want anyone to place a PHP file in there and run it).

Cleaning up

It’s probably a good idea to periodically remove the files from my-blocked-ips, partly to improve performance checking for a file in that directory but mainly because innocent people on dynamic IP addresses could be unfairly banned – say if the IP address happens to be one previously (ab)used by an exploited computer. So a cron job to periodically un-ban older addresses would seem useful, something like this:

find /full/path/to/my-blocked-ips/ -type f -maxdepth 1 -mtime -2 -exec rm -f {} ;

Afterthought

Ok, I should have thought of this before but I don’t want this thing blocking the Googlebot (or any other search-engine spiders). If everything goes right it shouldn’t happen anyway, since there are no links leading to that page, but just to be on the safe side I’ve added this to robots.txt:

User-agent: *
Disallow: /wp-comments-post.php

Well-mannered bots will read that and not touch the blocking script. Spam-bots will most likely ignore it.

Does it work?

Too soon to tell. This site (like most WordPress blogs I guess) does receive a fair amount of comment spam – Akismet is showing 81 comment spams from the past 12 days. I’ll keep an eye on the system before and after the change and update this post later. I think success hangs on one important question: do the spam-bots actually look at the comments form in the pages or just default to the WordPress standard script? I’m assuming the latter, but if I’m wrong then the comment spam will continue coming in on the real contact form, in which case something smarter will be needed – perhaps based on the Bad Behavior plugin. We shall see.

Meanwhile, if anyone has relevant comments I’d be interested to see them (if only so I know the site is still working!)

Update (22 Jan 2007)

First, doing this requires some care to avoid either blocking legitimate users or letting the spam through unabated. With the site updates to version 2.06 and then 2.07 in quick succession it went through a short period in both of those states, so if any genuine visitors tried to post a comment and got themselves blocked for a day or two – sorry, mea culpa. I now have it set up with no modifications to the standard wordpress files or directories (except for my own template) which should allow for painless upgrades.

(If anyone’s interested in the file system set up let me know and I’ll post the details).

All that makes it hard to analyse results but it appears to me that:

  1. During the period when the system was working correctly, very few spammers were caught and blocked – suggesting that in most cases they aren’t simply going to wp-comments-post.php without checking that it’s the target of the comment form.
  2. The rate of comment spams overall has reduced dramatically. Even when the system was effectively disabled the site received 31 spam comments in 15 days, about one third of the rate earlier.

The best way I can interpret these rather conflicting results is that comment spammers may look for a standard WordPress install – anything non-standard and they simply move on to the next victim. If so, reducing comment spam may be easier than I thought…

I’ll update with some results after the system has been in action (and working) for a while longer.

Version 0.31 alpha

November 1st, 2006

The “it mostly works” release! If you try it out please be sure to let me know what you think – you can drop me an e-mail or add a comment here.

Thanks,
Chris

Changes in this version:

  • Many assorted bug fixes
  • Much improved monitoring, error logging and downtime management
  • Better Cygwin compatibility
  • Bandwidth limit applied to rsync transfers (thanks Steve!)

Upgrading

  1. Backup everything!
  2. If you have modified your scripts/config file, copy your changed settings and add them to the system/config file – as a general rule, make configuration changes in the system directory if they apply by default or in the individual host / account directory if they are specific to a host / account. No config changes should ever be made in the scripts directory, because the next version will overwrite them.
  3. Download and extract the new archive.
  4. Copy all extracted files into your clonepanel directory, overwriting those already there and maintaining the sub-directory structure. eg. if your clonepanel directory is “clonepanel” and you’ve extracted the new archive into “cp0.31″:
    cp -r cp0.31/* clonepanel/

Latest version should always be at: clonepanel.com/latest/

This version is at: clonepanel.com/downloads/clonepanel_0.31.tar.gz

Please see the installation instructions.

A backup backup server?!

October 16th, 2006

Apparently I need a backup for my backup vps, which is currently unreachable. I know it’s still running because I’m still getting e-mail from it through gmail – messages indicating that it’s unable to connect to any of the other servers! And this is what you’re seeing on the monitor display – the grey means no data, and clearly the monitor script needs improvement because really it should show all grey for the past hour or so.

Meanwhile, to get some real monitor results, I’ve started up the old linux machine on my own dsl connection. It’s a good idea every week or two anyway since it will sync all the accounts and give me another off-site backup – one that’s easily copied to DVD.

Potentially a problem though is that I now have two systems both trying to write the monitor data to a single host. I need some elegant way to deal with this…

Update: The VPS is now back online and all is normal. To avoid the monitor data issue I changed the value of MONITOR_RESULT_DIR on the second machine. The final step to redundancy is to use a redirect on the monitor server which would send the backup data if the main data is unavailable.

Monitor demo

October 8th, 2006

A quick demo of the monitor display. This is live data for real servers (names have been changed to protect the innocent!).

Update – 01 November 2006

Added a javascript style-switcher and summary information (this month’s percentage availability and number of days uptime).

Notes

Measurements are taken at 5 minute intervals, represented here by one pixel – a total of 12 hours range on the graphs shown. Javascript keeps the graphs updated (reloading the latest data file every 5 minutes) as long as you stay on the page.

Initial view is server load average. Use the “LTMFSD” buttons or the style changer in your browser (eg. View -> Page Style) for other parameters: page load time, free memory, swap memory, MySQL connection and disk space.

The coloured display is indicative only, based on roughly a log scale, so that small variations are visible. For example on the load average display there is a visible difference between a load of 0 and 0.2, yet the full scale covers up to 100.

To view actual measurements click anywhere on the graph (you need to be quite precise).

Normally the monitor would be inserted into any page just by adding the stylesheet links in the head and a javascript tag in the body. In this case I’ve used an iframe to avoid permission problems in Firefox and other Mozilla-based browsers. (The javascript loads data files from another domain).