Wenn Sie ein unbekanntes Paket konfigurieren möchten, müssen Sie schrittweise vorgehen. Zunächst sollten Sie lesen, was der Paketbetreuer dokumentiert hat. So wird die Lektüre von /usr/share/doc/paket/README.Debian es Ihnen gewiss ermöglichen, etwas über spezielle Vorkehrungen zu erfahren, die getroffen wurden, um die Verwendung der Software zu vereinfachen. Manchmal ist dies unerlässlich, um Unterschiede zum ursprünglichen Verhalten des Programms zu verstehen, wie es in der allgemeinen Dokumentation (zum Beispiel den HowTos) beschrieben ist. Manchmal erklärt die Datei auch Einzelheiten der häufigsten Fehler, so dass Sie keine Zeit mit gewöhnlich auftretenden Problemen vergeuden.

Anschließend sollten Sie einen Blick auf die offizielle Dokumentation der Software werfen - sehen Sie in Abschnitt 7.1, „Dokumentationsquellen“ nach, um die verschiedenen vorhandenen Dokumentationsquellen zu ermitteln. Der Befehl dpkg -L paket gibt eine Liste der in dem Paket enthaltenen Dateien aus; so können sie schnell feststellen, welche Dokumentation verfügbar ist (wie auch die in /etc/ befindlichen Konfigurationsdateien). dpkg -s paket führt die Paket-Header auf und zeigt alle möglichen empfohlenen oder vorgeschlagenen Pakete an; darin können sie die Dokumentation finden oder ein Hilfsprogramm, das die Konfigurierung der Software erleichtert.

Schließlich sind auch die Konfigurationsdateien häufig intern mit zahlreichen erklärenden Kommentaren versehen, die die verschiedenen möglichen Werte für jede Konfigurationseinstellung im Einzelnen darlegen. Und zwar so konkret, dass es häufig ausreicht, eine der verfügbaren Zeilen zu aktivieren. Manchmal werden auch Fallbeispiele der Konfigurationsdateien im Verzeichnis /usr/share/doc/paket/examples/ bereitgestellt. Sie können als Basis für Ihre eigene Konfigurationsdatei dienen.

Was ein Daemon tut ist etwas komplizierter, da dieser nicht direkt mit dem Administrator interagiert. Um zu überprüfen, ob ein Daemon tatsächlich läuft, müssen Sie ihn testen. Um zum Beispiel Apache (Webserver-Daemon) zu überprüfen, testen Sie ihn mit einer HTTP-Anforderung.

Um solche Tests zu ermöglichen, protokolliert ein Daemon normalerweise alles, was er tut, sowie auch alle Fehler, die ihm begegnen, in sogenannten „Protokolldateien“ oder „Systemprotokollen“. Protokolle werden im Verzeichnis /var/log/ oder einem seiner Unterverzeichnisse gespeichert. Um für jeden Daemon den genauen Namen der Protokolldatei herauszufinden, sehen Sie in seiner Dokumentation nach. Hinweis: Ein einzelner Test ist nicht immer ausreichend, wenn er nicht alle etwaigen Anwendungsfälle abdeckt; einige Probleme treten nur unter ganz bestimmten Umständen auf.

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 Kapitel 14, Sicherheit), scan these files in search of alerts to be dealt with.

If your various searches haven't helped you to get to the root of a problem, it is possible to get help from other, perhaps more experienced people. This is exactly the purpose of the debian-user@lists.debian.org mailing list and its language specific siblings debian-user-lang@lists.debian.org. As with any community, it has rules that need to be followed. Before asking any question, you should check that your problem isn't already covered by recent discussions on the list or by any official documentation.

Once those two conditions are met, you can think of describing your problem to the mailing list. Include as much relevant information as possible: various tests conducted, documentation consulted, how you attempted to diagnose the problem, the packages concerned or those that may be involved, etc. Check the Debian Bug Tracking System (BTS, described in sidebar Abschnitt 1.3.2.1, „Fehler melden“) for similar problems, and mention the results of that search, providing links to bugs found. BTS starts on:

Je höflicher und genauer Sie sind, desto größer sind Ihre Aussichten, eine Lösung zu erhalten oder doch wenigstens Teile einer Antwort. Falls Sie passende Informationen über private E-Mails erhalten, sollten Sie in Betracht ziehen, diese öffentlich zusammenzufassen, so dass sie auch anderen nützen. Das ermöglicht Anderen, die vielleicht das gleiche Problem haben, mit verschiedenen Suchmaschinen in den Archiven der Mailingliste die Problemlösung zu finden.

Wenn alle Ihre Versuche, ein Problem zu lösen, fehlschlagen, ist es möglich, dass die Lösung nicht in Ihrem Verantwortungsbereich liegt, und dass das Problem von einem Programmfehler hervorgerufen wird. In diesem Fall besteht die richtige Vorgehensweise darin, den Fehler an Debian oder direkt an die ursprünglichen Entwickler zu melden. Hierzu grenzen Sie das Problem möglichst weitgehend ein und erstellen eine minimale Testsituation, in der er reproduziert werden kann. Wenn Sie wissen, welches Programm offensichtlich der Grund für das Problem ist, können Sie das dazugehörige Paket mit dem Befehl dpkg -S betroffene_datei finden. Überprüfen Sie die Fehlerdatenbank (https://bugs.debian.org/paket), um sicherzustellen, dass der Fehler nicht bereits gemeldet worden ist. Sie können dann Ihren eigenen Fehlerbericht mit dem Befehl reportbug einsenden, einschließlich möglichst vieler Informationen, insbesondere einer vollständigen Beschreibung der minimalen Testfälle, die es jedem ermöglichen, den Fehler zu reproduzieren.

Die Teile dieses Kapitels zeigen ein Weg, Probleme effektiv zu lösen, die die folgenden Kapitel hervorrufen könnten. Benutzen Sie sie so oft wie nötig!