Product SiteDocumentation Site

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.

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 deve guardare la documentazione ufficiale del software; riferirsi alla sezione precedente 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 della documentazione o un'utilità che può 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.

7.2.2. Monitorare l'attività dei demoni

Un demone rende un po' più complicato capire la situazione, 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.
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.
Qualunque operazione preventiva comincia consultando regolarmente i registri del server più importanti. Si possono così diagnosticare i problemi ancor prima che vengano segnalati dagli utenti scocciati. Anzi, a volte gli utenti aspettano che i problemi si ripetano per diversi giorni prima di segnalarli. Si può usare uno strumento specifico per analizzare il contenuto dei file di registro più grandi. 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. Alcuni di questi programmi operano in maniera modulare e permettono di analizzare diversi tipi di file di registro. Questo è il caso di lire o anche modlogan. Altri strumenti, come logcheck (un programma discusso in Capitolo 14, Sicurezza), scorrono questi file alla ricerca di avvisi di cui occuparsi.

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 lista di posta . 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.
Soddisfatte queste due condizioni, si può pensare a descrivere il problema alla lista. Includere quante più informazioni pertinenti possibile: quali prove si sono effettuate, che documentazione si è consultato, i tentativi 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 STRUMENTO Sistema di tracciamento dei bug (BTS)) alla ricerca di problemi simili e menzionare il risultato di questa ricerca, fornendo i link ai bug trovati. Il BTS comincia a:
Più cortesia e precisione si sono 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 (http://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.