Linux on Marcello Barnaba

Docker vs. iptables: una storia di rabbia e la chain DOCKER-USER

Fri, 30 Jan 2026 00:00:00 +0100

Siamo nel 2026, e stiamo ancora lottando con l’arroganza assoluta di Docker riguardo al networking Linux.

Ecco lo scenario: faccio girare un host ibrido. Da un lato, ho una macchina virtuale KVM che fa girare Home Assistant (perché ho bisogno del controllo completo del SO e della cifratura del disco). Dall’altro, ho la solita lista di container Docker – NUT per monitorare il mio UPS Lakeview (Vultech) di merda e Technitium per DNS e DHCP – in esecuzione direttamente sull’host.

Sembra semplice. Dovrebbe essere semplice.

Ma nel momento in cui ho installato Docker, la comunicazione con la mia VM Home Assistant è morta. Semplicemente cessata di esistere.

Il problema: Docker è un dittatore

Docker, per default, tratta le tue regole iptables come se fossero semplici suggerimenti. Quando il demone si avvia, sostanzialmente sovrascrive la chain FORWARD, inserisce la sua logica, e imposta policy che isolano efficacemente qualsiasi cosa non sia un container gestito da Docker stesso.

Se hai un’interfaccia bridge per una VM (come br0 o virbr0), le regole di Docker spesso finiscono per droppare i pacchetti destinati a quella VM perché non corrispondono alla sua logica interna per il traffico dei container.

La soluzione ingenua (e perché fallisce)

La mia prima reazione – come qualsiasi sysadmin che fa questo lavoro dai primi anni 2000 – è stata sistemare le regole a mano e poi eseguire:

iptables-save > /etc/iptables/rules.v4

Questa è una trappola!

Se usi iptables-persistent (o netfilter-persistent) con Docker, stai entrando in un mondo di dolore per due motivi:

Root cifrata con LUKS su Raspberry PI 5

Tue, 20 Jan 2026 00:00:00 +0000

Premessa

Quindi ho cominciato a far girare Home Assistant a casa su un Raspberry PI 5 e ho semplicemente installato HAOS su una SD. Poi ho iniziato a sentirmi sempre più a disagio nel salvare credenziali nel filesystem di HA in chiaro (qualsiasi offuscamento non è sufficiente).

Considerando che configurare una root cifrata con HAOS è semplicemente impossibile senza forkarlo, e considerando anche che dedicare un intero RPI5 a HAOS è uno spreco di risorse, ho deciso di aggiungere un SSD al Pi, avviarlo con Raspbian e poi far girare HAOS dentro una VM.

In questo modo, posso avere una root cifrata sull’host principale, cifrando così l’intera VM HAOS.

Inoltre posso ora fare snapshot dell’intera VM HAOS e ho molta più flessibilità nella gestione. Ultimo ma non meno importante, posso anche usare la CPU e la RAM rimanenti del RPI per qualcos’altro.

Ringraziamenti

Prima di tutto, un grande grazie a questo post che mi ha dato le indicazioni iniziali su come fare il setup. Ma quel post del 2021 è ora leggermente datato, e molti passaggi non sono più necessari.

Secondo, un grande grazie a Eric Fjøsne per aver usato questa guida e averla corretta dato che l’avevo scritta perlopiù a posteriori :-).

Requisiti

Un RPI5 con Debian 13 (trixie) o successivo
Una chiavetta USB decente e affidabile che può essere completamente cancellata
Una tastiera e un monitor collegati direttamente al RPI

Panoramica

L’idea di fondo è:

Prepariamo un initrd che contiene i seguenti strumenti:
- resize2fs per ridurre e ingrandire filesystem ext4
- cryptsetup per gestire la cifratura delle partizioni
Configuriamo il sistema per avviarsi da una root cifrata che non esiste ancora, forzando così il sistema a cadere nell’initrd.
Nell’initrd, riduciamo il filesystem root alla dimensione minima possibile
Copiamo il filesystem root dalla partizione in chiaro sulla chiavetta USB
Creiamo la partizione cifrata usando LUKS
Copiamo il filesystem root dalla chiavetta USB sulla partizione cifrata
Estendiamo il filesystem root alla dimensione massima
Configuriamo SSH nell’initrd così da poterlo sbloccare anche dopo aver piazzato il Raspberry Pi in un posto senza tastiera o schermo.

Pronti? Via!

Talk su MetalOS ad All Systems Go! 2025

Thu, 09 Oct 2025 00:00:00 +0000

Ho presentato un talk ad All Systems Go 2025, la conferenza fondamentale sullo userspace Linux. La conferenza è organizzata principalmente dal team di systemd, ed è un punto d’incontro annuale per tutti quelli che lavorano su software di sistema Linux.

Il tema di quest’anno è stato prevalentemente “container, container, container”, con molte nuove funzionalità in systemd per supportare la containerizzazione e anche esperienze pratiche da persone che lavorano sul campo su come usano systemd e software collaterali per costruire infrastrutture a container.

Ho presentato insieme al mio collega Serge Dubrouski il nostro lavoro nella costruzione di un sistema operativo alla scala di Meta. Gestiamo un sistema operativo basato su immagini, ma l’azienda viene da due decenni di aggiornamenti del SO online, quindi abbiamo dovuto progettare una strategia di migrazione adeguata e gettare le fondamenta per il futuro.

Descriviamo come prepariamo le release CentOS dall’upstream, gli strumenti OSS che abbiamo costruito per creare le immagini del SO, e la tecnologia interna (MetalOS) che abbiamo ideato per costruire un SO che gira su milioni di server Linux.

Puoi anche scaricare il video per la visione offline.

Domande? Commenti? Sfogate qui sotto! 🤣

Fare il bind della porta 80/TCP come non-root sul server di sviluppo

Thu, 07 Jul 2011 14:00:00 +0000

Quindi hai una VM Linux che usi per lo sviluppo, perché vuoi replicare l’ambiente di produzione il più fedelmente possibile. Hai molte applicazioni da gestire, devono girare tutte contemporaneamente perché sono dei bei web service REST JSON.

Sei stanchissimo di ricordarti quale hai messo sulla porta 8081, e i tuoi file di configurazione stanno diventando un vero casino. Quindi configuri degli alias per gli indirizzi IP sull’interfaccia di rete e decidi di assegnare persino dei nomi host — /etc/hosts va benissimo — per ogni applicazione.

Poi, in una configurazione del genere, perché dovresti ancora farle girare su porte superiori a 1024? Non sarebbe fantastico digitare il nome dell’applicazione nella barra degli indirizzi del browser? Sì che lo sarebbe, ma è meglio non farle girare come root, comunque.

La soluzione sono le Linux capabilities (vedi anche qui). Quella che ci interessa è cap_net_bind_service: dà a un processo il diritto di fare il bind su porte well-known (< 1024). Se usi un linguaggio interpretato, ovviamente dovrai aggiungere la capability all’interprete stesso. Ecco perché c’è sviluppo nel titolo di questo articolo — non dovresti configurare questo su un server di produzione, se non sai cosa stai facendo.

Un’ultima stranezza: se ti capita di fare dlopen() su shared object che linkano dinamicamente verso librerie fuori dai path canonici, non puoi caricarli tramite LD_LIBRARY_PATH (ad es. il SYBASE.sh) perché viene ignorato per i processi con setcap. Meglio spostare i path delle librerie in uno snippet dentro /etc/ld.so.conf.d.

tl;dr

Assumendo che tu sia l’ultimo e più grande sviluppatore Rails, dovresti diventare root — o usare sudo, come preferisci — e

Il modo migliore per iniziare una nuova giornata

Tue, 26 May 2009 10:00:00 +0000

XFS internal error XFS_WANT_CORRUPTED_RETURN at line 295 of file fs/xfs/xfs_alloc.c.  Caller 0xc018066c
 [<c017fed0>] xfs_alloc_fixup_trees+0x1b0/0x2e0
 [<c018066c>] xfs_alloc_ag_vextent_near+0x31c/0x9c0
 [<c018066c>] xfs_alloc_ag_vextent_near+0x31c/0x9c0
 [<c0180187>] xfs_alloc_ag_vextent+0xf7/0x100
 [<c01824fe>] xfs_alloc_vextent+0x35e/0x420
 [<c019015d>] xfs_bmap_alloc+0x80d/0x12b0
 [<c0111254>] try_to_wake_up+0xa4/0xc0
 [<c02cf248>] schedule+0x308/0x5c0
 [<c01939c4>] xfs_bmapi+0x514/0x1470
 [<c0130069>] find_lock_page+0x29/0xe0
 [<c013013c>] find_or_create_page+0x1c/0xb0
 [<c01d9116>] kmem_zone_zalloc+0x26/0x50
 [<c01a2296>] xfs_dir2_grow_inode+0xf6/0x3c0
 [<c01b57a6>] xfs_iget_core+0x326/0x5a0
 [<c0163315>] alloc_inode+0xd5/0x170
 [<c01b978b>] xfs_idata_realloc+0x3b/0x160
 [<c01a3e2d>] xfs_dir2_sf_to_block+0xad/0x680
 [<c0137882>] cache_grow+0xe2/0x150
 [<c01aa27b>] xfs_dir2_sf_addname+0x9b/0x110
 [<c01a1c51>] xfs_dir2_createname+0x131/0x140
 [<c01d9116>] kmem_zone_zalloc+0x26/0x50
 [<c01cebcb>] xfs_trans_ijoin+0x2b/0x80
 [<c01d4967>] xfs_create+0x407/0x6c0
 [<c017e766>] xfs_acl_vhasacl_default+0x36/0x50
 [<c01df8f4>] linvfs_mknod+0x2c4/0x390
 [<c01a1d62>] xfs_dir2_lookup+0x102/0x110
 [<c01228b8>] in_group_p+0x38/0x70
 [<c01ba9a6>] xfs_iaccess+0xc6/0x1a0
 [<c0157cb7>] permission+0x97/0xd0
 [<c0158f94>] __link_path_walk+0xda4/0xe90
 [<c0157cb7>] permission+0x97/0xd0
 [<c015984c>] vfs_create+0x9c/0x120
 [<c015a00b>] open_namei+0x58b/0x5e0
 [<c014aa9d>] filp_open+0x2d/0x50
 [<c014ac70>] get_unused_fd+0x50/0xc0
 [<c0157ae7>] getname+0x67/0xb0
 [<c014ad9c>] sys_open+0x3c/0x80
 [<c0102867>] sysenter_past_esp+0x54/0x75

xfs_force_shutdown(hda8,0x8) called from line 1091 of file fs/xfs/xfs_trans.c.  Return address = 0xc01e2c5c
Filesystem "hda8": Corruption of in-memory data detected.  Shutting down filesystem: hda8
Please umount the filesystem, and rectify the problem(s)
xfs_force_shutdown(hda8,0x1) called from line 353 of file fs/xfs/xfs_rw.c.  Return address = 0xc01e2c5c
printk: 12 messages suppressed.

Gia’, farei l’umount di /var, se questa macchina non facesse da act_as_router e non avesse pppd che non molla il lock su /var/run/pppd2.tdb…

pppd   222 root  mem   REG    3,8    88080525 /var/run/pppd2.tdb (path dev=0,0 inode=34)

Ovviamente kill 222 ; pppd call dsl-provider non funziona. BLEAH. Mettiamoci un router davanti… configura, port forward, e si ricomincia… poi fdisk /dev/hdc per ricreare la struttura delle partizioni sul nuovo hard disk, mkfs.xfs su tutte le nuove partizioni, mount /dev/hdcX /target, pax -r -w -p e /{bin,boot,dev,etc,home,initrd,lib,media,root,sbin,srv,tmp,usr,var} /target… aspetta un sacco per la copia perche’ ci sono settori danneggiati sul disco sorgente, chroot /target, vi /etc/lilo.conf e sostituisci boot=/dev/hda con boot=/dev/hdc, lancia lilo -v mentre sei nel chroot, verifica /etc/fstab, e finalmente shutdown per rimuovere il disco guasto e riavviare… ripristinando lilo.conf. evvai!