Backups and Upgrades

Tutorials / Administration

Prerequisites

Apache 1.3 or 2.0

The differences between the two versions are that some compiling and configuration options have changed. The one specifically related to Sitellite is that Apache 2 requires a new "AcceptPathInfo" setting set to "On".

The other setting that can affect Sitellite is the "AllowOverride" setting. Usually, we simply recommend it be set to "All", which gives us more options in the .htaccess files used by Sitellite. However, we'll also be looking at the possibility of inlining the .htaccess settings into the main Apache configuration and turning .htaccess off completely, which I've seen improve the performance of Apache by up to 20%.

PHP 4.3

We recommend new sites use PHP 5 wherever possible, because PHP 4 will be officially unsupported by the PHP development team by the end of 2008.  If PHP 4 is your only option, Sitellite runs just fine in PHP 4.3 or greater.

The key to the PHP installation is that it be installed as both an Apache module (ie. mod_php) not as a CGI binary, and also as a command-line utility.  FastCGI is also supported in the latest Sitellite releases.  This last option is the default since 4.3, so we shouldn't have to worry about that.  Usually all we need to do is add the following switch to the "configure" line when compiling PHP:

./configure --with-apxs=/usr/local/apache/bin/apxs

MySQL 3.23 or greater

As of this writing, MySQL 5.0  is the latest stable version of MySQL.  Sitellite works with all versions of MySQL from 3.23 on, however I do recommend keeping up to date with MySQL upgrades for the best performance and security.

Configuring Sitellite

Basic installation

A basic Sitellite installation begins with unzipping the Sitellite tarball into the document root of the web site, and copying its contents, including the .htaccess file (which is often missed), into the document root. 

mysql -p -u root
(enter password)
mysql> create database DBNAME;
mysql> grant all on DBNAME.* to USER@localhost identified by 'PASS';
mysql> flush privileges;
mysql> quit

The Sitellite web installer will create the necessary database tables, however make sure you save your database connection info, which you'll need to provide during the Sitellite installation.

chmod -R 777 cache
chmod -R 777 inc/app/cms/conf/services
chmod -R 777 inc/app/*/conf
chmod -R 777 inc/app/*/data
chmod -R 777 inc/app/*/lang
chmod -R 777 inc/conf
chmod -R 777 inc/data
chmod -R 777 inc/html
chmod -R 777 inc/lang
chmod -R 777 install
chmod -R 777 pix
chmod 777 inc/app/*

After setting the folder permissions, you're now ready to launch the Sitellite Web Installer by pointing your website to "/install/" at your website, for example:

• http://www.example.com/install/

Follow the steps of the installer and enter the database info when requested and you should end up with a fully running copy of Sitellite at the end of it.

The Task Scheduler

Sitellite has a "scheduler" utility that can be used in conjunction with cron, or called manually, to run tasks in Sitellite from the command-line.

cd /PATH/TO/SITELLITE
php -f index scheduler-app

Sitellite Scheduler

Abstract:

    Provides a command-line interface to execute scheduled actions in
    Sitellite.  Relies on Cron, At, or other system schedulers to
    provide the timing capabilities.  This scheduler simply provides
    the entry point, security wrappers for scripts, and error logging
    capabilities.

Usage:

    From the command-line:
    bash$ cd /PATH/TO/SITELLITE; php -f index scheduler-app help

    From a Cron script:
    0 0 * * * cd /PATH/TO/SITELLITE; php -f index scheduler-app all

Options:

    NONE        Prints this help info
    help        Prints this help info
    TASK        Execute the specified task
    all         Execute all of the tasks in succession

Tasks:

    documents
    flushqueue
    googlesitemap
    jabbercheck
    mailcheck
    scanner
    siteinvoice
    sitesearch

Examples:

    Print this help:
    php -f index scheduler-app

    Execute the sitesearch task:
    php -f index scheduler-app sitesearch

    Execute all tasks:
    php -f index scheduler-app all

0 0 * * * cd /PATH/TO/SITE; /usr/bin/php -f index scheduler-app documents
0 1 * * * cd /PATH/TO/SITE; /usr/bin/php -f index scheduler-app flushqueue
0 2 * * * cd /PATH/TO/SITE; /usr/bin/php -f index scheduler-app sitesearch

The Scheduler Log

2008-07-26 19:15:46 (documents) Error: Error message here.

You'll find all of Sitellite's configuration options under the Control Panel tab in the Admin menu. This includes:

• Access Levels
• Activity Log
• Applications
• Cache Settings
• Preferences
• Resources
• Roles
• Site Settings
• Statuses
• Teams
• Users
• Workflow Services

Access Levels

Sitellite comes with 4 built-in access levels, which cover the basic levels needed by most websites. It is a good idea to keep these and simply add your own instead of deleting the ones there, since ones like "public" and "private" are used to determine the visibility of pages and other content items.

The 4 built-in access levels are:

• member – For member-only content areas
• private – For admin-only content areas or applications
• public – For any users including anonymous visitors
• subscriber –For paid site members

Activity Log

The activity log provides a view of all of the editor activity on the site. This includes login and logout times, adding, editing and deleting content, and error messages. The data logged for each log entry includes:

• Date/Time
• Action (Login, Edit, etc.)
• Username
• IP Address
• Message

You can browse the log by action type, username, and date, including day, week, month, and year date ranges.

Applications

The applications screen contains a list of all available apps installed on the Sitellite framework. Applications that are editable have an edit icon next to them which brings up a settings form for that app, and add-on applications can be enabled/disabled in a single click.

You can tell at a glance which apps are enabled because the disabled apps are greyed out. Core apps can't be disabled because their functions may be relied on by other apps as well.

Cache Settings

Sitellite's caching abilities are fairly robust, but by default all caching is disabled. For storage, Sitellite by default uses files in the "/cache/" folder in the filesystem, and keeps a list of cached files in the "sitellite_cache_file_list" database table. The cache can also be configured to simply output the proper HTTP headers for use with 3rd party cache/proxy servers.

Additionally, Sitellite has independent caches for database queries and for the site menu hierarchy. Typically, enabling just the menu cache can yield good results on moderate-to-large-size websites with many pages. To enable any of the cache types, simply enter a number of seconds in its duration field. We recommend 1 hour as a good starting point, but that depends on the frequency of updates to your site.

You can also control which URLs can be cached and which can't be. The cacheable URLs should contain a list of URLs followed by an "=yes" or "=no" to denote whether that URL is cacheable. URLs can also contain an asterisk (*) to denote a wildcard match.

/index/*-action = no
/index/*-form = no
/index/*-app = no
/index/news-app = yes
/index/news-*-action = yes

Preferences

The preferences contain a list of user preference settings Sitellite offers, such as language or default view (Web View or Control Panel). These are not typically edited except in very custom situations.

Resources

Resources is a list of elements that user roles can be restricted from. Resource types include apps, content collections, as well as custom resources you can define for use in your own apps. This list then appears under the Resources tab in the Add/Edit Role forms.

If there is no resource defined for a collection or app, Sitellite assumes site editors should be granted access to it by default. If an app or collection needs to be restricted but doesn't have a resource defined, such as a custom collection or app, simply add one to this list and you will be able to control access to it on a role-by-role basis after that.

When adding resources, if their system name begins with "app_" then that tells Sitellite that the resource is an app. For collections, Sitellite then matches it against the list of collection definitions in the "inc/app/cms/conf/collections" folder. If no matching collection is found, the resource is considered custom.

Roles

Each user in Sitellite belongs to exactly one role, and one or more teams. The role defines all of the access levels, statuses, and resources that the user can access.

So for example a "writer" role may be able to read and write to the "draft" access level, but only read from the "approved" access level. This means that the writer can't approve their own changes. An "editor" role would be needed for that.

With resources, the writer can be restricted from certain content collections and apps, but not others.

Built-in Roles

There are nine built-in roles, but five of them are the most commonly used, and all of them are fully customizable to suit the needs of your site. The main five are:

•  master – A role allowing access to everything, typically reserved for the person responsible for the site settings. This role is also often used on smaller sites with only one site editor.
• writer – A writer can create changes to content that require the approval of an editor. This role works with Sitellite's default workflow notifications to trigger emails to an editor user from the same team.
• editor – An editor can approve changes from writers or make their own approved changes directly to the live site. This role also works with Sitellite's default workflow notifications and receives emails when a writer marks a change with a "pending" status.
• member – A non-administrative role used for membership services on the site itself.
• translator – A role used for translators of content on multilingual sites. This role works with the default workflow notifications and receives emails when content in the default language is approved by an editor on the same team.

Site Settings

The site settings allow you to update the core behaviour of Sitellite. These are broken down into five sections:

• Database – The MySQL database connection settings.
• Site – The domain, document root and basic site behaviour.
• Server – Settings affecting the behaviour of the Sitellite Content Server, including the default handler (web page or box), error handler, template set, and output compression (gzip).
• Internationalization – These settings determine how Sitellite's multilingual capabilities behave, including how the language of the current visitor is determined (from their browser settings, a session cookie, a "/fr/" prefix in the URL, or from their Sitellite preferences).
• Messaging – The email and Jabber (aka XMPP) server connection settings, for workflow notifications and other message forwarding.

Statuses

Statuses determine the lifecycle stage of a content item such as a web page or news story. The status list is fully customizable, but we recommend against removing the statuses that are in place and simply to add new ones for your workflow requirements.

There are 6 built-in statuses:

• approved – A document that has been approved and is visible on the public website.
• archived – A document that is no longer visible on the public site, but can still be accessed in the system.
• draft – A document that is in progress and not yet ready to be published to the website.
• pending – A document that is ready for editorial approval and publishing on the live website.
• queued – A document that has been approved for publishing to the live site at a future date. The document queue is published by Sitellite's task scheduler, which can also automatically archive documents after a certain date/time as well.
• rejected – A document that needs further changes before it can be reviewed for publishing again.

In Sitellite Professional Edition, there is also a "parallel" status for performing A/B or Multivariate testing. Setting an approved page to "parallel" will allow the site editors to create multiple concurrent live versions of a page and have Sitellite test them against live visitors. Sitellite requests a URL from the page that is to be the goal that you want to direct users towards, and will then measure which version causes the best conversion ratio.

Teams

Teams break up content into groups of site editors who can perform their various roles on particular pages of the site. Each content item is owned by a team, and the users belonging to that team are responsible for that content item.

On smaller sites, typically everyone belongs to the same team and all content is owned by that team, but for larger sites teams can be used to separate the workflow of multiple groups of writers, editors and translators.

There are 5 built-in teams, and these are fully customizable. Typically, non-admin-level users such as site members belong to the "none" team, and on smaller sites the admins would belong to "core". The others are meant to serve as examples.

• core
• design
• editing
• none
• development

Users

The user list includes both admin and non-admin users, e.g., site members or subscribers. These are all managed in the same place and use the same authentication system in Sitellite.

You can add, edit, and delete users from the user list as well as search for them by name, role, and several other properties. You can also export the users in comma-separated values (CSV) format for use in external applications such as a CRM tool or contact database.

Workflow Services

The workflow services page contains a list of all workflow services defined by the various applications installed in Sitellite. These are triggered by certain actions in the system, from adding, editing or deleting a document to logging in or out of the software.

The default services that are enabled activate the activity log and the workflow notifications, and update links and child pages in the site tree when pages are deleted or renamed. It's a good idea to leave these services enabled.

Additional services cover resetting the cache on page edits, search indexing and more.

There are many ways you can optimize your server setup, depending largely on the traffic level of your website, and the types of services being offered. These range from caching solutions to load balancing and clustering database servers to offsetting files onto services like Amazon S3.

There are also tools like the YSlow Firefox extension which can help optimize your website load time. There's a lot you could write about each of these tools and techniques, which are outside of the scope of this lesson. Here we'll simply cover a few common ways of improving the server environment itself to make Sitellite work as efficiently as possible.

Optimizing the Apache Web Server

Several popular ways of improving Apache's performance include:

• Eliminating unused Apache modules, which reduces the amount of stuff loaded into the web server.
• Some people recommend recompiling Apache with the modules loaded statically instead of dynamically, however this has certain drawbacks to it as well.
• Turning .htaccess off and putting any .htaccess directives directly into the main Apache configuration file(s).
• Compiling Apache with architecture specific optimizations at compile-time.
• Optimizing the number of starting processes and the min/max processes based on how much traffic your web site sees.
• Reducing the KeepAlive time of dynamic scripts can also help.

<Directory /PATH/TO/SITELLITE>
	<Files index>
		ForceType application/x-httpd-php
	</Files>
	<Files sitellite>
		ForceType application/x-httpd-php
	</Files>
	DirectoryIndex index index.html index.php
	AddType text/html .tpl
	php_flag short_open_tag off
</Directory>

<Directory /PATH/TO/SITELLITE/inc/data>
	Order allow,deny
	deny from all
</Directory>

The actual contents of the inlined contents will depend on the actual contents of each .htaccess file, for example the mod_rewrite parts in the global .htaccess file in Sitellite's document root.

cd /PATH/TO/SITELLITE
find . -name .htaccess -print

Optimizing PHP

The best way to optimize PHP is to install a code-level cache, which doesn't affect the way PHP scripts function at all, but can improve the performance of PHP code by several hundred percent in many cases, by moving it to RAM instead of reading it from the server's hard drive for every page request.

pecl install apc

extension="apc.so"

Then restart Apache and you should have APC cache installed and running.

Optimizing MySQL

I won't go into detail on the many ways you can optimize a MySQL database installation. Instead, here are a few good starting points:

• http://dev.mysql.com/tech-resources/presentations/presentation-oscon2000-20000719/ 
• http://forums.theplanet.com/lofiversion/index.php/t20983.html
• http://rudd-o.com/archives/2006/03/02/tuning-a-mysql-server-in-5-minutes/
• http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html

Operating System

Security at the operating system level consists of the following general areas:

Keeping the system up to date

This simply means applying patches provided by your operating system vendor. Appropriate preparations should always be done first to ensure that patches don't break running applications and services. We prefer Debian-based servers and use the apt-get tools for managing our own servers.

Keeping installed software up to date

Software providers will provide updates and security patches from time to time, which should be applied to the server regularly. On Debian, apt-get helps make this a highly manageable process.

Controlling access to the server

There are several ways to restrict access ot the server. For starters, services that are not in use should be disabled. Services that are in use usually allow you to control who has access to them. For example, you may want to restrict MySQL access to the server itself only, if it only needs to be accessed by the web applications themselves. Or if you do need remote MySQL access, you can enable it on a per-IP basis.

The other way of controlling access is by using a firewall. A firewall can be a good secondary way of ensuring that services that shouldn't be accessible are indeed inaccessible. iptables is another popular tool for configuring access to a server.

Apache

Apache is a highly configurable web server, which can make it a challenge to secure. The general rule of thumb in configuring Apache is to turn off any features you don't need. For example, if you're not using WebDAV for anything, it is a good idea to not only disable the mod_dav extension, but to simply not install it at all. And if all your applications are in PHP, then there's no need to also enable CGI support. This way, there are less places a potential security flaw can occur.

Another option that can add a little security-through-obscurity (STO) to your environment is to hide the fact that you're using Apache. You can do this by not specifying your web server at all, or by specifying a different web server altogether (ie. lying). While it's not something to depend upon in and of itself, STO is a good idea as an extra measure of defense. STO makes it more difficult for potential hackers to accurately profile your web site. Profiling a site is the process of discovering and documenting everything they can find out about your server environment so that they can go back and formulate an attack plan.

To hide your web server from web clients, see the following settings in the Apache documentation:

• http://httpd.apache.org/docs/mod/core.html#serversignature
• http://httpd.apache.org/docs/mod/core.html#servertokens

ErrorDocument 403 /index/myapp-error-action?code=403
ErrorDocument 404 /index/myapp-error-action?code=404

For more information on the ErrorDocument setting:

• http://httpd.apache.org/docs/mod/core.html#errordocument

Another Apache security consideration is encryption. Ordinary HTTP web site requests are sent across numerous relays on the Internet with no prevention of any one of those relays from snooping in on your communication. Configuring Apache's mod_ssl module to enable Secure Socket Layer (SSL) support allows you to encrypt communication sent between your browser and the server, preventing the possibility of snooping (or at least making it much more difficult). For more info, check out the official mod_ssl web site:

• http://www.modssl.org/

It's also a good idea to disable directory listings, so that directories without index files show a 403 Forbidden notice instead of a list of available files. This can be changed via the following setting:

• http://httpd.apache.org/docs/mod/core.html#options

Options -Indexes

Additional Apache security tips are available here:

• http://httpd.apache.org/docs/misc/security_tips.html

PHP

PHP has had a mixed track record of security. Several of its early features, such as the register_globals setting, turned out to be security hazards and are now disabled by default (and some are slated for removal entirely in upcoming versions).

Another reason PHP has historically had a bad reputation for security is that it drastically lowered the bar for web application development, enabling many inexperienced people to create web apps they couldn't before. This lead to many apps becoming popular that were written essentially by amateurs and hobbyists, who didn't have any background in security.

Many security issues also arose after the fact as new techniques in web development created new possibilities for attackers as well, such as cross-site scripting attacks.

But both PHP and its developer community have matured over the years and in the right hands PHP can now be considered to be just as secure as any other language or platform. It simply depends on the software you run on it, the server environment its run on (e.g., shared versus dedicated hosting), and the experience level of the developers writing software for it.

Shared hosts will always be inherently less secure than properly managed dedicated servers, simply because you don't control the entire machine. While there are steps a host can take in minimizing the possible issues, security in a shared environment can never be 100%.

Instead of highlighting one or two individual configuration options such as open_basedir, expose_php or safemode, it would be better to simply point you to some resources for further research into securing PHP:

• http://www.php.net/security-note.php
• http://www.php.net/manual/en/security.php
• http://phparch.com/c/books/id/0973862106
• http://phpsecurity.org/
• http://phpsec.org/library/
• http://phpsec.org/projects/phpsecinfo/

MySQL

The general principles of limiting access to applications and services on the server are one of the key MySQL security consideration. This is done in two ways with MySQL.

bind-address = 127.0.0.1

mysql -u root

If you are not rejected, you need to set the root password. Additionally, you can restrict user accounts based on hostname and which database(s) they can access. For more info, see:

• http://dev.mysql.com/doc/mysql/en/Default_privileges.html
• http://dev.mysql.com/doc/mysql/en/Privilege_system.html

port = 3306

A second MySQL security consideration is to ensure that MySQL is running as the recommended "mysql" system user, and not as "root". This is similar to Apache running as "nobody", and is a common security precaution used to prevent server-side daemons from becoming loopholes for hackers to gain access to the rest of the server.

For complete MySQL security information, see:

• http://dev.mysql.com/doc/mysql/en/Security.html

Sitellite

send_version_header = off

error_reporting = "E_NONE"

File Permissions

A general rule for managing file ownership is to grant only as much ownership as necessary, and no more. For example, if you need permission to write to the cache and inc/data directories of your Sitellite installation, don't simply execute a "chmod -Rf 777 *" from the web server root.

Components to Back Up

The main components to consider when backing up a Sitellite installation are the database and the files. So packaging up a backup requires first that you export the MySQL database to a file that can be backed up with the rest of the files.

Simple Backup

cd /PATH/TO/SITELLITE
mysqldump --password='PASS' -u USER DBNAME > backup.sql
tar -cf backup.tar .htaccess *
gzip backup.tar
cp backup.tar.gz /PATH/TO/BACKUPS
rm -Rf backup.sql backup.tar.gz

0 4 * * * /home/USER/bin/backup.sh

Backups with RSync and SSH

My preferred backup method for our sites is to use rsync and SSH to perform the backups. Backing up a gzipped file is okay because the resulting file is stored efficiently, but rsync only backs up the changes made to files since the last backup, so it's better on bandwidth which can add up over time. In this example, rsync is also tunnelled through SSH so the data is sent securely.

To setup rsync securely, you first have to generate and exchange SSH keys between the live and backup servers.

ssh-keygen -t dsa -b 1024 -f /home/USER/rsync-key

scp /home/USER/rsync-key.pub remoteuser@backupserver:/home/remoteuser/

if [ ! -d .ssh ]; then mkdir .ssh ; chmod 700 .ssh ; fi
mv rsync-key.pub .ssh/
cd .ssh/
if [ ! -f authorized_keys ]; then touch authorized_keys ; fi
chmod 600 authorized_keys
cat rsync-key.pub >> authorized_keys

from="1.2.3.4" ssh-dss ...

ssh -i /home/USER/rsync-key remoteuser@backupserver

#!/bin/sh

# the path to the sitellite installation
SITE="/PATH/TO/SITELLITE"

# the IP address of the backup server
RMACHINE=1.2.3.4

# the username on the backup server
RUSER=USER

# your rsync SSH key on the live server
RKEY=/home/USER/rsync-key

# the target folder on the backup server
RTARGET="/PATH/TO/BACKUPS"

# edit the USER, PASS and DBNAME here as well
mysqldump -A -f -u USER --password="PASS" DBNAME > $SITE/.htbackup.sql
gzip -f $SITE/.htbackup.sql

if [ ! -f $RKEY ]; then
  echo "Couldn't find ssh keyfile!"
  echo "Exiting..."
  exit 2
fi

if ! ssh -i $RKEY $RUSER@$RMACHINE "test -x $RTARGET"; then
  echo "Target directory on remote machine doesn't exist or bad permissions."
  echo "Exiting..."
  exit 2
fi

if ! ssh -i $RKEY $RUSER@$RMACHINE "test -d $RTARGET/$SOURCE"; then
  ssh -i $RKEY $RUSER@$RMACHINE "mkdir -p $RTARGET/$SOURCE"
fi

rsync -a --delete -e "ssh -i $RKEY" $SOURCE/ $RUSER@$RMACHINE:$RTARGET/$SOURCE/

rm $SITE/.htbackup.sql

exit 0

Using the same cron entry as before, your site should now automatically backup via rsync over SSH nightly at 4am.

Upgrading Sitellite

First, back up your site. Never attempt to perform an upgrade without first backing everything up. It's also a good idea not to perform the upgrade on a live site directly, but rather to set up a duplicate test site and use that to perform the upgrade, in case something goes wrong.

Upgrading Sitellite is a mostly manual process, but first, you'll need to check which version of Sitellite you're running by going to the Control Panel > Tools > Upgrade Utility. The current version is printed on the main screen of the upgrade utility. You'll need to remember this for later, so it may be good to write it down.

In this lesson, we're going to install the upgrade in a separate location, then move it over once the upgrade process has been completed and the new site has been tested. Because of this, upgrading will require a separate website root on the same server as your website, as well as a separate temporary MySQL database. We usually recommend using a subdomain (ie. upgrade.yourwebsite.com) for the temporary upgrade spot.

Taking Stock

inc/app/news/conf/properties.php - News section configurations
inc/app/myapp - Custom code for this site
inc/app/siteevent/conf/properties.php - Event listings configurations

Places to look for custom settings and other customizations include:

1. inc/app - Custom apps may reside here (ie. "myapp")
2. inc/app/*/conf/properties.php - Application-specific settings
3. inc/app/*/data - Data specific to an app (not all apps have this, but some do including SiteBanner, SiteConnector, and SiteSearch)
4. inc/app/*/lang - Translation files for individual apps
5. inc/app/cms/conf/collections - Custom collections (ie. content types)
6. inc/app/cms/conf/services - Custom workflow services
7. inc/app/cms/data - Version history for Web Files collection
8. inc/conf - Global configurations
9. inc/data - Web Files data storage
10. inc/html - Custom template sets
11. inc/lang - Global translation files
12. inc/sessions - Session/authentication configurations

Note: This step is something you'll only have to do the first time (or something you can do as part of the process of building your initial site), and can be reused with minor updates over time as your site is extended or modified. It also serves as useful documentation for your development team.

It's also a good idea at this time to read through the change log and make note of any changes that may affect your website based on your system configuration (Apache/MySQL/PHP versions, etc.) and which apps your website makes use of. This is found in the file install/changes.txt or through the Control Panel under Tools > Upgrade Utility.

Install the Upgrade

Install the new download of Sitellite as a secondary site. Sitellite upgrades come as a full copy, not as a patch for your existing version. Only the database and your data/customizations are preserved from your existing installation, so nothing on the site is lost but you can't simply "drop in" the upgrade -- you need to install it in a secondary location.

Do not simply replace the old site with the new installation, this will overwrite existing data. See Sitellite installation instructions for this. Please note that you will need a secondary temporary web space and an additional temporary MySQL database for this step. Most modern website hosts provide sufficient space and features that this should not be an issue.

Copy Settings/Customizations

Once you have your new Sitellite installation of the latest release up and running, now you will need to copy your existing website settings over, including templates and database settings, to the new site. These were collected in step 1.

cp -R /path/to/old_site/inc/data/* /path/to/new_site/inc/data/
cp -R /path/to/old_site/inc/app/cms/data/*
  /path/to/new_site/inc/app/cms/data/
cp -R /path/to/old_site/inc/app/cms/conf/collections/*
  /path/to/new_site/inc/app/cms/conf/collections/
cp -R /path/to/old_site/inc/app/cms/conf/services/*
  /path/to/new_site/inc/app/cms/conf/services/
cp -R /path/to/old_site/inc/html/my_template_set
  /path/to/new_site/inc/html/
#etc.

For individual files such as your global configurations and properties.php files from individual apps, you should compare them to the new ones before simply copying the old ones over, since new properties may have been added to these files between releases.

For files modified from the original source code, you may need to compare the two versions of these files using a utility such as diff which will highlight the differences and allow you to merge them to produce a new current version with the upgrade modifications as well as your own. For more info about this, please see below under "Patching Modified Files".

Upgrade Utility

Now log into the new Sitellite website and go to Control Panel > Tools > Upgrade Utility. From here, click on the "Apply the 4.x.x upgrades" link. This will perform any necessary database and other automated updates.

Testing

You should now have a fully working copy of your website running on this new copy of Sitellite. Make sure you test everything to make sure it works. When you've finished testing it, you should be safe to replace your existing website with this new one.

Some places to be sure to verify things are correct include:

• All public-facing applications and pages
• Control Panel > Admin > Site Settings
• Control Panel > Admin > Workflow Services
• Admin login and member login facilities
• Basic editing functions

Patching Modified Files

diff -c /old_site/some_file.php /new_site/some_file.php > diff.txt

patch -i diff.txt

diff -cr /old_site /new_site > diff.txt

cd /old_site
patch -i ~/diff.txt

For more info on comparing and patching files usind diff and patch, see A Short Introduction to GNU Diff and Patch.