How to integrate Alerta alerts with Zulip

Zulip (https://zulip.com) is an open source messaging system that has a unique threaded chat model with topics for threads. Alerta (https://alerta.io) is on open source alert management tool that aggregates alerts from various sources and displays them on an easy to use web interface.

In addition to displaying alerts, Alerta can also be set up to send notifications to various external tools such as Telegram and Slack. At the moment there is no explicit way to send the alerts to Zulip instead. However, Zulip does support Slack style incoming webhooks as a compatibility feature through which we can push notifications to Zulip streams (like channels or chat rooms in Zulip lingo).

Please refer to the documentation on how to install and use Zulip1 and Alerta2 if you don’t already have them running. You also have to create a Zulip bot to be able to receive incoming webhooks from Alerta.

Once you have your Zulip bot (with its API key) and you have enabled the Slack plugin3 in Alerta, all you have to do is set the SLACK_WEBHOOK_URL as in the example below:

https://DOMAINNAME/api/v1/external/slack_incoming?api_key=API_KEY&stream=STREAM_NAME&topic=TOPIC

For testing make sure you’re logged into Zulip with your usual user and joined the stream you have configured above to see the incoming messages. After that all you have to do is either send Alerta a fake alert using its JSON API or wait for one of your services to fail and create an alert.


  1. Zulip’s Slack style incoming webhook documentation: https://zulip.com/integrations/doc/slack_incoming ↩︎

  2. Alerta documentation: https://docs.alerta.io ↩︎

  3. Alerta Slack plugin: https://github.com/alerta/alerta-contrib/tree/master/plugins/slack ↩︎


253 Words

2021-09-15 00:00 +0000

Install fdupes (or other small program) on FreeNAS

FreeNAS (now TrueNAS) does not have access to FreeBSD’s ports or packages. Normally extra software needs to be installed in jails. However sometimes you need software on the host itself. It is possible to copy program binaries from the jail to the host if you take care of a few things first.

It is not advised to install packages on an appliance such as FreeNAS. For this reason FreeNAS does not come with FreeBSD packages or ports. In these situations you’re supposed to create a jail and install the software you need inside that jail instead. However you might prefer to have some basic utilities on the host itself. In my use case I thought fdupes would be much more useful if it had access to all my disks directly. The following instructions are fdupes, a duplicate file finder, but it will work for sufficiently small utilities for which there is a package on a similar FreeBSD version. For large programs the dependencies might be too big to handle.

First you need to have a copy of the binary you need. You can get it from an existing FreeBSD installation or pkg install it in a FreeNAS jail. Make a directory on Freenas such as ‘~/bin/fdupes’ to keep things tidy. Move the binary you have into this directory. You can try running it now. If you’re lucky it will just run. That means it either does not need to load any system libraries to work or the libraries it needs are already part of FreeNAS.

If it didn’t work on the first try, you will see an error message about a missing library. Currently for fdupes on FreeNAS the missing library would be libpcre2-32.so.0 - a perl style regular expression library. You can also run ‘ldd ./fdupes’ to list the libraries it needs and which of them are missing. Here’s some sample output.

root@freenas ~/bin/fdupes]# ldd fdupes
fdupes:
        libpcre2-32.so.0 => not found (0)
        libncursesw.so.8 => /lib/libncursesw.so.8 (0x80025e000)
        libc.so.7 => /lib/libc.so.7 (0x8002c0000)
[root@freenas ~/bin/fdupes]#

Identify the missing libraries and copy it from the machine which donated you the fdupes binary to the same directory where you placed fdupes on FreeNAS. Running ldd there will help you identify its location without having to deal with multiple symlinks pointing to the same library.

In order to run a binary on unix systems without installing its required dynamic libraries systemwide, you can pass the location of the dynamic library as an environment variable. This is all a long way of saying you should do the following

[root@freenas ~/bin/fdupes]# ls -1
fdupes
libpcre2-32.so.0
[root@freenas ~/bin/fdupes]# LD_LIBRARY_PATH=/root/bin/fdupes \
                         /root/bin/fdupes/fdupes

If you run this you will see that fdupes is indeed possible to run right now. Example:

[root@freenas ~/bin/fdupes/tmp]#  LD_LIBRARY_PATH=/root/bin/fdupes \
                         /root/bin/fdupes/fdupes -r /root/bin/fdupes
/root/bin/fdupes/libpcre2-32.so.0
/root/bin/fdupes/tmp/libpcre2-32.so.0

/root/bin/fdupes/fdupes
/root/bin/fdupes/tmp/fdupes.sh

/root/bin/fdupes/fdupes
/root/bin/fdupes/tmp/fdupes

That’s pretty cool. To make it a little bit more user friendly, we can put the LD_LIBRARY_PATH in a script which you can call directly, remembering to have it also handle command arguments meant for the actual binary we’re calling. You can call the script anything but if you want to call it just fdupes for ease of use, you first have to rename the fdupes binary to something else, like fdupes.bin. Then create a new script called fdupes. Make sure both have executable permissions. Here’s the contents of our new fdupes script.

[root@freenas ~/bin/fdupes/tmp]# cat fdupes.sh
LD_LIBRARY_PATH=/root/bin/fdupes  /root/bin/fdupes/fdupes.bin $*

Now you can call /root/bin/fdupes (or put it in PATH and run it directly) from anywhere on the system with your usual fdupes parameters (that’s the $* part).