When you want to configure an unknown package, you must proceed in stages. First, you should read what the package maintainer has documented. Reading /usr/share/doc/package/README.Debian will allow you to learn of specific provisions made to simplify the use of the software. It is sometimes essential in order to understand the differences from the original behavior of the program, as described in the general documentation, such as howtos. Sometimes this file also details the most common errors in order for you to avoid wasting time on common problems.

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, awffull for Apache), FTP servers, proxy/cache servers, firewalls, e-mail servers, 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.

Falls alle Ihre Suchen Ihnen nicht geholfen haben, zum Kern des Problems vorzudringen, ist es möglich, Hilfe von anderen, möglicherweise erfahreneren Leuten zu bekommen. Dies ist genau der Zweck der Mailingliste [email protected] und ihrer sprachspezifischen Geschwister debian-user-Sprache@lists.debian.org. Wie bei jeder Gemeinschaft hat sie Regeln, die zu befolgen sind. Bevor Sie eine Frage stellen, sollten Sie überprüfen, ob das Problem nicht bereits durch noch nicht lange zurückliegende Diskussionen oder durch eine offizielle Dokumentation abgedeckt ist.

Treffen diese beiden Bedingungen zu, können Sie daran gehen, Ihr Problem in der Mailingliste zu beschreiben. Fügen Sie möglichst viele sachdienliche Informationen bei: verschiedene Tests, die Sie durchgeführt haben, Dokumentationen, die Sie zurate gezogen haben, wie Sie versucht haben, das Problem zu einzugrenzen, die betroffenen oder möglicherweise beteiligten Pakete, usw. Überprüfen Sie die Debian-Fehlerdatenbank (BTS, in der Seitenleiste Abschnitt 1.3.2.1, „Fehler melden“ beschrieben) auf ähnliche Probleme und erwähnen Sie die Ergebnisse dieser Überprüfung, indem Sie Verweise zu den Fehlern, die Sie gefunden haben, angeben. Das BTS beginnt auf

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 Methoden, Probleme effektiv zu lösen, die die folgenden Kapitel hervorrufen könnten. Benutzen Sie sie so oft wie nötig!