Posts by mcktr

This forum was archived to /woltlab and is now in read-only mode.

    AFAIK the /etc/aliases are used for local delivery e.g. mails to the "root" user should delivered to the "administrator" user.

    Have you tried the sender_canonical_maps setting?

    1. Modify your Postfix configuration file # vim /etc/postfix/

    2. Add sender_canonical_maps = hash:/etc/postfix/sender_canonicalto your config

    3. Create the given file # vim /etc/postfix/sender_canonical

    4. Add icinga mon@yourdomainhere.tld (on Debian based Distributions nagios mon@yourdomainhere.tld) to that file

    5. Modify the file permissions to ensure that only "root" can read/modify it # chmod 600 /etc/postfix/sender_canonical

    6. Create the Postfix lookup table # postmap /etc/postfix/sender_canonical

    7. Restart/Reload your Postfix daemon

    When Icinga now sends a mail your should see that it is send by "mon@yourdomainhere.tld".

    Some mail provider expect that the authenticated user e-mail address is the same as the sending e-mail address, so you can't send from user "person1@yourdomainhere.tld" a mail with "mon@yourdomainhere.tld" as sender address.


    your Icinga 2 VM can establish a connection to your MySQL IDO database? There should be a log entry about the successful established connection or one if the connection is not successful established. Please also verify that you can establish a connection from your Icinga Web 2 VM to your MySQL IDO database (via CLI mysql client).

    Please also ensure that the ido-mysql feature is enabled.


    please read the FAQ and provide more information about your setup (OS version, etc.).

    Is this your first setup or did you upgrade an existing setup? We need more context to help here.

    I see that you have enabled "ido-mysql" and "ido-pgsql", you should choose only one feature, only MySQL or only PostgreSQL. Also ensure that you have installed the features, they have own packages.


    from the documentation: "It is not necessary that both the master and the client node establish two connections to each other. Icinga 2 will only use one connection and close the second connection if established." This means if the connection between the master and the client ist not established both will try to establish them. Icinga 2 will close the second connection, because it only needs one.

    Factors for choosing one connection direction could be a firewall e.g. if you don't want to open the firewall on your clients for Icinga 2 you can let them to connect to you master. A other factor could be reducing the log entries, every connection will produce a log entry, you can avoid a couple of them when you choose a dedicated direction.

    Choosing a connection direction is not associated with the configuration mode. The configuration mode only says where the configuration is made, for top down this means that the configuration is made on your master and every client/satellite get its configuration from the master.

    I'm giving director a try and I keep running into issues where my deployments are failing because of (presumably) pre-defined objects with the same name from the stock conf.d/* configs. When installing director, is there a recommended way to remove the cruft from the stock configs or maybe import first? This is a stock icinga2 install, I haven't added anything manually yet.

    It is a common and recommended way to disable the recursive inclusion of the conf.d directory. You can achieve that by editing the icinga2.conf file.

    Code: icinga2.conf
    1. [...]
    2. // include_recursive "conf.d" // disable the recursive inclusion
    3. include "conf.d/api-users.conf" // include the api authentication and permission settings

    When I first started the director wizard it imported the command definitions, but that was it. No templates for hosts or services, or the default hosts and services were imported. Did I miss something or is this intentional? I understand that it's not a great thing to use director and textual edits to define objects simultaneously, but do I really need to set all of the default objects in director from scratch?

    The Director wizard only import the command definitions from the Icinga Template Library (ITL). Hand crafted configuration files or the example configuration below the conf.d directory will not be touched/read during the wizard.

    It is also a recommended way to use one configuration method, either hand crafted configuration files or the Director for example. This avoids that you get multiple objects with the same name, which will fail during config validation.


    I assume that you use the Icinga 2 REST API for command transport, right?

    Please verify that the API credentials are correct. You can find the credentials that Icinga Web 2 is using in the following file /etc/icingaweb2/modules/monitoring/commandtransports.ini.

    // edit: You can also view/edit the current credential settings in Icinga Web 2. You can read more about inside the Icinga Web 2 documentation.…oc/05-Command-Transports/

    The actual credentials and permissions on which the Icinga 2 API "listens" you can find inside the api-users.conf inside your conf.d directory. Please also read the documentation about the authentication against the API…inga2-api/#authentication


    please show us your zone/endpoint, host and template configuration.

    This appears to work but I don't understand how or why? I haven't defined any host.vars.client_endpoint - is this set to by default?

    I am guessing that inside your template, that your host object has imported, the custom variable client_endpoint is set to the host name.

    Please share the configuration files, than we can explain it based on this.

    You can limit the access on specific notification objects with the director/notification/apply/filter-by-name setting. I did a quick test and for editing only notifications I need the following permissions module/director and director/notifications.

    Looks like this:

    After reading through the linked issue in the one I shared above, I assume that it should work, but I cannot guarantee it that this has no side effects.

    As far as I understand the issue, Icinga 2 will store utf8 data nonetheless that the character set is latin1. What you need to do is set the character set to latin1 in Icinga Web 2 for your Icinga 2 database resource.

    I did also a couple of tests and setting the character set to latin1 in Icinga Web 2 and added comments and downtimes that contains "íéáűőúöüó", they didn't crash Icinga 2.

    Please re-read the issue over here: maybe I totally overlooked something.


    hast du mal in die icinga2.log Datei reingeschaut, ob dort übermäßig viele Einträge zu einem bestimmten Ereignis zu finden sind?

    Welche Version des Windows Agent läuft auf deinem Windows Host? Hast du ggf, den User abgeändert, mit dem der Icinga 2 Windows Dienst läuft?