Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[dev.icinga.com #11525] Cannot remove service from host, service became service template #183

Closed
icinga-migration opened this issue Apr 5, 2016 · 8 comments
Labels

Comments

@icinga-migration
Copy link
Member

@icinga-migration icinga-migration commented Apr 5, 2016

This issue has been migrated from Redmine: https://dev.icinga.com/issues/11525

Created by las68 on 2016-04-05 09:43:32 +00:00

Assignee: (none)
Status: Resolved (closed on 2016-04-07 23:14:56 +00:00)
Target Version: (none)
Last Update: 2016-04-07 23:14:56 +00:00 (in Redmine)


I created service 'Check HP Proliant health' based on check_hpasm command and assigned it to host.

I cannot deploy this config successfully and I decide to delete service.
But button 'Delete'is not active for service.

  1. service for some unknown reason became service template (Services / Preview / Config preview: ... )

template Service "Check HP Proliant health" {
check_command = "check_hpasm"
enable_notifications = true
enable_active_checks = true
enable_passive_checks = true
enable_event_handler = true
enable_perfdata = false
zone = "icinga2.sibmg.local"
}

  1. and I got an error when deploying, probably for some misconfiguration:

information/ConfigItem: Committing config items
information/ApiListener: My API identity: icinga2.sibmg.local
critical/config: Error: Validation failed for object 'check_hpasm' of type 'CheckCommand'; Attribute 'zone': Object 'director-global' of type 'Zone' does not exist.
Location: in /var/lib/icinga2/api/packages/director/icinga2.sibmg.local-1459849226-17/zones.d/director-global/commands.conf: 3:1-3:33
/var/lib/icinga2/api/packages/director/icinga2.sibmg.local-1459849226-17/zones.d/director-global/commands.conf(1): library "methods"
/var/lib/icinga2/api/packages/director/icinga2.sibmg.local-1459849226-17/zones.d/director-global/commands.conf(2):
/var/lib/icinga2/api/packages/director/icinga2.sibmg.local-1459849226-17/zones.d/director-global/commands.conf(3): object CheckCommand "check_hpasm" {
^
/var/lib/icinga2/api/packages/director/icinga2.sibmg.local-1459849226-17/zones.d/director-global/commands.conf(4): execute = PluginCheck
/var/lib/icinga2/api/packages/director/icinga2.sibmg.local-1459849226-17/zones.d/director-global/commands.conf(5): command = [ PluginDir + "/check_hpasm" ]

critical/config: 1 error

check_hpasm exist in PluginDir


Relations:

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Apr 5, 2016

Updated by tgelf on 2016-04-05 10:11:48 +00:00

  • Tracker changed from Bug to Support

First of all please use the current master, if not already doing so. 1.0.0 has some small nasty gotchas, there will be a 1.0.1 very soon.

las68 wrote:

I created service 'Check HP Proliant health' based on check_hpasm command and assigned it to host.

I cannot deploy this config successfully and I decide to delete service.
But button 'Delete'is not active for service.

If "Delete" is not active for a service template please hover the button with your mouse, it will probably tell you that this template is still in use. If you assigned it to a host it will be visible in the host's "Services" tab.

  1. service for some unknown reason became service template (Services / Preview / Config preview: ... )

That's by design. That global "services" list is basically your "Services catalog", you can then either add them to single hosts (or even host templates, pretty cool) in their "Services" tab. Or you can configure multiply apply rules (with different assignment rule sets).

  1. and I got an error when deploying, probably for some misconfiguration:

critical/config: Error: Validation failed for object 'check_hpasm' of type 'CheckCommand'; Attribute 'zone': Object 'director-global' of type 'Zone' does not exist.

Hmmm... ok, I understand. There is a reason for this, I guess I need to provide more config options and more docs for the next version :p Quickfix for you:

  • Please create a global zone named "director-global" in your icinga2.conf, zones.conf or similar. Global zone means setting the attribute "global" to "true"
  • It is a very good idea to do so on all your Icinga instances in case of a distributed setup, also on agents in case you want to have a smooth centralized configuration
  • As this zone didn't exist at kickstart time and the GUI currently doesn't allow you to create external objects, please then run:
icingacli director zone create director-global --is_global --object_type external_object

Cheers,
Thomas

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Apr 6, 2016

Updated by las68 on 2016-04-06 06:59:44 +00:00

I created director-global by issueing this command
icingacli director zone create director-global --is_global --object_type external_object

I see director-global in zones.
object Zone "director-global" { global = true }

but after rendering config I did not see any mention about director-global zone, and, in result I got the same error about.
this is part of renedered config.

zones.d/icinga2.sibmg.local/zones.conf

object Zone "hp43.sibmg.local" { parent = "icinga2.sibmg.local" endpoints = [ "hp43.sibmg.local" ] }

nothing about director-global

P.S. Direktor updated from github 15 minutes ago. The problem is the same. direct-global from Zone definition cannot get into config.

tgelf wrote:

First of all please use the current master, if not already doing so. 1.0.0 has some small nasty gotchas, there will be a 1.0.1 very soon.

las68 wrote:
> I created service 'Check HP Proliant health' based on check_hpasm command and assigned it to host.
>
> I cannot deploy this config successfully and I decide to delete service.
> But button 'Delete'is not active for service.

If "Delete" is not active for a service template please hover the button with your mouse, it will probably tell you that this template is still in use. If you assigned it to a host it will be visible in the host's "Services" tab.

> 1. service for some unknown reason became service template (Services / Preview / Config preview: ... )

That's by design. That global "services" list is basically your "Services catalog", you can then either add them to single hosts (or even host templates, pretty cool) in their "Services" tab. Or you can configure multiply apply rules (with different assignment rule sets).

> 2. and I got an error when deploying, probably for some misconfiguration:
>
> critical/config: Error: Validation failed for object 'check_hpasm' of type 'CheckCommand'; Attribute 'zone': Object 'director-global' of type 'Zone' does not exist.

Hmmm... ok, I understand. There is a reason for this, I guess I need to provide more config options and more docs for the next version :p Quickfix for you:

* Please create a global zone named "director-global" in your icinga2.conf, zones.conf or similar. Global zone means setting the attribute "global" to "true"
* It is a very good idea to do so on all your Icinga instances in case of a distributed setup, also on agents in case you want to have a smooth centralized configuration
* As this zone didn't exist at kickstart time and the GUI currently doesn't allow you to create external objects, please then run:

[...]

Cheers,
Thomas

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Apr 6, 2016

Updated by tgelf on 2016-04-06 07:58:33 +00:00

tgelf wrote:

Hmmm... ok, I understand. There is a reason for this, I guess I need to provide more config options and more docs for the next version :p Quickfix for you:

* Please create a global zone named "director-global" in your icinga2.conf, zones.conf or similar. Global zone means setting the attribute "global" to "true"
* It is a very good idea to do so on all your Icinga instances in case of a distributed setup, also on agents in case you want to have a smooth centralized configuration
...

Did you also do this step? This has to be done in your Icinga 2 configuration, not through the director. The CLI command was just there to let the Director know that such a zone exists.

Cheers,
Thomas

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Apr 6, 2016

Updated by las68 on 2016-04-06 09:18:08 +00:00

Oops! Nope.

Well, I added definition of director-global to /etc/icinga2/zines.conf as of follows:

object Zone "director-global" {
global = true
}

and I successfully deployed config to icinga2.

But anyway, should we rely on any other config files not prepared in Direktor?
Only as workaround, I believe )).

But anyway , I like Direktor very much. A great step forward.

tgelf wrote:

tgelf wrote:
> Hmmm... ok, I understand. There is a reason for this, I guess I need to provide more config options and more docs for the next version :p Quickfix for you:
>
> * Please create a global zone named "director-global" in your icinga2.conf, zones.conf or similar. Global zone means setting the attribute "global" to "true"
> * It is a very good idea to do so on all your Icinga instances in case of a distributed setup, also on agents in case you want to have a smooth centralized configuration
> ...

Did you also do this step? This has to be done in your Icinga 2 configuration, not through the director. The CLI command was just there to let the Director know that such a zone exists.

Cheers,
Thomas

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Apr 7, 2016

Updated by tgelf on 2016-04-07 23:13:36 +00:00

  • Relates set to 11547
@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Apr 7, 2016

Updated by tgelf on 2016-04-07 23:14:56 +00:00

  • Status changed from New to Resolved

Well, for a single-node Icinga it could work fine without that global zone, all other scenarios would need one. So I decided to make it a hard requirement, just forgot to mention it in the docs :p I created a related ticket, will be fixed.

Cheers,
Thomas

@Fiiti
Copy link

@Fiiti Fiiti commented Mar 6, 2017

Till Today nothing happens about this. Neither any hint in the Documentation (imho) nor the director itself adding them.
Would it not make sense to add these cofig generally and automatically?

So long,
Fiiti

@Thomas-Gelf
Copy link
Contributor

@Thomas-Gelf Thomas-Gelf commented Mar 6, 2017

Neither any hint in the Documentation (imho) [..]

@Fiiti: this is the very first step in the Getting Started section of our documentation

[..] nor the director itself adding them.

Zones are a security feature in Icinga 2. Therefore adding them for a single Icinga node through the API would work, but in a distributed environment it doesn't behave like you might expect. Manually adding that zone is usually only required for your core (master/satellite) nodes. For your Agents you should try to use the sample config/scripts provided by the Director - you'll find that zone in all of them.

Cheers,
Thomas

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.