Linux — esercizi

calm@calmict:~$ ls linux/esercizi/

01Le tracce della storia sulla tua macchinaFondamentale›

Cosa costruisci

> Esercizio del Capitolo 1 — Da Unix a Linux: la storia che spiega il presente del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

leggere la release del kernel distinguendo la versione di base dal suffisso aggiunto dalla distribuzione;
risalire da un comando al pacchetto che lo fornisce e alla licenza dichiarata nei metadati locali;
riconoscere un sistema merged-/usr e spiegare perché /bin punta a /usr/bin.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap01/solution
./run.sh

Esito atteso

[ ] Lo script stampa la release restituita da uname -r, la terna numerica di base e l'eventuale suffisso della distribuzione o della build.
[ ] L'output spiega che i numeri identificano una linea di release, ma non dimostrano da soli l'assenza o la presenza di correzioni retroportate.
[ ] Per ls e uname compaiono percorso, pacchetto di appartenenza, licenza dichiarata e fonte locale consultata.
[ ] Lo script mostra che cos'è /bin sulla macchina in uso e, quando è un collegamento, dove conduce.
[ ] La spiegazione collega la vecchia necessità di avere /bin disponibile prima di montare /usr alla moderna unificazione in /usr/bin.
[ ] Lo script termina senza errori, non richiede privilegi e non modifica il sistema.

Cartella su GitHub ↗README completo ↗

02Comporre uno strumento che non esisteFondamentale›

Cosa costruisci

> Esercizio del Capitolo 2 — La filosofia Unix: strumenti che si combinano del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

trasformare un problema operativo in una sequenza di piccoli filtri;
collegare awk, sort, uniq e head in una pipeline riproducibile;
distinguere una pipeline concorrente da una semplice sequenza di comandi;
controllare il risultato intermedio e quello finale senza affidarti alla sola apparenza.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap02/solution
./run.sh

Esito atteso

[ ] report.txt contiene i percorsi 5xx, con conteggi decrescenti.
[ ] Hai verificato almeno un risultato intermedio prima del rapporto finale.
[ ] start/answers.md descrive il tipo di dati che attraversa ogni pipe.
[ ] Hai osservato la prima riga del consumatore prima della fine della pausa di due secondi.
[ ] Sai spiegare perché sort può ritardare l'output pur facendo parte di una pipeline concorrente.
[ ] solution/run.sh termina con tutti i controlli superati e non lascia file temporanei.

Cartella su GitHub ↗README completo ↗

03Il confine, visto dallo sportelloFondamentale›

Cosa costruisci

> Esercizio del Capitolo 3 — Kernel e user space: la linea che divide i due mondi del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

osservare le richieste che un programma in user space rivolge al kernel;
contare e classificare le system call con il riepilogo di strace;
riconoscere ENOENT come esito della ricerca di un file inesistente;
separare l'identità amministrativa UID 0 dalla modalità privilegiata della CPU.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap03/solution
./run.sh

Esito atteso

[ ] Hai ottenuto e annotato il riepilogo strace -c e il numero totale di system call.
[ ] Hai individuato una openat fallita con ENOENT per il file inesistente.
[ ] Hai tracciato un processo che stampa UID 0 e hai osservato le sue system call.
[ ] Sai spiegare perché UID 0 e modalità kernel non sono la stessa cosa.
[ ] solution/run.sh supera i controlli oppure segnala esplicitamente un divieto a ptrace.
[ ] Le tracce temporanee sono state eliminate.

Cartella su GitHub ↗README completo ↗

04Leggere una macchina che non conosciFondamentale›

Cosa costruisci

> Esercizio del Capitolo 4 — Anatomia di un sistema installato del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

ricavare identità e famiglia di una distribuzione da /etc/os-release;
riconoscere il gestore dei pacchetti e interrogare il suo database;
confrontare il kernel in esecuzione con i pacchetti dichiarati come installati;
usare findmnt e lsblk per trovare directory sostenute da filesystem separati.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap04/solution
./run.sh

Esito atteso

[ ] Hai annotato distribuzione, versione e famiglia usando /etc/os-release.
[ ] Hai identificato il gestore dei pacchetti e interrogato un pacchetto installato.
[ ] Hai confrontato uname -r con la dichiarazione del database dei pacchetti.
[ ] Hai elencato le directory sostenute da partizioni a blocchi diverse da quella di /.
[ ] Hai distinto un mount separato da un semplice sottoalbero della stessa sorgente.
[ ] solution/run.sh termina con tutti i controlli superati senza modificare il sistema.

Cartella su GitHub ↗README completo ↗

05Riconoscere e mettere in salvo la propria catena di avvioFondamentale›

Cosa costruisci

> Esercizio del Capitolo 5 — BIOS e UEFI: due modi di accendere una macchina del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

distinguere un avvio UEFI da un avvio BIOS osservando l'interfaccia del firmware;
individuare ed esplorare la EFI System Partition senza modificarla;
leggere BootCurrent, BootOrder e le voci BootNNNN prodotte da efibootmgr -v;
creare e verificare un backup della catena di avvio senza scrivere nella NVRAM.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap05/solution
./run.sh

Esito atteso

[ ] Hai stabilito UEFI o BIOS dalla presenza di /sys/firmware/efi.
[ ] In UEFI hai identificato sorgente, tipo e opzioni di mount della ESP.
[ ] Hai elencato i loader della ESP senza smontarla, rimontarla o scriverci.
[ ] Hai interpretato BootCurrent, BootOrder e almeno una voce BootNNNN.
[ ] Hai creato un archivio verificato con copia della ESP, metadati e impronte.
[ ] Hai previsto una seconda copia su un supporto differente.
[ ] Non hai eseguito alcun comando efibootmgr che scriva nella NVRAM.

Cartella su GitHub ↗README completo ↗

06Entrare in un sistema dalla porta di servizioFondamentale›

Cosa costruisci

> Esercizio del Capitolo 6 — Il bootloader e il passaggio di consegne del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

leggere e conservare la riga di comando del kernel in uso;
modificare temporaneamente una voce di GRUB senza cambiare la configurazione su disco;
confrontare un avvio silenzioso con uno che mostra i messaggi del kernel;
raggiungere la modalità di soccorso e avviare /bin/bash come PID 1;
spiegare perché l'accesso alla console di avvio equivale spesso al controllo del sistema.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap06/solution
./run.sh

Esito atteso

[ ] Hai conservato e interpretato la riga di comando corrente dell'host.
[ ] Hai osservato un avvio senza quiet e i messaggi prima nascosti.
[ ] Hai raggiunto il prompt della modalità di soccorso.
[ ] Hai verificato /bin/bash come PID 1 con init=/bin/bash.
[ ] Hai modificato GRUB soltanto al volo, senza scrivere la configurazione di avvio.
[ ] Hai spiegato il rischio associato all'accesso fisico alla console.
[ ] Il processo qemu è terminato e la directory con l'overlay non esiste più.

Cartella su GitHub ↗README completo ↗

07Aprire la cassetta in prestitoFondamentale›

Cosa costruisci

> Esercizio del Capitolo 7 — Il kernel prende il controllo del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

distinguere i moduli di dracut dai moduli del kernel presenti nell'initramfs;
riconoscere i driver scelti per raggiungere il disco e il filesystem della radice;
individuare gli hook o le unità che preparano /sysroot e il passaggio alla radice vera;
dimostrare in una VM perché un driver di storage mancante impedisce l'avvio;
ricostruire un initramfs funzionante senza conoscere la password del guest.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap07/solution
./run.sh

Esito atteso

[ ] Hai ispezionato una copia, mai il file originale in /boot.
[ ] Hai distinto moduli dracut e moduli del kernel.
[ ] Hai collegato i driver di storage e filesystem alla radice dell'host.
[ ] Hai letto almeno un hook reale e il meccanismo di switch-root.
[ ] Hai rotto soltanto l'initramfs nell'overlay e osservato la shell dracut.
[ ] Hai conservato il messaggio di errore reale del guest.
[ ] Hai riparato l'immagine senza password e verificato il boot finale.
[ ] Il processo QEMU e la directory temporanea non esistono più.

Cartella su GitHub ↗README completo ↗

08Scrivere un servizio e misurare un avvioFondamentale›

Cosa costruisci

> Esercizio del Capitolo 8 — PID 1: da init a systemd del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

scrivere e validare una unità utente con dipendenze esplicite;
configurare e osservare un riavvio automatico;
distinguere l'avvio immediato con systemctl --user start dall'abilitazione agli avvii futuri con systemctl --user enable;
confrontare systemd-analyze blame con systemd-analyze critical-chain senza confondere durata e impatto sul percorso critico.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap08/solution
./run.sh

Esito atteso

[ ] Il servizio principale parte solo dopo la sua dipendenza oneshot.
[ ] Il log contiene almeno due timestamp e NRestarts è almeno 1.
[ ] Dopo start il servizio è attivo ma non abilitato.
[ ] Dopo enable, prima del nuovo start, il servizio è abilitato ma inattivo.
[ ] Hai confrontato la prima posizione di blame con la catena critica e spiegato perché non identificano necessariamente la stessa unità.
[ ] Le unità, il collegamento di abilitazione e i dati runtime del laboratorio non esistono più al termine.

Cartella su GitHub ↗README completo ↗

09Radiografia di un processoFondamentale›

Cosa costruisci

> Esercizio del Capitolo 9 — Anatomia di un processo del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

ispezionare stato, memoria, descrittori aperti e namespace di un processo vivo attraverso /proc;
riconoscere uno zombie e collegarlo alla mancata wait del processo padre;
distinguere il sonno interrompibile S dal sonno non interrompibile D;
verificare sperimentalmente l'effetto di SIGKILL su un processo bloccato su una FIFO;
(passo opzionale, richiede sudo) produrre un vero stato D con un device-mapper delay e vedere perché una FIFO non può farlo.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap09/solution
./run.sh

Esito atteso

[ ] Hai trovato in /proc il file mantenuto aperto dal processo di prova.
[ ] Hai letto VmRSS, smaps_rollup e i collegamenti dei namespace del processo.
[ ] Hai osservato uno stato Z e la sua scomparsa dopo waitpid.
[ ] Hai osservato che il blocco sulla FIFO è S, non D.
[ ] Hai verificato che SIGKILL termina il processo bloccato sulla FIFO con stato di attesa 137.
[ ] Hai annotato perché la FIFO non può dimostrare lo stato D, senza dichiararla verificata comunque.
[ ] (se hai eseguito il passo 6) Hai osservato STAT D e State: D (disk sleep) durante l'attesa sul device dm-delay, e il contatore non nullo di dmsetup status mentre l'I/O era in sospeso.
[ ] Nessun processo, device-mapper, loop device o file temporaneo labcap09 rimane al termine.

Cartella su GitHub ↗README completo ↗

10Duplicarsi, trasformarsi, sparireFondamentale›

Cosa costruisci

> Esercizio del Capitolo 10 — fork, exec, wait: come nasce e muore un processo del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

osservare dall'esterno la relazione fra un processo genitore e il figlio creato da fork();
dimostrare che exec() sostituisce il programma senza cambiare il PID;
riconoscere uno zombie dallo stato Z e rimuoverlo facendo eseguire wait() al genitore.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap10/solution
./run.sh

Esito atteso

[ ] ps mostra contemporaneamente genitore e figlio, con la relazione PID/PPID corretta.
[ ] Il PID prima e dopo exec è identico e il programma osservato dopo exec è sleep.
[ ] Il figlio terminato appare con stato Z prima della wait del genitore.
[ ] Dopo SIGUSR1 al genitore, il PID dello zombie non esiste più.
[ ] Tutti i processi di prova sono terminati e la directory temporanea è stata rimossa.

Cartella su GitHub ↗README completo ↗

11Vedere lo scheduler decidereIntermedio›

Cosa costruisci

> Esercizio del Capitolo 11 — Lo scheduler: chi gira, e per quanto del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

osservare come più processi CPU-bound si dividono una quota limitata di CPU;
misurare l'effetto di nice sulla CPU e distinguerlo dalla priorità delle operazioni di I/O;
riconoscere un carico alto con CPU quasi scariche leggendo insieme load average, processi eseguibili e utilizzo CPU.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap11/solution
./run.sh

Esito atteso

[ ] Ogni comando docker run contiene un limite --cpus esplicito e termina entro pochi secondi.
[ ] Hai osservato quattro processi dividersi due CPU e registrato i tick di ciascuno.
[ ] Sotto contesa CPU, il processo con nice 0 ha accumulato più tick di quello con nice 15.
[ ] Il confronto dd documenta che nice da solo non garantisce la priorità I/O e identifica le altre variabili rilevanti.
[ ] Hai riconosciuto molti processi eseguibili insieme a un utilizzo CPU confinato a circa un quarto di core.
[ ] Nessun container labcap11 è rimasto in esecuzione.

Cartella su GitHub ↗README completo ↗

12Parlare a un processo che non vuole ascoltareFondamentale›

Cosa costruisci

> Esercizio del Capitolo 12 — Segnali: la messaggistica del kernel del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

intercettare SIGTERM ed eseguire una chiusura ordinata fuori dal signal handler;
dimostrare che SIGKILL non può essere intercettato e impedisce la pulizia applicativa;
usare SIGHUP per rileggere una configurazione senza cambiare PID;
diagnosticare e correggere un processo PID 1 che fa attendere docker stop per dieci secondi.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap12/solution
./run.sh

Esito atteso

[ ] SIGHUP ricarica il valore modificato e il PID del servizio non cambia.
[ ] SIGTERM produce una riga di chiusura ordinata e rimuove il file di lavoro.
[ ] SIGKILL lascia il file di lavoro, dimostrando che la pulizia non è stata eseguita.
[ ] Il container difettoso impiega circa dieci secondi a fermarsi.
[ ] Il PID 1 corretto inoltra la terminazione al figlio, lo raccoglie e si ferma rapidamente.
[ ] Nessun processo di prova e nessun container labcap12 rimane attivo.

Cartella su GitHub ↗README completo ↗

13Due processi, un indirizzo, due memorieFondamentale›

Cosa costruisci

> Esercizio del Capitolo 13 — Memoria virtuale: indirizzi che mentono del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

dimostrare che due processi possono usare lo stesso indirizzo virtuale per contenuti diversi;
leggere /proc/PID/maps e interpretare permessi e scopo delle principali regioni;
misurare RSS e PSS in /proc/PID/smaps_rollup e spiegare come vengono conteggiate le pagine condivise.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap13/solution
./run.sh

Esito atteso

[ ] Due processi distinti riportano lo stesso indirizzo virtuale e valori iniziali diversi.
[ ] Modificare la pagina di alpha non cambia il valore osservato da beta.
[ ] Hai identificato eseguibile, heap, stack, pagina anonima, librerie, vvar e vdso leggendo i loro permessi.
[ ] Hai misurato RSS e PSS per entrambe le istanze e spiegato perché PSS è inferiore in presenza di pagine condivise.
[ ] Entrambi i processi di prova sono terminati e i file temporanei sono stati rimossi.

Cartella su GitHub ↗README completo ↗

14Provocare i fault e guardarli accadereFondamentale›

Cosa costruisci

> Esercizio del Capitolo 14 — Paging, page fault e swap del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

distinguere fault minori e maggiori misurandoli su due letture dello stesso file;
osservare il copy-on-write creare copie private una pagina alla volta dopo fork;
riconoscere un principio di thrashing dalle scansioni, dai refault e dalla pressione sulla memoria;
confinare un esperimento di pressione della memoria in un cgroup con risorse limitate.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap14/solution
./run.sh

Esito atteso

[ ] Hai registrato fault minori e maggiori della prima e della seconda lettura dello stesso file.
[ ] Hai osservato l'aumento dei fault minori mentre il figlio modifica pagine condivise dopo fork.
[ ] Hai spiegato il legame tra copy-on-write e fault minori.
[ ] Hai eseguito la pressione della memoria solo in un container con limiti espliciti e timeout, oppure hai documentato perché il demone non era accessibile.
[ ] Hai confrontato almeno due metriche tra scansioni, refault e pressione della memoria.
[ ] Al termine non restano container o processi del laboratorio.

Cartella su GitHub ↗README completo ↗

15Riempire la memoria e guardare chi cadeFondamentale›

Cosa costruisci

> Esercizio del Capitolo 15 — Allocazione, cache e OOM killer del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

distinguere memoria libera e memoria disponibile quando cresce la page cache;
osservare che una grande allocazione virtuale non consuma memoria fisica finché le pagine non vengono toccate;
provocare un OOM confinato e identificare il processo terminato dal kernel;
verificare i limiti di memoria e l'esito OOM attraverso lo stato del container.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap15/solution
./run.sh

Esito atteso

[ ] Hai confrontato memoria libera e stima della memoria disponibile prima e dopo aver riempito la page cache.
[ ] Hai mostrato che la memoria virtuale cresce molto più della memoria fisica per un'allocazione non toccata.
[ ] Hai ottenuto OOMKilled=true ed exit code 137 per il solo container OOM.
[ ] Hai letto i log dell'allocatore fino al blocco che precede la terminazione.
[ ] Hai verificato che memory e memory-swap coincidano per ogni container.
[ ] Nessun processo o container del laboratorio resta attivo al termine.

Cartella su GitHub ↗README completo ↗

16Lavorare con i numeri, non con i nomiFondamentale›

Cosa costruisci

> Esercizio del Capitolo 16 — Tutto è un file: descriptor e I/O del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

osservare la tabella dei descriptor di un processo durante open e close;
verificare che una redirezione cambia l'oggetto associato a un numero di descriptor;
riconoscere un file cancellato ma ancora aperto;
collegare la chiusura dell'ultimo descriptor al recupero dello spazio occupato.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap16/solution
./run.sh

Esito atteso

[ ] Hai confrontato la tabella dei descriptor prima di open, dopo open e dopo close.
[ ] Hai identificato il numero del descriptor aggiunto e poi rimosso.
[ ] Hai verificato che il descriptor 1 punti al file dopo la redirezione.
[ ] Hai trovato con lsof il file cancellato ancora aperto, con NLINK uguale a zero.
[ ] Hai verificato che la voce scompaia dopo close.
[ ] Nessun processo o file temporaneo del laboratorio resta al termine.

Cartella su GitHub ↗README completo ↗

17Un albero, tanti mondiIntermedio›

Cosa costruisci

> Esercizio del Capitolo 17 — VFS: il livello che unifica i filesystem del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

osservare come un mount nasconde temporaneamente il contenuto della directory sottostante;
creare una vista privata dell'albero dei mount senza privilegi amministrativi;
confrontare la stessa pathname dall'interno e dall'esterno di un namespace;
attraversare /proc/PID/root per raggiungere, quando consentito, la vista di un processo isolato.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap17/solution
./run.sh

Esito atteso

[ ] Hai visto il file originale prima del mount, nascosto durante il mount e di nuovo visibile dopo umount.
[ ] Hai verificato che il file creato nel tmpfs sia visibile soltanto nella vista isolata.
[ ] Hai confermato da mountinfo che labcap17tmpfs appartiene solo al namespace privato.
[ ] Hai raggiunto il file interno tramite /proc/PID/root oppure hai documentato il rifiuto dei permessi.
[ ] Non hai usato sudo e non hai montato nulla nella vista reale dell'host.
[ ] Al termine non restano processi, mount o directory scratch del laboratorio.

Cartella su GitHub ↗README completo ↗

18Il nome non è il fileFondamentale›

Cosa costruisci

> Esercizio del Capitolo 18 — Inode, link e struttura del filesystem del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

distinguere un nome di directory dall'inode a cui punta;
confrontare hard link e link simbolici quando un nome viene rimosso;
riconoscere l'esaurimento degli inode anche quando rimane spazio per i dati;
pubblicare un file completo mediante una rinomina atomica.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap18/solution
./run.sh

Esito atteso

[ ] I due hard link hanno lo stesso inode e il contatore sale a 2, poi torna a 1 dopo la rimozione di un nome.
[ ] Il link simbolico rotto è riconosciuto come link ma non come percorso verso un file esistente.
[ ] L'esaurimento avviene soltanto sull'immagine labcap18.img e df mostra inode esauriti con spazio dati ancora libero.
[ ] Il lettore della prova di rinomina atomica non osserva stati assenti o parziali.
[ ] Loop device, mount, immagine e file temporanei sono stati rimossi a fine prova.

Cartella su GitHub ↗README completo ↗

19Il dato che credi di aver salvatoIntermedio›

Cosa costruisci

> Esercizio del Capitolo 19 — I filesystem reali e il block layer del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

osservare i dati sporchi presenti nella cache del kernel dopo una write;
misurare la differenza fra completare una scrittura e richiederne la sincronizzazione;
sostituire un file senza esporre stati intermedi e rendere durevole anche la nuova voce di directory;
ricostruire la pila che collega un mount ai dispositivi a blocchi sottostanti.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap19/solution
./run.sh

Esito atteso

[ ] Hai raccolto Dirty prima della write, subito dopo e dopo la sincronizzazione del file.
[ ] Hai misurato entrambe le scritture e sai distinguere completamento di write da persistenza richiesta con fsync.
[ ] Il produttore esegue scrittura completa, fsync del file, rename e fsync della directory, in quest'ordine.
[ ] Il lettore concorrente non osserva stati mancanti, parziali o misti.
[ ] La copia con conv=fsync supera cmp e produce checksum uguali; non è stato simulato un crash reale.
[ ] Hai letto la pila dei dispositivi con findmnt e lsblk senza scrivere su un dispositivo a blocchi.
[ ] Tutti i file di prova sono stati rimossi a fine esercizio.

Cartella su GitHub ↗README completo ↗

20Il numero dietro il nomeFondamentale›

Cosa costruisci

> Esercizio del Capitolo 20 — Utenti, gruppi e identità del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

distinguere il nome di un account dal suo UID numerico;
prevedere l'effetto di una rinumerazione sulla proprietà mostrata per i file;
diagnosticare permessi incoerenti su un volume condiviso da ambienti con mappe UID diverse;
seguire una catena PAM e riconoscere i gruppi auth, account, password e session.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap20/solution
./run.sh

Esito atteso

[ ] useradd e usermod sono stati eseguiti soltanto in un container effimero.
[ ] Hai osservato l'UID 21001 invariato nell'inode mentre il nome proprietario scompare e poi cambia.
[ ] Il volume condiviso riproduce un rifiuto di lettura fra UID 23001 e 24001 nonostante il nome utente uguale.
[ ] Hai identificato auth, account, password e session nella catena PAM dell'host.
[ ] La lettura PAM non ha modificato file e tutti i container e dati di prova labcap20 sono stati rimossi.

Cartella su GitHub ↗README completo ↗

21Cancellare un file che non puoi leggereFondamentale›

Cosa costruisci

> Esercizio del Capitolo 21 — Permessi, setuid e capabilities del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

collegare creazione e cancellazione ai permessi della directory anziché a quelli del file;
distinguere il permesso di attraversamento da quello di elencazione;
confrontare un eseguibile setuid root con lo stesso eseguibile dotato della sola capability necessaria;
verificare privilegi effettivi e cleanup senza modificare binari o account dell'host.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap21/solution
./run.sh

Esito atteso

[ ] Hai cancellato un file illeggibile grazie a scrittura e attraversamento sulla directory.
[ ] Hai osservato rm fallire sia senza scrittura sia senza attraversamento sulla directory.
[ ] Il percorso noto è accessibile in una directory modo 0111, ma l'elenco con ls è negato.
[ ] Setuid e setcap sono stati applicati soltanto alla copia nella scratch isolata del container.
[ ] La prova setuid funziona con EUID 0; la prova cap_net_raw funziona mantenendo l'EUID dell'utente labcap21user.
[ ] Nessun account, attributo di sicurezza, container o file di prova rimane sull'host.

Cartella su GitHub ↗README completo ↗

22Due gruppi, una cartellaIntermedio›

Cosa costruisci

> Esercizio del Capitolo 22 — ACL e permessi estesi del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

concedere diritti diversi a due gruppi sulla stessa cartella;
impostare ACL predefinite che si propagano ai nuovi contenuti;
interpretare la mask e l'effetto di chmod sulle ACL estese;
verificare quali metodi di copia conservano le ACL.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap22/solution
./run.sh

Esito atteso

[ ] La cartella assegna diritti differenti a due gruppi oltre ai nove bit tradizionali.
[ ] Un file e una sottocartella nuovi ereditano le ACL predefinite.
[ ] Hai osservato chmod modificare la mask e hai ripristinato i diritti con setfacl.
[ ] Hai confrontato una copia che conserva le ACL con due copie che non clonano l'ACL nominata.
[ ] Hai compilato answers.md e rimosso la cartella scratch.

Cartella su GitHub ↗README completo ↗

23Fermare root con una politicaAvanzato›

Cosa costruisci

> Esercizio del Capitolo 23 — Mandatory Access Control e hardening del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

riconoscere un diniego SELinux che si manifesta come risposta HTTP 403;
correggere l'etichetta di un contenuto senza allargare i permessi Unix;
usare una modalità permissiva limitata a un solo dominio per la diagnosi;
dimostrare che gli argomenti di un processo non sono un posto sicuro per i segreti.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap23/solution
./run.sh

Esito atteso

[ ] Hai riprodotto un 403 causato dall'etichetta e un 200 dopo chcon, senza chmod.
[ ] Hai diagnosticato il diniego rendendo permissivo soltanto httpd_t e hai poi rimosso l'eccezione.
[ ] Un secondo utente nel container ha letto il segreto da /proc/PID/cmdline.
[ ] Nessun server o container di laboratorio è rimasto attivo e la directory scratch è stata rimossa.
[ ] answers.md contiene contesti, codici HTTP e spiegazioni richieste.

Cartella su GitHub ↗README completo ↗

24Il comando che non hai scrittoFondamentale›

Cosa costruisci

> Esercizio del Capitolo 24 — La shell: cosa fa prima di eseguire del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

distinguere il testo digitato dagli argomenti ricevuti dal programma;
riconoscere gli effetti di suddivisione in parole e globbing;
proteggere nomi di file e variabili con le virgolette;
rendere uno script indipendente dalla directory corrente e dal PATH interattivo.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap24/solution
./run.sh

Esito atteso

[ ] Hai mostrato il vettore di argomenti risultante da quoting, variabili e globbing.
[ ] Hai riprodotto il fallimento del nome con spazio e lo hai corretto con le virgolette.
[ ] Lo script originale riesce con il PATH interattivo ma fallisce con env -i.
[ ] Lo script corretto riesce con env -i usando un percorso derivato dalla propria posizione.
[ ] Hai compilato answers.md e rimosso tutti i file temporanei.

Cartella su GitHub ↗README completo ↗

25Riempire lo sportelloFondamentale›

Cosa costruisci

> Esercizio del Capitolo 25 — Pipe e redirection: comporre strumenti del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

misurare la capacità effettiva di una pipe senza supporre un valore fisso;
osservare la contropressione fra produttore e consumatore;
riconoscere una subshell creata da una pipeline Bash;
collegare lo stato 141 a SIGPIPE in presenza di pipefail.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap25/solution
./run.sh

Esito atteso

[ ] Hai misurato la capacità riempiendo davvero una pipe fino a EAGAIN.
[ ] Hai osservato il produttore bloccato e la sua ripartenza dopo una lettura del consumatore.
[ ] Hai ottenuto count=0 con la pipeline e count=3 con la sostituzione di processo.
[ ] Hai provocato lo stato 141 e identificato il produttore come processo terminato da SIGPIPE.
[ ] Tutti i processi e i descrittori della prova sono terminati.

Cartella su GitHub ↗README completo ↗

26Vedere quello che nessuno ti diceIntermedio›

Cosa costruisci

> Esercizio del Capitolo 26 — System call, procfs e sysfs: guardare dentro del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

usare strace per trovare la system call che spiega un errore taciuto dal programma;
riconoscere il buffering di stdio quando stdout è collegato a una pipe e correggerlo;
leggere e modificare un sysctl di rete in un namespace isolato;
distinguere una modifica immediata da una configurazione caricata all'avvio.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap26/solution
./run.sh

Esito atteso

[ ] La traccia mostra openat con risultato -1 ENOENT per il file mancante.
[ ] Hai osservato zero byte durante l'esecuzione bufferizzata e dati già visibili con output non bufferizzato.
[ ] Hai verificato i valori 0 e 1 del sysctl esclusivamente dentro labcap26.
[ ] Sai spiegare il ruolo del file in /etc/sysctl.d e hai eseguito l'eventuale prova di riavvio solo su una macchina sacrificabile.
[ ] Il namespace labcap26 e i file temporanei sono stati rimossi.

Cartella su GitHub ↗README completo ↗

27Seguire un pacchettoIntermedio›

Cosa costruisci

> Esercizio del Capitolo 27 — Lo stack TCP/IP dentro il kernel del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

leggere la distribuzione per CPU delle interruzioni associate alla rete;
provocare e riconoscere lo scarto dovuto al buffer di ricezione di una singola socket UDP;
distinguere lo scarto della socket da quello registrato sull'interfaccia;
verificare se net.netfilter.nf_conntrack_max è davvero isolato per namespace, e riconoscere il sintomo quando non lo è.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap27/solution
./run.sh

Esito atteso

[ ] Hai riportato i contatori per CPU di almeno una sorgente di interruzioni di rete, oppure hai documentato che l'ambiente non ne espone.
[ ] Hai fatto crescere Udp RcvbufErrors e i drop della socket senza attribuirli erroneamente a RX dropped dell'interfaccia.
[ ] Hai riletto nf_conntrack_max sia dentro labcap27 sia dal namespace iniziale dopo averlo scritto a 128 nel namespace, e hai verificato che il valore non è cambiato.
[ ] Hai verificato che tutti i flussi UDP inviati risultano tracciati e ricevuti, coerente con l'assenza di un tetto realmente applicato.
[ ] Hai annotato perché nf_conntrack_max non è isolato per-namespace su questo kernel, a differenza di net.ipv4.ip_forward.
[ ] labcap27, la sua tabella nft e ogni processo di prova sono stati rimossi.

Cartella su GitHub ↗README completo ↗

28Costruire una rete con le proprie maniIntermedio›

Cosa costruisci

> Esercizio del Capitolo 28 — Interfacce, indirizzi, routing e socket del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

creare namespace di rete e spostare al loro interno le estremità di una coppia veth;
configurare indirizzi e verificare la connettività tra due stack di rete isolati;
costruire un segmento Ethernet con un bridge e tre endpoint;
usare ip route get per prevedere interfaccia e indirizzo sorgente scelti dal kernel.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap28/solution
./run.sh

Esito atteso

[ ] I nomi labcap28 sono stati controllati prima della creazione.
[ ] labcap28a raggiunge labcap28b sulla coppia veth diretta.
[ ] Tre endpoint raggiungono gli altri attraverso labcap28br.
[ ] Le decisioni mostrate da ip route get coincidono con i test di connettività.
[ ] Tutti i namespace, il bridge e tutte le veth labcap28 sono stati rimossi.

Cartella su GitHub ↗README completo ↗

29Un firewall minimo, e la prova che filtra dove crediIntermedio›

Cosa costruisci

> Esercizio del Capitolo 29 — nftables e il firewall del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

costruire un ruleset con policy predefinita drop ed eccezioni esplicite;
distinguere i percorsi input e forward osservando contatori nominati;
pubblicare un servizio interno con DNAT;
riconoscere indirizzo e porta prima e dopo la traduzione.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap29/solution
./run.sh

Esito atteso

[ ] Il ruleset ha policy drop ed espone soltanto le eccezioni richieste.
[ ] Il collegamento pubblicato incrementa labcap29_forward_web ma non labcap29_input_seen.
[ ] Il servizio è raggiungibile tramite 10.29.1.1:18080 e il server registra 10.29.2.2:8080 come destinazione locale.
[ ] Un collegamento non autorizzato verso 10.29.2.2:9090 fallisce.
[ ] I tre namespace, le veth, i processi e il ruleset isolato sono stati rimossi.

Cartella su GitHub ↗README completo ↗

30Costruire un'illusioneAvanzato›

Cosa costruisci

> Esercizio del Capitolo 30 — Namespaces: le illusioni del kernel del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

creare insieme namespace user, PID, rete, UTS e mount senza privilegi amministrativi;
confrontare PID, hostname e rete osservati dall'host con quelli visibili nella shell isolata;
entrare dall'esterno nei namespace di un processo con nsenter;
interpretare la mappatura che rende un utente root nel namespace senza renderlo root sull'host.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap30/solution
./run.sh

Esito atteso

[ ] La shell usa contemporaneamente namespace user, PID, rete, UTS e mount con propagazione privata.
[ ] PID, hostname e namespace di rete interni sono diversi da quelli osservati sull'host.
[ ] nsenter avvia dall'esterno un processo che osserva la stessa vista isolata.
[ ] /proc/self/uid_map dimostra che root interno è mappato all'UID non privilegiato dell'host.
[ ] La rete isolata contiene soltanto loopback e la shell non vede i processi dell'host.
[ ] Tutti i processi e le risorse temporanee sono stati rimossi.

Cartella su GitHub ↗README completo ↗

31Mettere un tettoAvanzato›

Cosa costruisci

> Esercizio del Capitolo 31 — Cgroups v2: contabilità e limiti del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

creare cgroup v2 soltanto dentro una scope utente delegata;
limitare un carico a mezzo core e leggere il throttling da cpu.stat;
confinare un allocatore di memoria e osservare l'OOM del solo gruppo;
confrontare la pressione recuperabile di memory.high con il limite rigido di memory.max.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap31/solution
./run.sh

Esito atteso

[ ] Tutti i cgroup del laboratorio sono figli di una scope utente con delega esplicita.
[ ] cpu.max rappresenta mezzo core e cpu.stat mostra almeno un evento di throttling.
[ ] Lo stesso carico da 72 MiB sopravvive a memory.high ma viene terminato da memory.max.
[ ] memory.events mostra un aumento di high nel primo caso e di oom_kill nel secondo.
[ ] Il processo di controllo resta fuori dai cgroup limitati.
[ ] La durata dei carichi è limitata e tutti i cgroup e processi temporanei vengono rimossi.

Cartella su GitHub ↗README completo ↗

32Il tuo container, dalla prima rigaAvanzato›

Cosa costruisci

> Esercizio del Capitolo 32 — Un container a mano, senza Docker del > *Manuale di Linux* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

costruire un filesystem di base in una directory temporanea;
combinare namespace user, PID, rete, UTS, mount e IPC senza privilegi sull'host;
sostituire la radice con pivot_root e montare proc soltanto nella nuova radice;
applicare limiti CPU e memoria tramite un cgroup v2 delegato;
collegare il container a un lato host isolato con una coppia veth;
provocare in modo controllato saturazione CPU e OOM e verificare l'invisibilità dei processi host.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd linux/ed1/cap32/solution
./run.sh

Esito atteso

[ ] Il filesystem è stato costruito in una directory temporanea e pivot_root ha reso irraggiungibile la vecchia radice.
[ ] Il container usa tutti i namespace richiesti e proc è stato montato soltanto dopo pivot_root.
[ ] La coppia labcap32-host e labcap32-guest collega il container al lato host isolato senza modificare la rete reale.
[ ] Il processo sentinella dell'host non è visibile dal container.
[ ] cpu.stat mostra throttling e memory.events mostra un OOM kill nel cgroup limitato.
[ ] Ogni carico è breve e limitato; nessun processo, cgroup, mount, interfaccia o file temporaneo rimane al termine.

Cartella su GitHub ↗README completo ↗

Le fondamenta e la filosofia

L'accensione

I processi

La memoria

File e filesystem

Identità, permessi, sicurezza

Shell e interfaccia col kernel

La rete

L'isolamento: il ponte verso i container

Cosa costruisci

Obiettivi

Come testarlo

Esito atteso

Cosa costruisci

Obiettivi

Come testarlo

Esito atteso

Cosa costruisci

Obiettivi

Come testarlo

Esito atteso

Cosa costruisci

Obiettivi

Come testarlo

Esito atteso

Cosa costruisci

Obiettivi

Come testarlo

Esito atteso

Cosa costruisci

Obiettivi

Come testarlo

Esito atteso

Cosa costruisci

Obiettivi

Come testarlo

Esito atteso

Cosa costruisci

Obiettivi

Come testarlo

Esito atteso

Cosa costruisci

Obiettivi

Come testarlo

Esito atteso

Cosa costruisci

Obiettivi

Come testarlo

Esito atteso

Cosa costruisci

Obiettivi

Come testarlo

Esito atteso

Cosa costruisci

Obiettivi

Come testarlo

Esito atteso

Cosa costruisci

Obiettivi

Come testarlo

Esito atteso

Cosa costruisci

Obiettivi

Come testarlo

Esito atteso

Cosa costruisci

Obiettivi

Come testarlo

Esito atteso

Cosa costruisci

Obiettivi

Come testarlo

Esito atteso

Cosa costruisci

Obiettivi

Come testarlo

Esito atteso

Cosa costruisci

Obiettivi

Come testarlo