We’re coming from a semi-manual migration from old Nagios to Icinga2 (+IDO and Icingaweb2). The old hosts and services were recreated in the new Icinga2 via the native (not Director) API. Since managing hosts via the API is not so fun, some part of the config (templates, users, some commands) are in .conf files. We now decided to install Director. Installation went ok, but after the installation none of the existing templates, hosts, services are visible in Director. The total number of objects is not so huge, probably below 500.
I tried all kind of imports unsuccessfully. Even fileshipper with directories.ini, but didn’t find a way to trigger it the import. SyncRules require a specific ImportSource to be defined, but we talk about complete .conf files with mixed object types.
If we manage to import all data to Director, we can go away from configuring via .conf or native API.
What is the best way to get there?
Objects created from within the director are visible, but some “external” objects (object not created within director) are visible. An example is commands, where you can go to:
Icinga Director > Commands > External Commands and view commands that were configured in the Icinga2 configuration directories. This seems to be the only thing that I can quickly find that are External.
The Director API might be able to recreate the objects for you with some hacking – you would need a script that sends the configs (via JSON payload) to director. I suspect the original configs will need to be disabled/removed from config directories before Icinga will start without errors/warnings.
So I guess the main option is the tedious one, to import all with scripts and then use Director.
For the moment we ended up using Postman directly () with the native icinga2 API. A bit unfriendly and ineffective at times.
I would have expected Director to import/sync all external configuration, coming from files or native Icinga2 API, mark where they come from, and be able to import/move and manage the data coming from the native API at least. Hope we can see such development at some point @tgelf.
Otherwise thanks for the work you guys put in this, it’s working reliably and gives us peace of mind to. have the tests working all the time!
The Icinga2 API and the Director API are 2 different APIs. Using the director API to create the configuration objects was a suggestion, meant to run one time to take some of the tedious work out.
Did you check for some external objects using the example above?
) with the native icinga2 API. A bit unfriendly and ineffective at times.