[dev.icinga.com #1878] macro HOSTGROUPNAME #732

Closed
icinga-migration opened this Issue Sep 8, 2011 · 12 comments

Projects

None yet

1 participant

@icinga-migration
Member

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

Created by gzin on 2011-09-08 10:27:52 +00:00

Assignee: (none)
Status: Closed (closed on 2012-05-02 08:01:35 +00:00)
Target Version: (none)
Last Update: 2014-12-08 09:42:21 +00:00 (in Redmine)

Icinga Version: 1.10.0
OS Version: any

Some (hostgroup-) macros do not work in host or service definitions.
For example in "action_url" or "icon_image".

Example:
action_url http://wiki/.../SvcView?hostgroup=$HOSTGROUPNAME$&hostname=$HOSTNAME$

HOSTNAME gets resolved, but HOSTGROUPNAME (or HOSTGROUPNAMES,...) stay unresolved ($HOSTGR...$)

I'm currently using version 1.5.0. Same problem in icinga version 1.4.2. Same problem in nagios (v3.2.3)

@icinga-migration
Member

Updated by mfriedrich on 2011-09-08 14:41:48 +00:00

  • Target Version changed from 1.5 to 1.6
@icinga-migration
Member

Updated by mfriedrich on 2011-09-25 13:25:41 +00:00

does this happen on the core (e.g. when pushing a notification and replacing that macro) or the cgis (classic ui) using the action_url over there?

@icinga-migration
Member

Updated by gzin on 2011-09-26 12:28:41 +00:00

Yes, that's right. Notifications are sent correctly, it seems to be a CGI bug.

@icinga-migration
Member

Updated by mfriedrich on 2011-10-06 14:47:12 +00:00

  • Project changed from Core, Classic UI, IDOUtils to 19
  • Category changed from Other to 44
@icinga-migration
Member

Updated by mfriedrich on 2011-10-06 15:56:30 +00:00

test config for varification.

###############################################################################
###############################################################################
#
# HOST DEFINITION
#
###############################################################################
###############################################################################

# Define a host for the local machine

define host{
        use                     linux-server            ; Name of host template to use
                                                        ; This host definition will inherit all variables that are defined
                                                        ; in (or inherited by) the linux-server host template definition.
        host_name               localhost-test
        alias                   localhost-test
        address                 127.0.0.1
        action_url              http://wiki/.../SvcView?hostgroup=$HOSTGROUPNAME$&hostname=$HOSTNAME$
        }



###############################################################################
###############################################################################
#
# HOST GROUP DEFINITION
#
###############################################################################
###############################################################################

# Define an optional hostgroup for Linux machines

define hostgroup{
        hostgroup_name  linux-servers-test ; The name of the hostgroup
        alias           Linux Servers ; Long name of the group
        members         localhost-test     ; Comma separated list of hosts that belong to this group
        }

output on status.cgi then.

localhost-test 

but still, can't debug macro (no-)allocation currently.

@icinga-migration
Member

Updated by mfriedrich on 2011-10-06 16:39:56 +00:00

  • Status changed from New to Feedback
  • Target Version deleted 1.6

from a further analysis, this seems to be intended to be disabled. problem is that in order to grab the macros for a host being in hostgroups, you will have to

  • process each host (line by line in view)
  • loop through the complete hostgroup list and check wether the host is in the hostgroup
  • if it is, get the hostgroup pointer and grab the hostgroup values
  • this could be a performance killer, so i would not fix that, but make it opt-in.
  • problem - what happens if the host is in more than one hostgroup then? the macro grabbing will be overriden each time. just checked this by adding the host to a second hostgroup.
define hostgroup{
        hostgroup_name  linux-servers-test2 ; The name of the hostgroup
        alias           Linux Servers2 ; Long name of the group
        members         localhost-test     ; Comma separated list of hosts that belong to this group
        }

so the code works to grab the last hostgroup found, grabbing the macros and then letting that process below in action_url. but i don't think this is a proper solution to the real problem, that those macros can't just be concatenated or similar.

diff --git a/cgi/status.c b/cgi/status.c
index 2e94743..37a53d0 100644
--- a/cgi/status.c
+++ b/cgi/status.c
@@ -2167,7 +2167,15 @@ void show_host_detail(void) {
                                        status_bg_class = "BGUNREACHABLE";
                        }

-                       grab_host_macros(temp_host);
+                       grab_host_macros_r(mac, temp_host);
+
+                       hostgroup * temp_hostgroup;
+                       /* find the hostgroups for this host and grab the hostgroup macros */
+                       for (temp_hostgroup = hostgroup_list; temp_hostgroup != NULL; temp_hostgroup = temp_hostgroup->next) {
+                               if (is_host_member_of_hostgroup(temp_hostgroup, temp_host) == TRUE) {
+                                        grab_hostgroup_macros_r(mac, temp_hostgroup);
+                                }
+                        }

                        if (content_type == HTML_CONTENT) {

the notification macros clearly state this

$HOSTGROUPNAME$


The short name of the hostgroup that this host belongs to. This value is taken from the hostgroup_name directive in the hostgroup definition. If the host belongs to more than one hostgroup this macro will contain the name of just one of them.

i'll leave that here for further discussion.

  • opt-in cfg option if fixed this way
  • only grab the first host/servicegroup macros?
@icinga-migration
Member

Updated by gzin on 2011-11-08 18:48:14 +00:00

Hi!

Only one hostgroup for HOSTGROUPNAME would be fine. There is also "HOSTGROUPNAMES" ("S" at the end) available:

$HOSTGROUPNAMES$     A comma separated list of the short names of all the hostgroups that this host belongs to.

I had a look at the code meanwhile, there is already some useful functionality for that included, but it is not used for the CGI, only for the CORE ("NSCORE"):

Parts of the function:

int grab_host_macros_r(icinga_macros *mac, host *hst) {
        mac->host_ptr = hst;
        mac->hostgroup_ptr = NULL;
#ifdef NSCORE
        /* save pointer to host's first/primary hostgroup */
        if (hst->hostgroups_ptr)
                mac->hostgroup_ptr = (hostgroup *)hst->hostgroups_ptr->object_ptr;
#endif
        return OK;
}

and:

struct host_struct{
        char    *name;
        char    *display_name;
        char    *alias;
        char    *address;
        hostsmember *parent_hosts;
        hostsmember *child_hosts;
        servicesmember *services;
        char    *host_check_command;
...
#ifdef NSCORE
...
        objectlist *hostgroups_ptr;
#endif
...
}

I tried to set the "NSCORE" in cgi/status.c without further code analysis, that caused a memory error. "NSCORE" is used very often.

What should I/we do?

@icinga-migration
Member

Updated by mfriedrich on 2011-11-08 18:57:25 +00:00

the problem with classic ui (#define NSCGI) is, that you can't use pointers targetting daemonized memory linked lists, but the macros need to be fetched right when loading the page once.

so the proposed git diff already does that, calling the hostgroup macros to be fetched and then replaced within the html output.

the overall problem is, that this is a performancekiller, looping through all hostgroups, checking if the actual host is a member. a n * m timing, where n = hostcount, m = hostgroupscount, which could cause problems on larger systems.

it might be worth taking this as an opt-in cfg option.

ps: don't reuse #define NSCORE in cgis, that's not possible and will cause unexpected behaviour.

@icinga-migration
Member

Updated by mfriedrich on 2012-04-20 12:40:25 +00:00

anymore on that, or can i close this as "wontfix"?

@icinga-migration
Member

Updated by ricardo on 2012-05-02 07:59:27 +00:00

I would suggest closing it.

@icinga-migration
Member

Updated by mfriedrich on 2012-05-02 08:01:35 +00:00

  • Status changed from Feedback to Closed

wontfix - provide feedback when asking to reopen it.

@icinga-migration
Member

Updated by mfriedrich on 2014-12-08 09:42:21 +00:00

  • Project changed from 19 to Core, Classic UI, IDOUtils
  • Category changed from 44 to Classic UI
  • Icinga Version set to 1
  • OS Version set to any
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment