Chapter 6. Configuration
The centralized managing of the configuration of different servers is not a trivial problem to be solved and if implemented in the wrong way, it could make administrators think they have lost control of the servers and of what they do: if automatisms are ill defined and not too transparent, the risk is they hinder the administrators' attempts to interpret any possible problems. On the other hand, the automatic managing of the servers configuration is also an excellent possibility to manage a complex structure using energies in an intelligent way (since they are not endless).
This chapter details the solution we have implemented and the way this solution interacts with the overall system. Understanding this mechanism is crucial if you want to know how to modify the servers configuration so as to have services do what you want them to.
6.1. Overview
The servers configuration is centralized and it is connected to different mechanisms allowing specific customizations. In particular we have decided to use CFengine to manage the simpler configuration files, that is files not depending on the users' data stored in the LDAP database, and customized scripts (the LDAP bindings for the various scripting languages are rather simple to be used) for the rest.
6.1.1. Database-independent configuration
CFengine has turned out to be a very useful tool, allowing us to create a management model based on the principle of the least differentiation possible among servers: configuration files are identical on each server, but it is possible to edit them with a series of simple substitutions . It is even possible to keep entirely different files for one or all boxes, as we will see below in this same chapter. This management model makes it quite easy to use very big configuration files with a lot of identical options and some options that need to be specified for each single server (for example the IP address bound to a service or to a hostname).
The centralized management of configuration files has to allow to keep track of the various modifications and of who made them, and it has to make them reversible.
That is why we have chosen to combine a version control system (as CVS, we are using Subversion) with which we manage a common repository that is then replicated on all servers: this means that one needs to modify files in a single place and that they will then be spread all over the servers to the right final destination, as determined by the CFengine configuration. At the same time, a copy of the original configuration is kept on each box so that it is possible to change very quickly the main server if needed. As a further backup, the Subversion server is also located on another box.
The picture below details through a diagram which is the exact place to modify files and what are the different mechanism the modifications are distributed through.
Configuration Data Flows
It is definitely better that files managed this way are the ones that in some way are different from a standard debian install, since it is unnecessary to manage the whole /etc tree.
A detailed explanation of the /configfiles directory is included in Section 6.2.1>.
6.1.2. Database dependent configurations
Some services have a configuration that depends on the data included in the users' LDAP database because it is impossible (or unpractical at least) for them to read the database content dynamically. An example is the web server: in this case we have chosen to simplify the database data structure (avoiding the use of mod_config_ldap that reads the apache directive directly from complex LDAP objects) in order to make the management of the data easier. However, this solution implies the creation of the Apache configuration file in some other way.
These files are then generated automatically with some script that can be found on each server in the /configfiles/scripts directory (we can also put them somewhere else, if we find a more intelligent place in the filesystem). These scripts read the LDAP database data and create the configuration files accordingly. Other actions are possible too: for example one could check the existence of directories in the filesystem and their permissions, or the same thing for mailbox Maildirs, or other similar administrative tasks.
The basic idea is that the LDAP database is the authoritative source for the system configuration and that the scripts simply translate this source of information in actual data in the filesystem and configuration files. This implies that, in order to modify the configuration files, it will necessarily modify the LDAP database (we will see later on in this document how it is possible to do such a feat!).