Issue: I need to get a notification if a necessary volume on my Linux device is not mounted, as this volume cannot get automatically mounted because a passphrase is required. The curl-request is dependent on the custom DNS (Pi-hole).
When setting up my Intel NUC I decided that all my persistent data of the running docker containers should be stored on an encrypted volume which I encrypted with Luks (a good read for doing this can be found here). Unlocking an encrypted volume can either be done by using a passphrase or by creating an USB dongle. Having a dongle connected the entire time would defeat the meaning of an encrypted volume, so I decided to unlock it by passphrase.
This might cause some trouble when the device reboots (due to power outage or other unforeseen circumstances) as it’s hard to notice if the device rebooted. After such an event it is important to immediately unlock the encrypted volume and restart the docker containers which are using this partition. So some kind of health check on the encrypted volume has to be done.
Creating a health check on the mount of the volume is a rather easy task. I decided to just grep the output of lsblk and check if the mount is in there. If that is not the case then I want to send a notification to my devices by using Pushbullet. This can be done with a simple curl request to the API. However all my tests failed and the notification could not be sent – this is where it’s getting interesting.
Because one of the running containers is a custom DNS server (Pi-hole, which also functions mainly as an adblock) which needs access to its files on the encrypted volume, the DNS server doesn’t start correctly (because the encrypted volume is not mounted at this point). When the DNS server is not running, requests to the Pushbullet API cannot be resolved. I have found myself in some kind of deadlock situation.
However fixing this issue is not very hard. One way would be to move the config files of Pi-hole to the unencrypted partition, so that Pi-hole is able to start without the encrypted volume beeing mounted and can serve DNS requests so that the alarming script can communicate with the Pushbullet API. But I want all my docker volumes and the files to stay on the encrypted partition, so this possibility was out of question.
The method I decided to pursue was a different one. Because the internet connection was established after a reboot and just the DNS resolution was not possible, I decided to resolve the Pushbullet API by using another DNS server (and not the custom one). A way to do this is by using the dig command. When sending a curl request it is possible to add the custom resolve of a hostname. This can be done by using the following argument:
--resolve <host to be resolved>:<the port>:<the actual ip>
By levering this possibility I wrote a very simple shellscript which retrieves the IP of the pushbullet api by using the Google DNS server and uses this IP to forge a curl request. The shell script has to be run by passing the access token for Pushbullet as the first argument.
./checkLuksMount.sh <access token>
#!/bin/bash CHECK=`lsblk | grep /media/enc` if [ -z "$CHECK" ] then PUSHBULLET_IP=`dig @8.8.8.8 api.pushbullet.com | grep "ANSWER SECTION" -A 2 | grep -v -e CNAME -e "ANSWER SECTION" | cut -f5` curl --resolve api.pushbullet.com:443:$PUSHBULLET_IP --silent --output /dev/null --header "Access-Token: $1" --header 'Content-Type: application/json' --data-binary "{\"body\":\"NUC Luks Volume not mounted /media/enc \",\"title\":\"NUC Mount Alarm\",\"type\":\"note\"}" --request POST https://api.pushbullet.com/v2/pushes fi
I’ve added a cronjob which just executes this shell script and therefore checks if the encrypted volume is mounted. If the NUC reboots and the mount is lost (or: not yet unlocked) I will get a notification and can use a simple shellscript over SSH from e.g. my phone to unlock the volume. I just have to enter the passphrase. By doing this the mount is health checked and there is no security issue whatsoever.
Android Backups - Nextcloud vs. Resilio Sync - IT-obey!
[…] work the encrypted partition has to be available, which it will be not after a reboot for example. My most recent post deals with the concept and checking if the mount is […]