Setting up signal-cli on Linux
Setting up the Signal console client is a bit clunky, but not hard. First you need a Linux distribution which features
glibc>=2.29, check this first with
ldd --version.As always my distribution is Debian (Bullseye), if you are using Arch or some other distribution, you can check, if the library requirements which I will build from scratch, may already be packaged. You also need a phone number, which isn’t registered with Signal yet, to which you may receive calls or text messages once at registration. I just used my landline.
You will need the following repositories:
Go to the signal-cli project-root and build it:
Go to libsignal-client project-root, change to the java-directory and make sure to remove android from the build options, otherwise this will take ages:
Go to zkgroup project-root and build it:
You have to make the built libraries available for Java, either copy them to the java-library path (make sure they are readable for all users) or add them to the LD_LIBRARY_PATH environment variable, whenever you intend to use the signal-cli binary.
To get the default java-library-path execute:
Usually, on Linux, that’s
/usr/java/packages/lib/, though this directory might not exist yet, so:
Or do something along the lines of the following code snippet, to use the environment-variable solution:
Now go to signal-cli project-root. We will have to make some preparations. First, prepare your phone number, if you use a number which does not support SMS, use the
--voice-switch to receive a call instead. Your full phone number means your number, including your country code (including a leading
+) and including your area code (without any leading zeros).
You also need a captcha-token. For this open a browser tab first. Then open the developer console, then make sure to have ‘persist-logs’ on, and only after that navigate to the captcha-generator.
You may or may not actually have to solve a captcha. After you the check succeeded, you will likely get a pop-up to open signal, ignore that and look into the dev-console, there should be something similar to:
Copy everything after
signalchaptcha:// and use it as the token for the
--captcha-argument. Be advised, the token isn't valid very long:
You will now get a SMS/call with the verification-code, which you can use with:
You should consider setting a pin directly after, for help with this and other options use. You have to use
signal-cli receive regularly, otherwise your account will be flagged inactive and potentially deleted. You may omit the
-u option if you only have registered one account with this user on this machine. Data (including private keys) is saved to
~/.local/share/signal-cli/. Here are some of the relevant commands:
Connecting Icinga2 Monitoring
Running the Gateway & Connecting Icinga2
Clone the signal-http-gateway repository.
Add the target number(s) (one per line) to a file called signal_targets.txt in the root directory of the project and execute the server:
The HTTP request must be a POST-request, with Content-Type: application/json and a json-field containing the key “message” with the value being the message you want to send.
The following locations are supported:
You can test your setup with curl:
If you already followed the “Icinga Notifications in Telegram” tutorial in the past, then you don’t have to do anything! It will already work, for all those who are new to it, here is a rundown of how to configure Icinga.
The following part assumes you already have a working Icinga2-instance. Icinga-web is not needed. On most systems just installing Icinga via the package-manager will create a working instance (
apt install icinga2 on Debian). If you don't care about the explanation you can just clone the atlantishq monitoring-tools into /etc/icinga2/monitoring-tools/ and add an
at the end of icinga.conf. Make sure the directory and it’s contents can be read by Icinga. Here’s a breakdown of the contents:
This is the “NotificationCommand”. It’s the actual command executed to send a notification, as you can see, we are just using curl to send a POST request to the server, which will send out the signal message.
However this gets very messy, very quickly so I created a small python-script that emulates the arguments of the mail notification script already in included Icinga, so you can just copy and paste the NotificationCommand for mail notifications (usually in notifications.conf in /etc/icinga2) and replace the path/name.
We then need to apply this notification to something:
By convention we import the mail-service-notification object as a basis, then we define user_groups for which we want to send notification. This (in our case) is not about whom to send notifications, but for which services we send notifications. Usually you just want the icingadmins group here because this group already exists by default and will get notifications for anything (unless you already changed this behavior). If you have a special notification group with additional filters, rules, etc, you can use this group instead (or use a single user with the “user = … “-directive).
Finally “ assign where host.address” is basically an “ assign everywhere” since every service likely has an address. Obviously you could use something more specific here, like assign where host.vars.signal_notifications. Please refer to the Icinga2 Documentation for information about the exact workings of the assign-directive.