0

I have a conditionnal rule in Icinga to execute a script for checking cas authentification. The script use an URL and grep a string in the page returned. URL and string are given attributes to the script.

Here's the defintion of a host :

 object Host "m" {
  address = "1xx.xx7.25"
  import "linux-server"
  display_name = "m"    
  vars.curl_casURL = "http://xxx.html"
  vars.curl_casGREP = "Returned String"
}

Here's the code for the Service, it's only executed when the 2 variables curl_casURL and curl_casGREP are defined in the host :

apply Service "cas"  {
  import "generic-service"
  check_command = "cas"
  assign  where (host.vars.curl_casURL && host.vars.curl_casGREP)
}

In the web Interface, it's OK, I saw that the script is executed for the server "m".

Here's the command :

object CheckCommand "cas" {
  import "plugin-check-command"
  command = [ PluginDir + "/icinga-curl_cas.sh" ]
  command +=[  vars.curl_casURL + vars.curl_casGREP ]
}

But the script never receives the arguments and echoes a critical state because of the first line of the script :

if [ ! $1  ]
 then
  echo "GIVE ME AN  URL, PLEASE!"
  exit $STATE_CRITICAL
fi

I didn't find in the documentation the answer. Could anyone help me? Thanks!!

1 Answers1

0

Accessing custom attributes as runtime macros is wrong in your example:

object CheckCommand "cas" {
  import "plugin-check-command"
  command = [ PluginDir + "/icinga-curl_cas.sh" ]
  command +=[  vars.curl_casURL + vars.curl_casGREP ]
}

Using your CheckCommand asking how to access custom attributes as command attributes requires little knowledge about runtime macros and their values, and of course the command arguments syntax.

Since you are using an ordered list of parameters without any key, I'd just do it the ugly way and add the custom attribute values as runtime macro strings to the array.

object CheckCommand "cas" {
  import "plugin-check-command"
  command = [ PluginDir + "/icinga-curl_cas.sh", "$curl_casURL$", "$curl_casGREP$" ]
}

The macro resolver will automatically lookup the required values, and it does not matter if they are defined as default value on the CheckCommand, the Host object or the service using the CheckCommand.

Though I'd recommend using GetOpts with parameters and values for your script (better readability and the positions of values won't matter on later changes).

while getopts "u:g:" opt; do
  case $opt in
    u)
      URL=$OPTARG
      ;;
    g)
      GREP=$OPTARG
      ;;
    [....]
    \?)
      echo "Invalid option: -$OPTARG" >&2
      exit 1
      ;;
    :)
      echo "Option -$OPTARG requires an argument." >&2
      exit 1
      ;;
  esac
done

Using command arguments is pretty simple then. It also allows you to add an argument description which can be helpful later on (and retrieved via the API in 2.4).

object CheckCommand "cas" {
  import "plugin-check-command"
  command = [ PluginDir + "/icinga-curl_cas.sh" ]

  arguments = {
    "-u" = {
      value = "$curl_casURL$"
      description = "URL for curl"
    }
    "-g" = {
      value = "$curl_casGREP$"
      description = "GREP for curl"
    }
  }
}
dnsmichi
  • 466
  • 3
  • 11
  • Thank you. You save my time! I'll use the second way. I've looked in the icinga documentation and didn't found the right syntax of the ugly way! – Is ma Live Nov 25 '15 at 17:54
  • The good syntax for while getopts in this case is: `while getopts "u:g:" opt; do` – Is ma Live Nov 26 '15 at 09:31