Node-Red Control Dashboard for AllStarLink 3

I’ve recently built a new AllStarLink (ASL) node for my MB7IBW gateway that I have recently brought up on air on the 2m band.

AllStarLink 3 has a lot of changes in it when compared to the previous version and this of course impacts my Node-Red Control Dashboard that I’ve been using to manage my first ASL node for well over a year now.

To build the node I used the RaspberryPi imager and added the AllStarlink 3 image as detailed on the allstarlink.org website.

Installing the system this way makes it pretty easy compared to previous installs but, it comes with some quirks which cause issues with Node-Red.

From the outset the plan has always been to have AllStartLink 3 and Node-Red running on the same Pi4 to keep it totally self contained. This was easy enough to achieve and works without issue.

Node-Red Control Dashboard for AllStarLink 3
Node-Red Control Dashboard for AllStarLink 3

Installing Node-Red onto a Pi4 is really easy and is fully documented on the Node-Red Website.

Once the AllStarLink 3 operating system was installed on my SD card, booted and operational I installed Node-Red. I soon realised that there were a few things I had to do before loading the Node-Red flow.

AllStarLink 3 no longer logs connect and disconnect messages in the connectlog like it did in AllStarLink 2. To get logging working again I had to create two new BASH scripts as detailed below and put them into /etc/asterisk/myscripts.

For the connect information I created the BASH script as detailed below.

#!/bin/bash

# /etc/asterisk/myscripts/connectlog.sh

echo $1 Connected $2  on $(date +"%T") - $(date +"%m-%d-%Y")  >> /var/log/asterisk/connectlog

For the disconnect information I created the 2nd script detailed below.

#!/bin/bash

# /etc/asterisk/myscripts/disconnectlog.sh

echo $1 Disconnected $2  on $(date +"%T") - $(date +"%m-%d-%Y")  >> /var/log/asterisk/connectlog

Once these scripts were created I had to change the ownership and privileges as detailed below.

cd /etc/asterisk/myscripts
chown asterisk:asterisk ./*
chmod 750 ./*

I also had to change ownership/privileges of /etc/asterisk/myscripts.

cd /etc/asterisk
chown asterisk:asterisk ./myscripts
chmod 755 ./myscripts

Once the two scripts were in place I had to alter the asterisk config so that it called the scripts as part of the connect/disconnect process.

I found the connpgm and discpgm entries in /etc/asterisk/rpt.conf and changed them as shown below.

connpgm = /etc/asterisk/myscripts/connectlog.sh

discpgm = /etc/asterisk/myscripts/disconnectlog.sh

Next I disabled the temporary filesystems that are used by default for the apache and asterisk logging as it’s useful to keep the apache logs for debugging and I needed the asterisk logs for the Node-Red dashboard.

Disabling the temporary file system is very easy to do, just edit the /etc/fstab and comment out the two lines as shown below.

# Comment out the next line for persistent Apache logs
#tmpfs  /var/log/apache2        tmpfs   defaults,noatime,nosuid,nodev,noexec,mode=0775,size=32M 0 0

# Comment out the next line for persistent Asterisk logs
#tmpfs  /var/log/asterisk       tmpfs   defaults,noatime,nosuid,nodev,noexec,mode=0775,size=32M,uid=102,gid=106 0 0 

# Note: These lines are wrapped, should be on 1 line in the /etc/fstab

Once the entries in the /etc/fstab were commented out I rebooted the Pi4 to get persistent filesystems.

The final thing that had to be done was to allow user repeater to use sudo without a password so that it could be used to perform reboot/shutdown/process restart as user root from within the dashboard.

# /etc/sudoers

# Allow repeater sudo without password
repeater ALL=(ALL) NOPASSWD: ALL

Once this was all done I imported the Node-Red flow, configured the SSH nodes with login credentials for the Pi4 (important to use the user repeater for SSH), clicked deploy and the dashboard was ready for use.

Node Red AllStarLink3 Control Dashboard Flow
Node Red AllStarLink3 Control Dashboard Flow

I’ve been using the dashboard for a few weeks now and it’s running perfectly, without error.

If you want to build your own Node-Red Control Dashboard for your AllStarLink 3 node then, just download the flow using the button below and import it into your flow editor.


More soon …

Power surge kills UPS/RAID Array and more

Ever since we moved into the village of Eyke we’ve suffered with power cuts and power surges. It’s been that bad that we have a number of uninterruptible power supplies (UPS) dotted around the house to keep important things running when the power goes out.

Of late it’s been getting worse, not just the power cuts but, the power bouncing on and off very quickly for period of 10-15secs when the power comes back on. Unfortunately we had a particularly bad power bounce when the power came back on and it killed the main UPS for the IT equipment rack and also took out my RAID storage array that I use for backups.

On top of this the main server computer also took a hit and its solid state (SSD) drives started to fail. This left me in a position where I had no backups to recover from and had to get all the data off the running virtual machines (VMs) before the SSDs failed.

My old server that I decommissioned some months ago was now my radio shack PC and so had a desktop operating system on it and lots of HAM radio software installed and configured but, I needed to press it back into service as a server again, very quickly!

So after backing up the desktop data I rebuilt the computer as a server again and began the tedious job of building new VMs and migrating the configuration and data over from the old VMs.

You’re probably wondering why I didn’t just transfer the VMs over hole to the replacement server?
To do this I’d need to shut them down to get a clean snapshot however, when I tried it with a small, unimportant VM it became corrupt during the shutdown process and could no longer be transferred to the replacement server.

Not wanting to take the risk with any of the other VMs due to having lost all the backups, I decided to replicate all the VMs manually. Needless to say this isn’t a 5min job!

So, after a rather long week rebuilding everything I now have all the services up and running on the replacement server and the damaged server ready to be stripped down to an empty case and rebuilt from scratch.

This has meant that at times my M0AWS Blog, The Matrix server and other online services have been offline for short periods but, sadly there was nothing I could do about it. Unfortunately the national grid/power companies take no responsibility for such events and say they only guarantee the frequency of the mains power (50Hz) not the voltage!

The last entry in the old UPS log was an over voltage alert showing 1000v!

With a new UPS in place and online, we’ve already had a number of power cuts and it’s handled them well, lets hope we don’t get another big one!

Backups are now running again on external drives that are disconnected when not in use to protect them from power surges and all the services successfully migrated over to the replacement server.

More soon ….