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.

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.

Forum

September 26th, 2006

In response to overwhelming demand (ok, just one person – thanks Nick ;) I’ve added a small Vanilla forum. If you have any questions feel free to start a new topic there or place a comment on any post.

View ClonePanel Forum

Edit: Forum changed from SMF to Vanilla, link changed accordingly.

ClonePanel on MS Windows XP

August 14th, 2006

I just installed the latest version of Cygwin and tried it out. The developers have done a truly great job with that because to my surprise it worked!

There was one small glitch – the IP address used on the remote server had some strange characters added, which initially killed the automated remote login. It turned out that I had an escape code entered in front of the IP address of the local server. On further experiment, when entering data at a prompt on the Cygwin terminal, using the cursor keys (up, down, left, right arrows) enters an escape sequence which is invisible but is read by the script. (The same thing happens using PuTTY connecting to a Linux server except that the characters are visible, so are easily deleted.)

So the fix is not to use the arrow keys when prompted for input (backspace seems ok). If you do have problems then check the config file carefully for extra characters – edit the file (eg. clonepanel/hosts/HOSTNAME/config) don’t just print it out, since these characters don’t display!

I’ve now successfully tested backup and sync, get and set dns zone on Cygwin. I’ll take this further when I get the time, unless anyone else would like to continue…?

If you’re interested in using Cygwin for ClonePanel you will need rsync, OpenSSH, openssl, openssl-devel and cron installed in addition to the defaults – just select these from the list during setup. rsync and OpenSSH are under “Net”, cron is under “Admin”, openssl and openssl-devel under “Libs”. Nano / pico fans and anyone wanting a simple easy-to-use editor should also select nano from the “Editors” section.

Edit 1: Added openssl and openssl-devel to list of required modules after testing get_dns and set_dns scripts (these are libraries required by the Net::DNS perl modules).

Edit 2: Changed glitch explanation in the light of further investigation (original below).

I’ll try to work out a fix for this but in the meantime the work-around is to set up the new account with ./account add as in the standard instructions. It will set up the remote key, attempt to test it and fail. Then go into the account on the host server and edit the .ssh/authorized_keys file. On the last line you should see something like:

from=”172.31.255.0″,command=”/home/username/cp0.30/scripts/sync_r” ssh-dss AAA…

Where the IP address and username would be whatever you just entered. This is followed by a long string of characters that make up the key.

If you see other characters between the from=” and your IP address, delete them and save the file.

Then back on the cygwin computer, type:

./sync_remote -u username -H HOSTNAME

to complete the setting up of the remote system (interrupted earlier by the error). If you get no errors this time you should be good to go!

Backup / monitoring system on a VPS

August 13th, 2006

I just moved the main clonepanel system (for backup and monitoring) to a small Xen VPS from VPSLand.com – 96Mb memory, 192Mb swap and 4Gb disk space (2Gb usable space with the operating system taking up the rest). A tiny package at a very reasonable price (US$12 per month), yet it’s performing brilliantly!

The biggest client account (a little over 500Mb in total) was syncronized – a complete download – the first time in 9.5 minutes (effectively around 900kB/s). Syncing a second time required 4 small databases dumped and downloaded plus checking all files (although none had changed) – all done in 9 seconds.

It’s early days yet but I really like the Xen system with dedicated memory that cannot be given away to other virtual servers on the same node – I’ve seen no trace of that little lag that seems so common on all Virtuozzo systems I’ve tried.

More reviews in the hosting category, coming shortly.

Version 0.30 alpha

July 28th, 2006

The first version to be made publicly-available – if you’re interested in being a guinea pig alpha tester please be sure to let me know what you think – you can drop me an e-mail or add a comment here.

Thanks,
Chris

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

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

Please see the installation instructions.

ClonePanel web site (WordPress version)

July 21st, 2006

I was updating the old web site to the latest version of Xaraya (1.1) and getting frustrated with some of the changes that demand modification of existing themes.

I’ve also been working on a couple of WordPress sites recently and loved the tiny code-base and the simplicity of integrating my own php code into a WordPress site.

Don’t get me wrong – I like Xaraya but it’s a huge beast! And if I’m going to be developing and maintaining other WordPress sites it makes more sense for me to concentrate on that rather than learning how to do the same things through Xaraya…

So I deleted Xaraya, downloaded WordPress and a neat theme from themes.wordpress.net and a couple of hours later here it is – the new WordPress-powered ClonePanel.