Re: [icinga-users] Delete dependency with wildcard via API
> On 29 Sep 2016, at 20:03, Zachary McGibbon wrote:
>
> Is there any way to delete a host dependency with a wildcard? In my example,
> I create a dependency for an access point to the switch, but if I remove the
> access point I might not know which switch it was connected to so I would
> want to clear all upstream dependencies.
>
> Example:
>
> Create dependency:
>
> curl -k -s -u 'root:pass' \
> -H 'Accept: application/json' \
> -X PUT
> 'https://localhost:5665/v1/objects/dependencies/burnside-2-ap225!burnside-sw66'
> \
> -d '{ "attrs": { "parent_host_name": "burnside-sw66", "child_host_name":
> "burnside-2-ap225" } }' \
> | python -m json.tool
>
> Delete dependency: (DOES NOT WORK??)
>
> # delete object
> curl -k -s -u 'root:pass' \
> -H 'Accept: application/json' \
> -X DELETE 'https://localhost:5665/v1/objects/dependencies' \
> -d '{ "filter": "match(\"burnside-2-ap225\",child_host_name)"}' \
> | python -m json.tool
I’d try dependency.child_host_name but generally I’m always interested in the
error message returned by statements in the first place :)
Kind regards,
Michael
--
Michael Friedrich, DI (FH)
Senior Developer
NETWAYS GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
Tel: +49 911 92885-0 | Fax: +49 911 92885-77
CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB18461
http://www.netways.de | michael.friedr...@netways.de
** OSMC 2016 - November - netways.de/osmc **
** OSDC 2017 - Mai – osdc.de **
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] Icinga 1.x to 2.x - Migration Questions
Hi, > On 27 Sep 2016, at 14:03, Kimball, Tim wrote: > > I'm in the process of planning an Icinga 1.x to Icinga 2 migration (2.5.4 in > this case). Unfortunately the docs and wiki are not helping 100% with our > particular setup, as we're also (slowly) migrating from source to packages. > Among other things. :) > > My concerns are below. Any help/pointers etc would be appreciated. > > > 1) For now, we'd like to use the same plugins from our Icinga 1.x install in > Icinga 2.x; Part of that is due to our compiling a custom nrpe with a larger > output buffer (yes, we'll fix that later - probably by switching to the new > Agent/Client for Linux hosts). > > From the install notes, it looks like I just have to set PluginDir to > /usr/local/icinga/libexec (our old plugin dir), correct? Anywhere your plugins live although I would recommend to install them by package, and use the same prefix for your compiled nrpe binary. > > > 2) As part of the migration, we'll need to start on Classic UI and migrate to > Web2 later on (its not fully under my control to hot swap this interface). > There are no notes in the normal install for this, and the wiki only > discusses doing this by source. However, I do see a > 'icinga2-classicui-config' package which may help. The Classic UI served well for several years, and also as first interface when we started developing Icinga 2 more than three years ago. In the meantime lots of things changed, and Icinga Web 2 reached its first stable version. It evolved ever since and is our primary interface which we support with Icinga 2. It is possible to use the Classic UI with Icinga 2 but we do not recommend it. There are certain limitations (creating notification/user objects which are then used as contacts for authorisation in the Classic UI, which is ugly as f*ck, or the command expander which does not work with the dynamically rendered CheckCommands (runtime calculations possible), for example). Therefore we decided to only describe the working supported way of using our primary web interface, Icinga Web 2. > > If we already have Classic setup under 1.x, can we just install this config > package, or will a second 'standalone' compile of Classic (set to /icinga2/ > on apache) be needed first? We would like to keep the Icinga 1.x web > instance intact, in case of rollback. There’s a package which provides just the configuration with changed paths required for the underlying CGI binaries. They’re the same as with Icinga 1.x. The apache configuration serves a different path as well. > > > 3) We run PNP4Nagios in Gearman Mode, with the process_perfdata.pl on a > dedicated host. Bulk Mode / NPCD does not seem to support this configuration > (though I could just be reading the docs wrong). Does anyone have tips on > migrating this so we don't lose the grapher data? Running a distributed setup with masters and satellites, you may just enable the PerfdataWriter feature with a local NPCD daemon on the satellites as well. I guess that’s similar what you’re doing with your current setup, but to be honest I have never looked into mod_gearman in combination with PNP. Still I would recommend to have the performance data only on the master zone whereas your Icinga Web 2 and web interfaces may query and display the data. > > I have no concern with moving the graphs back to the Icinga Master, but we > eventually want to use the PNP server as part of an active-active cluster > pair with the Master. So moving these files twice would be annoying. We > also don't use the popup integration etc, so if that breaks we don't care > right now. As said, having them on the master is most logical choice within a current Icinga 2 setup. > > Graphite is a longer-term goal, but it would need to run in parallel for six > months (minimum) before stopping our PNP setup. That’s just a “feature enable graphite” away and may run from the very first start in parallel with “feature enable perfdata” on the master(s). Kind regards, Michael -- Michael Friedrich, DI (FH) Senior Developer NETWAYS GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg Tel: +49 911 92885-0 | Fax: +49 911 92885-77 CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB18461 http://www.netways.de | michael.friedr...@netways.de ** OSMC 2016 - November - netways.de/osmc ** ** OSDC 2017 - Mai – osdc.de ** ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] Delete dependency with wildcard via API
Hmm... I was trying to find a better way to do it, so here's my rundown of
my update script:
1. Poll Oracle database (cmdb) for all switches, access points, upses, etc
2. Parse all object data (switches, access points, UPSes, etc), includes
parent device (ex. uplink switch)
3. Verify if object exists in Icinga2 via API (to set POST or PUT)
4. Add/Update object in Icinga2 API
5. Verify if child/parent dependency already exists in Icinga2 via API (to
set POST or PUT)
6. Add/update the dependency in Icinga2 API
7. Delete all old hosts created via API
8. Delete all old dependencies created via API
Now, step 7 and 8 are interesting, how do I delete all 'old' devices..?
When starting my update script I take the current time stamp and put this
into a var (vars.database_run = script run time) as well as another
variable (vars.database_source = cmdb)
To then delete the old hosts & dependencies I run a DELETE for all entries
that match the vars.database_source = cmdb and vars.database_run not like
the current time of the new script run.
This works fine for hosts, but I don't think it is working right for
dependencies with parent hosts that were created in conf files (not via
API).
My example:
curl -k -s -u 'root:icinga' \
-H 'Accept: application/json' \
-X GET 'https://localhost:5665/v1/objects/dependencies' \
-d '{ "filter": "match(\"cmdb\",dependency.vars.database_source)"}' \
| python -m json.tool
{
"results": [
{
"attrs": {
"__name": "1010sherb-sw1!bronfman-c6k",
"active": true,
"child_host_name": "1010sherb-sw1",
"child_service_name": "",
"disable_checks": false,
"disable_notifications": true,
"ha_mode": 0.0,
"ignore_soft_states": true,
"name": "bronfman-c6k",
"original_attributes": {
"child_host_name": "1010sherb-sw1",
"parent_host_name": "bronfman-c6k",
"vars": null
},
"package": "_etc",
"parent_host_name": "bronfman-c6k",
"parent_service_name": "",
"paused": false,
"period": "",
"states": null,
"templates": [
"bronfman-c6k"
],
"type": "Dependency",
"vars": {
"database_run": "Fri Sep 30 10:11:11 2016",
"database_source": "cmdb",
"device_type": "cisco_switch"
},
"version": 1475244672.135489,
"zone": ""
},
"joins": {},
"meta": {},
"name": "1010sherb-sw1!bronfman-c6k",
"type": "Dependency"
},
The I try and delete with the same filter:
curl -k -s -u 'root:icinga' \
-H 'Accept: application/json' \
-X DELETE 'https://localhost:5665/v1/objects/dependencies' \
-d '{ "filter": "match(\"cmdb\",dependency.vars.database_source)"}' \
| python -m json.tool
I notice that the dependencies that were created with two hosts via the API
are deleted, however I also have hosts (mostly more core and distribution
routers) that were created using conf files. The dependencies that are
created with these hosts as parents are not deleted! example:
"code": 500.0,
"errors": [
"Object cannot be deleted because it was not created using
the API."
],
"name": "1010sherb-sw2!bronfman-c6k",
"status": "Object could not be deleted.",
"type": "Dependency"
Am I doing something wrong here or does this look like a bug?
- Zac
On Fri, Sep 30, 2016 at 3:24 AM, Michael Friedrich <
michael.friedr...@netways.de> wrote:
>
> > On 29 Sep 2016, at 20:03, Zachary McGibbon
> wrote:
> >
> > Is there any way to delete a host dependency with a wildcard? In my
> example, I create a dependency for an access point to the switch, but if I
> remove the access point I might not know which switch it was connected to
> so I would want to clear all upstream dependencies.
> >
> > Example:
> >
> > Create dependency:
> >
> > curl -k -s -u 'root:pass' \
> > -H 'Accept: application/json' \
> > -X PUT 'https://localhost:5665/v1/objects/dependencies/burnside-
> 2-ap225!burnside-sw66' \
> > -d '{ "attrs": { "parent_host_name": "burnside-sw66", "child_host_name":
> "burnside-2-ap225" } }' \
> > | python -m json.tool
> >
> > Delete dependency: (DOES NOT WORK??)
> >
> > # delete object
> > curl -k -s -u 'root:pass' \
> > -H 'Accept: application/json' \
> > -X DELETE 'https://localhost:5665/v1/objects/dependencies' \
> > -d '{ "filter": "match(\"burnside-2-ap225\",child_host_name)"}' \
> > | python -m json.tool
>
> I’d try dependency.child_host_name but generally I’m always interested in
> the error message returned by statements in the first place :)
>
> Kind regards,
>
