What do I need to send a costum notification to any e-mail address?

It is bit off topic. Icinga2, Icingaweb2+Director is running. Sending a custom notification works. BUT, not to an e-mail.

Executing external command: [1575902660] SEND_CUSTOM_HOST_NOTIFICATION;icingaagent;0;Admin;TEST TEST TEST TEST

What do I need? Postfix? How do I connect it to Icinga?

Kind regards

You will need a mail utility and postfix to relay the mails to some smtp relay.
I, for example, install bsd-mailx and postfix on my Ubuntu systems.

In /etc/icinga2/conf.d/commands.conf the notification commands are already defined. Inlcude them in your config (e.g. with a include "conf.d\commands.conf" in your /etc/icinga2/icinga2.conf) and run the kickstart wizard of the Director again.

Then you will need a user object with a mail address specified and a notification template to use the notification commands.
Then create a notification rule, set the user, the states and types you want to be notified for (best done on the user level imo).
The default notification scripts can be found under /etc/icinga2/scripts and they use the present mail uility on the CLI.

1 Like

Partially described in the docs too.

2 Likes

Was looking for that passage, searched for it earlier in the docs at the general notifications chapter :slight_smile: :+1:

So I read the docs but it didn’t get me anywhere. Is there any precise tutorial how setup an e-mail notification?

Where do I create this object and notification template. Do you have an example for both?

Where and how? What is “user level”?

As you are using the Icinga Director, this is where you need to configure those things.
Just have a look at the main menu of the Director, you will find everything there. As the Director is pretty self-explanatory, imo, I’d say just play around with it and create the things needed. in case you encounter problems after the creation/deployment, first check the deployment log inside the Director for errors, then consult the community :slight_smile:

You have the possibility to define the states and types for the notification in two(or more) places.

  1. On the notification apply rule (or the notification template)
  2. on the user object (or the user template)

I would suggest to define them on the user object (e.g. the “operating user” only gets notifications for host DOWN and service CRITICAL) and configure the notification rule/template to have the recovery&UP/OK states and types as well.

1 Like

Look in my first post. Everything is setup in Director. Custom notification is send. My question is where and how can I get a connection to sendmail how do set my domain to finally recieve the sent custom notification.

As we don’t know how you normally send your mail (exchange, gmail,…) I suggest you just search the net for something like postfix mailrelay smarthost for [your mail system]. There should be various tutorials on how to set up postfix to relay mails to some external mailing host.
Here is the very detailed postfix documentation:
http://www.postfix.org/BASIC_CONFIGURATION_README.html

The recipient address has to be set in the user object which then has to be added to the notification apply rule.

1 Like

You’ll need to install a local MTA, mail transfer agent. That can either be Postfix, exim, sendmail. Distributions tend to prefer one of these. That’s unrelated to Icinga itself, other Linux system tools also use the MTA to forward system messages or anything else.

Within their configuration, you’ll need a mail server which is responsible for the sender’s domain and also owns the MX record for the zone (SPF also helps with trust). That’s called a mail relay.

A variety of guides exist on the internet, just google with your distribution name, postfix, mail relay and you’re likely to find one.

Cheers,
Michael

1 Like

Hi - it sounds like you are asking how to set up a proper sendmailer service on your server running Icinga. That is really a separate (Linux “core”) topic.

When I want to test whether my mail sending on an Icinga server works, I just log in as “icinga” in the shell and use the {mail -s some_subject to_normal_mail_address} command. If this works, a std. (or improved) notification script - under /etc/icinga2/scripts as a rule - called by Icinga to send your mail should work. If the simple shell command test doesn’t work, the first place I look is the /var/log/maillog, which is usually quite revealing…

For our std. case for our customer monitoring servers we set up, we ask the customer to name us a “relay host”, that we then configure in the appropriate files under /etc/postfix. This means the Icinga server machine is not actually doing proper sendmailing, but lets an external (customer) machine handle that. If that is of interest, say the word.

P.S.: I just noticed that some of this was already mentioned in the previous 2 posts. Sorry for any repetition.

2 Likes