Hi there!

I've created a small jinja macro to convert YAML to Icinga config : https://github.com/jbox-web/icinga2-macro-formula/blob/master/icinga2-macro/macro.jinja

You convert this to this.

It's fully understood by Icinga2 and it's tested :)

There is one caveat : it cannot render empty hashes, so empty_hash: {} and ['a', 'sample', 'array', { with_empty_hash: {} } won't be rendered.

Proposed Changes

I would like to add the following functionality:

• Install Icinga2 on a Debian/Ubuntu/RedHat/CentOS client.
• Configure the client as Icinga2 client by automatically running the node wizard and obtaining a ticket from the master.
• Add the client to an already existing Icinga2 master/satellite, using Top Down Command Endpoint configuration mode (https://www.icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/#top-down-command-endpoint).
• Make it possible to define the services that should be monitored on the Icinga2 client.

This would furthermore need the following changes regarding the directory structure of the formula:

• Move the current configuration for the icinga2 master in a state called icinga2.master.
• Add the aforementioned configuration for the icinga2 client to a state called icinga2.client.
• Check for files that can be used for both states and place them accordingly.

If this enhancement is favored, I can contribute via a pull request. Moreover it would be interesting to see who is currently active and responsible for this repository.

The other possibility would be to create a new repository in the group saltstack-formulas with only functionality for configuring and adding clients (e.g. icinga2-client-formula).

Thanks.

Hey Community,
i have studied the icinga2 formula and i see that there always the use of the default config folder "/etc/icinga2/conf.d".
So for our company we set up a distributed monitoring with HA Icinga2 Master with Agents like described in the official docs here:
https://icinga.com/docs/icinga-2/latest/doc/06-distributed-monitoring/#high-availability-master-with-agents

After finding static entries of default conf.d path i see for now no possibility to use this formula for our distributed monitoring setup.
static entries of conf.d in config.sls line 79:
{%- set path = "{}/conf.d/hosts/{}".format(icinga2.config_dir, host) %}

So for now i can't see that it is possible to use the formula for described setup right?
Am i right so far?

Thanks for help. :)
Best regards,
Darkentik

Formulas iterating over dictionaries should use the items() method instead of iteritems() because the latter method has been removed from Python 3. While the items() method in Python 2 uses more memory than iteritems(), these dictionaries are typically small (e.g., sets of settings from Pillar).

Hi,
why is it not possible to run the Installation with CentOS or Redhat?
Is there a way to run the pkg installation with CentOS or Redhat? Not only debian and Ubuntu?

Thanks

@martinhoefling @puneetk
First of all: Thank you for sharing your code and time!

I'd like to get this formula to work with current Icinga2 on FreeBSD and Ubuntu 16.04. There seem to be many useful commits floating around on GitHub but no PRs. Instead of creating another standalone fork I'd rather work through the Issue list, fix the bugs and place my work on top of that. (So much thought went into this piece of software, work should be continued.)

What I plan on doing:

• Use the os*map pattern much like https://github.com/saltstack-formulas/openvpn-formula/blob/master/openvpn/map.jinja
• FreeBSD support
• Update pillar.example
• keep backwards compatibility

Questions I have:

• Am I welcome to do that?
• @martinhoefling is there a (technical) reason you stopped merging your ongoing development back into this formula?

Greetings
Alex

The instances.ini configuration file provided by the monitoring module has been renamed to commandtransports.ini
Compare https://github.com/Icinga/icingaweb2/blob/master/doc/02-Installation.md#-upgrading-to-icinga-web-2-200

#13

When you define a host in the pillar the formula tries to create a new conf file under conf.d/hosts/ but because the directory doesn't exist by default it will fail.

NRPE has been sort of left aside on icinga2.
Agent allows for secure transport and also allows high amount of checks per minute

Hey,
i wonder why here are included more than icinga2 states such like postgresql, that have their own formula.
I think this is not a good idea.
According to my other question about HA setup with satellites and more, i think that it would be better to focus on icinga2 components only.
Maybe we could split icingaweb2 as own state into its own formula.
In our company we follow a service splitting concept so we have our icinga stack with icinga master, icingaweb2, mariadb server, grafana and influxdb all on separate virtuell machines on each location.

I am interested in hearing your opinions.

Best regards,
Darkentik

Hi,

have you ever tested the nrpe-server part "standalone" ? ;)

    Data failed to compile:
----------
    Rendering SLS "base:icinga2.nrpe-server" failed: Jinja variable 'dict object' has no attribute 'defaults'; line 14

---
[...]
      - file: /etc/default/nagios-nrpe-server

/etc/default/nagios-nrpe-server:
  file.managed:
    - contents: |
{%- for key, value in icinga2.nrpe.defaults.iteritems() %}    <======================
        {{ key }}={{ value }}
{%- endfor %}

/etc/nagios/nrpe_local.cfg:
  file.managed:
[...]

---

and the repository is only included into the main init.sls...
=> should be moved to e.g. repository.sls and then with

include:
  - .repository

added to the monitoring client + server each.

Bests

Hi,
icinga2.classicui will fail when on Debian Jessie, as mod_version is statically linked and therefore no module load file is available.

#13