Test::Server - what about test driven administration?


        cp -r examples /etc/t
        cd /etc/t
        vim test-server.yaml
        prove /etc/t

        use Test::Server;


Ever heard of test driven development? What about test driven administration? Take a look around examples/ folder for example tests that you can run agains your server.

The general configuration should be done through the test-server.yaml and should be managable by any non Perl awear admin (are there any?). Of course you are free to put any other test that make sence for your server.

The idea behind this is following: You run prove /etc/t and everything is fine. Server is up and running. Life is nice. Then somebody calls you at 3am... Oups! What went wrong? You login to the server (if possible of course) and run the prove /etc/t friend. Something failed? => fix it. Nothing failed? => write a test that will reveal that something is wrong && fix the problem of course ;). And then at 6am go happily to sleep again...

To be the administration really test drive ;) you should be writing your tests before you install the server...

Any other benefits? What about migration || reinstalation of the server? Do you always remember what services || purpouses is the server used for? You just scp the /etc/t folder to the new machine and prove /etc/t will tell you. If not you'll write a test ;).

Or are you writing firewall rules and need to check if you didn't close some ports that you should not? Check out the 03_open-ports.t.

I hope you'll enjoy the idea as I do. (until I find that there are 30 other similar solutions like this...)



For the moment just runs prove /etc/t. Any other better idea?


I have tried to organize examples/ a little bit. Tests with 01_* should be run directly on the server. The other should run also remotely. Than there can be a central "test" server that will collect all /etc/t folders (without 01_*) and the test could be run also remotely. Testing remote access to the services. Store the collected test in /folder/server_name, run prove -r /folder and watch how everything works(?)!.

The tests starting with 02_* should be essential but short running tests that should work in all cases and the rest of the tests will most likely fail if they do.



check hostname and ip resolution on interfaces


check running processes


query dns server and check for the answers

check also if the dns responses are fast enought


disk free/full check


query all nameserver-s in /etc/resolv.conf and make sure all are reachable.


compare local machine time with a ntp server to make sure both are in the sync.

For the idea thanks to Emmanuel Rodriguez Santiago.


Checks a file(s) and generates failed tests on every line found there. Allows any program in the system to pass messages to the monitoring simply by adding line into a file


check web sites


Check if the ports are open and if the service is responding.


Check the output of the shell command with a regexp. Check the exit code.

For the idea thanks to Aldo Calpini.


Check folders it there are not too many files and if the files (logs, tmp, etc.) didn't grow too large.


File directory permissions and sizes for a directories (e.g. Is cache dir writeable for httpd)

For the idea thanks to Peter Hartl.


check if interfaces has a PTR record which properly resolves back to interface ip


After given number of days a fail test will occure. The purpose is to make sure monitoring team is receiving alarms properly. If the admins finds out that this test fails for couple of days without anyone notice then there is something wrong.


Does traceroute and check first or last N network hops to the host. It's using system traceroute program.



run `smartctl -q errorsonly -H -l selftest /dev/hda` and produce error if there will be some output


check with Net::Ping if hosts are reachable


There are no restrictions in Perl and there are no best solutions => so the sky is the limit! (Or we our self are the limit?)


Check out the Build.PL for the list of examples that are installed in /etc/t.


Any wishes || good ideas for general server tests should go here. Do you have any? Send it! Or even better send the .t file.

        * connect to database and check if count of rows in all table doesn't exceed some number

SEE ALSO, and a book "Perl Testing: A Developer's Notebook"


If you like automation check out also Sysadm::Install for system admin scripting.


Jozef Kutej


Copyright (C) 2006 by Jozef Kutej

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself, either Perl version 5.8.4 or, at your option, any later version of Perl 5 you may have available.