unfoxo

3 milioni di richieste al giorno, zero CDN: l'ottimizzazione di CoMaps

2026-04-19T00:00:00+02:00

CoMaps è un’applicazione di navigazione Open Source che utilizza i dati di OpenStreetMap come base cartografica. Uno dei suoi punti di forza è la capacità di funzionare completamente offline, scaricando le mappe in anticipo o a mano a mano che si esplora.

L’app fornisce pacchetti compressi e distillati dai dati di OpenStreetMap, che includono solo le informazioni utili a una navigazione di tutti i giorni. In questo modo con pochi GB è possibile ottenere mappe sempre disponibili e una ricerca completamente offline.

Non è dato sapere quanti siano gli utenti effettivi¹ (in quanto non ci sono nè tracking nè statistiche), tuttavia fornire mappe di alta qualità su una scala così grossa e soprattutto mantenendo la privacy degli utenti è una sfida infrastrutturale interessante.

Lo scopo di CoMaps è quello di abbandonare CDN commerciali e utilizzare per una serie di nodi indipendenti gestiti direttamente dai volontari del progetto. In questo modo, il traffico passerebbe esclusivamente attraverso soggetti realmente coinvolti e allineati con gli obbiettivi del progetto, senza intermediari.

Da Aprile 2026 unfoxo offre a CoMaps il nodo “comaps-it1”.

È realmente una CDN?

L’obbiettivo di una CDN è quello di portare i dati il più vicino possibile all’utente: i dati vengono copiati e distribuiti su diversi nodi che coprono maggior numero possibile di aree geografiche differenti. In questo modo, in qualsiasi luogo si trovi l’utente, statisticamente avrà almeno un nodo abbastanza vicino da cui scaricare i dati nel modo più veloce possibile. Nodi più vicini significano anche costi del traffico inferiore e maggiore resilienza.

Lo scopo della “CDN” di CoMaps è diverso: ogni client si connette a nodi casuali e scarica solo le regioni della mappa in formato compresso. In questo modo diventa quasi impossibile capire, correlando le richieste di un utente in particolare, la sua posizione esatta.

In più, essendo gli stati divisi in sezioni molto grossolane e non in “tiles” (i “quadretti” classici delle altre app di navigazione), nel caso peggiore è possibile conoscere solo una posizione molto approssimata dell’utente.

L’architettura del nodo comaps-it1

In una CDN il server http è ciò che si contrappone tra utente e dati: è quindi necessario che sia efficiente e ottimizzato.

Filesystem: Bcachefs su SSD SATA, con caching nvme
Sistema operativo: Alpine Linux
Web Server: Nginx

Per la sincronizzazione il team di CoMaps utilizza sftp, che è stato installato su un container separato con permessi di scrittura solo nella cartella che verrà poi servita dal nodo.

Bcachefs è stato scelto per la possibilità di poter creare un archivio a due “strati”: davanti, i dischi nvme eccellono in velocità e ricevono tutte le scritture e le letture dei dati più “caldi”.

I dischi SATA, al contrario, vengono utilizzati come archivio per i dati utilizzati meno, fornendo lo spazio necessario ma a un costo molto inferiore e con una longevità maggiore.

Alpine Linux è stato scelto per la leggerezza e la semplicità: si tratta del sistema operativo su cui si basano moltissime immagini di Docker, ma eccelle anche utilizzato come sistema operativo base e si avvicina molto bene al metodo “old school” di gestione di server.

Il server web non è un elemento critico: siccome la banda è il limite per questo progetto, qualsiasi server web probabilmente l’avrebbe saturata. In questo caso ho deciso di usare nginx per la familiarità e la possibilità di agire sia come server statico che come proxy.

Ottimizzazione delle performance

Il server è stato avviato con le impostazioni di default per un periodo iniziale e il logging attivo, in modo da poter stabilire una baseline. Il server, sostenuto dalla pool SSD, era in ogni caso in grado di saturare la WAN attraverso il quale era collegato.

Sono sorte però opportunità per ottimizzare ancora di più il sistema: un carico minore significa meno consumo di energia, una durata più lunga dei componenti ma anche la possibilità di dirigere quel carico verso altri compiti più importanti.

La legge di pareto

Chiunque abbia avuto a che fare con grandi numeri conoscerà sicuramente la legge di Pareto. Statisticamente, il 20% delle cause genera l‘80% degli effetti.

Ciò significa che, se riusciamo a individuare e ottimizzare “il 20%” responsabile del lavoro, potremo teoricamente ottenere l‘80% di performance in più.

Ho quindi raccolto un giorno di log. In totale sul server sono passate all’incirca 3 milioni di richieste.

Utilizzando uno script bash, possiamo estrarre facilmente solo le richieste relativamente alle mappe dividerle per stato:

## sed -n 's/.*\/260405\/\([^_.]*\).*/\1/p' access.log | sort | uniq -c | sort -nr | awk '{cnt[NR]=$1; name[NR]=$2; total+=$1; lines=NR} END {for(i=1;i<=lines;i++) 
printf "%8d %6.2f%% %s\n", cnt[i], (cnt[i]/total)*100, name[i]}'
  934949  32.25% France
  532499  18.37% Germany
  252621   8.71% US
  148178   5.11% Italy
   98293   3.39% Netherlands
   86948   3.00% Spain
   61763   2.13% Belgium
   57862   2.00% Austria
   53080   1.83% Switzerland
   51552   1.78% World
   50985   1.76% Canada
   49935   1.72% UK
   [... altri stati qui ...]

Dai log emerge chiaramente: l‘80% del traffico è generato da soli 12 stati su 220. Nel nostro caso il 5% causa l‘80% del traffico. Possiamo quindi concentrarci nell’ottimizzare questa piccola parte per ottenere un risultato nettamente migliore.

La ram non usata è ram sprecata

Sin da subito è emersa un’inefficienza del sistema: la maggior parte delle richieste leggeva direttamente dal disco. Un operazione comunque efficiente grazie all’utilizzo degli SSD ma che, in caso di altri carichi concorrenti, avrebbe sicuramente causato rallentamenti.

La causa era semplice: Linux utilizza pesantemente la ram libera come cache del disco, e il container dedicato al server web aveva solo 512MB allocati. Poichè buona parte della memoria era occupata dal sistema stesso, il server era costretto a “buttare via” i dati appena letti senza poterli tenere in memoria.

Dando invece a Linux la giusta quantità di RAM, possiamo fare in modo che la sfrutti al meglio riempiendola con i dati più “caldi” provenienti dal disco.

Questa “pienezza” è in realtà solo apparente, ed infatti la memoria usata per il caching può essere liberata immediatamente nel caso un altro software ne abbia bisogno. Non tutti ne sono a conoscenza e addirittura esiste un sito web dedicato che spiega bene il concetto.

A quanto corrisponde il 5% individuato prima? Possiamo scoprirlo sommando la dimensione di tutti gli stati che lo compongono:

## du -ch France_* Germany_* US_* Italy_* Netherlands_* Spain_* Belgium_* Austria_* Switzerland_* World* Canada_* UK_*
[...]
38.7G   total

Ho quindi allocato al server web circa 40GB di RAM, in modo da dare l’opportunità al sistema di tenere in memoria buona parte di quei file. Nel giro di qualche ora il sistema riportava di averne usati 39.3G (colonna buff/cache).

## free -h
              total        used        free      shared  buff/cache   available
Mem:         125.7G       39.4G        3.0G        1.9G       39.3G       40.3G

Ciò ha causato un immediata discesa dell’utilizzo del disco, che da un utilizzo medio di 15MB/s con picchi di 60MB/s si è stabilizzato a circa 5MB/s con picchi di 10MB/s (praticamente un terzo), con una curva sempre più bassa a mano a mano che l’algoritmo ottimizzava i file più letti.

L’effetto benefico della RAM aggiuntiva appare ancora più evidente dal grafico della pressione IO, che indica la percentuale di tempo “persa” ad aspettare che i dischi siano disponibili.

Chi ha bisogno di atime?

Risolto il nodo delle letture frequenti, rimane un altro fatto di cui tener conto: le scritture frequenti.

Anche se leggendo un file questo non viene effettivamente “modificato”, tra i propri metadati contiene l’ultima volta che ha subito un accesso.

Questo dato viene aggiornato dal sistema operativo ed è visualizzabile con il comando stat:

## stat World.mwm 
  File: World.mwm
  Size: 53104836        Blocks: 103728     IO Block: 4096   regular file
Device: 800h/2048d      Inode: 5518608     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/ UNKNOWN)   Gid: ( 1000/ UNKNOWN)
Access: 2026-04-18 10:28:45.836942564 +0000
Modify: 2026-04-06 07:03:48.000000000 +0000
Change: 2026-04-07 07:01:31.892520553 +0000

Ciò significa che ad ogni file scaricato, anche nel caso il file sia presente in RAM, corrisponde una piccola scrittura che aggiorna quel valore. È utile in caso di audit o per tenere un elenco di file recenti, ma nel nostro caso siccome ogni file ha accessi continui, perde completamente di significato.

Non si tratta di molto traffico, ma è comunque possibile disattivarlo aggiungendo le opzioni di mount noatime o lazyatime.

Le due opzioni devono essere messe nel file /etc/fstab e causano i seguenti effetti:

noatime: la data di accesso non viene mai aggiornata
lazyatime: la data di accesso viene aggiornata solo in concomitanza con una modifica (che avrebbe comunque causato una scrittura) o passate 24 ore dall’ultimo aggiornamento

Nel mio caso ho abilitato globalmente lazyatime sull’intero filesystem: controllare il tempo di accesso può essere comodo per capire se alcuni file sono utilizzati o no, e i log di accesso permettono comunque di tirare fuori i timestamp esatti nel caso sia necessario.

Quelle continue scritture

Non ci avevo mai fatto caso, ma la totalità di traffico in scrittura del server web era causata dal file access.log, aggiornato ad ogni visita. Ogni richiesta generava una riga, e ogni riga generava una scrittura sul file.

Nginx fornisce tre opzioni aggiuntive da aggiungere alle impostazioni di logging:

access_log /var/log/nginx/access.log privacyfmt gzip buffer=32k flush=10m;

Ecco l’effetto che ha ognuno di queste:

gzip: L’intero log viene compresso al volo con gzip (livello 1). Nel mio caso, 758MB di log diventano 34.4MB (22 volte meno)
buffer=32k: Verrà scritto su disco solo al raggiungimento di 32kb di log in sospeso…
flush=10m: … o finchè non sono passati 10 minuti dall’ultima scrittura

L’unico svantaggio di questo approccio è la possibilità di perdere fino a 10 minuti di log in caso di crash del server. Non ho interesse nel tenere log così granulari, di conseguenza ho applicato queste direttive globalmente.

Nota: al termine ho comunque disattivato i log per policy CoMaps. Il logging iniziale è stato effettuato con un formato che non includeva indirizzi IP e User-Agent (privacyfmt).

Conclusioni

Rendere disponibile il nodo per CoMaps non è solo un modo per contribuire a un progetto Open Source, ma anche l’opportunità di imparare a conoscere le sfide causate da un traffico particolare come quello causato da questa app.

Nonostante il traffico significativo, la presenza di altri nodi contribuisce a distribuire efficacemente il traffico ben sotto la soglia di saturazione. I client sono progettati per scaricare da quanti più nodi possibile in contemporanea e ritentare in caso di errore.

Anche se ci fosse, in futuro, la necessità di limitare il traffico, i client si adatterebbero di conseguenza scaricando da altri nodi più veloci.

Sono felice di fornire questo nodo e vi invito a contribuire anche solo scaricando l’app per provarla e lasciare un’opinione. CoMaps è un progetto relativamente nuovo e serve molto aiuto in tutti i fronti!

Google dice “100K+” download, ma probabilmente ci sono molti più download da F-Droid e altri store alternativi. ↩

Resuscitare un macchinario industriale afflitto da bit rot

2026-04-10T00:00:00+02:00

Il bit rot è un fenomeno che affligge, prima o poi, qualsiasi supporto di memorizzazione digitale. È la tendenza che hanno i supporti a degradarsi nel tempo, causando il capovolgimento di alcuni bit, che da zero diventano uno e viceversa.

In base alla posizione e al significato dei bit che degradano possono accadere varie conseguenze: nella migliore delle ipotesi, il difetto riguarda una parte di memoria non utilizzata o che contiene dati non critici. Nella peggiore delle ipotesi, il bitrot colpisce una parte essenziale del sistema che lo manda completamente in tilt.

L’addon di rete

Questo progetto è nato quando l’interfaccia web di un macchinario industriale ha smesso di funzionare, impedendo al proprietario di raccogliere dati e di monitorarne lo stato. Sebbene il display integrato (collegato a un PLC separato) funzionasse ancora, con la parte web ko diventava sensibilmente più difficile da usare.

L’interfaccia web è gestita da un modulo esterno che si collega alla porta seriale del macchinario e agisce da “tramite”. Al suo interno è presente un piccolo computer con Linux che legge e scrive i dati su una scheda SD installata al suo interno.

Prima di mettere le mani sul dispositivo, è importante capire le condizioni correnti. Si è avviato? È bloccato? Cosa sta facendo?

Per capire cosa aspettarci da un modulo funzionante al 100%, possiamo leggere il manuale. Ecco alcune informazioni utili:

il DHCP non è supportato: l’unico modo per utilizzare il dispositivo è tramite un IP statico
le credenziali di default sono “guest / guest”
è presente un’interfaccia web in http sulla porta 80

Ottenere l’accesso

Il dispositivo è stato collegato a un router ed è stato analizzato il traffico di rete. Il mio metodo preferito per ottenere l’accesso a un dispositivo è tramite l’utilizzo dell’indirizzo IPv6 link-local, ma sembra che IPv6 sia stato disabilitato, probabilmente a causa dell’età avanzata del dispositivo o di una configurazione intenzionale.

Non conoscendo l’indirizzo IP statico configurato, dobbiamo connetterci direttamente al dispositivo e tentare ogni singolo IP finchè non riceviamo una risposta, con il programma arp-scan.

$ arp-scan -I enp4s0f4u2 192.168.0.0/24
Interface: enp4s0f4u2, type: EN10MB, MAC: 1c:bf:ce:fb:e3:63, IPv4: 192.168.88.52
Starting arp-scan 1.10.0 with 256 hosts (https://github.com/royhills/arp-scan)
192.168.0.102   00:11:0c:0f:7f:bb       Atmark Techno, Inc.

Ora che abbiamo scoperto l’indirizzo IP possiamo riconfigurare la scheda di rete e procedere a una scansione per verificare quali servizi sono ancora attivi.

$ nmap 192.168.0.102
[...]
Host is up (0.00088s latency).
PORT   STATE SERVICE
21/tcp open  ftp
23/tcp open  telnet

Il fatto che FTP e Telnet siano presenti indica che il sistema operativo si è avviato, ma la mancanza di http fa presupporre un problema sul server web. Il server telnet, probabilmente lasciato dagli sviluppatori per comodità, è utile in quanto ci permette di ottenere un accesso diretto alla console del dispositivo.

Prima di tentare un login possiamo connetterci senza credenziali per ottenere ulteriori informazioni sulla dispositivo, leggendo il banner di sistema, che solitamente contiene il nome host e altre informazioni.

$ telnet 192.168.0.102
Trying 192.168.0.102...
Connected to 192.168.0.102.
Escape character is '^]'.

atmark-dist v1.26.1 (AtmarkTechno/Armadillo-440)
Linux 2.6.26-at15 [armv5tejl arch]

WEB-MGR login:

AtmarkTechno è un produttore giapponese di schede embedded, e Armadillo-440 è il nome in codice di una scheda i.MX257 ormai fuori produzione. Fortunatamente, sul loro sito web sono ancora disponibili documentazione e tutto ciò che serve per ripristinare il sistema da zero nel caso fosse necessario.

Il kernel 2.6.26-at15 è stato rilasciato nel 2008, ma consultando l’archivio di Atmark sembra questa versione sia stata utilizzata fino al 2013.

Proviamo ad entrare con le credenziali “guest” presenti sul manuale: nonostante siano relative all’interfaccia web spesso gli sviluppatori, per semplicità, riciclano le password.

WEB-MGR login: guest
Password: *****
[guest@WEB-MGR (ttyp0) ~]$

Successo! Sfortunatamente l’utente guest ha accesso molto limitato alla macchina. Per ottenere un accesso totale è necessario passare all’utente root. Se guest si trova nell’elenco “sudoers”, è possibile farlo con un semplice comando:

[guest@WEB-MGR (ttyp0) ~]$ sudo su -
[guest@WEB-MGR (ttyp0) ~]$

Il comando sudo su - ci riporta immediatamente alla console originale. Accesso negato.

Esistono altri utenti da tentare? Elencando le cartelle presenti all’interno di /home/ possiamo intuire chi ha accesso al sistema.

[guest@WEB-MGR (ttyp0) ~]$ ls /home/
ftp/      guest/    hide/     ho/       mw/       wm/       www-data/

Tra le varie cartelle, hide attira subito l’attenzione: il nome fa pensare a un’utenza di servizio “nascosta” creata dagli sviluppatori. Proviamo ad autenticarci riutilizzando la stessa password di guest.

WEB-MGR login: hide
Password: *****
[hide@WEB-MGR (ttyp0) ~]$ sudo su -
[root@WEB-MGR (ttyp0) ~]#

Root ottenuto! Come in ogni film di hacking che si rispetti, siamo entrati dalla backdoor.

Dov’è il server web?

Ora che possediamo accesso al sistema con root, possiamo leggere e modificare qualsiasi cosa. Per prima cosa, controlliamo se il server è in esecuzione. Usando il comando ps aux otteniamo un elenco dei processi, tra cui però non appare alcun server http.

Prima di continuare dobbiamo capire quale server stiamo cercando. Potrebbe essere nginx, apache2, lighttpd, o magari qualche server embedded base come uhttpd.

Fortunatamente nella cartella /etc/ è presente un file lighttpd.conf, che ci guida direttamente verso il server scelto dagli sviluppatori.

Provando a eseguire lighttpd, veniamo immediatamente fermati da un errore:

[hide@WEB-MGR (ttyp0) ~]$ lighttpd
lighttpd: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory

libz è una libreria esterna, solitamente inclusa nel sistema operativo base, che si occupa di comprimere e decomprimere file. Buona parte dei server web moderni ne ha bisogno per poter implementare la compressione HTTP, essendo le pagine HTML molto propense alla compressione.

All’avvio di lighttpd, uno speciale programma chiamato “linker dinamico” cerca e carica in memoria tutte le librerie di cui il software avrà bisogno. Le librerie di sistema, tra cui libz.so.1, si trovano solitamente all’interno della cartella /lib/, ma il linker effettua una ricerca anche in altre cartelle nel caso sia necessario.

Il fatto che lighttpd ci dica “No such file or directory” indica che la libreria potrebbe essere stata cancellata o corrotta a tal punto da diventare illeggibile.

Save slot 1

Fino ad ora ci siamo limitati a guardare ma non toccare, evitando di causare errori aggiuntivi su una memoria che sappiamo già essere danneggiata.

Per poter lavorare liberamente senza il rischio di distruggere l’unica copia dei dati rimasta, è utile creare una copia di backup del sistema operativo d’origine.

Fortunatamente, avendo già l’accesso root possiamo usare una combinazione di dd e netcat per inviare l’intero contenuto della scheda SD ad un computer a nostra scelta¹. Spostando l’immagine su un computer esterno otteniamo anche la possibilità di utilizzare software molto più moderni e potenti, velocizzando il lavoro.

Dov’è finita la libreria?

Ora che siamo al sicuro, possiamo indagare su che fine abbia fatto libz.so.1.

Un controllo veloce rivela che il file “libz.so.1” esiste, ed è un collegamento al file “libz.so.1.2.3.3”.

Aggiungendo LD_DEBUG=libs prima di un comando, possiamo chiedere al linker di descrivere ogni operazione che compie.


[root@WEB-MGR (ttyp0) ~]## LD_DEBUG=libs lighttpd
   [...]
      2999:     find library=libz.so.1 [0]; searching
      2999:      search cache=/etc/ld.so.cache
      2999:      search path=/lib:/usr/lib/tls/v5l/fast-mult:/usr/lib/tls/v5l:/usr/lib/tls/fast-mult:/usr/lib/tls:/usr/lib/v5l/fast-mult:/usr/lib/v5l:/usr/lib/fast-mult:/usr/lib:/lib/arm-linux-gnueabi/tls/v5l/fast-mult:/lib/arm-linux-gnueabi/tls/v5l:/lib/arm-linux-gnueabi/tls/fast-mult:/lib/arm-linux-gnueabi/tls:/lib/arm-linux-gnueabi/v5l/fast-mult:/lib/arm-linux-gnueabi/v5l:/lib/arm-linux-gnueabi/fast-mult:/lib/arm-linux-gnueabi:/usr/lib/arm-linux-gnueabi/tls/v5l/fast-mult:/usr/lib/arm-linux-gnueabi/tls/v5l:/usr/lib/arm-linux-gnueabi/tls/fast-mult:/usr/lib/arm-linux-gnueabi/tls:/usr/lib/arm-linux-gnueabi/v5l/fast-mult:/usr/lib/arm-linux-gnueabi/v5l:/usr/lib/arm-linux-gnueabi/fast-mult:/usr/lib/arm-linux-gnueabi               (system search path)
      2999:       trying file=/lib/libz.so.1
      2999:       trying file=/usr/lib/tls/v5l/fast-mult/libz.so.1
      2999:       trying file=/usr/lib/tls/v5l/libz.so.1
      2999:       trying file=/usr/lib/tls/fast-mult/libz.so.1
      2999:       trying file=/usr/lib/tls/libz.so.1
      2999:       trying file=/usr/lib/v5l/fast-mult/libz.so.1
      2999:       trying file=/usr/lib/v5l/libz.so.1
      2999:       trying file=/usr/lib/fast-mult/libz.so.1
      [... a bunch of other tries here ...]

lighttpd: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory

Il linker cerca in /lib/, ma poi tenta tutte le altre cartelle che conosce. libz.so.1 esiste ed è in /lib/. Come mai sta venendo ignorato?

È possibile che qualcosa abbia sostituito libz.so.1 con un file completamente diverso? Per curiosità, ho provato a usare lo strumento file, che analizza i file e ne descrive il contenuto:

/lib$ file libz.so.1.2.3.3
libz.so.1.2.3.3: ELF 32-bit LSB shared object, *unknown arch 0x20* version 1 (SYSV)
   can't read elf program headers at 1073741876, missing section headers at 1130896

Ignorando “unknown arch”, l’errore “can’t read elf program headers” rivela il mistero: il file è completamente corrotto.

In cerca di un libz.so.1.2.3.3

Nonostante libz sia inclusa in qualsiasi computer con Linux (e probabilmente anche Windows), non possiamo prendere un file libz qualsiasi e sostituirlo nella cartella di sistema. Man mano che le librerie evolvono, infatti, cambiano il loro funzionamento e le versioni successive diventano incompatibili con quelle precedenti.

In più, questo non è un computer normale, ma è basato su una CPU “ARM”: anche se la libreria fosse corretta, la CPU non saprebbe come interpretarla.

Fortunatamente libz è così diffusa che possiamo dare per scontato che sia inclusa nell’immagine di sistema creata dal produttore. Per ottenere quell’esatta versione, dobbiamo capire quando questa libreria è stata creata e trovare un’immagine di quell’epoca.

## ls -lah libz.so.1*
-rw-r--r--  1 root root  81K 17 nov  2010 libz.so.1.2.3.3

La libreria è stata creata il 17 novembre 2010, esattamente il giorno precedente al rilascio di questa immagine ISO: https://download.atmark-techno.com/armadillo-440/iso/a400_20101118_free.iso

Scaricando l’ISO ed estraendola, otteniamo l’intero contenuto originale della cartella /lib/.

Per precauzione ho confrontato tutte le librerie originali con quelle presenti nella scheda: corrispondevano tutte, tranne libz, che ho sostituito immediatamente.

Secondo tentativo

Ora che la libreria è stata sostituita, possiamo riprovare ad eseguire lighttpd:

[root@WEB-MGR (ttyp0) /bin]## lighttpd
2026-04-08 17:44:12: (../../src/server.c.521) No configuration available. Try using -f option.

L’errore è cambiato: ciò significa che libz è stata finalmente caricata! lighttpd ci sta semplicemente dicendo che non trova un file di configurazione. Proviamo ad fornirgli il file lighttpd.conf trovato prima (e l’opzione -D, in modo che lighttpd non vada in background):

[root@WEB-MGR (ttyp0) ~]## lighttpd -D -f /etc/lighttpd.conf
../../src/configfile.c.792: 0, (null)

Per quanto questo errore possa sembrare criptico, una veloce ricerca indica che si tratta di un problema di sintassi del file di configurazione. Vediamo cosa c’è all’interno:

## lighttpd configuration file
#
## use it as a base for lighttpd 1.0.0 and above
#
## $Id: lighttpd.conf,v 1.7 2004/11/03 22:26:05 weigon Exp $

############ Options you really have to take care of ####################

## [���Ѥ���module������] modules to load

[... normal config file ...]

                              fastcgi.server = (
                   0".app" => (
      !                 "localhost" => (
                "      0    "socket" =>
                               "/tmp/app-Socket.socket"(
                                "max-procs" => 1,
                                "bin-path" => 2/mspec/srg/�pp.rb",
##              !        (      0 "bi�/environment" 5> ("TZ* =. "JST-9")
                       $)               `   �),
 (        � $       ".html" => (
                        "localhost  => (�             �  �           "socket" =>
 0 $                            "/tmp/app/socket2.socket",
  `                             "max-procs" => 1,
                               !"bin-path" => "/chamb/src/route.rb",
!`       "              )
         �          )
##               $    ".rb" => (
##                       "localhost" => (##       (    "                  "/tmp/ruby-socket.socket",
##                               "max-procs" =>"1,
##  $                            "Bin-path" => "/usr/bin/ruby"
##    "     (     (      )
##                    )
                )

Ecco l’esempio perfetto di bitrot! All’interno del file di configurazione, alcuni bit hanno cambiato stato e in base alla loro posizione hanno causato:

caratteri inesistenti o non validi, ora mostrati come “�”
sostituzioni di caratteri con altri: il carattere \n (a capo) prima di "localhost" è diventato uno spazio, unendo due righe
cambi tra maiuscole e minuscole: bin-path è diventato Bin-path

Ed è questo il motivo per cui il bit-rot è così pericoloso: mentre la perdita totale di un file rende il problema immediatamente evidente, il bitrot altera in modo subdolo e graduale i file, fino a quando il sistema diventa troppo degradato per continuare a funzionare. Il pericolo sta nell’ambiguità di non sapere quali file sono intatti, e quali hanno subito variazioni.

In questo caso il bitrot aveva colpito l’inizio e la fine del file, mentre la parte centrale era completamente intatta.

Riscrivere sulle spalle di chi è stato addestrato a riscrivere

La mia conoscenza di lighttpd in combinazione con ruby non è abbastanza approfondita da poter riscrivere il file da capo: di conseguenza ho preso spunto da un metodo utilizzato per addestrare i primi LLM.

BERT (creato da Google nel 2018) è un modello del linguaggio addestrato utilizzato il metodo “MLM” (Masked Language Modeling). Il concetto è semplice: si offre al modello un testo e si sostituiscono alcune parole con il token [mask]. L’obbiettivo del modello è quello di sostituire la maschera con le parole mancanti e ottenere il testo originale.

I modelli neurali moderni, con miliardi di parametri, sono in grado di eseguire questo compito molto bene. Ho sostituito tutti i caratteri corrotti, o che a occhio sembravano invalidi, con il carattere ?, e poi ho utilizzato ollama con un modello locale e il seguente prompt per ricostruire il file.

This attachment is a config file of an old lighttpd server recovered from a corrupted sd card.
The bit rot caused bit flips that modified characters through the entire file.
Non-printable characters were replaced with question marks (?): those are supposed to be corrected.
Be aware of bit flips that cause subtle syntax errors such as missing semicolons, case folding and letter replacements.
Provide a corrected file. Do not rewrite it, reorder options or optimize. Only edit the corrupted parts.

Nonostante il prompt, purtroppo i modelli moderni tendono troppo voler “aiutare” e spesso riscrivono da capo, ottimizzano o rielaborano l’input piuttosto che modificarlo e basta.

Quindi, invece di fidarmi ciecamente dell’output del modello, ho verificato e applicato manualmente le differenze riga per riga, integrando solo le correzioni effettive e ignorando i commenti extra aggiunti dall’LLM.

Nonostante il file di configurazione ora valido e il server in esecuzione, l’interfaccia web era raggiungibile ma mostrava una pagina bianca. Controllando il file di log, è emerso un problema in un file ruby responsabile dell’interfaccia.

Siccome il disco era ormai confermato corrotto e non sapevo con certezza se ci fossero altri file danneggiati, ho deciso di controllarli tutti.

Un file ruby afflitto da bitrot, statisticamente, avrà almeno un carattere non ASCII (�). Quando il comando file analizza un file con caratteri non ASCII lo classifica come “binary data”. Possiamo quindi cercare tutti i file ruby classificati in questo modo per ottenere una lista di quelli corrotti.

## Feed all the *.rb files to the "file" command, then only include lines that match binary data
$ find . -name '*.rb' -exec file {} \; | grep 'binary data'
./RqstHndl.rb: a /usr/bin/ruby -I/chamb/src -Ku script executable (binary data)

Solo RqstHndl.rb è risultato corrotto, ed è stato riparato utilizzando lo stesso metodo adottato per la configurazione sopra.

Successo!

Aprendo l’interfaccia da un browser, è apparsa finalmente l’interfaccia descritta nel manuale:

Sostituzione della SD

L’interfaccia è visibile e funzionante. La scheda SD su cui stava girando, però, aveva già mostrato segni di instabilità. È necessario quindi sostituirla con una nuova e, possibilmente, più longeva.

Aprire l’involucro del modulo è facile: all’interno si trova solo un SBC con una scheda aggiuntiva che mantiene data e ora (RTC) e un’interfaccia RS485 supplementare utilizzata per la connessione al PLC del macchinario.

Il filesystem interno è di soli 2 GB, ma l’uso di una scheda classificata come “High Endurance”, unito alla scelta di una capienza superiore (16GB) per distribuire le scritture su un area più ampia, renderà ancora più improbabile che il difetto accada in futuro (o almeno, entro la dismissione del macchinario).

È stato tentato un nuovo avvio per verificare la compatibilità con la nuova scheda, questa volta osservando tramite porta seriale la presenza di errori aggiuntivi. Non tutto è andato per il meglio:

[... bootloader and kernel boot above ...]
Running local start scripts.
Starting udevd: udevd[164]: add_to_rules: unknown key 'KERN�L' in /etc/udev/rules.d/z99_usb_image_update.rules:1
udevd[164]: add_to_rules: unknown key 'B�S' in /etc/udev/rules.d/z99_usb_image_update.rules:1
udevd[164]: add_to_rules: unknown key 'KERNML' in /etc/udev/rules.d/z99_usb_image_update.rules:2
udevd[164]: add_to_rules: invalid rule '/etc/udev/rules.d/z99_usb_image_update.rules:2'
                                                                done
Loading /etc/config:                                            done
Changing file permissions: udevd-event[227]: run_program: exec of program '/bi�/sh' failed
udevd-event[229]: run_program: exec of program '/bi�/sh' failed

[... infinite loop of run_program ...]

Questi errori ci hanno permesso di individuare altri file da correggere in /etc/profile e /etc/udev/rules.d/. Inoltre, gli errori generavano un loop infinito di scritture nel log di sistema, sommergendo la SD di scritture.

È possibile che questo piccolo errore nella regola udev abbia causato tutti gli altri problemi.

Controllo del filesystem

Prima di dichiarare il sistema sicuro è necessario utilizzare fsck.ext3 sulla partizione per trovare e correggere gli errori rimanenti. Solitamente, fsck corregge gli errori del filesystem e sposta i file orfani o irrecuperabili nella cartella lost+found/.

$ sudo fsck.ext3 -v -y /dev/sdb1
e2fsck 1.47.3 (8-Jul-2025)
/dev/sdb1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Directory entry for '.' in ... (64209) is big.
Split? yes

Directory inode 64209, block #0, offset 12: directory corrupted
Salvage? yes

Pass 3: Checking directory connectivity
'..' in /etc/config.bak (64209) is <The NULL inode> (0), should be /etc (64001).
Fix? yes

Couldn't fix parent of inode 64209: Couldn't find parent directory entry

Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****

/dev/sdb1: ********** WARNING: Filesystem still has errors **********


       4583 inodes used (3.82%, out of 120000)
         39 non-contiguous files (0.9%)
          1 non-contiguous directory (0.0%)
            ## of inodes with ind/dind/tind blocks: 146/1/0
      37720 blocks used (7.86%, out of 479990)
          0 bad blocks
          1 large file

       3687 regular files
        268 directories
        132 character device files
        133 block device files
          0 fifos
 4294967295 links
        353 symbolic links (353 fast symbolic links)
          1 socket
------------
       4573 files

C’è ancora un problema. Ironicamente, è proprio il backup dei file di configurazione a impedire a fsck di riparare il filesystem.

Per capire cosa sta succedendo, dobbiamo fare un passo indietro e spiegare cos’è un inode.

Nei filesystem come ext3, il nome associato al file è solo un etichetta comoda che viene data dall’utente per individuarlo.

I dati reali e i metadati del file (permessi, dimensione, dove si trovano i blocchi fisici sul disco) sono memorizzati in una struttura dati chiamata inode, a cui sono assegnati numeri univoci.

Quando il sistema cerca /etc/config.bak, in realtà va a cercare l’inode associato a quel nome, 64209.

Guardando il report finale di fsck, un valore bizzarro salta all’occhio: il filesystem riporta 4.294.967.295 collegamenti (hard link). Siccome ogni collegamento è, a sua volta, associato a un inode, è tecnicamente impossibile avere più collegamenti che inodes.

In più, il numero corrisponde esattamente a 0xFFFFFFFF, ovvero il più grande numero intero rappresentabile a 32 bit - una coincidenza troppo strana per essere casuale.

Questo valore fuori scala è causato dall’inode 64209, che il sistema associa proprio alla cartella /etc/config.bak, la stessa che sta bloccando fsck.

Purtroppo, tentare di eliminare quella cartella usando il normale comando rmdir causa un crash immediato del sistema. Per risolvere la situazione serve agire a basso livello: dovremo usare debugfs, uno strumento che consente di modificare “chirurgicamente” il filesystem, agendo direttamente sugli inode.

## debugfs -w /dev/sdb1
debugfs 1.47.3 (8-Jul-2025)
debugfs:  stat <64209>
Inode: 64209   Type: directory    Mode:  0775   Flags: 0x0
Generation: 3813769555    Version: 0x00000000:00000000
User:     0   Group:     0   Project:     0   Size: 4096
File ACL: 0
Links: 2   Blockcount: 8
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x4e264393:00000000 -- Wed Jul 20 04:55:15 2011
 atime: 0x69d67a22:60bfcb28 -- Wed Apr  8 17:54:10 2026
 mtime: 0x4e264393:00000000 -- Wed Jul 20 04:55:15 2011
crtime: 0x00000000:00000000 -- Thu Jan  1 01:00:00 1970
Size of extra inode fields: 32
BLOCKS:
(0):268290
TOTAL: 1

debugfs:

Lo strumento mette a disposizione una shell interattiva. Scrivendo ncheck 64209 verifichiamo a quale percorso corrisponde l’inode corrotto:

debugfs:  ncheck 64209
Inode   Pathname
64209   /etc/config.bak

Come sospettato, è il backup. Siccome si tratta di una cartella vuota, possiamo rimuoverla direttamente agendo sul filesystem:

debugfs:  rmdir /etc/config.bak
debugfs:  quit

Siamo pronti per eseguire nuovamente il controllo. Nel caso la rimozione della cartella abbia causato altre inconsistenze nel filesystem, fsck potrà occuparsene e terminare la riparazione, ottenendo un filesystem pulito al 100%.

## fsck.ext2 /dev/sdb1
e2fsck 1.47.3 (8-Jul-2025)
/dev/sdb1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sdb1: 4582/120000 files (0.9% non-contiguous), 37719/479990 blocks

Il sistema è stato completamente ripristinato. Per sicurezza, è stata creata un’immagine disco del risultato finale per poter ripristinare il tutto in caso di problemi futuri.

Conclusioni

Quando si progetta un dispositivo embedded, specialmente se dovrà funzionare senza supervisione per decenni, una corretta attenzione all’integrità del filesystem è cruciale. I bit flip accadranno prima o poi e il sistema deve essere in grado di ripararli o, perlomeno, rilevarli.

Ci sono alcuni accorgimenti da seguire:

Mantenere il sistema in sola lettura: separare i dati utente e di sistema in partizioni diverse e permettere la scrittura solo sulla partizione utente.
Considerare la possibilità di corruzione totale: avere una partizione extra per un’immagine “factory” o “recovery” che possa riportare il dispositivo allo stato di fabbrica.
Se possibile, eseguire tutto dalla memoria: anche se la RAM embedded raramente è ECC, qualsiasi problema potrà essere risolto con un riavvio.
Scrivere in modo atomico e validare le scritture (CoW): invece di sovrascrivere direttamente i file di configurazione, scriverli altrove e poi spostarli nella destinazione.
Loggare solo l’essenziale e in blocchi: non è necessario scrivere continuamente su SD. Quando si porta il dispositivo in produzione, ridurre la frequenza dei commit così che le scritture siano deframmentate oppure disattivare completamente i log.
Utilizzare filesystem moderni con funzioni di “checksum” e “scrub”, che controllano e riscrivono i dati corrotti prima che vengano persi del tutto.

Tutto questo può essere facilmente implementato con progetti Open Source come Yocto Linux, Alpine Linux o progetti della community come DietPi.

Idealmente si dovrebbe creare un immagine disco a sistema spento, dato che farlo su un sistema in esecuzione produce al 100% un immagine inconsistente. Non è un grosso problema qui poiché il filesystem è comunque corrotto e i file di cui abbiamo bisogno non vengono mai modificati. ↩

Ho installato una webcam pubblica sul tetto di casa mia

2023-12-10T00:00:00+01:00

Nel 2008, quando l’Italia ha spento il segnale televisivo analogico, il governo aveva promesso a tutti che sarebbe bastato comprare un nuovo televisore per continuare a guardare la TV, tenendo la vecchia antenna. In realtà, il trasmettitore della mia zona non ha mai funzionato bene, costringendo tutti a passare al satellite e presto i pali sui tetti sono stati abbandonati, sostituiti da parabole sui balconi.

Mio padre fece lo stesso, e scoprendo il palo appena liberato, me ne appropriai subito per fare ogni genere di esperimenti, soprattutto con antenne e radio fatte in casa. Sedici anni dopo ho montato una telecamera in cima al palo e l’ho resa disponibile online affinché tutti potessero vederla.

Il panorama corrente

La maggior parte delle telecamere online funziona in modo semplice: un singolo file JPEG pubblicato su una pagina web, con un timestamp, proveniente direttamente dalla cartella cgi-bin di una vecchia telecamera. Altre utilizzano segmenti video di quindici secondi in loop, aggiornati ogni pochi minuti, per dare l’impressione di un video in tempo reale.

Nonostante questo approccio funzioni e sia sufficiente per semplicemente “vedere” un panorama, volevo qualcosa che desse una sensazione di diretta. Ciò significava trovare una videocamera che non solo fosse di ottima qualità, ma che fornisse anche un flusso pulito con cui poter lavorare.

Videocamere di “videosorveglianza”

Purtroppo, la maggior parte delle fotocamere consumer attualmente in commercio è vincolata all’ecosistema del proprio produttore e non dispone di un’interfaccia web, oppure ne ha una molto limitata. Hanno bisogno di un server, funzionano solo se si possiede un account e, prima o poi, saranno accessibili solo tramite abbonamento una volta che il produttore deciderà di averne avuto abbastanza.

Il mio obiettivo non è gestire un sistema di sicurezza, quindi non mi servono funzioni come registrazione, rilevamento dei movimenti, archiviazione o altre funzionalità “AI”. Ho scelto una telecamera del genere perché sono molto diffuse e abbastanza robuste da resistere per anni su un palo esposto alle intemperie, e la stessa risoluzione necessaria per riprendere il volto di un ladro farà in modo che ogni dettaglio del paesaggio sia ben visibile.

Fortunatamente, nel 2008, Axis, Bosch e Sony hanno creato ONVIF, “Open Network Video Interface Forum”. L’idea è semplice: qualsiasi telecamera ONVIF espone il proprio flusso in modo standard e supporta il rilevamento e la configurazione da parte di altri dispositivi compatibili.

Quindi, ho cercato una telecamera ONVIF.

Sony è ancora il re

Sebbene la maggior parte dei sensori sia in grado di produrre immagini di buona qualità durante il giorno, uno degli obiettivi di questa telecamera è quello di riprendere il tramonto e fornire immagini nitide del porto vicino durante la notte. Ciò richiede una buona gamma dinamica (altrimenti il sole oscurerebbe tutto) e algoritmi di regolazione automatica efficienti, in modo da garantire immagini di buona qualità in qualsiasi condizione di luce.

Sony è ancora il re nel settore dei sensori e produce una linea specializzata chiamata “Sony Starvis”. Questi sensori offrono una gamma dinamica straordinaria e una visione notturna in grado di mostrare dettagli e colori anche in condizioni di oscurità quasi totale.

In realtà, però, non è necessario acquistare una fotocamera Sony. Questo sensore viene fornito da Sony ai produttori di videocamere, quindi è possibile scegliere tra tantissime marche diverse: solitamente il modello del sensore è indicato nella scheda del prodotto, o basta chiedere al produttore.

PoE

L’uso di un iniettore PoE comporta il passaggio di un unico cavo che fornisce sia l’alimentazione che dati. Ciò semplifica l’installazione e garantisce che tutto sia IP67. Inoltre, sebbene le telecamere siano progettate per rimanere sempre accese, il bit rot è sempre in agguato e molti switch PoE dispongono di un sistema di riavvio automatico nel caso la videocamera non trasmetta dati per un certo periodo di tempo.

In questo modo, i blocchi del software (e ce ne sono stati alcuni in questi tre anni) si riducono ad un reboot e a un paio di minuti di downtime.

La scelta

Con un budget piuttosto limitato e la voglia di installarla il prima possibile, ho acquistato una telecamera PTZ (pan, tilt, zoom, orientabile a distanza) prodotta da Reolink: la RLC-830A (ora fuori produzione). Rispetto ad altre marche, offre un’ottima qualità a un prezzo ragionevole e consente comunque il controllo locale.

Questa scelta ha comportato ulteriori vantaggi: avevo già lavorato con loro in passato (utilizzandoli in modo improprio come telecamere per machine vision), sapevo che il sensore era esattamente quello di cui avevo bisogno e, sebbene ONVIF fosse già sufficiente, era disponibile anche un’API aggiuntiva ben documentata.

Proteggere e servire il video

Sebbene la telecamera consenta l’accesso a più utenti o ospiti tramite il pannello integrato, rendere visibile l’intera interfaccia della telecamera solo per mostrare l’immagine è estremamente insicuro e poco pratico da gestire. Grazie a ONVIF, tuttavia, otteniamo uno streaming di buona qualità trasmesso tramite RTSP (“Real Time Streaming Protocol”) che non richiede alcun accesso.

Molti player supportano RTSP e, in teoria, sarebbe possibile trasmetterlo direttamente esponendo la videocamera. Tuttavia, ci sono alcuni problemi:

I browser non supportano RTSP in modo nativo. Lo streaming RTSP significherebbe dover utilizzare un app esterna o un relay per convertirlo in WebSocket
Le telecamere non sono progettate per fornire molti flussi simultanei. Non ho testato quanti ne possa gestire questa telecamera, ma presumo non molti.
Ogni flusso RTSP si somma alla larghezza di banda in upload
Botnet! Esistono sciami di dispositivi IoT con connessioni Internet prese in ostaggio da malintenzionati che le usano per lanciare attacchi DDoS.

Inoltre, a causa della sua distanza dalla fibra ad alta velocità, questa telecamera è collegata a una connessione Internet che fornisce solo 30 Mbps in uplink. Anche se la larghezza di banda necessaria per servire un panorama quasi statico non è enorme, basterebbero solo un paio di client connessi a saturare l’uplink della connessione – che, tra l’altro, è condivisa anche con l’utilizzo normale di internet a casa.

Per questo motivo, ho preso ispirazione dai giganti dello streaming e ho utilizzato la tecnologia che alimenta Youtube, Netflix e qualsiasi IPTV al mondo: HLS (“HTTP Live Streaming”).

HLS verso il resto

Lo streaming tradizionale funziona creando un buffer circolare: immaginate uno spezzone di nastro ad anello su cui la telecamera registra continuamente. Ogni utente che desidera vedere il video si connette al server, e il server inizia a inviare i dati a partire dalla posizione dell’utente all’interno del ciclo.

Il server deve tenere traccia della posizione di ogni connessione e inviare i pacchetti in base alle esigenze del client. La maggior parte del lavoro è svolta dal server.

HLS, invece, sposta il lavoro sul client: lo streaming viene suddiviso in spezzoni da 5-15 secondi con un ID sempre crescente, a cui viene associato un file (manifest) che indica dove si trovano gli spezzoni e come riprodurli.

Questo trasforma un singolo flusso continuo in tanti piccoli file statici che rendono la distribuzione e il caching su larga scala molto efficaci, poiché i server non devono nemmeno supportare lo streaming video né sapere in quale posizione si trovano gli utenti.

Il manifest, nel caso di uno streaming live, contiene i segmenti più recenti che sono stati prodotti. Riprodurre lo streaming è molto semplice:

Scarica il manifesto
Controlla l’ID dell’ultimo segmento generato
Scarica e riproduci il segmento
Torna al punto 1¹

Tutto avviene tramite HTTPS, quindi non solo è compatibile con la maggior parte, se non tutti, i browser moderni, ma viene anche raramente bloccato dai firewall aziendali.

Utilizzando ffmpeg è facile trasformare uno streaming RTSP in HLS. Basta fornirgli lo streaming di origine e una cartella di destinazione, e verrà fatto tutto al volo, senza ricodifica:

$ ffmpeg -an -i rtsp://[...] -c:v copy -f hls \
-start_number 0 -hls_time 5 -hls_list_size 5 -hls_flags delete_segments \
/tmp/videodata/index.m3u8

Ecco cosa fa il comando, pezzo per pezzo:

-an: rimuovi l’audio
-i rtsp://[...]: utilizza questo stream rtsp come input
-c:v copy: copia il video (senza ricodificarlo) – in questo modo azzeriamo l’uso di CPU e RAM
-f hls: usiamo il formato HLS
-start_number 0: numerando i segmenti dal numero 0 in poi…
-hls_time 5: …e rendendoli lunghi 5 secondi
-hls_list_size 5: scrivi gli ultimi 5 segmenti nel manifest…
-hls_flags delete_segments: …e cancella i più vecchi
/tmp/videodata/index.m3u8: mettendo il manifest qui

Questo comando viene eseguito in modo continuo e crea la struttura necessaria nella directory /tmp/videodata/: il manifest (index.m3u8) e una serie di segmenti chiamati indexXXX.ts, dove XXX rappresenta l’ID.

Ad esempio, ecco come appare la cartella dopo circa mezzo minuto:

$ ls /tmp/videodata/
index1.ts  index2.ts  index3.ts  index4.ts  index5.ts  index6.ts  index.m3u8

Il contenuto del manifesto è chiaro:


#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:2
#EXTINF:5.999978,
index2.ts
#EXTINF:3.999978,
index3.ts
#EXTINF:5.999989,
index4.ts
#EXTINF:3.999978,
index5.ts
#EXTINF:5.999978,
index6.ts

Tralasciando l’inizio del file che indica la versione del manifest, è presente TARGETDURATION (che comunica al lettore la durata prevista dei segmenti, in modo che possa visualizzare la barra in basso), MEDIA-SEQUENCE (ID del segmento iniziale) e poi una lista di cinque segmenti, tutti con il loro nome e la durata.

Il MEDIA-SEQUENCE è necessario perché il browser deve conoscere l’ID di ogni segmento in modo da non saltare o riprodurre i segmenti due volte. Notate come, nonostante non sia più incluso nel manifesto, “index1.ts” esista ancora sul disco. Questo serve ad assicurarsi che ogni client abbia finito di riprodurre quel pezzo prima che venga cancellato.

Noterete anche che non tutti i file hanno la lunghezza esatta che abbiamo specificato nel comando, e questo è normale: il video può essere suddiviso solo in corrispondenza dei keyframes, che vengono determinati dalla telecamera in base alla quantità di movimento e altre impostazioni di codifica.

Dividere lo stream in punti diversi senza reencodarlo lo corromperebbe, creando un risultato identico al datamoshing. Poiché abbiamo specificato -c:v copy, ffmpeg rifiuta di dividere in punti non validi, ottenendo lunghezze dei segmenti leggermente variabili.

Questa cartella può essere servita con qualsiasi server web. Un player recupererà automaticamente i segmenti e li riassemblerà lato client.

Distribuzione dello streaming

Mentre ffmpeg è in esecuzione su un piccolo server situato nella stessa posizione della telecamera, il sito web vero e proprio è ospitato su un VPS con un uplink gigabit. In questo contesto, quando parlo di “frontend” mi riferisco al proxy presente sul VPS (il server Nginx) che si trova tra gli utenti e la telecamera.

Tutto, tranne la generazione effettiva del video, viene gestito da questo frontend. Quando gli utenti richiedono segmenti video, il frontend li recupera dal backend, li memorizza nella cache e li distribuisce.

Tuttavia, configurare un semplice server di caching non è sufficiente. Lo streaming live presenta un problema di tempistica unico: appena creato un nuovo segmento, tutti gli spettatori lo scaricheranno esattamente nello stesso momento. Finito di riprodurlo, il segmento sarà immediatamente obsoleto e nessun’altro lo richiederà più.

Ecco perché dobbiamo ottimizzare il proxy correttamente, altrimenti c’è il rischio che i segmenti vengano memorizzati nella cache solo dopo che tutti hanno smesso di richiederli.

Thundering herd as a service

L’obiettivo di un server web con cache è quello di fornire le risorse ai visitatori il più rapidamente possibile. Per questo motivo, se più utenti richiedono contemporaneamente una risorsa che non è ancora presente nella cache, un server standard potrebbe aprire più connessioni dirette al backend per fungere da proxy, salvando il file (e fornendolo dalla cache) solo una volta che la prima connessione ha completato il download.

Ciò è altamente dannoso per uno streaming HLS. Se 50 persone richiedono un segmento aggiornato nello stesso momento, il server aprirà 50 connessioni simultanee al backend.

Su un uplink da 30 Mbps, lo streaming di quel segmento di 5 secondi verso quelle connessioni richiederà molto più di 5 secondi. Di conseguenza, il segmento sarà già obsoleto nel momento in cui verrà effettivamente memorizzato nella cache, sprecando larghezza di banda e causando un buffering infinito per tutti.

Vogliamo invece che il server recuperi il segmento dalla videocamera una sola volta, lo salvi e poi fornisca quella copia memorizzata nella cache a tutti gli altri utenti. Questo è esattamente ciò che fa la direttiva proxy_cache_lock di Nginx.

Quando è abilitata, se più client richiedono lo stesso file non memorizzato nella cache, il server inoltrerà solo la prima richiesta al backend e metterà in attesa le altre. Una volta che la prima richiesta avrà terminato il download e il file sarà nella cache, il server sbloccherà il resto delle richieste, che verranno completate attingendo dalla cache.

In questo modo, il backend trasmette ogni segmento solo una volta e il server front-end può gestire comodamente centinaia di spettatori simultanei senza mai saturare l’uplink. Questa configurazione trasforma essenzialmente una connessione economica residenziale da 30 Mbps in uno streaming in grado di gestire centinaia di spettatori, risparmiando una linea dedicata o costosi aggiornamenti.

La differenza è notevole. Monitorando una singola connessione e attivando proxy_cache_lock, la velocità è immediatamente passata da 50 kbit/s (in fase di buffering) a 300 kbit/s, ovvero esattamente il bitrate necessario per uno streaming in tempo reale.

Conclusioni

Con la webcam online e funzionante, non restava che condividerla. I primi utenti sono arrivati grazie al passaparola: amici, parenti e loro conoscenti. Il traffico era prevalentemente locale e immagino che la webcam venisse utilizzata per controllare il tempo o per guardare l’alba e il tramonto. Ricevevo screenshot quotidiani e bastava anche un breve periodo di inattività perché il LUG (“Linux User Group”) locale di utenti Linux si attivasse in pochi minuti, segnalando il problema.

Volevo renderla realmente pubblica. Ho quindi cercato “webcam meteo online” e ho trovato Windy, una sito di meteo che mostra webcam e accetta anche segnalazioni. Dopo averla aggiunta lì, la webcam si è diffusa ed è stata inserita in modo organico in vari portali e app meteo. A volte era elencata sotto la città corretta, altre volte sotto il nome di una città vicina.

Mentre alcune piattaforme (purtroppo!) mostrano solo l’immagine preview.jpg, altre rimandano effettivamente al sito web. Il traffico che arriva è… curioso.

Il picco di traffico si verifica principalmente all’alba e al tramonto, con visualizzazioni provenienti sia da utenti locali che da luoghi come Germania, Russia o Francia (in particolare, la Costa Azzurra).

Eventi nelle vicinanze, come il Festival di Sanremo e la gara Milano-Sanremo generano picchi evidenti di visualizzazioni, così come eventi meteorologici quali forti tempeste o cicli lunari insoliti (curiosamente, la luna riesce a saturare il video meglio del sole).

A un certo punto, ho notato che qualcuno dalla Germania guardava lo streaming per ore ogni giorno, iniziando esattamente alle 9:00 e finendo alle 17:00. Controllando l’User-Agent, sembrava una Smart TV. Immagino che usasse la webcam come quadro vivente, o forse aveva semplicemente dimenticato di spegnere la TV.

Se volete dare un’occhiata alla telecamera, la trovate qui.

Grazie della lettura.

… controllando che il prossimo segmento sia effettivamente sucessivo a quello precedente, per evitare salti e ripetizioni di segmenti ↩