Photo by Eric Prouzet on Unsplash

English version available here

L’esperienza insegna, l’esperienza forma. Probabilmente, se sei giovane, starai pensando “ok, boomer” e sarai pronto a chiudere questo articolo, passando oltre. Se sei meno giovane, invece, potresti pensare che sia il solito articolo “rivoluzionario”, contro il sistema e contro le big corporation.

Non è così.

Circa 20 anni fa tutti gli utenti di sistemi operativi alternativi (ovvero non Windows) venivano visti come degli alieni in quanto “tutto il mondo usa Windows”. Si sognava “l’anno della svolta di Linux (o FreeBSD) su Desktop, argomento su cui si scherza ancora oggi. Di fatto questi sistemi operativi sono arrivati davvero ovunque (sotto forma di Android, Smart Home, Playstation, in parte MacOS, ecc.), in maniera ovviamente diversa rispetto a come avremmo sognato.

Già allora mi adiravo e rispondevo “per quale ragione dovrei usare Windows? Solo perché lo usano tutti?”. La risposta, di solito, era questa: “Nel mondo reale e lavorativo tutti usano Windows”.

Per quanto in un certo senso potessero avere una parte di ragione, non mi sembrava un motivo valido per costringermi ad usare un sistema operativo inadatto o, quantomeno, meno efficace per il mio lavoro.

Il tempo mi ha dato ragione. Internet ha visto prevalere i server basati su sistemi Unix o Unix-like, i datacenter sono diventati principalmente basati su Linux (grazie, Amazon, per aver spinto ancora di più questo trend!), è nato il concetto di “cloud” e tutto ciò che ne deriva. Router e firewall hanno iniziato ad essere basati su Linux o sistemi *BSD e lo sviluppo è andato avanti non più solo sul mantenere in piedi un packet filter ma sulle funzionalità aggiuntive che oggi abbiamo a disposizione.

I big player sono entrati in gioco, Microsoft stessa ha iniziato ad amare Linux, FreeBSD e, con il WSL, ha definitivamente dimostrato che non si può ignorare “l’altro”.

Ad oggi, dire di essere un sistemista Linux genera ammirazione e rispetto, mentre meno di venti anni fa mi sentivo rispondere “Linux è un giocattolo che si usa nelle università, il mondo utilizza Windows”. Essere sistemisti esperti in sistemi *BSD, invece, genera ancora strani pensieri nell’interlocutore.

L’esperienza mi ha dunque insegnato che non esiste (e non deve esistere!) un solo modo di fare le cose. Nel mondo dell’Open Source, poi, la pluralità di soluzioni agevola uno sviluppo diversificato e che potrebbe, nel tempo, riservare sorprese.

Pochi giorni fa ho pubblicato un articolo su come ho effettuato una migrazione da un server Proxmox a FreeBSD senza particolari problemi e migliorando l’efficienza del sistema. L’articolo ha avuto un successo inaspettato, ha ricevuto in pochi giorni un enorme numero di visite e i commenti sono stati entusiastici. Qualche commento critico, ovviamente, è giunto. Amo i commenti critici in quanto a volte è fondamentale vedere le cose da un altro punto di vista. Quando sono davvero convinto, resto comunque della mia idea mentre se il commento critico dovesse riuscire a suscitare un dubbio, avrei lo spunto di indagare ancor di più. Di fare ricerca. Di sperimentare, che è poi alla base del nostro mestiere.

Ecco perché non ho mai simpatizzato con chi, con arroganza (e l’arroganza, spesso, è sinonimo di ignoranza), chiude a qualunque soluzione che non sia la propria favorita.

Dovremmo ormai aver imparato che quello tecnologico è un mondo pressoché infinito, fatto di strumenti (ovvero mattoni) con cui costruire una soluzione al nostro problema. Vedere persone adulte o anziane arroccate su posizioni chiuse e rigorose è triste, ancor più triste è vedere persone giovani (magari anche competenti) che chiudono le porte a tutto ciò che non sia la soluzione “hype” del momento, magari spinta proprio da tanto marketing di chi, su quelle soluzioni, ha investito molti soldi. Dire “siamo nel 2023 e tutti usano Kubernetes sul cloud, su cluster gestiti”, ad esempio, vuol dire ignorare che non tutti gli strumenti sono adatti per risolvere tutti i problemi. Non utilizzo una bilancia industriale per pesarmi in quanto sarebbe troppo grande o troppo costosa o comunque inadatta allo scopo. Non tutti, dunque, dovrebbero utilizzare bilance industriali per pesarsi.

Lo studio del problema dovrebbe sempre essere il primo passo verso la ricerca degli strumenti più adatti alla soluzione dello stesso. Per fortuna non esiste “una taglia unica”, in informatica. Così come non sempre lo strumento più “moderno e in voga” sarà quello più adatto e longevo sul lungo periodo.

"Il server è pieno, aggiungi spazio!"

Anche se ci sono decine di giga di log inutili. Anche se ci sono decine di giga di roba inutile, lasciata sul server solo per inerzia.

Le recenti innovazioni nel campo delle risorse hardware hanno generato dispositivi con prestazioni sempre più elevate, capacità di memoria superiore e consumi energetici ridotti. Questa tendenza ha permesso lo sviluppo di applicazioni e servizi che fino a poco tempo fa erano impensabili. Tuttavia, un lato oscuro di questo progresso riguarda il peggioramento dell'ottimizzazione del software.

L'ottimizzazione non è più una priorità

Il progresso tecnologico ha portato ad un contesto in cui l'hardware potente e accessibile è diventato la norma. Di conseguenza, gli sviluppatori non sentono più l'urgenza di ottimizzare il loro software. In passato, quando le risorse erano limitate, l'ottimizzazione era una necessità per garantire il corretto funzionamento delle applicazioni e per evitare sprechi di risorse. Oggi, invece, gli sviluppatori tendono a concentrarsi su altre priorità, come l'implementazione di nuove funzionalità o il miglioramento dell'esperienza utente. L'ottimizzazione non conta più. La soluzione, per loro, è sempre ricorrere ad hardware più potente.

Il peggioramento dell'ottimizzazione del software ha diverse conseguenze negative:

1. Consumo energetico: Applicazioni non ottimizzate consumano più energia rispetto a quelle ottimizzate, contribuendo ad un impatto ambientale maggiore. La crescente preoccupazione per il cambiamento climatico rende questa questione particolarmente rilevante.
2. Spreco di risorse: Quando gli sviluppatori trascurano l'ottimizzazione, le applicazioni utilizzano risorse hardware in modo inefficiente, sprecando spazio su disco, memoria e potenza di calcolo. Questo spreco si traduce in costi maggiori per gli utenti, che potrebbero essere costretti ad aggiornare il loro hardware più spesso del necessario.
3. Prestazioni ridotte: Applicazioni non ottimizzate possono causare lentezza, lag e crash, compromettendo l'esperienza utente e la produttività. Inoltre, l'hardware meno recente potrebbe non essere in grado di eseguire correttamente questi programmi, limitando l'accesso ad una porzione di utenti.
4. Sicurezza e stabilità: Un software non ottimizzato potrebbe presentare falle di sicurezza o bug, esponendo gli utenti a potenziali rischi. Inoltre, le applicazioni instabili possono causare la perdita di dati o compromettere l'integrità del sistema.
5. Manutenzione e aggiornamenti: La mancata ottimizzazione rende più difficile e costoso mantenere e aggiornare il software, poiché gli sviluppatori devono affrontare un codice più complesso e disorganizzato. Ciò può portare a ritardi nel rilascio di patch e nuove funzionalità.

Per invertire questa tendenza e garantire un futuro più sostenibile ed efficiente per il settore del software, è fondamentale che gli sviluppatori riconoscano l'importanza dell'ottimizzazione. Di seguito alcuni passi che possono essere intrapresi per promuovere un cambiamento positivo:

• Formazione ed educazione: Insegnare ai programmatori l'importanza dell'ottimizzazione e fornire loro strumenti e tecniche per implementarla sin dall'inizio del processo di sviluppo. Spesso diventa difficile, specialmente per noi sistemisti "adulti", spiegare a chi non è abituato ai limiti fisici dell'hardware ma crede che il cloud sia "a risorse infinite, basta pagare di più". Dobbiamo però farlo, altrimenti saremo poi noi a dover rispondere quando il server sarà lento o, peggio, pieno.
• Standardizzazione e buone pratiche: Promuovere l'adozione di standard e buone pratiche che guidino gli sviluppatori verso un approccio più efficiente nella creazione del software.
• Benchmark e metriche: Utilizzare strumenti e metriche per valutare l'efficienza del software e confrontarlo con soluzioni concorrenti, incoraggiando così un continuo miglioramento delle prestazioni.
• Incentivi e riconoscimenti: Creare premi o incentivi per le aziende e gli sviluppatori che si impegnano a produrre software ottimizzato, riconoscendo pubblicamente i loro sforzi.

L'abbondanza di risorse hardware e a basso costo (almeno in apparenza) ha portato ad un peggioramento dell'ottimizzazione del software, poiché gli sviluppatori non la considerano più una priorità. Tuttavia, è possibile invertire questa tendenza attraverso la formazione, l'adozione di buone pratiche e la promozione di un approccio più sostenibile ed efficiente allo sviluppo del software. Solo così potremo sfruttare appieno le potenzialità offerte dall'innovazione tecnologica, garantendo al contempo un impatto positivo sull'ambiente e sull'esperienza utente.

NOTA: Il seguente post è la traduzione dell'equivalente in inglese sul blog it-notes. L'originale sarà sempre più aggiornato.

Per garantire il corretto funzionamento dei nostri server, è fondamentale utilizzare dispositivi watchdog. Tuttavia, su Raspberry PI, il demone watchdog sembra avere problemi di stabilità.

Il problema è dovuto alla presenza di un particolare watchdog hardware, presente sui nostri Raspberry, che richiede di essere "accarezzato" abbastanza spesso. Per questo motivo, se non si utilizzano specifiche opzioni, il demone watchdog non funzionerà correttamente, poiché i tempi di "accarezzatura" standard di FreeBSD sono troppo elevati.

Per abilitare e far funzionare correttamente il watchdog, è sufficiente aprire il file /etc/rc.conf con il proprio editor preferito e aggiungere le seguenti righe:

…
watchdogd_flags="-s 4 -t 8"
watchdogd_enable="YES"

Successivamente, sarà possibile riavviare il sistema o semplicemente il demone watchdog, digitando il comando "service watchdogd restart".

In questo modo, il demone verrà avviato e sarà in grado di utilizzare il watchdog hardware presente sul Raspberry PI in modo corretto e stabile.

Notizia delle scorse settimane: “le e-mail di Libero e Alice non funzionano. Non funzionano da giorni e riprenderanno a funzionare “appena possibile””. Tutti indignati - lo capisco - ma di fatto vedendo il livello di pubblicità, spam e quant’altro direi fosse chiaro che i due servizi non fossero più gestiti in maniera “impeccabile”.

Notizia apparsa nello stesso periodo, Microsoft ha avuto problemi, per cui Outlook, Teams, ecc. hanno avuto seri disservizi per ore.

Anche Facebook, Whatsapp e Instagram hanno avuto seri problemi, in passato . E questi sono tutti servizi che perdono milioni di euro per ogni minuto di down.

Eppure oggi, nel mondo interconnesso, un’interruzione di connettività o di servizio viene vista come una tragedia.

Gestisco server da così tanto tempo che un bimbo nato quando ho messo online i miei primi servizi può essere laureato e avere avuto a sua volta figli. Il mio primo server è stato archiviato dalla Wayback Machine nel 2002, ma ha almeno un anno in più. Alcuni colleghi con cui lavoro quotidianamente sono nati dopo il mio primo server.

Eppure oggi, come mai prima, uno stop di un servizio (anche fuori orario, anche se pianificato, anche se il servizio in quel momento non serve) è diventato inaccettabile.

Ogni mattina un sistemista si sveglia e sa che dovrà correre contro il tempo per patchare, controllare, riavviare servizi prima che una vulnerabilità possa colpire il proprio sistema. Ogni mattina un utente si sveglia e dovrà usare il servizio proprio nei pochi secondi in cui il sistemista lo sta riavviando. Anche se il sistemista aveva avvisato che avrebbe riavviato il servizio a quell’ora, causando “pochi minuti” di interruzione. Anche se il sistemista si è alzato alle 4 del mattino per farlo. Anche se l’utente, alle 4 del mattino della domenica, di solito dorme.

La Rete è fatta di componenti interconnesse e solo parti di essa sono controllabili. Può accadere che qualcosa salti: un gestore di servizi, una dorsale, un dns esterno. Dobbiamo imparare ad accettare che qualcosa, ogni tanto, possa non essere pienamente efficiente.

Quando si ha un negozio fisico, può esserci un’interruzione di corrente, di acqua, di gas, un allagamento, lavori in strada... perché ciò che è online non può essere fermo un minuto ogni 6 mesi, se preannunciato? Oppure un’ora ogni anno, se c’è un problema imprevisto?

Le promesse del “cloud” hanno indotto tutti a credere che esista il 24/7 sempre e comunque. Ma no, in realtà non esiste e più l’infrastruttura è complessa, più parti possono rompersi. E le promesse di “always online” sono spesso annegate in termini e condizioni con responsabilità limitatissime in caso di infrazione.

Meglio cinque minuti offline oggi che un attacco domani, con relativo rischio di fuoriuscita di dati personali.

NOTA: Il seguente post è la traduzione dell'equivalente in inglese sul blog it-notes. L'originale sarà sempre più aggiornato.

La rete di OVH (e Soyoustart, ovviamente) sembra essere configurata in modo "strano" e l'impostazione degli IP di failover non è sempre così semplice e lineare.

A volte si vuole (o si deve) assegnare un indirizzo IP pubblico a una jail FreeBSD senza utilizzare NAT, ma non c'è molta documentazione su come farlo all'interno di una jail.

Supponiamo che l'indirizzo IP pubblico del vostro server host FreeBSD sia 1.2.3.4 e che l'ip di failover sia 6.7.8.9.

Prima di tutto, andate nel vostro pannello di controllo (OVH/Soyoustart/ecc.) e generate un indirizzo MAC per l'indirizzo ip pubblico di failover che volete assegnare alla vostra jail. Supponiamo che sia ca:fe:ca:fe:ca:fe

Ora fate login nell'host FreeBSD e prendete nota del suo gateway (dovrebbe essere 1.2.3.254, ma ricontrollate), vi servirà più avanti.

È il momento di creare la jail. Apprezzo molto BastilleBSD perché è leggero, non ha dipendenze e viene sviluppato attivamente. In questo articolo non mi occuperò di come installare e avviare Bastille, per ulteriori informazioni consultate la documentazione ufficiale.

A questo scopo abbiamo bisogno di VNET, in modo che la vostra jail abbia il suo stack di rete completo. Se avete letto che VNET è instabile, avete trovato alcuni vecchi articoli. Non preoccupatevi, potete usarlo ora, è stabile e già da tempo.

Quindi, create la jail. Utilizzando VNET, verrà creata un'interfaccia bridge e verranno collegate sia le interfacce di rete fisiche che quelle della jail. Supponiamo che la vostra interfaccia host fisica sia "em0" e che la vostra jail sia chiamata "p1":

bastille create -V p1 13.0-RELEASE 6.7.8.9 em0

State chiedendo a Bastille di creare una jail (-V) VNET, chiamata p1, di tipo (release) FreeBSD 13.0-RELEASE, il suo ip sarà 6.7.8.9 e il bridge creato sarà collegato a em0. La jail verrà creata e avviata, ma non siete ancora pronti ad usarla.

Spegnete la jail:

bastille stop p1

Modificate ora il file jail.conf per impostare l'indirizzo MAC dell'interfaccia che avete generato nel pannello web.

Avrete qualcosa di simile a questo:

…  
vnet;  
vnet.interface = e0b_bastille0;  
exec.prestart += "jib addm bastille0 em0";  
exec.prestart += "ifconfig e0a_bastille0 description "vnet host interface for Bastille jail p1"";  
exec.poststop += "jib destroy bastille0";  
}

Aggiungete questa riga dopo exec.prestart += "jib addm bastille0 em0";

exec.prestart += "ifconfig e0a_bastille0 ether ca:fe:ca:fe:ca:fe”;

Ora configurate l'interfaccia di rete all'interno della jail, dato che Bastille non è riuscito a capire la "strana" configurazione di rete di OVH. Modificate il file rc.conf della jail. Se non avete fatto particolari modifiche alla configurazione di Bastille, dovrebbe essere:

/usr/local/bastille/jails/p1/root/etc/rc.conf

Rimuovete le impostazioni di rete già impostate da Bastille e sostituitele con qualcosa di simile:

ifconfig_vnet0="inet 6.7.8.9 netmask 255.255.255.255 broadcast 6.7.8.9"  
static_routes="ovh"  
route_ovh="-net 1.2.3.254 -iface vnet0"  
defaultrouter="1.2.3.254"

Il gateway si trova al di fuori della netmask della jail, quindi FreeBSD deve essere istruito affiché imposti una rotta statica che permetta alle connessioni di raggiungere il gateway "estraneo" (1.2.3.254) attraverso una specifica interfaccia di rete.

Salvare, uscire e avviare la jail:

bastille start p1

Bene, è ora possibile eseguire il ping dell'ip pubblico della jail e la jail raggiungerà il mondo esterno tramite il suo indirizzo IP pubblico.