The best way to test online software is to use a demo site that has that software installed. Many content management systems like Joomla use the demo sites to present their product for public (see http://demo.joomla.org ). The main issue with the demo sites is that giving unrestricted access to everyone might cause severe damage to the site, and it doesn't have to be someone with bad intentions. For example the site could be compromised if someone is testing a change in the configuration. Having the demo site too restrictive is also not a good solution because by doing that you can't show all your product features to a potential customer.

This article describes how to create a demo site by giving enough access to public so one can fully test the product and also create a procedure that resets the demo to a working state at a specific time (a counter showing the remaining time until the demo will be restored to its original state is really helpful). A working state for the demo site means that we have the site code & database tested successfully and all the features of the site are working properly. 

We are going to setup 3 demo sites for Jentla Flexile template with Joomla 1.6 code at http://flexile.jentla.com/demo1 , http://flexile.jentla.com/demo2 and http://flexile.jentla.com/demo3. What's different from other demo sites is that the code is updated automatically in the demo site with the newest revisions from subversion repository once it passes our tests. For code updates we are using Jenkins ( http://jenkins-ci.org ) - an open-source continuous integration server , and the acceptance tests are done using Selenium (http://seleniumhq.org) – a software testing framework.

Preparation of code using Jenkins

The first job that needs to be configured in Jenkins is the one that gets the nightly build of Joomla and the latest code of Jentla Flexile admin template installed together in the same workspace.

In Jenkins main menu, click on New Job . Add a name for the project(“Flexile1”) and select “Build a free-style software project “:

 

 

In the configuration menu for the new project, it's better to discard old builds and keep only a few of the latest build records. Also we can setup a custom workspace in the “Advanced Project Options “ section so we don't have to work with the really long and complicated path that's provided by default for the project workspace. (We have selected /app/jenkins/flexile1)

The most important part in the job configuration is the 'Source Code Management”. Here we can select the 2 repository URLs, one for the Joomla 1.6 code and one for the Jentla Flexile 1.6 template. We have set the following configuration

 

In the Build Triggers section, we have set the project to be build periodically. The schedule syntax is very similar to the one used by cron in Unix ( http://en.wikipedia.org/wiki/Cron ). To have the project build every 1 hour we've added the following:

In the “Post-build Actions” section of the configuration we can setup various tests (like Selenium/JUnit tests) and also build other projects if the build was successful. We will not get into details for the testing actions right now.

In the second stage, we need to setup the project that copies and prepares the workspace code for the demo site. The new project will be called 'Flexile1_deployment' and it needs to be build after the main project “Flexile1” was built. You can set this up in Job configuration → Build triggers by selecting 'Build after other projects are built'.

To copy the code to a new folder , we have created a shell script (update_flexile1.sh) that needs to be added in the Build section of the job configuration, in the Execute shell paragraph.

 

The shell script just creates a new folder with the .svn subfolders removed.

#!/bin/bash


#Deleting prior temporary folder
rm -rf /app/demos/flexile1_

#copy workspace to a temporary folder
cp -rp /app/jenkins/flexile1 /app/demos/flexile1_


#delete .svn folders from temporary location
cd /app/demos/flexile1_
/bin/delsvn


#Rename temporary folder to working directory
cd /app/demos
rm -rf /app/demos/flexile1
mv flexile1_ flexile1


The final step is to add in the Flexile1 configuration in the “Post-build Actions” the following:

 

At this point, we should have both projects up and running:

 

 

Flexile1 job console output:

 

After finishing the Jenkins configuration, we should have a working code with the latest Joomla 1.6 code and latest Jentla Flexile admin template in /app/htdocs/flexile1. The next step is to configure the initial state of the demo site using that code and secure the Joomla site.

Securing the Joomla demo

The requirements are simple: allow users almost complete administrator access to the joomla site but prevent them from doing bad things. The solution is unfortunately a bit more complicated. True for the much improved user permissions of Joomla 1.6 makes all this a bit easier there still are many things to do. Let’s make a check list of things that need to be done:

1. limit the user actions as little as possible

2. prevent the users from gaining access to the files, database or denying access to other users

3. limit the possible damage if a malicious users bypasses no. 2

How do you prevent users from doing bad things in the Joomla administrator interface? Easy: we deny them the possibility of installing or removing components, modules and plug-ins. First thing we did was to create a user group for the demo users and set special permissions for this group:

You can see in the above picture the settings of the Demo Administrator group for the Extensions Installer. Be sure to visit all Joomla functions that could allow a user to do damage and set appropriate permissions:

• Installer must be denied completely

• Modules, plugins can be browsed and configured (allow the users to publish, unpublish and move them around) but don’t allow them to erase them

• Global configuration denied completely, you don’t want them seeing your DB configuration

• User manager denied completely, you don’t want users changing passwords, creating new users, etc.

A few issues directly related to Joomla remain that cannot be fixed using the built-in security settings:

• You don’t want the demo user changing it’s own password. Even if the user manager is denied one can still visit the My Profile page and change his password. There’s no way to deny this from Joomla it’self but a simple rewrite rule in your apache configuration will help you here:

RewriteCond %{REQUEST_URI} ^/demo/administrator/

RewriteCond %{QUERY_STRING} ^option=com_admin&view=profile&layout=edit

RewriteRule ^(.*)$ /demo/administrator/index.php? [L,R=301]

• As a safety measure create a new superadministrator user in place of admin, name it something different and set a complicated random password. After this remove the original admin user.

Ok, we now have a fairly secure Joomla installation so we will move on to the server configuration.

We will not go into details, be sure to follow the usual rules of configuring a secure LAMP server. There are though a couple of particular issues:

• Be sure that you use a mysql user that only has access to the demo site database and nothing more

• Have the Joomla code and folders made read-only to the apache user (only leave write access to the cache and tmp folders) This will prevent the installation of extensions even if the user manages to bypass the build in security.

• Disable potential dangerous features in php.ini:

allow_url_fopen = 0

allow_url_include = Off

disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open

Reset demo site at regular intervals

The source folder from which we reset the code is not accessible from apache. Set it outside the document root. Also be sure not just to overwrite but also remove files not found in the source, otherwise one attacker could leave files on the demo server for later use.

After you reset the files reset the database as well. Set-up a cron job (belonging to another user, not apache) to do the above at regular intervals.

Be sure to keep the Joomla version up to date and check the logs from time to time, set-up other monitoring tools to be sure that you catch any unexpected security breach.

To reset the code and database, we use a simple system, comprised of different scripts:

demo-sync-code.sh that syncs the local copy of the code with the one jenkins builds for us.

# cat demo-sync-code.sh

#!/bin/bash

# syncs with the automated jenkins build

SOURCE='jenkins@ZAC1D07REL:/app/demos/flexile1/' # note the trailing slash!
DESTINATION='/app/demosource/code/'
EXCLUDE='/app/scripts/demo-sync-code-exclude.txt'

# r = recursive; a = archive and will attempt to set weird permissions
rsync -rz --delete --exclude-from=$EXCLUDE $SOURCE $DESTINATION --progress

# Ensure correct permissions will be propagated
find $DESTINATION -type f -exec chmod 644 {} ;
find $DESTINATION -type d -exec chmod 755 {} ;

# Apache only needs read access
chown -R root.apache $DESTINATION
# though it needs to be able to write here
chown -R apache $DESTINATION/tmp
chown -R apache $DESTINATION/logs

Let’s take a look at the exclude file:

# cat demo-sync-code-exclude.txt

configuration.php

installation/

Simple enough we don’t copy over the configuration.php configuration file and the installation folder. Next script used is demo-reset-code.sh that resets the code for one environment using the synced source above and a skel folder (that holds files particular to the environmnet, right now configuration.php)

# cat demo-reset-code.sh

#!/bin/bash

SOURCE='/app/demosource/code/'
SKEL='/app/demosource/skel/'

DESTINATION=( /app/htdocs/flexile.jentla.com/demo1 /app/htdocs/flexile.jentla.com/demo2 /app/htdocs/flexile.jentla.com/demo3 )

if [ $# -ne 1 ]; then
    echo "Please specify the env. number (1..n) or all"
    exit 1
fi
if [[ $1 != 'all' ]]; then
    if [[ $1 -gt ${#DESTINATION[*]} ]] || [[ $1 -lt 1 ]]; then
        echo "Environment number must be between 1 and ${#DESTINATION[*]}"
        exit 1
    fi
fi

case $1 in
    all)

for dst in ${DESTINATION[*]}
do
    echo -e "Overwritting $dst ..."
    rsync -az --delete $SOURCE $dst
    echo -e "Copying files from $SKEL`basename $dst` to $dst/"
    /bin/cp -fr $SKEL`basename $dst`/* $dst/
    echo -e " done!n"
done

        ;;
    *)

    echo -e "Overwritting ${DESTINATION[$1-1]} ..."
    rsync -az --delete $SOURCE ${DESTINATION[$1-1]}
    echo -e "Copying files from $SKEL`basename ${DESTINATION[$1-1]}` to ${DESTINATION[$1-1]}/"
    /bin/cp -fr $SKEL`basename ${DESTINATION[$1-1]}`/* ${DESTINATION[$1-1]}/
    echo -e " done!n"

        ;;
esac


We need a similar script that will reset the database of an environment:

# cat demo-reset-dbs.sh


#!/bin/bash

# Reloads DB's for the flexile demo sites

SOURCEDB='/app/demosource/db/flexdemo.sql'
DESTDB=( flexdemo01db flexdemo02db flexdemo03db )
# order the above array with the db's of demo1 .. demon

MYUSER='****'
MYPASS='******'

if [ $# -ne 1 ]; then
    echo "Please specify the env. number (1..n) or all"
    exit 1
fi
if [[ $1 != 'all' ]]; then
    if [[ $1 -gt ${#DESTDB[*]} ]] || [[ $1 -lt 1 ]]; then
        echo "Environment number must be between 1 and ${#DESTDB[*]}"
        exit 1
    fi
fi

case $1 in
    all)
        for db in ${DESTDB[*]}
        do
            echo -e "Importing $SOURCEDB to $db ..."
            mysql -u $MYUSER -p$MYPASS $db < $SOURCEDB
            echo -e " done!n"
        done
        ;;
    *)
        echo -e "Importing $SOURCEDB to ${DESTDB[$1-1]} ..."
        mysql -u $MYUSER -p$MYPASS ${DESTDB[$1-1]} < $SOURCEDB
        echo -e " done!n"
        ;;
esac


For ease of use we also have a master script running the two above (so we can reset an environment completely)

# cat demo-reset-env.sh

#!/bin/bash

LOGFILE='/var/log/demo-env.log'
UPDATECODE='/app/scripts/demo-sync-code.sh'
ENVPATH='/app/htdocs/flexile.jentla.com'
ENVNO=3

if [ $# -ne 1 ]; then
    echo "Please specify the env. number (1..n) or all"
    exit 1
fi
if [[ $1 != 'all' ]]; then
    if [[ $1 -gt $ENVNO ]] || [[ $1 -lt 1 ]]; then
        echo "Environment number must be between 1 and $ENVNO"
        exit 1
    fi
fi

# Check if the log file exists

if [ ! -f $LOGFILE ]; then
    echo "Creating logfile at $LOGFILE"
    touch $LOGFILE
fi

echo -e "Resetting $1 at `date`" >> $LOGFILE
echo -e "Updating the code from build server" >> $LOGFILE
eval $UPDATECODE

case $1 in
    all)
        /app/scripts/demo-reset-code.sh all >> $LOGFILE
        /app/scripts/demo-reset-dbs.sh all >> $LOGFILE
        ;;
    *)
        /app/scripts/demo-reset-code.sh $1 >> $LOGFILE
        /app/scripts/demo-reset-dbs.sh $1 >> $LOGFILE
        ;;
esac

Why use different scripts when simply one could do the job? Well because for once you might want to manually reset an environment (or only it’s code or database) and we wanted the sync from Jenkins separated so that resetting the environment will continue to work if for some reason the source cannot be synced with the Jenkins server. And last but not least because it’s easier to maintain and add features in the long run.

The demo-reset-env.sh script is called from crontab to reset environments every hour but at different times.

All done! We have now made sure that each environment gets cleaned up using sources inaccessible to outside users once per hour.

Conclusion

Using this tutorial you can quickly and easily make a website demo if you have a Joomla extension that you want to show online. There are minor changes to be completed by you, like changing the repository path of your extension or the paths to the bash scripts. Have fun!