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

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.
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.
As a preventive operation, the administrator should regularly read the most relevant server logs. They can thus diagnose problems before they are even reported by disgruntled users. Indeed users may sometimes wait for a problem to occur repeatedly over several days before reporting it. In many cases, there are specific tools to analyze the contents of the larger log files. In particular, such utilities exist for web servers (such as analog, awstats, webalizer for Apache), for FTP servers, for proxy/cache servers, for firewalls, for e-mail servers, for DNS servers, and even for print servers. Other tools, such as logcheck (a software discussed in Capitolo 14, Sicurezza), scan these files in search of alerts to be dealt with.

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 . 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 sono state effettuate, che documentazione è stata 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 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!