TDC: Test-driven configuration, the first steps

During TDD (Test-driven development) you have some kind of specifications that your new module needs to fulfill. Hence you know what functions need to be implemented and what kind of tests you need to write.

During TDC things are similar. You know the software you are going to install. Hence you know how this software works, what configuration is needed and what kind of features you and your users want to use in the beginning.

This results in a number of similar tests for each software.

1. In a first step you need to check whether …
   • … the binaries are available
   • … the common config files are available
   • … the directories are available
   • … all files and directories have the correct owner and access permissions

   In case you install a package from your distribution, a set of predefined config files should be included in the delivery and your test should be green immediately after installation.

   In case you do a manual installation you need to fiddle around with the configuration files. But as you thought before what config is needed, this task should be an easy one.

   These tests are not only important for the initial installation, but also later on, when you upgrade your system or just install a newer release.
   Often enough names of binaries have been changed (apache -> apache2), the path of config files has been changed, the name of the package has been changed ) or even some binaries are now part of a different package.

   If a test fails, you immediately know that something changed and your configuration (or only the tests) needs to be adapted.

2. If all files are in the proper place, in the second step you need to check whether their contents is fine as well. Some software has its own tool to check the config files.

   For example “apache2ctl configtest” does a syntax check of the Apache config. Nagios does such checks with “nagios -v nagios.cfg”.

3. The third step would be to check whether the newly installed software is running. You also need to check whether the correct number of processes is running. For example exim4 basically starts a process for each incoming email and normaly (at least in my case) there are up to five processes running. In case you have 128 exim4 processes running, this might be an indicator that there is something wrong with your incoming email.

As written in the previous article, I am doing configuration management with puppet, so the corresponding puppet module will appear in this repository.