HBLink3 e i primi passi per creare un network radio

di | 17/10/2019

Questo software, il cui sorgente è disponibile all’ indirizzo https://github.com/n0mjs710/hblink3 è sotto licenza GNU GPL v3, totalmente scritto in python e già reso compatibile con la versione 3, permette di acquisire e distribuire flussi DMR con semplicità e risorse limitate (anche se sempre si consiglia di lavorare su server in datacenter). Per il monitoraggio via web (dashboard) dei vari processi e scambi di dati è disponibile HBmonitor3; anche questo software è scritto in python, da poco portato alla versione 3 e disponibile a questo indirizzo https://github.com/sp2ong/HBmonitor Anche questo software è sotto licenza GNU GPL v3. La premessa è doverosa: prima di addentrarsi nell’installazione e gestione di questi sistemi è prerogativa la padronanza informatica sui concetti di server, sistema operativo linux, reti e linguaggi di programmazione nonchè script di sistema. Altro fattore importantissimo: il collegamento di questi software verso altri sistemi e reti può provocare malfunzionamenti alle infrastrutture se non gestito con metodo e quindi è bene sempre interfacciarsi con i sysop e gestori dei network indicando quello che si sta facendo ed il permesso di farlo. Una cosa è la sperimentazione personale, in casa, un’altra è il collegamento verso altri sistemi. Esiste un gruppo a questo indirizzo  https://dvswitch.groups.io/g/HBlink dove si trovano molte informazioni su questi software e relativo supporto. Fare sempre, prima di postare una domanda, una ricerca nel forum; magari si tratta di argomenti già gestiti ed ampiamente documentati. Tratteremo il mondo HBLink3 in più articoli, ricordiamoci che sono sistemi dinamici e le variazioni alle funzionalità sono molto frequenti quindi cerchiamo sempre di aggiornarci on-line trattando questi scritti come un primo avvicinamento nella comprensione di queste strutture software.

La configurazione si basa su due files: il primo hblink.cfg dove vengono definiti i parametri generali ed i collegamenti, che possono essere di quattro tipologie (di tutte le tipologie possono esistere più collegamenti, prestando attenzione alle porte utilizzate e replicando le relative sezioni):

1. Master: questo tipo di collegamento è quello che permette ai ponti ed agli hotspot di collegarsi al server hblink (da fuori verso il nostro sistema).
2. Openbridge: questo tipo consente di collegare insieme più server hblink, collegare server Brandmeister o IPSC2 per scambiarsi più flussi in unica connessione.
3. Peer: questo tipo consente di collegarsi a server Brandmaister o IPSC2 come se fossimo un ponte od un hotspot MMDVM (dal nostro sistema verso altri network).
4. XLXPeer: simile al precedente, ma usato per collegamenti con reflector XLX e consente di acquisire un flusso DMR legato ad un modulo di quel XLX. Ad esempio collegandosi a XLX039 è possibile acquisire il flusso del modulo B – multiprotocollo Italia (TG90/DMR+ o TG22292/BM) e portarlo nel nostro sistema.

e rules.py, le regole dove vengono “combinati” i vari collegamenti gestiti nel precedente file.

un esempio operativo molto semplice è questo, supponendo di aver definito i seguenti collegamenti nelle sezioni in hblink.cfg:
MASTER-1 di tipo master per uso con hotspot simplex, quindi con tutti i TG (TalkGroup) sul TS2 (TimeSlot 2).
IT-MLINK di tipo peer con il server IPSC2 it.mlink.grupporadiofirenze.net e con la seguente riga

Options: StartRef=4000;RelinkTime=60;TS1_1=7;TS2_1=2225;

che significa per questa connessione sul network DMRPlus: nessun collegamento a reflector, impostazione TG 7 su SLOT 1 e TG 2225 su SLOT 2 in maniera statica (si possono definire fino a 5 TG per SLOT).

BRIDGES = {
‘TG2225’: [
{‘SYSTEM’: ‘MASTER-1′,’TS’: 2, ‘TGID’: 2225, ‘ACTIVE’:False, ‘TIMEOUT’: 3, ‘TO_TYPE’: ‘NONE’, ‘ON’: [2225], ‘OFF’: [4000,], ‘RESET’: []},
{‘SYSTEM’: ‘IT-MLINK’,’TS’: 2, ‘TGID’: 2225, ‘ACTIVE’: True, ‘TIMEOUT’: 15, ‘TO_TYPE’: ‘NONE’, ‘ON’: [], ‘OFF’: [], ‘RESET’: []},
],
‘TG7’: [
{‘SYSTEM’: ‘MASTER-1′,’TS’: 2, ‘TGID’: 7, ‘ACTIVE’:False, ‘TIMEOUT’: 3, ‘TO_TYPE’: ‘NONE’, ‘ON’: [7], ‘OFF’: [4000,], ‘RESET’: []},
{‘SYSTEM’: ‘IT-MLINK’,’TS’: 1, ‘TGID’: 7, ‘ACTIVE’: True, ‘TIMEOUT’: 2, ‘TO_TYPE’: ‘NONE’, ‘ON’: [], ‘OFF’: [], ‘RESET’: []},
],
}

La variabile BRIDGE esplicitata è un dizionario di liste di dizionari, dove la chiave principale è l’etichetta dei flussi definiti (può essere una qualsiasi stringa) sul server hblink, mentre i dizionari elementi delle liste rappresentano le caratteristiche dei flussi associati alle connessioni che vengono condivisi in quel flusso. In questo caso abbiamo due flussi denominati TG2225 e TG7. Il TG2225 è ottenuto condividendo (associando) il TG2225/2 lato MASTER-1 (hotspot collegati) ed il flusso TG2225/2 proveniente dal server IT-MLINK (reflector sperimentale NXDN), mentre il TG7 è ottenuto condividendo il TG7/2 lato MASTER-1 (hotspot collegati) ed il flusso TG7/1 proveniente sempre dal server IT-MLINK.

Questo il significato dei parametri presenti (chiave/valore):

Conviene lasciare sempre attivi senza timeout e senza TG di disconnessione tutti i flussi lato “altri server”, quindi le connessioni openbridge, peer ed xlxpeer ed attivare e disattivare le connessioni lato master per ascoltare o meno i flussi sugli hs/ponti collegati. Nell’esempio sopra i flussi sono entrambi disattivi all’avvio; si attivano in modo statico (senza timeout) con un colpo di PTT sul TG definito (2225 e 7) e si disattivano tutti con il TG4000.

Installazione del software HBLink su Server in Cloud

Si considera l’installazione di HBlink3 ed Hbmonitor3 (versioni per python 3) su una distribuzione linux Debian 9 “pulita” installata su un server in cloud Aruba con queste caratteristiche minime:

Tipo server: VPS SMART Aruba Debian 9
VCPU: 1
RAM: 1 GB
HDD: 20 GB SSD
Accesso: tramite SSH

Consideriamo, per semplicità, di lavorare come root e non consideriamo l’installazione e la configurazione del firewall. Quando tutto sarà operativo e “in produzione” è buona norma attivare le configurazioni di sicurezza necessarie.

Per prima cosa aggiorniamo la distribuzione ed impostiamo il ns. timezone:

apt update
apt upgrade
dpkg-reconfigure tzdata (scegliendo il fuso orario)

A questo punto dopo un reboot spostiamoci nella cartella /srv (cd /srv) e installiamo le librerie necessarie:

apt install autoconf automake libtool patch make cmake bzip2 unzip wget git mercurial
apt install build-essential pkg-config python3 python3-pip python3-twisted
wget -cN https://bootstrap.pypa.io/get-pip.py
python3 get-pip.py

e procediamo con l’installazione del software HBlink:

git clone https://github.com/n0mjs710/HBlink3.git

cd HBlink3/

pip3 install -r ./requirements.txt

cp hblink-SAMPLE.cfg hblink.cfg

cp rules_SAMPLE.py rules.py

ed infine la creazione del servizio (hblink.service) con questo contenuto:

[Unit]
Description=HBlink

After=network-online.target syslog.target
Wants=network-online.target

[Service]
StandardOutput=null
WorkingDirectory=/srv/HBlink3
RestartSec=3
ExecStart=/usr/bin/python3 /srv/HBlink3/bridge.py
Restart=on-abort

[Install]
WantedBy=multi-user.target

copiando il file nella giusta posizione:

cp hblink.service /lib/systemd/system/

Installazione HBmonitor (dashboard):

cd /srv

git clone https://github.com/sp2ong/HBmonitor.git

cd HBmonitor/

chmod +x install.sh

./install.sh

cp config_SAMPLE.py config.py

Modificare il file utils/hbmon.service aggiustando il percorso da /opt a /srv quindi:

cp utils/hbmon.service /lib/systemd/system/

Rimangono adesso da configurare correttamente i tre files: hblink.cfg, rules.py per hblink e config.py per hbmonitor. I dettagli saranno oggetto di prossimo articolo.

Una volta configurato tutto correttamente (con il file rules.py visto in precedenza) ed avviati i servizi possiamo verificare sul server IPSC2-IT-MLINK di essere correttamente connessi (il nostro server stabilisce un link verso il server di un altro network):

e dopo aver collegato un hotspot al nostro sistema HBLink questa è la dashboard:

Come vediamo c’è un HS collegato a MASTER-1 (il nostro sistema), nei bridge IT-MLINK è correttamente connesso (da noi verso altro network), mentre MASTER-1 è disconnesso su entrambi i flussi.

Con la pressione del PTT sul TG 7 sull’hotspot attiviamo il relativo flusso predisponendone l’ascolto:

se premiamo il PTT anche sul TG 2225:

entrambi i flussi sono connessi, ed inizia ad arrivare un flusso presente (QSO in corso). Con il TG 4000 ritorniamo alle condizioni di partenza.

Nei prossimi articoli vedremo di soffermarci su ulteriori funzionalità e configurazioni.

Buone prove e attenzione alla gestione “con metodo” di queste soluzioni che mai devono arrecare problemi a sistemi già in operatività.

Antonio IU5JAE [ antonio.matraia@alice.it ]

http://iu5jae.dyndns.org:8084/

 

Appendice: gestione dei servizi

I due servizi necessari, hblink ed hbmon, si gestiscono con il comando standard systemctl che ha questa sintassi (almeno per il nostro uso):

systemctl <comando> <servizio>

i principali comandi sono:

start – avvia il servizio
stop – arresta il servizio
restart – riavvia il servizio
status – mostra lo stato attuale
enable – avvia il servizio in automatico al boot
disable – disabilita l’avvio automatico

Appendice: rotazione dei Log

Nel caso di server “in produzione” un problema da gestire è quello della rotazione e conservazione dei log. Supponiamo di utilizzare logrotate già installato di default.

Bisogna creare un file di testo in /etc/logrotate.d con questo contenuto (supponendo di aver configurato entrambi i log in /var/log):

/var/log/hblink.log {
# queste due opzioni servono per non chiudere il file di log, altrimenti # si interrompe la scrittura fino al riavvio del servizio
copytruncate
delaycompress
# conserva 7 copie
rotate 7
# rotazione giornaliera
daily
# compressione
compress
# non viene segnalato errore se il file non esiste
missingok
# rotazione solo se il file non è vuoto
notifempty
}

/var/log/hbmon.log {
copytruncate
delaycompress
rotate 7
daily
compress
missingok
notifempty
}

Un altro file di cui bisogna controllare la dimensione è lastheard.log che si trova nella directory log di hbmonitor; per fare questo esiste uno script nella directory utils, sempre di hbmon, che si chiama lastheard. Occorre, dopo aver aggiustato i percorsi al suo interno e commentato le prime due righe, renderlo eseguibile, copiarlo in /etc/cron.daily/ e fare il reload di cron.

Appendice: personalizzazione della dashboard

Hbmonitor ha già al suo interno il server web per la gestione della dashboard (quindi se abbiamo un altro server web installato non possiamo usare la porta 80 nel file di configurazione config.py). Per personalizzarla basta modificare il file index_template.html nella sua directory principale, seguendo gli esempi commentati all’interno. Una volta modificato bisogna riavviare il servizio hbmon.