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.

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

Ho già scritto relativamente ad alcune delle mie strategie di backup in Proxmox. Proxmox Backup Server è un valido strumento, ma non è sempre l'opzione migliore, soprattutto se si utilizzano container lxc.

I container LVM e Ceph RBD sono già stati trattati in un altro post, ma una delle (molte) ottime opzioni, se si usa Proxmox, è ZFS. Utilizzo ampiamente ZFS sia su FreeBSD che su Linux (e ho sempre desiderato che BTRFS potesse raggiungere lo stesso livello di affidabilità).

Quando non ho bisogno di un file system in rete (come Ceph) o voglio superare i limiti di LVM, tendo a installare le VM di Proxmox e i container lxc su ZFS. Concentriamoci ora sul backup dei container lxc.

Proxmox utilizza i dataset ZFS per lo storage dei container lxc, quindi tutti i file si trovano su /nome-pool/subvol-x-disk-y. Possiamo eseguire facilmente il backup come abbiamo fatto nel mio precedente articolo, abbiamo solo bisogno di un modo diverso per eseguire le snapshot di tutti questi dataset.

I dataset ZFS forniscono una directory .zfs, nascosta, che contiene tutte le istantanee attualmente esistenti di quel dataset specifico. "ls" non la mostrerà, ma si può fare un "cd" e sarà utilizzabile.

Naturalmente si può usare zfs send/receive in maniera nativa (o un utile software che uso quotidianamente, zfs-autobackup, sia per le istantanee locali che per la replica remota), ma vogliamo salvare i file, non il dataset zfs, in modo da poter eseguire il backup su un file system diverso. Qualsiasi file system. Quindi useremo borg backup.

Supponiamo che il nostro pool ZFS sia chiamato "proxzfs". Ecco uno script di esempio. Naturalmente, questo è il mio script, funziona per me e non sono responsabile se non funziona per voi/distrugge tutti i vostri dati/mangia il vostro server/ecc.

#!/bin/bash

/usr/sbin/zfs snapshot -r proxzfs@forborg

REPOSITORY=yourpath/server/whatever:borgrepository/
TAG=mytag
borg create -v --stats --compression zstd --progress    \
   $REPOSITORY::$TAG'-{now:%Y-%m-%dT%H:%M:%S}'          \
   /proxzfs/*/.zfs/snapshot/forborg/  \
   --exclude '*subvolYouMayWantToExclude-disk-0*'

/usr/sbin/zfs destroy -vrR proxzfs@forborg

borg prune -v $REPOSITORY --stats --prefix $TAG'-' \
   --keep-daily=31 --keep-weekly=4 --keep-monthly=12

Questo piccolo script creerà un'istantanea @forborg per qualsiasi dataset che troverà sotto "proxzfs", quindi avvierà borg e gli chiederà di attraversare le snapshot forborg montate automaticamente all'interno della directory .zfs di qualsiasi dataset.

Quindi distruggerà le istantanee "forborg" ed eseguirà un prune di borg. Questo eliminerà i vecchi backup, in base alla politica impostata. Questo passaggio può essere evitato, ma io preferisco eseguirlo dopo un backup, in modo che il mio repository sia sempre coerente con la mia politica di data retention.

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

Caddy è un ottimo server web. È più facile da configurare rispetto a nginx e gestisce le richieste/rinnovi dei certificati ssl, quindi non è necessario utilizzare certbot/cron. A volte si potrebbe preferire usare Caddy invece di Nginx/Apache/Lighttpd/etc.

FreeBSD e Caddy funzionano molto bene insieme per siti web statici/reverse proxy, ma spesso abbiamo bisogno di servire siti web dinamici. Aggiungere PHP è abbastanza facile.

Iniziamo con l'installare e abilitare Caddy:

pkg install caddy  
service caddy enable

Ora installiamo PHP - diciamo PHP 8.1 - e abilitiamo php-fpm:

pkg install php81
service php-fpm enable

Preferisco usare php-fpm tramite socket locali, se il server web e php-fpm sono in esecuzione sullo stesso host. Perciò modifichiamo alcune configurazioni modificando /usr/local/etc/php-fpm.d/www.conf:

Cambiamo la configurazione da:

_listen = 127.0.0.1:9000_

a

_listen = /var/run/php81.sock_

Cambiamo ora il proprietario del socket, basta decommentare:

listen.owner = www  
listen.group = www  
listen.mode = 0660

Avviamo ora php-fpm:

service php-fpm start

Ora va modificato /usr/local/etc/caddy/Caddyfile. Basta aggiungere qualcosa del genere:

my.website.com {  
root * /usr/local/www/website  
php_fastcgi unix//var/run/php81.sock  
file_server  
}

Questo configurerà un virtualhost chiamato my.website.com (e Caddy cercherà di ottenere un certificato per esso), con la sua radice su /usr/local/www/website e processerà qualsiasi richiesta di file .php tramite php socket. La direttiva file_server assicura che i file statici possano essere serviti dal percorso principale.

Avviamo ora Caddy:

service caddy start

Questo è tutto. Naturalmente si tratta di una configurazione molto elementare, ma può essere usata come bozza per setup più avanzati. Per esempio, si può aggiungere qualcosa del tipo:

    @disallowed {
        path /xmlrpc.php
        path *.sql
        path /wp-content/uploads/*.php
    }

    rewrite @disallowed '/index.php'

e potrete avere un'installazione di Wordpress funzionante (e abbastanza sicura).