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 > host. > 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: remote script: /usr/local/sbin/convert.pl authorised_keys: from="xxx.xxx.xxx.xxx",command="/usr/local/sbin/convert.pl" .... 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... Berthold -- Dipl. Chem. Dr. Berthold Cogel University of Cologne E-Mail: co...@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 ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ icinga-users mailing list icinga-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/icinga-users
