1.2. Guidelines

The configuration described in this document has been thought of and written along guidelines that we believe respond to the needs we have just stated above. We have defined such guidelines as follows:

• Many of our replication schemes require that one server takes on the role of master, however we want to be able to quickly change this master server with any other box: this is why the general server configuration (e.g.: the files in the /etc directory, the users database, the mailbox/ftp/website database, etc.) is replicated on each box. Defining the "master" is thus simply equivalent to labelling a server as such, which allows for a fast switch in case something bad happens.

• Sensitive data (essentially mailboxes and mailing lists) have to be distributed among the various servers. The split-up criteria may be random or load-bound, but since our focus is not on a load-balanced situation, it is up to the server managers to decide. In any case, the association between each mailbox and its specific server needs only to be changed in the database, so that it is possible to relocate mailboxes very quickly if necessary. Saving the data lost in the compromised box is not considered a priority.

• If such a network is to work correctly, the different servers need to be substantially alike, configured in the same way and freely exchangeable. This implies that they have to be managed centrally, possibly by the same group of people.

This document describes essentially three different but related things:

1. the configuration of the various communication services (mail, web, mailing lists), developed in order to distribute our users among different servers without assigning them different virtual addresses (i.e.: all mail addresses will be something like @domain.org and not @server1.domain.org, @server2.domain.org, and so on...). This will keep in our users the feeling of always being in contact with a single organization.

2. the implementation of a mechanism to centrally manage all these configurations -- this mechanism permits to handle configurations not on each single server but with a higher level of abstraction (so that managing the whole network should be easier than managing N single servers).

3. the tricks to make all communications anonymous while using this infrastructure.

Of course one can find several ways to do all the things described above, and we have just chosen one amongst many: we do not imply this is the best solution ever, or even that this is an example of good practice. Generally speaking, we are just explaining why we have chosen something, based on our collective experience and on our greater familiarity with some tools than with others.

All the software used in this document is Free Software (the whole infrastructure is based on Debian).

Each of the following chapters will introduce the configuration of a part of the infrastructure.