Sitellite Server Administration
Chapter 1: Installing Sitellite
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.
From there, the MySQL database tables need to be created. If the database and database user also need to be created, you can say:
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
Next, you need to set the folder permissions so that the web installer can write to the necessary files. Use the following commands to do this:
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/
The Task Scheduler
To print out the help info for the scheduler, simply run the scheduler without specifying a task, like this:
cd /PATH/TO/SITELLITE php -f index scheduler-app
This outputs the following instructions:
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
While you can specify 'all' instead of an individual task, we recommend against it on production websites. It's better to be specific with the tasks you need to run, because you can enable/disable them individually, and because there is less overhead on the server from unneeded tasks. We recommend the following structure for task entries in cron. Note that each entry is offset by one hour to give the server ample time between tasks. Also note that the 'sitesearch' task is last, since it can run for a long time on large sites.
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
The task scheduler logs all output to the "inc/app/scheduler/log/scheduler.log" file, so any errors generated by a task will appear in that file. The format of the log file is:
2008-07-26 19:15:46 (documents) Error: Error message here.




John Luxford