Quick question. I had used Nagios several years ago, and I vaguely remember how to configure it using the *.conf files. I have now installed Icinga using the Director. Peeking at the conf files, it seems to me that Director stores its info somewhere else. I have the following questions:
I deduce that I should decide: either edit the conf files or use the director, but not both. Am I right?
If so, I will rather edit the conf files (which I can largely automate). But does the Director store its stuff? I would now need to merge the two.
related to that: do I need to uninstall, or somehow inactivate, the director? It seems to me that Icinga is ignoring the stuff that is in the *.conf files, after having been set up by the Director (but I may be wrong, I haven’t investigated this in detail).
many thanks for your help with these rather basic questions!
Someone may have more details, but basically Director stores the configurations in the database and generates the config files on-demand (when you deploy). They are written out locally that you can see in Icinga Director > Deployments.
ahhh, now I am starting to believe that there is something wrong with the installation. The Director shows the correct files, but they don’t seem to get deployed. The directory “/etc/icinga2/zones.d” is empty, even after deployment. In fact, the deployment does not seem to work, I get a “sandclock” image circling around infinitely (see pic)
It may depend on your distro, but mine (CentOS 7) has a user icinga. (It may also help to format your posts to make them easier to read.)
The Director-written configs are under /var/lib/icinga2/api/packages/director/, if you want to dig around a little. Search directories named zones.d; my Director uses director-global.
The daemon is used in current versions to fetch the answer of Icinga 2 after it has send the rendered configuration to the API endpoint.
And the location mentioned is correct, but just to add another detail: The API endpoint uses some kind of versioning, so you will find there different stages and some configuration which tells the system which one is the currently active stage.
But there is typically no need to dig there for an answer if you only use the Director (and zones.conf and constants.conf) as you can find the rendered configuration also in the UI next to the deployments.
Just to add a little on the conf files vs. Director point
You can use both. And will have to if you need more advanced configs which the Director can’t provide, e.g. setting variable values based on calculations or functions.
This generally is no problem.
Just keep in mind that
the objects from config files are not visible/editable inside the Director.
if you create equally named objects in the conf files and the Director neither will warn you about the duplicate until you try to render the config.
If mixing both and you added/changed something in the config files it is best to check the config first before deploying: icinga2 daemon -C
I keep all assets descriptors (DHCP assignments, DNS names, locations) into a MS-SQL database. I have written a script which generates Nagios configs (and also DHCP and DNS tables) therefrom. I am now wondering whether the script could instead directly update the Director database tables. In this scenario, Director and configs would stay synchronized, right? Is that a stupid/dangerous thing to do?
You should never directly modify director’s database but use director’s RestAPI.
In your case I’d create conf files directly from your database. I don’t see much advantages using director. And with conf files you don’t run into limitations of the director.
To reply indirectly to the previous poster and “log1c” some plusses for using Director:
With its forms, Director steers a team of configurers to set up things the same way, mostly; config. files offer a lot more freedom to configure however the hell people want to.
It also disciplines configurers in the usage of apply rules.
Director offers a clear log of all changes, and easy methods to do roll-backs of the config’s at a later time.
With special features like service sets, & corresponding blacklisting functions, Director makes “universal” implementation of services assignments to hosts more transparent/easy.
The API, together with the icingacli director command features, make automation / metadata-transfer scripts easier to set up in our (humble?) opinion.
Basically, if your team of configurers has more than 2 members, or if your team is handling more than about 10 Icinga-using customers, Director is a pretty useful tool. One does hope that its functionality does keep moving closer to all that config. files can do…
