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.