Assegnare ip failover di OVH a jail FreeBSD

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.

Backup efficienti di container LXC in Proxmox - ZFS

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.

FreeBSD, Caddy e PHP - un connubio perfetto

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).

Come riavviare macchine Linux o FreeBSD con storage inchiodato

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

A volte il filesystem si blocca. Non è possibile eseguire alcuna operazione e un "riavvio" causerà solo un tempo di attesa indefinito per l'I/O. È possibile accedere al server tramite ssh (o login tramite console), ma non è possibile eseguire alcuna operazione perché i dispositivi di archiviazione sono bloccati. Questo può accadere a causa di un problema sul file system o di uno strano bug del kernel. È più probabile che questo accada quando si ha a che fare con interfacce esterne collegate via usb.

Esiste un codice "magico" che attiva una condizione specifica del kernel e causa un riavvio.

Attenzione, questi comandi devono essere considerati come l'ultima risorsa. Non verrà eseguito il flush del disco, né verrà avviata la procedura di spegnimento, per cui si rischia di distruggere completamente il file system o qualsiasi file aperto.

Tuttavia, questa potrebbe essere l'opzione migliore che avete a disposizione e non sarà più dannosa di un hard reset o di un "tradizionale" cable pull - ma potete farlo da remoto.

Ricordate di lanciare i comandi con i privilegi di root:

Su Linux:

echo b > /proc/sysrq-trigger

In questo modo si attiverà un riavvio immediato - non verranno eseguite ulteriori operazioni sul disco.

Su FreeBSD:

sysctl debug.kdb.panic=1

Verrà generato un kernel panic che (per impostazione predefinita) causerà un riavvio.

Nuova vita al Blog!

Ho deciso di riprendere a scrivere più regolarmente su questo blog. Nei suoi primi anni di vita ero abbastanza assiduo, avevo anche un discreto seguito sia di lettori che di commentatori. Poi l’avvento dei social network ha freddato e ridotto l’interesse verso i blog e i miei impegni lavorativi hanno portato via sempre più tempo alla stesura dello stesso. Negli ultimi anni mi sono concentrato (un po’) di più sul blog tecnico, IT Notes.

Le cose stanno cambiando. I social non sono più così seguiti come un tempo e i blog stanno vivendo una seconda giovinezza. Proprio per questa ragione ho deciso di tornare ad essere un po’ più assiduo, sempre nei limiti del possibile. Scriverò sia di questioni tecniche, specialmente traducendo gli articoli che scriverò su IT Notes, ma anche di questioni di tutt’altro genere.

Un diario pubblico, uno spazio in cui esternare le mie osservazioni del mondo, della società e dell’evoluzione che, volenti o nolenti, ci travolge giorno per giorno.

Stay tuned :-)