Author Archives: spookyh

Alpine Linux, perché buttare l’hardware è peccato!

Avevo bisogno di un serverino domestico per alcuni esperimenti e per taccagneria passione per il trashware ho deciso di recuperare il mio “vecchio” (2007) EeePC 701 (Celeron M 900MHz, 2GB RAM, 4GB SSD).

Sono consapevole che un Raspberry Pi 4 sarebbe molto più performante, ma quanto ci avrei messo ad ammortizzare l’investimento?
L’EeePC 701 consuma:

  • 9,5V – 2,5A max → ~24W di picco
  • frequenza media della CPU su un uptime di 62 giorni: 113 MHz:32.73%, 225 MHz:21.17%, 338 MHz:15.11%, 450 MHz:10.52%, 563 MHz:6.91%, 675 MHz:2.72%, 788 MHz:3.57%, 900 MHz:7.28%
  • Una stima verosimile si attesta attorno ad una media di 11W

Tradotto in Euro significa:

  • 11 W × 24 h × 365 giorni = 96.360 Wh ≈ 96 kWh / anno
  • costo medio dell’elettricità in Italia nel 2025 = 0,30 €/kWh
    96 kWh × 0,30 € = ~28,80 € / anno

Un Raspberry Pi 4 Model B invece consuma:

  • 4,5 W × 24 × 365 = 39.420 Wh ≈ 39 kWh / anno
  • 39 kWh × 0,30 € = ~11,70 € / anno

Un Raspberry mi farebbe risparmiare circa 17€ l’anno, ma nuovo costa un centinaio di euro e per rientrare dell’investimento mi occorrerebbero circa 6 anni!

Ma veniamo ai problemi pratici: CPU a 32bit e disco da soli 4GB! Forse non ve ne siete accorti, ma la maggior parte delle distribuzioni ha deprecato il supporto all’architettura Intel 32-bit.

Nell’ordine ho quindi scartato:

  • Debian 12 (supporta i686 ufficialmente “solo” fino a giugno 2028), da amante del retrocomputing non mi ha entusiasmato la scelta di Debian di eliminare il supporto agli Intel a 32bit. L’installazione di base occupa circa 750MB.
  • Slackware 15/current: stabile, ma è complicato contenere la dimensione del sistema di base. L’installazione della maggior parte dei pacchetti delle serie a, ap, l ed n occupa circa 1200-1300MB, in oltre per il software extra ci si deve affidare a repository non ufficiali o ai maledetti Slackbuild.
  • Gentoo: RICOMPILARE UNA DISTRO MODERNA SU UN PC A 900MHZ?!!
  • Slitaz: progetto leggero ed interessante, ma non ha i pacchetti per il software che mi serve.
  • Tiny Core: stesso discorso di Slitaz.
  • Free/Net/OpenBSD: girano tutti senza problemi anche su i586, ma l’installazione minima richiede rispettivamente 1.3GB, 900MB e 1.2GB.
  • Arch Linux 32: uso Arch da 20 anni, c’era ancora installata una vecchia Arch sull’EeePC quando l’ho riesumato, ma mi sono ricordato di questo fork quando ormai era troppo tardi.
  • Void Linux: ha il miglio rapporto leggerezza-facilità d’installazione. Scartata perché ha un gestore di pacchetti con una sintassi troppo particolare per i miei gusti. L’installazione minima richiede circa 700MB.
  • Alpine Linux: non è solo sinonimo di container, può essere installata anche su hardware reale. Usa musl al posto di glibc ed è più leggera e performante di tutte le soluzioni precedenti. Purtroppo il suo installer non permette di gestire manualmente le partizioni, ma dato che l’installazione minima richiede meno di 200 MB ho deciso che valesse la pena effettuare l’installazione tramite chroot (stile Arch).

Installazione Alpine Linux tramite chroot

1. Configurazioni base

setup-hostname -n serverino
setup-keymap it it
setup-timezone -z Europe/Rome
setup-interfaces
passwd

2. Preparare il disco per btrfs

apk add btrfs-progs
cfdisk… [partizioni GPT con sda1 BIOS BOOT e sda2 Linux]
mkfs.btrfs /dev/sda2
modprobe btrfs
mount /dev/sda2 /mnt
cd /mnt
btrfs subvolume create rootvol
umount /mnt
mount /dev/sda2 -o subvol=rootvol,compress=lzo,sdd /mnt
mount –bind /dev /mnt/dev
mount –bind /proc /mnt/proc
mount –bind /sys /mnt/sys
mount -t devpts devpts /mnt/dev/pts -o gid=5,mode=620

3. Installare il sistema di base

setup-disk -m sys /mnt
chroot /mnt /bin/ash
apk update
apk upgrade
apk add grub grub-bios
grub-mkconfig -o /boot/grub/grub.cfg
grub-install /dev/sda

Sondaggio

Da quanto tempo usi Linux? Facci indovinare!
Vote

Filesystem cifrati (parte 3)

Per i malati del trashware ho voluto replicare il test precedente su un vecchio Pentium Dual-Core E5800 3.20GHz privo di accelerazione aes e con soli 4 GB RAM.
In questo caso non ho potuto usare gocryptfs perché supporta come minimo CPU x86-64-v2. Al suo posto, come FS userspace, ho ripiegato per il vecchio EncFS (solo a scopo didattico perché non è più attivamente sviluppato e non è attualmente considerabile sicuro).

Ext4 con fscrypt si è confermato il filesystem con le maggiori performance in scrittura, dm-crypt/LUKS non gli si è discostato di molto e lo ha addirittura superato in quanto a velocità di lettura. EncFS è riuscito a fare meglio solo dello ZFS che purtroppo dopo pochi secondi saturava sistematicamente un core della CPU.
Per trasferire 5GB cifrati con un PC di 15 anni fa occorrono (circa) quindi:

  • 1’06” con EXT4
  • 1’14” con LUKS
  • 3’06” con EncFS
  • 4′ con ZFS

Velocità in lettura

Filesystem cifrati (parte 2)

Su un PC con CPU Intel i7-4790K (dotata di accelerazione hardware per l’algoritmo di cifratura aes), 16GB di RAM ed hard disk Seagate Barracuda 7200 da 500GB il supporto per la cifratura integrato nel filesystem ext4 è stato quello che si è comportato meglio in assoluto, con velocità in scrittura praticamente identiche a quelle di ext4 con la cifratura disabilitata. dm-crypt/LUKS è stato più veloce di ZFS con file sotto ai 5 GB. gocryptfs come prevedibile, in quanto strumento user-space, è stato il filesystem più lento tra i 4.

Dettagli del test

Sono state create 3 partizioni sul disco:

  • una formattata con ext4 (con due cartelle da cifrare rispettivamente con FScrypt e gocryptfs),
  • un volume dm-crypt/LUKS formattato in ext4
    # cryptsetup luksFormat --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 5000 /dev/sdc2
    # cryptsetup open /dev/sdc2 lukspart
    # mkfs.ext4 /dev/mapper/lukspart
  • un pool ZFS col dataset cifrato
    zpool create tank /dev/sdc3
    zfs create -o encryption=aes-256-gcm -o keyformat=passphrase -o keylocation=prompt tank/encrypted_data
    zfs load-key tank/encrypted_data
    zfs mount tank/encrypted_data

Ho generato con dd 3 file rispettivamente da 1GB, 5GB e 10GB contenenti bit casuali

dd if=/dev/urandom of=testfile1G bs=1G count=1 oflag=direct
dd if=/dev/urandom of=testfile5G bs=1M count=5120 oflag=direct
dd if=/dev/urandom of=testfile10G bs=2M count=5120 oflag=direct

Con rsync ho misurato la velocità di trasferimento di questi file nelle varie partizioni o directory cifrate e per confronto anche con la semplice copia in una partizione ext4 non cifrata. Dopo ogni copia, per pulire la cache ho lanciato il comando “echo 3 > /proc/sys/vm/drop_caches”

time rsync --progress testfile1G /mnt/“filesystemcifrato“
time rsync --progress testfile5G /mnt/“filesystemcifrato“
time rsync --progress testfile10G /mnt/“filesystemcifrato“

Velocità in lettura

Per completezza ho misurato anche le velocità di lettura col comando:

time dd if=testfile5G of=/dev/null bs=1G count=1

Filesystem cifrati (parte 1)

Microsoft supporta la cifratura del disco da Windows 7 e da Windows 11 è attivata di default.
Anche Linux la supporta da moltissimo tempo e svariati progetti si sono susseguiti o affiancati nel tempo: il pionieristico CFS (1993), loop-AES (2001), cryptoloop (2002), dm-crypt (2003), EncFS (2003) e eCryptFS (2006).

Al momento le principali implementazioni crittografiche opensource disponibili su Linux sono:

  • dm-crypt/LUKS: tuttora lo standard della crittografia del disco su Linux. Funziona a livello di block device ed è trasparente per il filesystem (stile LVM), permette quindi la cifratura di interi dischi, partizioni o volumi logici.
  • fscrypt (2016): un framework di crittografia che opera a livello di file e directory anziché di device come LUKS. È integrato direttamente nel filesystem ext4 e F2FS (a “breve” dovrebbe utilizzabile anche su Btrfs). È utile se ci si vuol limitare a proteggere specifiche directory, magari per non sovraccaricare il sistema cifrando l’intero disco.
  • gocryptfs (2015): a differenza dei precedenti funziona in user-space tramite tramite FUSE. Come FScrypt permette la creazione di directory cifrate, ma al contrario di quest’ultimo non consente l’oscuramento dei metadati (timestamp, permessi).
  • ZFS (2019): permette di cifrare i dataset (sottovolumi). Purtroppo non essendo integrato nel kernel Linux è supportato nativamente da poche distribuzioni (Gentoo, NixOS, Proxmox…).

Quale scegliere?
Se si vuole cifrare l’intero disco probabilmente dm-crypt/LUKS è la scelta ideale, se si utilizza ext4 e ci si accontenta di cifrare solo qualche directory forse è FScrypt l’opzione migliore, se non si può fare a meno di un filesystem moderno come btrfs (che però manca ancora il supporto della cifratura) la soluzione più semplice è qualcosa che operi in user-space come gocryptfs. Se siete abbastanza avventurosi con ZFS potrete godere di una miriade di funzionalità, crittografia compresa.

Ma come si comportano sul campo questi filesystem?

Ho deciso di metterli alla prova su un Seagate Barracuda 7200 da 500GB su un moderno Intel i7-4790K con 16GB di RAM e su un più stagionato Pentium Dual-Core E5800 con 4GB RAM.

A breve l’esito dei test…