Command checks

The Nagios idiom check_command name!arg1!arg2 — one named command template, instantiated with different positional arguments per host or service — has a direct equivalent, and it’s how you avoid repeating a plugin invocation across fifty services that differ only in one flag.

Define a command once

resources: USER1: "/usr/lib/nagios/plugins"

commands: check_creds: line: "$USER1$/check_creds.sh --user $ARG1$ --password $_HOSTPASSWORD$"

resources plays the role of Nagios’s resource.cfg: $USERn$ macros, kept out of the main config the way credentials-adjacent paths always were. commands maps a name to a template line; $ARGn$ are positional arguments supplied at the call site, and $_HOSTxxx$ / $_SERVICExxx$ expand a host’s or service’s vars.

Instantiate it per object

hosts: gw: {
  address: "192.168.1.1"
  vars: PASSWORD: "s3cr3t"
  check: {type: "icmp", host: "192.168.1.1"}
  services: creds: check: {
    type:    "command"
    command: "check_creds"
    args:    ["jaque"]
  }
}

command is a key into the top-level commands map; args fills in $ARG1$, $ARG2$, etc. — the same !-separated argument list Nagios used, minus the ! splitting, which belongs to the importer frontend rather than this schema.

Two expansion modes

A command template is shell: false by default: the resolved line is tokenized and executed directly, like legacy checks. Setting shell: true hands the whole resolved line to /bin/sh -c instead — useful for a command that pipes or redirects, at the usual cost of shell quoting being the caller’s problem:

commands: check_shell: {
  line:  "echo $_SERVICEMESSAGE$ $ARG1$"
  shell: true
}

Once resolved, a command check runs exactly like a legacy exec plugin — same exit-code protocol, same process-group timeout handling.