Quando scrivo un articolo di solito tendo sempre a non dare per scontato quello che vado a descrivere, per questo motivo farò 2 accenni ai prodotti a cui faccio riferimento, e successivamente come abbinarli correttamente fra loro.
E’ un comodo servizio che è in grado di fornirvi accesso al vostro pc/server/raspberry, con sistema operativo gnu/linux, anche se questi sono collegati dietro una rete che non vi fornisce un ip pubblico, quindi quando il dispositivo è dietro una rete non raggiungibile direttamente dall’esterno (es. connessione tramite 3g, o wisp che non forniscono ip pubblico).
Dopo essersi registrati viene fornito uno script python con un token univoco che, una volta lanciato sul dispositivo, installerà il necessario per il funzionamento e, in fine, vi fornirà accesso alla porta 22 SSH e 80 HTTP tramite un tunnel gestibile direttamente dal vostro browser collegandosi alla loro interfaccia web (è disponibile anche un app per ios/Microsoft Store/android).
il primo dispositivo è gratuito, mentre per gli altri dovrete pagare un abbonamento.
Inutile dilungarsi troppo su questo prodotto noto a tutti i radioamatori, attualmente è lo “standard de facto” per gestire modem e gateway digitali radioamatoriali (hotspot o ripetitori), il tutto comodamente da interfaccia web leggera e veloce.
Fatte le dovute premesse, passiamo al “problema”.
Come molti di voi avranno avuto modo di valutare, PI-STAR è in grado di mantenere la propria “solidità” e garantire all’utente un funzionamento “out-of-the-box” grazie al proprio “recinto” costruito attorno al sistema operativo; vale a dire che, pur essendo un sistema operativo basato su raspbian (debian per raspberry), e pur mantenendone tutte le caratteristiche funzionali, gli sono stati creati di proposito dei vincoli da parte dello sviluppatore per evitare che un intervento sul sistema da un utente più smaliziato possa comprometterne il funzionamento e l’installazione dei futuri aggiornamenti che vengono periodicamente rilasciati.
Questi vincoli implicano, fra l’altro, filesystem in sola lettura di default, specifici permessi a file e directory, script che ad ogni riavvio ripristinano file all’interno di specifiche directory, e proprio su quest’ultimo punto mi soffermerò nelle prossime righe.
La prima volta che ho provato ad installare dataplicity su pi-star ho riscontrato una spiacevole anomalia, infatti il dispositivo restava raggiungibile solo fino a quando non si effettuava un riavvio del sistema, a quel punto non era più possibile in alcun modo ripristinarlo.
Non vi nego che, per mancanza di tempo e anche per un pizzico di pigrizia, inizialmente l’escamotage fu abbastanza bizzarro e insolito, ma di rapida soluzione, infatti per un periodo facevo disinstallare l’agent e reinstallarlo automaticamente ad ogni avvio del pi-star, ma questo comportava un ritardo notevole all’avvio del sistema e un deciso grado di complessità che non giovava certamente alla stabilità, ma successivamente ho indagato dando una rapida occhiata ai log e su cosa accadeva al PI-STAR durante il riavvio.
La conclusione è stata fortunatamente molto semplice, il servizio di dataplicity che fornisce il tunnel chiamato supervisor, genera i suoi file di log di default in /var/log/dataplicity , tutto normale direte, se non fosse che pi-star ad ogni riavvio si prende il disturbo di eliminate dai log tutto quello che non fa parte del suo default, fra cui anche la directory in questione, e ovviamente supervisor non riusciva più a partire non trovando più il percorso dei log.
Fortnatamente il servizio supervisor prevede un file di configurazione che trovate in /etc/supervisor/supervisord.conf
Aprendolo vi troverete un file simile a questo, e come potete notare dalle righe evidenziate, ho modificato il percorso su cui il servizio va a scrivere i log /var/log/dataplicity/supervisord.log semplicemente eliminando la directory dataplicity e facendo scrivere i suoi log direttamente in /var/log
; supervisor config file[unix_http_server]
file=/var/run/supervisor.sock ; (the path to the socket file)
chmod=0700 ; sockef file mode (default 0700)[supervisord]
logfile=/var/log/supervisord.log ; (main log file;default $CWD/supervisord.log)
pidfile=/var/run/supervisord.pid ; (supervisord pidfile;default supervisord.pid)
childlogdir=/var/log ; (‘AUTO’ child log dir, default $TEMP); the below section must remain in the config file for RPC
; (supervisorctl/web interface) to work, additional interfaces may be
; added by defining them in separate rpcinterface: sections
[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface[supervisorctl]
serverurl=unix:///var/run/supervisor.sock ; use a unix:// URL for a unix socket; The [include] section can just contain the “files” setting. This
; setting can list multiple files (separated by whitespace or
; newlines). It can also contain wildcards. The filenames are
; interpreted as relative to this file. Included files *cannot*
; include files themselves.[include]
files = /etc/supervisor/conf.d/*.conf
Una volta garantito un percorso valido per i log, tutto torna a funzionare regolarmente ad ogni riavvio.
Buona sperimentazione e al prossimo………”problema”