The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.
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

        check also if the dns responses are fast enought

    02_disk-free.t
        disk free/full check

    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.

    02_messages.t
        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

    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.

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

    03_folder-file.t
        File directory permissions and sizes for a directories (e.g. Is
        cache dir writeable for httpd)

        For the idea thanks to Peter Hartl.

    03_interfaces-ptr.t
        check if interfaces has a PTR record which properly resolves back to
        interface ip

    03_wakeup.t
        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.

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

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

    03_reachable.t
        check with Net::Ping if hosts are reachable

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?)

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

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.

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

SEE ALSO
    http://testanything.org/,
    http://en.wikipedia.org/wiki/Test_Anything_Protocol and a book "Perl
    Testing: A Developer's Notebook"

    Test::System

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

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.