Tag: Debian

Today I released v0.0.2 of my Puppet module puppet-tdc on puppetforge. This version now contains all the features that I mentioned in my first article about TDC.

Though having such a low version, I am using the module in production on my own servers now. I am sure one or another bug will appear but those will be only detected by testing :-). Maybe I also have to change the interface, so probably my old examples will be no longer working. The next steps will be the documentation and a first Debian package.

Anyway, this module does not only help to develop new classes with puppet, but also finds some mistakes that became forgotten. I intentionally avoided to automatically configure members of a new hostgroup in addition to the nagios services that I am going to test. So when adding TDC to the apache2 class, suddenly Nagios reported lots of unknown hosts. In this case I simply forgot to add them to the corresponding hostgroup for web servers and even forgot to monitor some hosts at all.

It again proves to be true that manually taking care of lists is really prone to errors.

The first module I want to develop with TDC is just a small one. I want to distribute email certificates obtained by Lets Encrypt to some email servers:

 class email_cert {

 }

I am using the puppet module puppet-tdc , that is at the moment only available on github.

The first things to add are some tests:

 class email_cert {
  class{'tdc':
  }
  class{'tdc::test_directory':
     directory    => ['/etc/email-cert'],
  }
  class{'tdc::test_file':
     file    => ['/etc/email-cert/mail-fullchain.pem', '/etc/email-cert/mail-privkey.pem'],
  }
 }

I am using the new class tdc and want to check whether the directory for the certificates is available and whether the certificates itself are there.

Great, after awhile my nagios shows lots of red stuff. Every server that uses my new class email_cert is automatically creating tests for nagios and distributes them. All of them fail.

So now it is time for the real data:

class email_cert {

  class{'tdc':
  }
  class{'tdc::test_directory':
     directory    => ['/etc/email-cert'],
  }
  class{'tdc::test_file':
     file    => ['/etc/email-cert/mail-fullchain.pem', '/etc/email-cert/mail-privkey.pem'],
  }

  file { [ '/etc/email-cert', 
         ]:
          ensure => 'directory',
          mode   => '750',
          owner  => 'Debian-exim',
          group  => 'nagios',
       }
  file { 'cert-fullchain.pem': 
         path    => "/etc/email-cert/mail-fullchain.pem", 
         ensure  => file, 
         mode    => '640',
         owner   => 'Debian-exim',
         group   => 'nagios',
         source  => "puppet:///modules/email_cert/cert/mail-$fqdn-fullchain.pem"
  } 
  file { 'cert-privkey.pem': 
         path    => "/etc/email-cert/mail-privkey.pem", 
         ensure  => file, 
         mode    => '640',
         owner   => 'Debian-exim',
         group   => 'nagios',
         source  => "puppet:///modules/email_cert/cert/mail-$fqdn-privkey.pem"
  } 
 }

After waiting some time, my nagios calms down and everything is green again. According to aNag, I also got 30 new tests.

Of course I had to change the config of nrpe and nagios a bit. In nrpe_local.cfg I had to add:

include_dir=/usr/local/nagios/tdc/config

in order to let nrpe know those newly created tests on the puppet agent.

I also had to tell the nagios server via its puppet module, that there is a new directory containing config data:

      file { '/etc/nagios4/conf.d/tdc':
          ensure => 'directory',
          source => 'puppet:///modules/nagios4_server/tdc',
          recurse => 'remote',
          path => '/etc/nagios4/conf.d/tdc',
          owner => 'root',
          group => 'root',
          mode  => '0755',
          notify  => Service["nagios4"],
        }

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.