Configurazione di un sistema “tipo” HBLink3
Come visto in precedenza i files di configurazione sono tre: due riguardano hblink (hblink.cgf e rules.py) ed uno hbmonitor (la dashboard, config.py). Vediamo in dettaglio una configurazione “tipo” molto semplice, ma comunque facilmente adattabile alle proprie esigenze.
Per prima cosa dobbiamo definire bene (scrivendolo su di un foglio) cosa vogliamo fare in quanto da questa specifica deriva tutto il resto, quindi:
- Quanti master vogliamo gestire ?
- Quali flussi vogliamo gestire ?
- Quali sorgenti abbiamo a disposizione ?
- Come vogliamo gestire i flussi sui master ?
Supponiamo di voler gestire 2 master (i nostri server dove si collegano a noi i sistemi hostspot e ripetitori), uno per gli hotspot simplex e l’altro per quelli duplex e/o ponti ripetitori; 5 flussi: 222/BM – 2241 – 22251 – 22292/BM (90/DMR+) – 8 (cluster tra i ns. sistemi sul TS2). Abbiamo a disposizione il server DMRPlus IPSC2-IT-MLINK ed il server BM 2222.
Da ogni connessione di tipo PEER (flussi verso altri network, in uscita dal nostro server) possiamo prelevare due flussi, uno per TS (TimeSlot). Avremo quindi bisogno di due connessioni come dalla seguente tabella:
Supponiamo di attivare questa gestione dei flussi (S = statico – D = dinamico):
ed utilizziamo il TG4000 (standard prassi) per scollegare tutti i TG dinamici attivati prima dello scadere del timeout.
Prendiamo in esame il file hblink.cfg (le variazioni suggerite rispetto ai valori del file di esempio hblink-SAMPLE.cfg che si trova con il software sono indicate tra parentesi quadre); in questo file sono presenti diverse sezioni: la prima è GLOBAL dove vengono impostati i parametri globali. Si può lasciare com’è; in questa sezione possiamo impostare le varie regole (ACL) di accesso e di registrazione ed i parametri ping_time e max_missed con cui vengono controllate le connessioni ai master.
[GLOBAL]
PATH: ./
PING_TIME: 5
MAX_MISSED: 3
USE_ACL: True
REG_ACL: PERMIT:ALL
SUB_ACL: DENY:1
TGID_TS1_ACL: PERMIT:ALL
TGID_TS2_ACL: PERMIT:ALL
Nella sezione REPORTS, che contiene i parametri relativi ai report via socket, non dobbiamo cambiare niente. Questi parametri li ritroveremo nella configurazione di hbmonitor
[REPORTS]
REPORT: True
REPORT_INTERVAL: 60
REPORT_PORT: 4321
REPORT_CLIENTS: 127.0.0.1
Nella parte LOGGER impostiamo i parametri relativi ai log generati da hblink come il LOG_FILE che lo possiamo impostare a var/log/hblink.log, LOG_HANDLERS che specifica come vengono generati i log lo possiamo impostare a console-timed (solo visualizzazione a schermo),file-timed (attenzione a non mettere spazi). Nel file sono elencate le varie opzioni possibili ed infine il livello di log che può essere abbassato ad INFO
[LOGGER]
LOG_FILE: /tmp/hblink.log [/var/log/hblink.log]
LOG_HANDLERS: console-timed [console-timed,file-timed]
LOG_LEVEL: DEBUG [INFO]
LOG_NAME: HBlink
Nelle due sezioni successive, ALIASES ed OPB-1, disabilitiamo (FALSE) solo la connessione OBP-1 in quanto nella prima è configurata la gestione degli elenchi (utenti, TG, ecc.) che vengono regolarmente scaricati da internet e nella seconda c’è un esempio di collegamento con protocollo OpenBridge che non verrà preso in considerazione in questo articolo
[ALIASES]
TRY_DOWNLOAD: True
PATH: ./
PEER_FILE: peer_ids.json
SUBSCRIBER_FILE: subscriber_ids.json
TGID_FILE: talkgroup_ids.json
PEER_URL: https://www.radioid.net/static/rptrs.json
SUBSCRIBER_URL: https://www.radioid.net/static/users.json
STALE_DAYS: 7
[OBP-1]
MODE: OPENBRIDGE
ENABLED: True [False]
IP:
PORT: 62035
NETWORK_ID: 3129100
PASSPHRASE: password
TARGET_IP: 1.2.3.4
TARGET_PORT: 62035
USE_ACL: True
SUB_ACL: DENY:1
TGID_ACL: PERMIT:ALL
Passiamo adesso a configurare le nostre connessioni MASTER (ingresso) e PEER (uscita, scambio flussi). Come da tabelle precedenti nel nostro esempio abbiamo 2 MASTER che chiameremo M-SIMPLEX ed M-DUPLEX e 2 PEER che chiameremo IT-MLINK-01 e BM-2222-01 Per le connessioni master i parametri di interesse sono (gli altri sono ovvi, comunque possiamo lasciare quelli di default):
[MASTER-1] [M-SIMPLEX]
MODE: MASTER
ENABLED: True
REPEAT: True
MAX_PEERS: 10
EXPORT_AMBE: False
IP: [<IP INTERFACCIA DI COLLEGAMENTO CON HS>]
PORT: 54000 [62030]
PASSPHRASE: s3cr37w0rd [passw0rd]
GROUP_HANGTIME: 5
USE_ACL: True
REG_ACL: DENY:1
SUB_ACL: DENY:1
TGID_TS1_ACL: PERMIT:ALL
TGID_TS2_ACL: PERMIT:ALL
duplichiamo l’esempio e creiamo anche il secondo collegamento master:
[MASTER-1] [M-DUPLEX]
MODE: MASTER
ENABLED: True
REPEAT: True
MAX_PEERS: 10
EXPORT_AMBE: False
IP: [<IP INTERFACCIA DI COLLEGAMENTO CON HS/PONTI>]
PORT: 54000 [62031]
PASSPHRASE: s3cr37w0rd [passw0rd]
GROUP_HANGTIME: 5
USE_ACL: True
REG_ACL: DENY:1
SUB_ACL: DENY:1
TGID_TS1_ACL: PERMIT:ALL
TGID_TS2_ACL: PERMIT:ALL
Ovviamente tutti i client connessi ad un master condividono i flussi dei peer, per evitare questo bisogna definire un master per ogni hotspot/ponte collegato. Non rimane che configurare le due connessioni PEER. Per queste connessioni i parametri sono molto simili a quelli utilizzati con MMDVM: vediamo i principali, gli altri sono ovvi:
[REPEATER-1] [IT-MLINK-01]
MODE: PEER
ENABLED: True
LOOSE: False
EXPORT_AMBE: False
IP:
PORT: 54001 [<PORTA CHE DEVE ESSERE UNICA SUL SERVER HBLINK>]
MASTER_IP: 172.16.1.1 [it-mlink.grupporadiofirenze.net]
MASTER_PORT: 54000 [55555]
PASSPHRASE: homebrew [PASSWORD]
CALLSIGN: W1ABC [<CALL CON CUI ACCEDE AL SERVER>]
RADIO_ID: 312000 [<ID CON CUI ACCEDE AL SERVER>]
RX_FREQ: 449000000
TX_FREQ: 444000000
TX_POWER: 25
COLORCODE: 1
SLOTS: 1 [3 = attivo SLOT 1 e SLOT 2]
LATITUDE: 38.0000
LONGITUDE: -095.0000
HEIGHT: 75
LOCATION: Anywhere, USA
DESCRIPTION: This is a cool repeater
URL: www.w1abc.org
SOFTWARE_ID: 20170620
PACKAGE_ID: MMDVM_HBlink
GROUP_HANGTIME: 5
OPTIONS: [StartRef=4000;RelinkTime=60;TS1_1=22251;TS2_1=2241;]
USE_ACL: True
SUB_ACL: DENY:1
TGID_TS1_ACL: PERMIT:ALL
TGID_TS2_ACL: PERMIT:ALL
duplichiamo l’esempio e creiamo anche il collegamento al server BrandMeister. In questo caso i flussi associati ai TS si dovranno gestire dall’account su “self care” brandmeister, come da seguente immagine:
[REPEATER-1] [BM-2222-01]
MODE: PEER
ENABLED: True
LOOSE: False
EXPORT_AMBE: False
IP:
PORT: 54001 [<PORTA CHE DEVE ESSERE UNICA SUL SERVER HBLINK>]
MASTER_IP: 172.16.1.1 [bm2222.dmrbrescia.it]
MASTER_PORT: 54000 [62031]
PASSPHRASE: homebrew [PASSWORD]
CALLSIGN: W1ABC [<CALL CON CUI ACCEDE AL SERVER>]
RADIO_ID: 312000 [<ID CON CUI ACCEDE AL SERVER>]
RX_FREQ: 449000000
TX_FREQ: 444000000
TX_POWER: 25
COLORCODE: 1
SLOTS: 1 [3]
LATITUDE: 38.0000
LONGITUDE: -095.0000
HEIGHT: 75
LOCATION: Anywhere, USA
DESCRIPTION: This is a cool repeater
URL: www.w1abc.org
SOFTWARE_ID: 20170620
PACKAGE_ID: MMDVM_HBlink
GROUP_HANGTIME: 5
OPTIONS:
USE_ACL: True
SUB_ACL: DENY:1
TGID_TS1_ACL: PERMIT:ALL
TGID_TS2_ACL: PERMIT:ALL
la configurazione delle connessioni è terminata. Adesso dobbiamo configurare, tramite il file rules.py, la gestione dei flussi acquisiti inserendo quanto necessario.
Il nostro file contiene la definizione di una variabile di nome BRIDGES che è un dizionario (python) i cui valori chiave sono le etichette dei flussi che vogliamo definire a livello di server hblink ed i relativi valori sono liste a loro volta composte da dizionari con le caratteristiche dei flussi relativi alle connessioni che vogliamo “unire”, ricordando il significato dei parametri:
BRIDGES = { 'TG222': [ {'SYSTEM': 'M-SIMPLEX', 'TS': 2, 'TGID': 222, 'ACTIVE': False, 'TIMEOUT': 10, 'TO_TYPE': 'ON', 'ON': [222,], 'OFF': [4000,], 'RESET': []}, {'SYSTEM': 'M-DUPLEX', 'TS': 1, 'TGID': 222, 'ACTIVE': True, 'TIMEOUT': 10, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []}, {'SYSTEM': 'BM-2222-01', 'TS': 1, 'TGID': 222, 'ACTIVE': True, 'TIMEOUT': 10, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []}, ], 'TG22292': [ {'SYSTEM': 'M-SIMPLEX', 'TS': 2, 'TGID': 22292, 'ACTIVE': False, 'TIMEOUT': 10, 'TO_TYPE': 'ON', 'ON': [22292,], 'OFF': [4000,], 'RESET': []}, {'SYSTEM': 'M-DUPLEX', 'TS': 1, 'TGID': 22292, 'ACTIVE': False, 'TIMEOUT': 10, 'TO_TYPE': 'ON', 'ON': [22292,], 'OFF': [4000,], 'RESET': []}, {'SYSTEM': 'BM-2222-01', 'TS': 2, 'TGID': 22292, 'ACTIVE': True, 'TIMEOUT': 10, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []}, ], 'TG22251': [ {'SYSTEM': 'M-SIMPLEX', 'TS': 2, 'TGID': 22251, 'ACTIVE': False, 'TIMEOUT': 10, 'TO_TYPE': 'ON', 'ON': [22251,], 'OFF': [4000,], 'RESET': []}, {'SYSTEM': 'M-DUPLEX', 'TS': 2, 'TGID': 22251, 'ACTIVE': False, 'TIMEOUT': 10, 'TO_TYPE': 'ON', 'ON': [22251,], 'OFF': [4000,], 'RESET': []}, {'SYSTEM': 'IT-MLINK-01', 'TS': 1, 'TGID': 22251, 'ACTIVE': True, 'TIMEOUT': 10, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []}, ], 'TG2241': [ {'SYSTEM': 'M-SIMPLEX', 'TS': 2, 'TGID': 2241, 'ACTIVE': True, 'TIMEOUT': 10, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []}, {'SYSTEM': 'M-DUPLEX', 'TS': 2, 'TGID': 2241, 'ACTIVE': True, 'TIMEOUT': 10, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []}, {'SYSTEM': 'IT-MLINK-01', 'TS': 2, 'TGID': 2241, 'ACTIVE': True, 'TIMEOUT': 10, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []}, ], 'TG8': [ {'SYSTEM': 'M-SIMPLEX', 'TS': 2, 'TGID': 8, 'ACTIVE': True, 'TIMEOUT': 10, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []}, {'SYSTEM': 'M-DUPLEX', 'TS': 2, 'TGID': 8, 'ACTIVE': True, 'TIMEOUT': 10, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []}, ], }
if __name__ == '__main__': from pprint import pprint pprint(BRIDGES)
Vediamo in dettaglio il primo flusso definito:
'TG222': [
questo e il nome del flusso, si può mettere qualsiasi stringa essendo una chiave del dizionario, deve essere unica
{'SYSTEM': 'M-SIMPLEX', 'TS': 2, 'TGID': 222, 'ACTIVE': False,
tutti i flussi di M-SIMPLEX devono stare sul TS2 ed avendo definito il TG222 come dinamico non deve essere attivo all’avvio
'TIMEOUT': 10, 'TO_TYPE': 'ON', 'ON': [222,], 'OFF': [4000,], 'RESET': []},
supponiamo di lasciare attivi per 10 minuti i TG dinamici, ovviamente verrà attivato da un PTT su quel TG e potrà essere disconnesso con il TG4000 prima dello scadere del tempo
{'SYSTEM': 'M-DUPLEX', 'TS': 1, 'TGID': 222, 'ACTIVE': True, 'TIMEOUT': 10, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []},
su M-DUPLEX abbiamo definito il TG222 come statico sul TS1 quindi deve essere attivo all’avvio, senza timeout e senza possibilità di scollegarlo
{'SYSTEM': 'BM-2222-01', 'TS': 1, 'TGID': 222, 'ACTIVE': True, 'TIMEOUT': 10, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []},
il flusso del TG222 viene acquisito da BM sul TS1, le connessioni verso i server esterni si lasciano sempre attive
],
gli stessi ragionamenti valgono per gli altri: una particolarità ce l’ha il TG8 che essendo interno al server hblink non ha la parte relativa alla connessione peer. Nel compilare questo file bisogna prestare molta attenzione a non creare loop o comunque malfunzionamenti sulle reti esistenti che andiamo a collegare, una prima regola da rispettare che evita loop indesiderati è sicuramente quella di inserire un solo peer per ogni flusso che definiamo.
Prima di avviare il servizio hblink, per verificare che almeno la sintassi del file rules sia corretta, si può lanciare il comando (dalla directory di hblink):
python3 ./rules.py
se non ci sono errori visualizzerà il contenuto della variabile BRIDGES.
L’ultimo file da modificare è il config.py di hbmonitor che possiamo lasciare quello di default (config_SAMPLE.py) o al limite modificare la descrizione, la porta del server web ed il percorso del file di log a var/log/
REPORT_NAME = ‘Dashboard of local DMR network’
CONFIG_INC = True
LASTHEARD_INC = True
HOMEBREW_INC = True
BRIDGES_INC = True
HBLINK_IP = ‘127.0.0.1’
HBLINK_PORT = 4321
FREQUENCY = 10
WEB_SERVER_PORT = 8080
CLIENT_TIMEOUT = 0
PATH = ‘./’
PEER_FILE = ‘peer_ids.json’
SUBSCRIBER_FILE = ‘subscriber_ids.json’
TGID_FILE = ‘talkgroup_ids.json’
LOCAL_SUB_FILE = ‘local_subscriber_ids.json’
LOCAL_PEER_FILE = ‘local_peer_ids.json’
FILE_RELOAD = 7
PEER_URL = ‘https://www.radioid.net/static/rptrs.json’
SUBSCRIBER_URL = ‘https://www.radioid.net/static/users.json’
LOG_PATH = ‘./log/’
LOG_NAME = ‘hbmon.log’
A questo punto non resta che avviare i due servizi hblink e hbmon in maniera demone o come processo sempre attivo, e controllare il tutto dalla dashboard che dovrebbe essere simile a questa:
Ricordo ancora una volta che sono sistemi e soluzioni software molti dinamici, controllare sempre sui siti degli sviluppatori la presenza di ultime versioni e relative funzionalità aggiunte e/o modificate. Operare con giudizio evitando qualsiasi possibile malfunzionamento ai sistemi/network esistenti e soprattutto informare sempre i gestori (sysop) dei server di quello che vogliamo andare a fare nel caso si prevedano interconnessioni verso l’esterno. Chi installa questi server deve essere in grado di manuternerli, aggiornarli e soprattutto avere piena conoscenza dei protocolli e delle reti, nonchè di Linux.
Buone prove, Antonio IU5JAE [ antonio.matraia@alice.it ]