How do you test a large configuration?

[Karl DeBisschop]

On Wed, 2003-06-25 at 11:58, Skip Montanaro wrote:
> I have a practical problem.  I've been running Nagios for a couple weeks now
> on my laptop, adapting more and more of the configuration data from our
> current system.  At this point I have
> 
>     * 155 host definitions
>     * 159 hostextinfo definitions
>     * 205 service definitions
>     * 63 contact grounds
>     * 18 contacts
>     * 25 escalations
> 
> and various smaller numbers of other definitions.
> 
> Now I have a practical problem.  Given that many of the systems being
> monitored are critical and can't be taken down to test that stuff works
> properly, how do I go about testing my configuration?  When I reload the
> system it obviously checks some things for me.  Other stuff, "leaf
> information", isn't so easy to check automatically (emails, pager numbers,
> missing service definitions, escalation ordering, etc).
> 
> To the greated extent possible, I'd like to avoid discovering mistakes in my
> configuration when a machine goes down and nobody notices.  Other than
> (actually, in addition to) tediously desk checking everything, do people
> have any suggestions for checking large configurations?

Use iptables on the nagios box to block communication with various ports
on various servers. Do this in a controlled manner and you should be
able to test most of your configs.

--
Karl



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null