Creating a command - Confused

Hi guys,

Although I read a lot of other posts on the subject, I’m confused about how to implement this.

If I have this command (from Nagios)…how would I define it in Icinga?

***My biggest concerns are the “command” textbox and the Arguments tab.
In the attachment I’ve provided, should my Command field be check-ips or check-nrpe?

define service {
 service_description check-IPs
 use linux-server-ubuntu-service-template
 host_name our hostname
 check_command check-ips!common_check_ip!-i,

La commande associées:

 define command {
 command_name check-ips
 command_line $USER1$/check_nrpe -n -H $HOSTNAME$ -t 60 -c $ARG1$ -a ‘$ARG2$’

Thank you so much everyone! I can’t wait to get everything set up!


Welcome to the glamorous world of Icinga. :slight_smile:
The good news is, you don’t need to create a lot of commands anymore like you had to with legacy tools like Nagios.

Icinga 2 allows for creating a single command which knows all options of the plugins but only uses the ones you really need.

So you don’t have to create check-ips, you can just use the nrpe definition from the ITL you already imported into Director. You just tell it which command to use from the nrpe.cfg file.

By the way: NRPE uses insecure connections (SSL with a known key is more obfuscation than security) and needs to have its configuration changed locally on the monitored host. Using arguments with NRPE is even more insecure. You should definitely consider changing to the Icinga 2 agent. It gives you, besides other benefits, configuration sync to the agent and secure communication.

1 Like

Thanks for the reply.

When using the agent, is there something to do/install/configure on the hosts?
We have 1100 hosts…

Yes, you have to install the agent. :slight_smile: It will replace NRPE.

You have to run some commands to get the communication going but only once. When it’s connected you can synchronise configuration to the agent whenever you change something.

I’d suggest you use Puppet or Ansible for the Agent rollout. It works like a charm and there modules / playbook available.

1 Like

We have chef…would that work too? for the deployment…

It should. I don’t really know chef but this is the minimal thing you need to do:

  • Configure a package repository (workaround: place the repo file in the correct directory)
  • Install some packages
  • Maybe place some files on the agent
  • Run some commands on the agent

It’s better first gather the setup ticket from the config-master, transfer it to the agent and then run some commands with it but if this gives you hard time, you can just run the commands on the agent to connect to the configmaster or a satellite and then sign the csr’s on the master manually or by script. (Always check if the CSRs are valid, though!)


the things @twidhalm explains with automation with chef and also the Icinga agent are totally valid, but still overwhelming imho. At first glance, you need to understand the differences between legacy (Nagios) and the current Icinga DSL format, especially in the way of passing command arguments.

There’s a couple of pre-defined command templates available in the ITL, so you don’t need to waste extra time with defining things others have done multiple times already. One of them is nrpe, amongst others like disk, load and community contributed definitions for famous check plugins like nwc_health or mysql_health.

I would assume that your current setup still runs while you’re migrating to Icinga, and as such, the NRPE daemon on the agent is still running.

For the first success with Icinga, I’d just implement the service in the Icinga way and then you may consider modern and secure agent communication with Icinga (TLS, endpoints, trust relationship preventing MITM attacks).

Analysis and Migration

As you know already, nrpe is there, and following your CheckCommand

command_line $USER1$/check_nrpe -n -H $HOSTNAME$ -t 60 -c $ARG1$ -a ‘$ARG2$’

there’s some things to consider:

  • -n disables SSL/TLS, which is totally bad. For migration purposes, the nrpe command requires the nrpe_no_ssl attribute set to true
  • -t 60 sets a hard timeout to 60s, this needs the nrpe_timeout set to 60s.
  • -c translates into nrpe_command which is passed as $ARG1$ in the command line
  • -a adds additional parameters on the command line (which must be enabled on the agent host)

The service itself adds the values for the two $ARGn$ macros in the old world.

check_command check-ips!common_check_ip!-i,

The above typically is bad practice, as it allows the caller to pass any shell command with -a and the remote end executes that. Compromised masters may abuse this to read secrets from the attacked host.

Anyhow, we know that the nrpe_arguments in Icinga pass -a as arguments, thus requiring an array.

  vars.nrpe_arguments = [ "-i", "," ]

In addition to that, the remote called nrpe command is just a string.

  vars.nrpe_command = "common_check_ip"


Do this outside of the Director for the first impression, and then move the learned bits and attributes into the Director. Later use the Director to manage an Icinga agent only. Follow the best practices for hosts already, making a transition to an agent easy.

The host object just needs the typical configuration settings, and you can use the template logic to e.g. store additional facts about the host itself.

template Host "linux-server-ubuntu" {
  vars.os_type = "Linux"
  vars.os_distribution = "Ubuntu"

object Host "" {
  import "linux-server-ubuntu"
  address = "..."
  vars.os_distribution_release = "18.04 LTS"
  vars.extra_ip_checks = true

There’s one extra thing above - extra_ip_checks to the apply rule below as filter.

Now, define a service apply rule which implements the previous check-IPs definition.

apply Service "IP Checks" {
  check_command = "nrpe"
  vars.nrpe_command = "common_check_ip"
  vars.nrpe_arguments = [ "-i", "," ]

  assign where host.vars.os_type == "Linux" && host.vars.extra_ip_checks == true // define your own rule/strategy where to generate a service object here

In the first iteration, this configuration should work and present something on the web interface. It is far from perfect though, since the service apply rule has the IP addresses hardcoded. One could move this line into the host object.

Still, requiring the admin to consider writing -i up front the argument is error prone. You should hide that inside the CheckCommand definition in the future.

Icinga Agent + Director

This requires to setup the master and then the agent with Icinga, following the docs e.g. for a Linux host.

To help you further, we need the definition of common_check_ip in your nrpe.cfg to actually build and use the proper CheckCommand definition.