Make Icinga 2 env-var-configurable

[Al2Klimov]

In July '26, @lippserd requested a plan from @Al2Klimov for more env vars.

The plan

Features

Icinga 2 knows its own types and their attributes and types:

Influxdb2Writer {
String host
String port
Dictionary::Ptr host_template
…
}

This enables hardcoding a NEW mapping in upstream like this:

icingadb => IcingaDB
influxdb2 => Influxdb2Writer
…

Icinga 2 shall derive all feature env vars automatically like this:

"ICINGA_“ + toupper("influxdb2“) + "_“ + toupper("host“)

Or:

ICINGA_INFLUXDB2_HOST [String]

For bools, convert the env variable value to a number first,
so that user input "1“ becomes 1 and finally true.

Set other scalars as-is, Icinga 2 already converts "6379“ to 6379.

Parse Dictionary/Array inputs as JSON, e.g:

ICINGA_INFLUXDB2_HOST_TEMPLATE: '{"measurement“:“$host.check_command$“}'

The set of these env vars is finite and evaluated once all other config is loaded,
just before activation.
If any ICINGA_INFLUXDB2_ var is set, Icinga 2 creates the respective object in memory:

object Influxdb2Writer/*mapped type*/ "influxdb2“/*hardcoded key*/ {
host = "192.0.2.69“/*user input*/
port = "8086“/*user input*/
ssl_enable = Number( "1"/*user input*/ )

host_template = Json.decode( {{{
{"measurement“:“$host.check_command$“}
}}}/*user input*/ )

…
}

Refuse deletion attempts via API, telling to remove the env var.

API users

Variable structure: ICINGA_APIUSER_<NAME>_<ATTRIBUTE>

<NAME> would be "infinite“, but <ATTRIBUTE>s would be finite
and handled just like above for the features.

Everything else (my fav option)

Alternatively, we could generalize env var structure to this:

ICINGA_<TYPE>_<NAME>_<ATTRIBUTE>

This way we’d just support everything one-size-fits-all, e.g:

ICINGA_INFLUXDB2WRITER_INFLUXDB2_HOST_TEMPLATE: '{"measurement“:“$host.check_command$“}‘