If the server has no OS then download and install Debian first. Depending on the kind of access you have to the server and the kind of media it can accept, the following links may be of interest.
Debian Conversion- Change an existing Linux distro into Debian using only SSH access
Ensure that you're using the same package repository for your Debian installation as we are, your /etc/apt/sources.list file should contain the following:
deb http://ftp.us.debian.org/debian stable main contrib non-free
deb http://security.debian.org stable/updates main contrib non-free
If you are making a replica of or rebuilding a specific system, then unpack a recent www-yyyy-mm-dd.tgz backup into /var/www and remove specific wiki content.
7za x www-yyyy-mm-dd-tgz
tar -xf www.tar /var
If starting a new server from scratch, then the main two things required are /var/www/tools and /var/www/extensions, the other procedures for installing codebases and wikis will add everything else necessary.
Extensions and Tools
You can obtain the scripts and extensions from the OD subversion repository, and then add any additional extensions you need. Note that there are also a number of extensions we use which are in the Wikimedia repository, so it may be easiest to unpack our od-extensions.tgz extensions snapshot instead.
cd /var/www
svn co svn+od://USER@svn.organicdesign.co.nz/svn/extensions
svn co svn+od://USER@svn.organicdesign.co.nz/svn/tools
Note: you must add a tunnel into ~/.subversion/config with od = ssh -p 1729 since we use a non-standard SSH port
Snapshots are also available as gzipped tar files, od-extensions.tgz and od-tools.tgz. After you have a wiki daemon running, the extensions and tools will be automatically synchronised to Organic Design's current tgz snapshots. The wiki daemon executes update-extensions.sh and update-tools.sh in /var/www/tools, and these can be called manually from root at any time. Any content that exists in the local extensions or tools but not in the OD version will be left alone during updates.
Next create the wikia global configuration in /var/www/tools/wikid.conf used by both the wikia and robot framework. Start with the wikid.conf.sample file.
Starting a bot
Now the the config is in place, try running the bot with the --install directive so that it starts up automatically when the system boots. If not running on a GNU/Linux machine, you may be best installing ActivePERL which comes with all the necessary libraries and is available for most platforms.
/var/www/tools/wikid.pl --install
Testing the bot
Check if the bot is running with pgrep wikid, and check the log in /var/www/tools/wikid.log. If you're running an IRC channel, check that your bot is in there and notifying the channel when articles change properly etc.
MySQL
To activate the slow query log for mysqld, and ensure that it's optimised for low memory (innodb is not necessary for our scale of work and disabling it frees over 100MB of RAM), add the following to the [mysqld] section of the /etc/mysql/my.cnf file:
The differences to the default php.ini file in our servers are as follows:
max_execution_time = 300
memory_limit = 64M
log_errors = On
error_log = syslog
post_max_size = 100M
upload_max_filesize = 100M
extension = domxml
extension = fileinfo.so
Apache
First enable the modules we're going to need:
a2enmod ssl
a2enmod rewrite
In our typical Apache configuration we have a simple single virtual-host container (see sample.vhost in our tools repo) containing any site-specific domain rules, and includes common.vhost which is rules that apply across all servers, and wiki.vhost which is the rewrite rules for friendly URL's. To proceed with minimal changes to the Apache configuration, replace the existing default container content which is usually in /etc/apache2/sites-enabled/000-default. Outside the single container, other SSL virtual-host definitions can be included which follow the format defined in ssl-sample.vhost and are named by domain and put in /var/www/ssl (more about SSL configuration in the next section).
The common rules ensure that the webmail sub-domain always bounces to HTTPS and maps to /var/www/domains/webmail, and the sample files give examples of adding other sub-domains. The SSL common file and samples allows any number of domains to use HTTPS connections each having their own certificate file. All the sample and common virtual-host files are listed below with a short explanation:
sample.vhost- same Apache virtual-host definition file
common.vhost- common rules used by all non-SSL sites and domains
ssl-common.vhost- common rules used by all SSL sites and domains
ssl-sample.vhost- sample SSL virtual-host definition to be included from the main file
First we need to ensure that we have a valid SSL certificate for each domain that will be using SSL connections. The following commands are embedded from the generate a self signed certificate procedure, but this will raise the "untrusted secure site" error in the client browser. For sites that require a proper commercial certificate, use the generate a certificate request for a commercial Certificate Authority procedure instead.
Our convention is to keep all the certificates in /var/www/ssl along with the the SSL virtual host definition for the domain . First change the current directory to /var/www/ssl and create the certificate with the following command format. Ensure the common name (cn) is entered as a wildcard such as *.foo.com so that the certificate applies to all the sub-domains such as www.foo.com or webmail.foo.com etc.
Ensure that the resulting file is accessible by the web-server:
chown www-data foo.com.pem
Each secure domain will require virtual-host definition in a separate file in the /var/www/ssl directory and having the same file name as the domain name it applies to. These files can be based on the ssl-sample.vhost file from the tools repository.
All of the SSL virtual-host definition files need to be included from the main Apache site definition file which is usually /etc/apache2/sites-available/default. The sample.vhost file shows to example SSL domains being included at the bottom.
Check the apache config before reloading
apachectl -t
If everything is ok reload the server
/etc/init.d/apache2 reload
Check the error log for problems.
tail -f /var/log/apache2/error.log
If you see a message like this everything is ok.
[Sat Mar 14 11:32:18 2009] [notice]
Apache/2.2.9 (Debian) DAV/2 SVN/1.4.2 PHP/5.2.0-8+etch13 mod_ssl/2.2.9 OpenSSL/0.9.8g configured
-- resuming normal operations
If you see something like this you have problems:
[Fri Mar 13 21:46:54 2009] [error] SSL Library Error:
218529960 error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag
[Fri Mar 13 21:46:54 2009] [error] SSL Library Error:
218595386 error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error
Check permissions and paths of certs and keys. The server will be down now.
Comment the last ''Include'' from ''vhosts'' and ''/etc/init.d/apache2 start''.
Server will be up now with no ssl.
Domain names
Adjust the names of the symlinks in the /var/www/domains directory to local domain names and ensure that those names are added to the /etc/hosts file.
Note: If you're installing your wikia structure on a local machine, then you must ensure that your domains such as foo.localhost are set in /etc/hosts as aliases for 127.0.0.1
DNS: if you need to set up a DNS server or Dymamic DNS system, see Configure DNS
Extracting Databases from a Backup
Extract the most recent database backup (this may overwrite existing databases of the same names)
7za x all-yyyy-mm-dd.sql.7z
mysql -u root -p < all.sql
mysqladmin -u root -p flush-privileges
Setting up FTP access
Some clients may require standard FTP access which although not very secure, can have some restrictions put on it to make it a little safer such as restricting users to their home directories and using a non standard port. We use the GPL proFTPD server in standalone mode.
apt-get install proftpd
Edit the /etc/proftpd/proftpd.conf file and change the port to something other than 21 and add the following directive to restrict users to their home directories (or set it to a shared FTP directory).
DefaultRoot ~
Following Symlinks
Note that following symlinks is not supported if the DefaultRoot directive is used because the directive creates a "jail" preventing access to any directories outside of it. Some administrators have said that mount --bind can be used to achieve this but it hasn't worked for us as that seems to just create a normal symlink as well.
