is it possible to check a whole icinga2 config outside of /etc/icinga2 with ‘icinga2 daemon -C’ ?
I know, there is a ‘-c’ parameter, but this only accepts .conf files, not folders.
Example given the currently production config runs in /etc/icinga2/…- and a “staging” config, which should be checked before going live, is in /tmp/icinga2/…
Is there a way to check the whole folder in /tmp ? Icinga2 Core only w/out director.
Thanks and cheers,
not sure what do you want to achive, but this folder needs to be included inside /etc/icinga2/icinga.conf configuration with option “include_recursive” or “include” will need to specify file by file … If you want to only check the configuration but not to be alpplied, then better try it in test env.
And here is the problem: As Icinga2 “clients” cannot be part of 2 icinga cluster, I am not able to build a Dev Environment which is a 1:1 mirror of the production environment. So what I want to archieve is simple. My “staging” icinga configuration, which is normally edited in /etc/icinga2, is copied and changed in another path e.g. /tmp/icinga2. I want to validate all the config in /tmp/icinga2 without restarting the service, changing the ConfigDir parameter in the SystemD unit or anything like this. The currently valid icinga2 config is stored in /etc/icinga2 and also should stay there. So it would be just an additional config check beside of the currently running one, not for the config in /etc/icinga2, but in /tmp/icinga2.
Normally I am doing everything in test, if I need to only check configuration. But if it is neccessery to check configuration against specific client in prod, I am just disabeling notification for that client … if I need develop new service check for that client … then step by step … making commands then icinga2 daemon -C/reload icinga2 or deploy with icinga2 director cause we are using director module … then making service template and deploy again and so on… You cannot broke something if you dont restart icinga2 service. If you restart Icinga2 service with broken configuration you could have a lot of issues which you could endend cleaning of configuration on all sattelites/endpoint nodes if you also using icinga2 agent on endpoints …
also I have called help for icinga2 daemon and got:
# icinga2 daemon -h
icinga2 - The Icinga 2 network monitoring daemon (version: r2.13.6-1)
icinga2 daemon [<arguments>]
Starts Icinga 2.
-h [ --help ] show this help message
-V [ --version ] show version information
--color use VT100 color codes even when stdout is not a
-D [ --define ] arg define a constant
-I [ --include ] arg add include search directory
-x [ --log-level ] arg specify the log level for the console log.
The valid value is either debug, notice,
information (default), warning, or critical
-X [ --script-debugger ] whether to enable the script debugger
-c [ --config ] arg parse a configuration file
-z [ --no-config ] start without a configuration file
-C [ --validate ] exit after validating the configuration
-e [ --errorlog ] arg log fatal errors to the specified log file (only
works in combination with --daemonize or
-d [ --daemonize ] detach from the controlling terminal
--close-stdio do not log to stdout (or stderr) after startup
Report bugs at <https://github.com/Icinga/icinga2>
Get support: <https://icinga.com/support/>
Icinga home page: <https://icinga.com/>
So maybe it is possible to use it with arg -c <file_path> to validate configuration. I have never tried with -c but could be possible. If you just need to validate configuration I higly recommend validate it in test … even you can export prod configuration using basket and add only what you need to test .
What about creating a
include_recursive pointing to your test directories and run icinga daemon with -c testing-icinga2.conf? (Heaven’t being trying it, tough)
Would’nt this check /etc/icinga2 + the include-recursive folder, which would be the same “staged” config, so I get “re-defined” errors?