NAME
Test::Server - what about test driven administration?
SYNOPSIS
cp -r examples /etc/t
cd /etc/t
vim test-server.yaml
prove /etc/t
use Test::Server;
Test::Server->run();
DESCRIPTION
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...)
METHODS
run()
For the moment just runs "prove /etc/t". Any other better idea?
examples/
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.
files
01_hostname-and-interfaces.t
check hostname and ip resolution on interfaces
01_running-processes.t
check running processes
02_dns-resolution.t
query dns server and check for the answers
02_resolv.conf.t
query all nameserver-s in /etc/resolv.conf and make sure all are
reachable.
02_time-sync.t
compare local machine time with a ntp server to make sure both are
in the sync.
For the idea thanks to Emmanuel Rodriguez Santiago.
03_sites-ok.t
check web sites
03_open-ports.t
Check if the ports are open and if the service is responding.
03_cmd-output.t
Check the output of the shell command with a regexp. Check the exit
code.
For the idea thanks to Aldo Calpini.
sky
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?)
TODO
Any wishes || good ideas for general server tests should go here. Do you
have any? Send it! Or even better send the .t file.
* check if all the interfaces has dns revers rr that properly resolves back
* I should write some easy example test for non perl admins
* file directory permissions for all relevant application directories
(e.g. Is cache dir writeable for httpd) (thanks Peter Hartl)
* check folders if the files (logs?) didn't grow too huge
* create Test::Server::Smoke to try examples on smoke testing servers
LINKS
,
and a book "Perl
Testing: A Developer's Notebook"
AUTHOR
Jozef Kutej
COPYRIGHT AND LICENSE
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.