Skip to content
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.

[dev.icinga.com #451] configuration check does not respect service_description not being set #224

Closed
icinga-migration opened this issue May 20, 2010 · 8 comments

Comments

@icinga-migration
Copy link

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

Created by marcel on 2010-05-20 13:45:55 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2010-06-26 13:54:55 +00:00)
Target Version: 1.0.2
Last Update: 2010-06-26 13:59:11 +00:00 (in Redmine)


I am not sure whether this is a bug or a feature, however if service_description is not set in service definition icinga runs, however ignores the whole service definition - this would be fine, although the v check command says that the host does not have service assigned, which is not entirely true the service is just wrongly set-up since service_description is a required refinition for service

Changesets

2010-05-27 10:56:35 +00:00 by (unknown) ecffcf0

error out on services without desc in config

refs #451

2010-06-23 06:07:26 +00:00 by mfriedrich 87f90d4

error out if services defined without description in service object definition (service def and/or used templates)

previous fix bailed out when no service_description was found
in a service definition. In larger setups it could happen that
service descriptions are passed directly into a template where
a service is being inherited of.

This is rewritten into the service object resolving with all
associated templates. If no service_description set in the
end, verify config will fail with an error pointing to the
service definition file and linenumber, it mentions probable
template usages.

refs #451
@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-05-27 10:58:23 +00:00

  • Assigned to set to magellanic
  • Priority changed from Low to Normal
  • Target Version set to 1.0.2

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-06-02 21:09:15 +00:00

  • Status changed from New to Resolved
  • Done % changed from 0 to 100

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-06-16 14:55:52 +00:00

  • Status changed from Resolved to Assigned
  • Done % changed from 100 to 50

this is not yet fully done - the hack checks directly on parsed service definitions. what if someone wants to set the service_description in a template?

in our setup this is true for several service checks where service_decription is being defined in a seperated service template. Without this patch it works as expected, but with the patch, it bails out because the final check is in the wrong place.

a finally compiled service object with all template inheritance resolved should be checked against a service_description.

int xodtemplate_resolve_service(xodtemplate_service *this_service)

in there, first the service definition and then recursive called, all template definitions are resolved.

xdata/xodtemplate.c:7232

                /* resolve the template service... */
                xodtemplate_resolve_service(template_service);

                /* apply missing properties from template service... */
                if(this_service->have_service_description==FALSE && template_service->have_service_description==TRUE){
                        if(this_service->service_description==NULL && template_service->service_description!=NULL)
                                this_service->service_description=(char *)strdup(template_service->service_description);
                        this_service->have_service_description=TRUE;
                        }

at first, another condition would make sense, if both are false, set the having also to false.

                if(this_service->have_service_description==FALSE && template_service->have_service_description==FALSE)
                        this_service->have_service_description=FALSE;

after looping through all templates, check if having is false - if yes, then bail out with an error, the one we will remove from the old commit.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-06-22 14:40:10 +00:00

hm i think i found an appropriate solution to be more compatible. currently with the previous bugfix applied, the verifyconfig bails out if service_description is missing in the service definition. since it could happen that the service object gets this directive from a template, we need to check after the object has been compiled together, but before it is not handled for the skipist search because of missing service_description.

in fact, it should not create an error, just a warning on the object reading then. the preflight checks warning won't be affected in this stage, just if you run -v you will see what's missing using the current bugfix.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-06-22 16:36:32 +00:00

ok solution was bullshit, a lot of warnings on templates where not service_description was defined - they are still service objects - were thrown. so another attempt - we know that services without host_name or service_description won't be registered during resolving them as objects, and adding to skiplist for checking duplicate hosts. after the adding to skiplist they are being registered and added as new services - but not if in precached mode (which needs 1x configuration generation of course!).

so this attempt takes the if service_description==NULL => continue and wraps that into an error message, returning an error. At this stage all service objects already have their template inherits resolved.

Test:

service without description
used template without description

=> FAIL

service with description
used template without description

=> OK

service without description
used template with description

=> OK

service with description
used template with description

=> OK (should be a warning for duplicate definitions though, but that's another bug)

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-06-22 16:36:46 +00:00

  • Assigned to changed from magellanic to mfriedrich

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-06-26 13:54:55 +00:00

  • Status changed from Assigned to Resolved
  • Done % changed from 50 to 100

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-06-26 13:59:11 +00:00

  • Tracker changed from Support to Bug

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant