Archive for the ‘Apache2 web server’ Category

How to create a DokuWiki farm

February 13, 2018 Leave a comment

Let’s see how to install DokuWiki, create a farm of wikis and run it privately i.e. with our wikis not being reachable from the Internet.

I assume you have an Apache web server and PHP-7 running on your box. I’ve done my installation on a Ubuntu box.

Install the wiki

First we download the tarball from here and uncompress it. The result is a directory called dokuwiki. Then follow the steps:

$ sudo mv /home/vicent/Downloads/dokuwiki /var/www/dokuwiki
$ cd /var/www
$ sudo chown -R www-data:www-data dokuwiki
$ sudo a2enmod rewrite

Then, using /etc/apache2/sites-available/000-default.conf as a template, we create and enable the following virtual host (/etc/apache2/sites-available/dokuwiki.conf)

<VirtualHost *:80>
ServerName dokuwiki
ServerAdmin webmaster@localhost
DocumentRoot /var/www/dokuwiki
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

Then edit /etc/hosts and add the line: dokuwiki

and restart the Apache service:

$ sudo systemctl restart apache2

Finally run the installation script with the web browser:


Just fill the fields (it is pretty easy) and you are done 🙂 Now you can run your wiki at http://dokuwiki

About the farm

Suppose that you want to have a wiki for every member of your family (for instance you, your wife and your daughter). Of course you can do it simply creating and organizing properly pages on your wiki instance. But just for fun you can also create a farm of wikis with three independent wikis: one for you, one for your wife and one more for your daughter.

Let’s see how to manually set up a farm of wikis. Usually there is only one farm per server. The farm is made of a farmer (the actual DokuWiki installation, described in the previous section) and one or more animals (i.e. individual wiki instances). The setup of a farm directory is what is needed to start farming. Our setup will be:

/var/www/dokuwiki -> the dokuwiki engine
/var/www/farm -> the dokuwiki farm directory which contains the animals

In the farm directory we can have as many animals as we like:

/var/www/farm/wiki_1 -> one wiki
/var/www/farm/wiki_2 -> another wiki

There are two different setups: virtual host based and .htaccess based. We will use the first one. Its main advantage is that it can create much more flexible URLs which are independent of the underlying file structure. The disadvantage is that this method requires access to the the Apache configuration files.

Beware that in our case (a wiki running locally, not visible from the Internet) the mentioned advantage is not really important and the disadvantage simply doesn’t apply.

To access the farm from your local machine you have to edit the /etc/hosts file as described above

Create the farm directory

Create an empty directory named /var/www/farm. That will be the farm directory and needs to be writeable by the web server.

$ sudo mkdir /var/www/farm
$ sudo chown -R www-data:www-data /var/www/farm
$ sudo chmod -R ug+rwx /var/www/farm
$ sudo chmod -R o-rwx /var/www/farm

Activate the farm

This is easy too.

$ sudo cp /var/www/dokuwiki/inc/preload.php.dist /var/www/dokuwiki/inc/preload.php

Open that file, uncomment the two relevant lines and set the farm directory:

if(!defined('DOKU_FARMDIR')) define('DOKU_FARMDIR', '/var/www/farm');

Add an animal

Download the animal template and extract it in the farm directory. The archive contains a directory called _animal which includes an empty data and a pre-filled conf directory. Rename the directory. Beware that virtual host setup needs animal directory names that reflect their URL e.g. the URL works with a directory named

In your /etc/hosts file you should add the line

Virtual Host Based Setup

For this setup we create and enable a new site in /etc/apache2/sites-available for each new animal. For example for we will create the file with the following content:

<VirtualHost *:80>
ServerName # this is the URL of the wiki animal
ServerAdmin webmaster@localhost
DocumentRoot /var/www/dokuwiki # the document root always needs to be the DokuWiki *farmer* directory
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

Now you should be able to visit the animal’s URL e.g. and enjoy your wiki.

Change the admin password

As the animal template includes a default admin user account with the password admin we should change that password as soon as possible and change the admin’s email address too.

I will stop here but there are a lot of things that you can do now: setup ACLs, install plugins, create namespaces… Please visit the DokuWiki website. There you will find tons of info about everything.


About the .htaccess file

December 20, 2012 2 comments

Many of you have a fair idea of what an .htaccess file is and what can be done with it. In my case that knowledge was not very accurate so I decided to learn more and to write this brief introduction to the subject.

.htaccess files are hidden text files that contain Apache directives. They are hidden for most operating systems because of the dot at the start of its filename. And they are also hidden on the web because most Apache web servers are configured to ignore them.

.htaccess files provide a way to make configuration changes on a per-directory basis as opposite to a per-server basis. It means that, when an .htaccess file is placed in a particular document directory, the configuration directives contained in the file apply to that directory and all its sub-directories, overriding the setup of those directives in the main configuration files. We have to pay attention to this recursive mechanism because a given .htaccess can override some behavior defined in a different .htaccess placed higher in the directory tree hierarchy.

We said that normally .htaccess files are ignored by the web servers. Why does it happen? Well, .htaccess files are not recommended for several reasons, mainly performance and security.

First, everything that can be done with an .htaccess file can also be done with the main configuration files of the server so, in principle, is not a good idea to put .htaccess files here and there because it makes more difficult to know the real configuration of the server.

Second, if they are enabled, every time the server receives a request, it will look for .htaccess files in every requested directory and its ancestors, and will process the found files in order to know which directives it must override. No caching mechanism here, it happens every time a request is received. In contrast, the main configuration has to be loaded just once. Even worse, if you are using RewriteRule directives in your .htaccess file, then the regex are re-compiled with every request to the directory (the main server is much more efficient as it compiles the regex just once and caches them).

So in general .htaccess files should be avoided: anything that goes into an .htaccess file can go into the main configuration files (using the same syntax in most cases) and performs worse… but they exist for a reason.

A typical case in which .htaccess files are used is that of an ISP hosting multiple sites on a single machine. If the server administrator wants to give users (i.e., content providers) the possibility of changing the configuration of their site without having access to the main configuration files, then .htaccess files are the way to go (of course, it implies security risks because people other than the service administrator will be able to change part of the server configuration). Also many popular CMSs like WordPress, Joomla or Drupal use .htaccess files.

Just one more thing. In order to use .htaccess files, the AllowOverride directive must be set to something different than None. This directive determines which directives are allowed in the file so we have to setup it accordingly to our needs. If AllowOverride is set to None then the .htaccess files are not even read by the web server.

That’s all about it. I’m not going to talk here about all the sorcery and tricky things that you can do using .htaccess files (you can do the same than with the main configuration files and using the very same syntax in most cases). In future posts I’ll talk about using the mod_rewrite module in .htaccess files and how it differs from using that module in the main configuration files.