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 im vorhergehenden Abschnitt 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.

Vorbeugend sollte der Administrator regelmäßig die wichtigsten Serverprotokolle durchsehen. Sie können auf diese Weise Probleme erkennen, noch bevor sie von verärgerten Nutzern gemeldet werden. In der Tat warten Nutzer manchmal mehrere Tage lang auf das wiederholte Auftreten eines Problems, bevor sie es melden. In vielen Fällen gibt es spezielle Hilfsprogramme, um den Inhalt größerer Protokolldateien zu analysieren. Insbesondere gibt es derartige Hilfsprogramme für Webserver (wie zum Beispiel analog, awstats, webalizer für Apache), für FTP-Server, für Proxy-/Cache-Server, für Firewalls, für E-Mail-Server, für DNS-Server und sogar für Druckserver. Einige dieser Hilfsprogramme arbeiten in modularer Weise und erlauben die Analyse verschiedener Arten von Protokolldateien. Dies ist der Fall bei lire oder auch bei modlogan. Andere Hilfsprogramme, wie logcheck (ein Programm, das in Kapitel 14, Sicherheit erörtert wird), durchforsten diese Dateien auf der Suche nach Alarmen, auf die reagiert werden muss.

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 in der Tat der Zweck der Mailingliste debian-user@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 sachbezogene Informationen bei: verschiedene Tests, die Sie durchgeführt haben, Dokumentationen, die Sie zu Rate 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 HILFSPROGRAMM Fehlerdatenbank 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 (http://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!