Back to the Future: Icinga2 notifications via XMPP

The commonly used method of notifying users in Icinga2 is (similar to other systems) sending an email. For more urgent and mobile notifications SMS, voice calls and a few other options are possible.

The grow and spreading of chat services made the ussage of such a service the obvious next step (or at least a great gadget). There are scripts for Slack, Rocket Chat, Matrix, Telegram, naturally IRC and, from hearsay, Iridium. As one might have deducted from the head line, the topic here is one more service, namely XMPP/Jabber (Jabber is the deprecated name of the protocol).

XMPP is a free standard (as in freedom, not only as in “free beer”), extensible and there are several implementations for server and client. Although it is not well known, the scope of application is huge. A small example are the chat services of several big tech companies which were simply based on XMPP at the beginning (and also mostly based on free software). Of course, as they grew, this environment was converted to a “walled garden”. The communication follows a procedure similar to email, a client (meaning the device of a user) connects to a server and hands over a message. This message will then be transfered to the target server (if necessary), which will deliver it to a user’s device. Comparably to email, XMPP is intented as a federated system; everybody can (in principle) operate a server and communicate with everybody else.
Accordingly an user is identified by a JID, consisting of a local part (user name) and a domain part in the form of user@domain.tld.

There are three reasons for notifications via XMPP:

  1. In general a second channel for notifications is useful, because the first one might fail. If the mail setup breaks down, nobody gets notified about it (or anything else anymore).
  2. XMPP is a very flexible and powerful protocol and a user can be notified in a short time span and on a wide range of devices (if the device is online or supports a PUSH-like behaviour). Additionaly an XMPP infrastructure of the necessary size can be operated without the need for external dependencies.
  3. The author of this article is a XMPP fan and wants to advertise XMPP a bit. Especially as an alternative to proprietary services of companies with questionable intent.

On the question of the implementation, there are several samples available, for example this article, which appeared in this blog. After six years an update seems appropriate though. Two details  are especially relevant here:

  1. The migration from Python2 to Python3.
  2. The XMPP library used there is deprecated.

For those reasons this variant was developed, but the usage of enviroment variables for the handover of sensible data (login credentials) is not (yet) supported, if one uses the Director for configuring this script. Addiotionaly the sleekxmpp library is deprecated. These and a few other change are implemented in this version, which is the reason and topic of this article.

If one wants to receive XMPP notifications from Icinga2, the ability to send XMPP messages in general is needed, meaning at least an account on a server, for example conversation.im or jabber.at. Alternatively the infra structure could be self operated, for example with an instance of ejabberd. As for dependencies of the script itself, Python3 with standard libraries and the slixmpp library is needed. The script has to copied to a fitting directory (possible /etc/icinga2/scripts) and the configuration from the icinga2_configdirectory has to be integrated in the icinga2 configuration. Especially the path of the script and the details of the sending and the receiving xmpp account have to replaced.

An example for this in action looks like this in conversations:

The whole thing is rather minimalistic at this point and helpful ideas, critic or proposals are welcome.

Finally there isn’t anything left, but to hope, that this might be helpful for someone. If this is the case, it would be really nice to hear about it 🙂

Lorenz Kästle
Lorenz Kästle
Consultant

Lorenz hat seinen Bachelor der Informatik an der FAU gemacht und sich zuletzt mit Betriebssystemen dort beschäftigt. In seiner Freizeit beschäftigt er sich ein wenig mit XMPP und der Programmiersprache Erlang.

NETWAYS stellt sich vor- Lorenz Kästle

This entry is part 1 of 30 in the series NETWAYS stellt sich vor

 

Name: Lorenz Kästle

Alter: 28

Position bei NETWAYS: Consultant

Bei NETWAYS seit: Juni 2020

 

 

 

Wie bist du zu NETWAYS gekommen und was genau gehört zu Deinem Aufgabenbereich bei NETWAYS?

Ich wollte nach dem Studium etwas Sinnvolles machen und der Open Source-Ansatz von Netways schien mir da passend zu sein.
Auf diese Weise leiste ich vielleicht einen kleinen Beitrag zur Verminderung des riesigen Bergs an proprietärer Software.

Als Consultant betreue ich Kunden und richte die Softwarelösungen
bei Kunden ein und passe sie an die jeweiligen Bedürfnisse an.
Zusätzlich wird den Kunden der Umgang mit den Programmen vermittelt.

 

Was steht bei dir gerade an?

Ich bin noch in der Anfangsphase und lerne gerade alles kennen was ich für die künftige Arbeit bei NETWAYS benötige.

 

Was machst Du, wenn Du mal nicht bei NETWAYS bist?

Ein wenig mit der eigenen Infrastruktur basteln und etwas an der
langen Liste von ToDos knabbern

 

Wie geht es in Zukunft bei Dir weiter?

¯\_(ツ)_/¯

Lorenz Kästle
Lorenz Kästle
Consultant

Lorenz hat seinen Bachelor der Informatik an der FAU gemacht und sich zuletzt mit Betriebssystemen dort beschäftigt. In seiner Freizeit beschäftigt er sich ein wenig mit XMPP und der Programmiersprache Erlang.