These are scripts that I have written myself for use in my homelab. Most of them are designed to be used as services managed by systemd, whereas some of them are either used as one-off tools or I have chosen to run them regularly with cron. I have included the systemd service and timer files, also written by me, for those which I control using systemd.
Most of the scripts also make use of Discord webhooks to send an alert to a Discord server when something happens, and also ping the user if their numerical ID is specified in-place of discordID.
They aren't perfect or tidy by any means, some may have unused functions or variables in them and in some places it probably would've been more sensible to use variables, but they work for what I've made them for.
This collection of files make up a heartbeat server and corresponding client which trigger a Discord webhook when a device stops reaching out to the server, and then trigger another one when that device comes back online.
The client service endlessly sends HTTP requests to the server which tells the server that the client device is online.
The server is a very simple HTTP server listening for any incoming connections which it assumes to be the client device alerting it that it's online. This does mean that it assumes the odd web-crawler to be the client device alerting it that it has come back online, but it works fine for my use-case. You can adjust the timeout to specify how long the server should allow before assuming the client device has gone offline. I have this service running on a third-party server outside of my home network. There is no content in the requests and responses passed between the client and the server, so these services make use of very little resources on both devices.
The server also alerts the Discord webhook of it's own status. When it is started, the heartbeatstatenotify.sh script is executed with the "success" argument, which tells me it's online. When the server is stopped via systemd, the systemd service is configured to execute the notify script with the "fail" argument to let me know the server is not currently listening for heartbeats.
The heartbeat server's alerts in action:
This script updates an instance of the Minecraft Bedrock dedicated server software for Linux and only sends out the status regarding the update process via a Discord webhook if there is an update available. I had this running through cron at 3am, however the download website changed and the script currently doesn't work as it should.
An example of the script working:
The day the script experienced the changed website:
The Minecraft server is managed using supervisord, which I gave a Python script to run that manages the up/down notifications. Will also upload that when I find it.
This script simply rips all the tracks from an audio CD to FLAC format using adcde which is configured to place them in a certain "processing" directory. Once that has complete, the sometimes lengthy description that abcde recieves from MusicBrainz is removed from each track, and then each track is placed into an artist/album directory structure. Once the tracks are organised correctly, beets is used to confirm that the metadata for each track is correct, which is configured to then move them to a directory used by Navidrome, which is a software that hosts the music collection as a streaming service. I chose to do this as it allows for a selection of unorganised tracks from various CDs to be placed in the "processing" directory and then organised by this script, so that beets can load them correctly.
A lot of the time, beets will mark tracks with the incorrect release dates which is understandable if the track came from a deluxe edition or album remaster, however sometimes an album has been quietly re-released maybe to update the copyright information, label or something else insignificant to the listener, and I have ended up with a copy of such a re-release. In such cases, the actual and original release date is usually still a part of the FLAC metadata so when I notice that Navidrome is displaying a suspicious release date for an album, I can run this script in the album's directory which replaces the release date metadata with the original release date metadata.
This is a simple service that I was using before writing the heartbeat scripts. It simply pings a specified domain 4 times and sends an alert when it stops receiving responses, and another one once it starts receiving them again. This script was useful, but only verified that the home network had an internet connection, and not whether the devices in the network were stil connected to it.
This script monitors the CPU temperature of the device it is running on and reports to the Discord webhook whenever the temperature surpasses a specified value. This script is run every 5 seconds using a systemd timer. On devices other than Raspberry Pis, I have modified versions of the script to get the temperature of each CPU core and calculate the average to get the CPU's average temperature.
The script in action:
My main server is always connected to a VPN mainly for encryption and IP masking as it participates in torrent swarms for legitimate data-archival efforts. The OpenVPN server is managed by myself and hosted on a third-party server. These scripts let me know the status of the VPN connection on my main server.
This is the main script and is executed by systemd and the OpenVPN client software whenever the connection status of the VPN changes. The accompanying systemd service is configured to execute the script with the "fail" argument whenever the service is stopped, such as when the machine is shut down or rebooted, which will let me know that the machine isn't currently connected to the VPN. The OpenVPN config file includes a line to execute the script with the "success" argument when the VPN connection comes back up, which alerts me that the machine is connected to the VPN again and also tells me the what the machine's public IP address is for clarity. The OpenVPN client has to execute the script via the wrapper script, as it doesn't complete the connection until every part of the config has completed, the wrapper script circumvents this by forwarding on the argument to the actual script and launching it as a background process. Temporary files keep a record of the last notification triggered to avoid multiple being sent out whilst the OpenVPN client attempts to reconnect.
The script's notifications in action when rebooting the client device:
