[icinga-users] keeping Icinga configurations in sync
cogel at uni-koeln.de
Fri Mar 16 17:44:22 CET 2012
Am 16.03.2012 15:50, schrieb Isaac Witmer:
> The current setup is two Icinga servers, one in a local network, and
> one outside in cyberspace.
> There are several servers in the local network that are checked by the
> local instance of Icinga, but the notifications and external servers
> are (for the most part) handled by the external instance.
> This causes some issues for keeping configurations in sync. If a new
> computer is added to the local network, a new configuration has to be
> added to the local Icinga, and then another almost identical
> configuration (except marked as passive:
> http://docs.icinga.org/1.0.1/en/passivechecks.html) on the external
> It's not quite as simple as simply copying the configurations between
> incinga servers, though, because one server can check the hosts and
> the other can't (firewall restrictions prevent the external server
> from accessing internal hosts).
> I've thought a bit about modifying the templates so that I can make
> the configurations in the template, but that doesn't quite work
> either. The issue being that host configurations are preferred to
> template configurations (understandably), meaning that I can't copy
> host configurations from the local instance to the external instance
> and expect the external instance to use a different (simply return
> critical when it doesn't get any alerts) check command.
> Am I making any sense? Are there any ideas/documentation that would
> make this easier?
> One idea that might help would be to attempt to script some things to
> output the configuration files that I need... Are there tools out
> there that do that already?
We're using cfengine to to maintain the configuration of out systems.
And the configuration of the icinga server is one part of the job. We
have a repository where we keep the configurations and cfengine
distributes the files. cfengine can replace strings and expand macros in
configuration files depending on the hostname where it is executed.
You can set up the machine where you manage your icinga configuration to
act as cfengine master. And you define rules to modify the files on the
target host. If you can keep the relevant parts in templates, it will
make the setup more straight forward.
If something like cfengine is to much overkill: Another possible
solution is the distribution with SSH forced commands. Create a
privat/public key pair and configure the remote host to call a forced
command for each login with this key. Make the remote script read out
the SSH environment so you can pass parameters with each call. Now you
can tell the remote host what to do by the way you call the remote script.
Just the short track:
convert.pl will be called always.
Now yo can do something like that:
cat <conffile|ssh -i <private_key> <user>@<host> \
<job> <targetfile> ....
set <job> to 'copy' or 'convert' and name the targetfile on the remotehost.
In convert.pl you can get the original ssh call from the environment by
reading $SSH_ORIGINAL_COMMAND. You can define what to do and the
patterns to replace within the call....
You don't need perl. bash will do also.
In the script you can do a 'cat - 2 > /dev/null > targetfile' to simply
write the file. Or you can pass the data to sed...
Now some script magic to prevent errors...
Dipl. Chem. Dr. Berthold Cogel University of Cologne
E-Mail: cogel at uni-koeln.de Regionales Rechenzentrum (RRZK)
Tel.: +49(0)221/470-7873 Robert-Koch-Str. 10
FAX: +49(0)221/478-86845 D-50931 Cologne - Germany
More information about the icinga-users