Product SiteDocumentation Site

7.2. Allgemeine Verfahren

Dieser Abschnitt dient dazu, einige allgemeine Tipps zu bestimmten Tätigkeiten zu geben, die ein Administrator häufig durchführen muss. Diese Verfahren werden natürlich nicht jeden denkbaren Fall in aller Ausführlichkeit abdecken, aber sie können als Ausgangspunkt für schwierigere Fälle dienen.

7.2.1. Ein Programm konfigurieren

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.
Then, you should look at the software's official documentation — refer to Abschnitt 7.1, „Dokumentationsquellen“ to identify the various existing documentation sources. The dpkg -L package command gives a list of files included in the package; you can therefore quickly identify the available documentation (as well as the configuration files, located in /etc/). dpkg -s package displays the package meta-data and shows any possible recommended or suggested packages; in there, you can find documentation or a utility that will ease the configuration of the software.
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.

7.2.2. Das Verhalten der Daemons (Hintergrundprozesse) überwachen

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. Some of these utilities operate in a modular manner and allow analysis of several types of log files. This is the case of lire. Other tools, such as logcheck (a software discussed in Kapitel 14, Sicherheit), scan these files in search of alerts to be dealt with.

7.2.3. In einer Mailingliste um Hilfe bitten

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

7.2.4. Einen Fehler melden, wenn ein Problem zu schwierig ist

If all of your efforts to resolve a problem fail, it is possible that a resolution is not your responsibility, and that the problem is due to a bug in the program. In this case, the proper procedure is to report the bug to Debian or directly to the upstream developers. To do this, isolate the problem as much as possible and create a minimal test situation in which it can be reproduced. If you know which program is the apparent cause of the problem, you can find its corresponding package using the command, dpkg -S file_in_question. Check the Bug Tracking System (https://bugs.debian.org/package) to ensure that the bug has not already been reported. You can then send your own bug report, using the reportbug command, including as much information as possible, especially a complete description of those minimal test cases that will allow anyone to recreate the bug.
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!