\n4. Grundlagen Linux

Ein paar Grundlagen benötige ich immer wieder, wenn ich die Vorgänge in einem\nLinux-System verstehen will.

Von diesen halte ich im Zusammenhang mit Fehlersuche für besonders wichtig:

die Bedeutung von Dateien und Verzeichnissen bei UNIX und Linux
das UNIX-Prozessmodell
die Schnittstellen über die ein Prozess mit seiner Umgebung interagiert

Darauf gehe ich in den folgenden Abschnitten ein.

",{"_219":220,"_43":44,"_47":48,"_45":46,"_65":66,"_221":222,"_253":217},"previewContent","

Inhaltsverzeichnis

\n
- \n Vorwort\n
  - \n Für wen ist dieses Buch\n
  - \n Wie ist das Buch aufgebaut\n
  - \n Danksagung\n
  \n
\n
\n I Allgemeine Themen\n
- \n 1. Methoden, Heuristiken und Modelle\n
  - \n Entscheidungsbaum\n
  - \n Bisektion\n
  - \n Statistische Verfahren, Korrelation\n
  - \n Abkürzungen und Umwege\n
  \n
- \n 2. Herangehen\n
- \n 3. Nachbereitung\n
\n
\n II Lokale Probleme\n
- \n 4. Grundlagen Linux\n
- \n 5. Totalausfall\n
- \n 6. Partieller Ausfall\n
- \n 7. Performance des Rechners\n
- \n 8. Werkzeuge zur lokalen Fehlersuche\n
\n
\n III Netzwerkprobleme\n
- \n 9. Grundlagen IP-Netzwerke\n
- \n 10. Totalausfall des Netzwerks\n
- \n 11. Partieller Ausfall des Netzes\n
- \n 12. Netzwerkperformance\n
- \n 13. Werkzeuge zur Fehlersuche im Netzwerk\n
- \n 14. Literatur\n
  - \n Bücher\n
  - \n Artikel in Zeitschriften, Proceedings, …\n
  - \n Online-Quellen\n
  \n
- \n 15. Kolophon\n
\n

Vorwort

\n\n

Johannes Loxen sagte in seiner Keynote zum Frühjahrsfachgespräch 2012 der GUUG\nüber den Unterschied von Closed-Source und Open-Source Software:

\n\n

\n
“Wenn es nicht funktioniert, hörst Du bei Closed-Source auf zu denken und\nrufst den Hersteller-Support an. Bei Open-Source fängt das Denken dann erst\nrichtig an”.
\n

\n\n

Dieses Buch ist für alle, die nicht nur intensiv sondern vor allem auch\nstrukturiert nachdenken wollen.

\n\n

Ich habe bereits viel Zeit mit Fehlersuche verbracht.\nSchon als Kind beim Basteln, wenn etwas nicht funktionierte.\nDann in meinem ersten Beruf, bei der Reparatur von Telefonen und\nTelefonanlagen, die damals noch mit Relais funktionierten, so dass ich ihnen\nim wahrsten Sinne des Wortes bei der Arbeit zusehen konnte.\nNach dem Studium, als Softwareentwickler, beim Debuggen meiner oder fremder\nProgramme.\nSpäter dann als Systemadministrator für UNIX und Netzwerke.

\n\n

Dabei war ich vor allem auf drei Dinge angewiesen um zum Erfolg zu kommen.\nDas erste und wichtigste ist ein grundlegendes Verständnis der\nMaterie und die Fähigkeit und Möglichkeit, weitere nötige Kenntnisse zu\nerwerben.

\n\n

Das zweite ist eine einigermaßen strukturierte Vorgehensweise, die\nmich in den meisten Fällen schneller zum Ziel führt als andere\nVorgehensweisen.

\n\n

Die dritte Voraussetzung ist die eigene Einstellung zum Problem.\nIch musste sehr oft und werde vermutlich noch oft die Erfahrung machen, dass\nich mir selbst bei der Lösung eines Problems im Weg stehe:

\n\n

Sei es, dass ich mir bereits vor Kenntnis aller relevanten Tatsachen\neine, eventuell falsche, Meinung bilde.
Sei es, dass ich durch Druck von außen oder selbst erzeugten Druck\nbesonders schnell sein will und dann beim oberflächlichen Hinsehen\nwichtige Details übersehe.
Sei es, dass ich angebotene Hilfe nicht annehme, weil ich es selbst\nschaffen will oder so sehr im Problem gefangen bin, dass ich das\nHilfsangebot nicht wahrnehme.
Sei es, dass ich kurz vor dem Ziel aufgebe und einfach nicht den\nletzten Meter gehe.

Allein diese Hindernisse zu überwinden ist eine Aufgabe für ein ganzes Leben.

\n\n

In diesem Buch bereite ich meine in mehr als zwanzig Jahren gesammelten\nErfahrungen mit der Fehlersuche bei Linux-Servern und in IP-Netzwerken auf.

\n\n

Ich habe diese beiden Themen kombiniert, weil einerseits Linux-Server fast\nimmer über IP-Netzwerke angesprochen werden und daher auf ein gut\nfunktionierendes Netzwerk angewiesen sind, andererseits Linux-Rechner\nfür mich ideal zur Analyse von Problemen im Netzwerk geeignet sind.

\n\n

Zwar benutze ich fast täglich Linux auf dem Desktop, allerdings verwende ich\nauch hier am häufigsten Terminal und Webbrowser, die in den meisten Fällen\nvorzüglich funktionieren, so dass ich kaum Gelegenheit hatte, Erfahrungen bei\nder Fehlersuche am Linux-Desktop zu sammeln.\nAus diesem Grund lasse ich diesen Bereich außen vor.

\n\n

Das gleiche gilt für IPv6 und WLAN, die ich zwar privat einsetze, aber\nnoch nicht im beruflichen Umfeld, so dass meine Erfahrungen damit nicht\nausreichen für eine fundierte und strukturierte Darstellung.

\n\n

In der Keynote von Johannes Loxen ging es so weiter:

\n\n

\n
“Manchmal wünscht man sich von den Closed-Source-Admins, dass Sie\nversuchen, weiter zu denken, indem sie sich der typischen Mittel der\nOpen-Source-Welt bedienen, also Netzwerk-Sniffer oder Debuggern.\nAllerdings wünscht man sich auch umgekehrt manchmal, dass\nOpen-Source-Admins nicht weiter denken - vor allem, wenn dies Zeit und\nGeld verbrennt und die entstehenden Kosten in keinem Verhältnis zum Wert\ndes Problems stehen”.
\n

\n\n

Hier gilt es eine Balance zu finden.\nBei Problemen, die weit über meinen Horizont gehen, habe ich kein Problem\ndamit, mir sofort Hilfe zu suchen.\nEinfache Probleme sind in der Regel im Nu geklärt.\nAnders ist es bei Problemen, die nur wenig schwieriger sind, als mein\nbisheriger Kenntnisstand.\nDas sind die Probleme, die am meisten Spaß machen, bei denen ich den\nFlow-Zustand erreiche, viel dabei lerne, besser werde und die Zeit vergesse.\nIch nutze in diesem Fall gern Timeboxing, stelle einen Kurzzeitwecker auf eine\nknappe halbe Stunde und nutze die Unterbrechung, um ein wenig Bewegung zu\nbekommen und mich zu überzeugen, dass ich noch auf dem richtigen Weg bin.

\n\n

Für wen ist dieses Buch

\n\n

Die Zielgruppe sind angehende und gestandene Systemadministratoren für\nLinux und/oder IP-Netzwerke.

\n\n

Ich setze grundlegende Kenntnisse der Kommandozeile voraus und dass der Leser\nweiß, wie er sie erreicht.\nZum Teil setze ich für die Analyse von Problemen spezielle Software ein, die\nnicht auf jedem System installiert ist.\nIch gehe davon aus, dass der Leser weiß, wie er Software auf seinem Rechner\ninstalliert.

\n\n

Dieses Buch soll Anfängern in der Systemadministration über die ersten Hürden\nbei der Fehlersuche helfen und sie bei ihren ersten Schritten begleiten.\nGestandene Administratoren werden vielleicht die eine oder andere Anregung\nentnehmen können.

\n\n

Wie ist das Buch aufgebaut

\n\n

Dieses Buch ist besteht aus drei Hauptteilen.

\n\n

Teil eins beschäftigt sich mit allgemeinen Themen der Fehlersuche, die\nauch in anderen Bereichen nützlich sein können.

\n\n

Im ersten Kapitel geht es um Methoden, Heuristiken und Modelle, also um\nstrukturelle Hilfsmittel, die mir bei bestimmten Problemen der Fehlersuche\nweiterhelfen.

\n\n

Im zweiten Kapitel geht es um die Herangehensweise an ein Problem.\nWann und wie setze ich die Hilfsmittel aus dem vorigen Kapitel ein?\nWie bereite ich mich auf die Fehlersuche vor?\nWie kann ich generell besser bei der Fehlersuche werden?

\n\n

Das dritte Kapitel geht auf die Nachbearbeitung eines Problems ein, die\nimmer auch eine Vorbereitung auf das nächste Problem ist.\nWelche Erkenntnisse kann ich aus der letzten Fehlersuche ziehen?\nKann ich diesen oder ähnliche Fehler in Zukunft vermeiden?

\n\n

Die beiden folgenden Teile des Buches sind ähnlich strukturiert.\nZuerst führe ich in Grundlagen ein, die als Hintergrundwissen für die\nfolgenden Kapitel benötigt werden.\nAls nächstes widme ich mich dem Totalausfall, dann Teilausfällen und was ich\ndarunter verstehe und schließlich Problemen mit der Performance.\nAm Schluß der Teile zwei und drei stelle ich jeweils einige Programme vor,\ndie ich bei der Fehlersuche häufig einsetze.

\n\n

Teil zwei beschäftigt sich mit lokalen Problemen einzelner Linux-Server.

\n\n

Das erste Kapitel dieses Teiles stellt Grundlagenwissen für die lokale\nFehlersuche auf Linux-Systemen vor.

\n\n

Im nächsten Kapitel geht es um Totalausfälle.\nDas können Hardwarefehler sein, Bootprobleme, ein Rechner der scheinbar oder\nwirklich nicht mehr reagiert oder ein Rechner, der durch Überlast so langsam\ngeworden ist, dass ich nicht einmal mehr eine Shell zur Diagnose bekommen kann.

\n\n

Das folgende Kapitel behandelt Teilausfälle bei Linux-Servern.\nDiese äußern sich meistens darin, dass Dienste nicht starten oder\nnicht korrekt arbeiten, oder dass Dateien nicht gespeichert werden können.

\n\n

Im anschließenden Kapitel geht es um die Performance von Linux-Servern.\nAlles funktioniert, aber richtig schnell ist es nicht.\nHier geht es darum, herauszufinden, was der Rechner macht, wenn es so lange\ndauert und wie man das beschleunigen kann.

\n\n

Das letzte Kapitel des zweiten Teils schließlich stellt Werkzeuge\nvor, die ich häufig einsetze.\nZusätzlich zu den wichtigsten Optionen zeige ich einige Anwendungsfälle\noder verweise auf Kapitel, in denen das Programm verwendet wird.

\n\n

Der dritte Teil des Buches behandelt die Fehlersuche im IP-Netzwerk.

\n\n

Das erste Kapitel dieses Teiles geht auf Totalausfälle im Netz ein.\nEin Totalausfall im Netzwerk ist für mich gegeben, wenn ein Rechner überhaupt\nkeinen Kontakt zum Netzwerk bekommt oder, wenn in einem Netzsegment die\nBasisdienste so weit ausgefallen sind, dass die Rechner\nihren Netzanschluß nicht produktiv nutzen können.

\n\n

Im nächsten Kapitel gehe ich auf Teilausfälle im Netzwerk ein.\nDabei unterscheide ich, ob ganze Netzsegmente nicht erreichbar sind oder\nnur einzelne Dienste.

\n\n

Danach geht es um Performance-Probleme im Netzwerk.\nWie analysiere ich diese?\nWelche möglichen Abhilfen gibt es?

\n\n

Und im letzten Kapitel stelle ich wiederum Werkzeuge vor, die mir bei der\nFehlersuche im Netz helfen.

\n\n

Übungen

\n\n

Ich habe mir in diesem Buch große Mühe gegeben, eine Hilfe bei der Fehlersuche\nzu bieten.\nDennoch kann es keine eigene Erfahrungen ersetzen.\nInsbesondere, wenn man vor einem schwierigen neuen Problem steht, ist es\nhilfreich, wenn die aus diesem Buch gewonnenen Erkenntnisse und die eigenen\nErfahrungen abrufbereit sind.\nAus diesem Grund habe ich einige Übungen im Buch eingestreut.\nBei diesen kommt es nicht immer auf das konkrete Ergebnis an, sondern\ndass man sie in einer freien Minute ausführt und beobachtet, was passiert.

\n\n\n\n \n

Übungen sind mit diesem Symbol gekennzeichnet.

\n\n

Zur Schreibweise

\n\n

Für Programmbeispiele und Eingaben auf der Kommandozeile verwende ich eine\ndicktengleiche Schrift, diese nehme ich auch im Fließtext, wenn ich Optionen\noder Befehle wortgetreu verwende.\nBei Kommandozeilen stehen Begriffe, die mit $ eingeleitet werden, wie zum\nBeispiel $gateway, für variable Angaben, die je nach Kontext ersetzt werden\nmüssen.

\n\n

Ansonsten verwende ich einen kursiven Font für Hervorhebungen.

\n\n

Danksagung

\n\n

Ohne die vielen Autoren der freien Software, die ich in meiner täglichen Arbeit\nnutze, wäre dieses Buch nicht möglich gewesen. Ich würde meine Arbeit auch\nnicht so ausüben können, wie ich es heute tue.

\n\n

Auch der Gemeinschaft, die das Internet möglich gemacht hat und die es täglich\naufs Neue mit Ideen, Anregungen und Problemlösungen füllt, die es nur zur\nrechten Zeit zu finden gilt, hätte ich viele der hier vorgestellten Kenntnisse\nselbst nicht erwerben können.

\n\n

Mein besonderer Dank gebührt Denise Betzendörfer und Stefan Naumann, die mir\netliche Hinweise zu diesem Buch gaben und mich auf Dinge aufmerksam machten,\ndie ich im Laufe der langen Beschäftigung mit dem Text gar nicht mehr\nwahrgenommen hatte.\nAuch Knut Schmädt, hat sich die Mühe gemacht, eine frühe\nVersion dieses Buches zu lesen und gab mir Feedback dazu.

\n\n\n

\nI Allgemeine Themen

\n\n

\n1. Methoden, Heuristiken und Modelle

\n\n

Um eine gemeinsame Sprache zu finden, lege ich zunächst kurz dar, was ich\nin diesem Buch unter Methoden, Heuristiken und Modellen verstehe.

\n\n

Methode

Spreche ich von einer Methode, meine ich ein auf Regeln aufbauendes\nVerfahren um konkrete Erkenntnisse oder praktische Ergebnisse zu erlangen,\nähnlich einem Algorithmus.\nEine Methode kann ich nur unter bestimmten Voraussetzungen sinnvoll einsetzen.\nSie liefert mir dann jedoch klar definierte Ergebnisse beziehungsweise\nErkenntnisse.

Heuristik

Das Lexikon online für Psychologie und Pädagogik¹\nbeschreibt eine Heuristik wie folgt:\n\n

“Als Heuristik oder heuristisches Vorgehen bezeichnet man in der\nPsychologie eine einfache Denkstrategie für effizientere Urteile und\nProblemlösungen, die meist schneller, aber auch fehleranfälliger ist als ein\nAlgorithmus.”

\n\n

Diese Definition kommt dem recht nahe, wie ich Heuristik in diesem Buch\nverwende.\nIm Gegensatz zur Methode bekomme ich keine klar definierten Ergebnisse,\nsondern bestenfalls Anhaltspunkte, die mir eine Richtung für die weitere\nUntersuchung anzeigen.

Modell: Unter einem Modell verstehe ich ein vereinfachtes Abbild der\nWirklichkeit, dass bestimmte, für die Betrachtung wesentliche Merkmale\nkorrekt abbildet und andere ignoriert.\nEin und dieselbe Situation kann ich mit verschiedenen Modellen beschreiben.\nWelches Modell ich wähle, hängt davon ab, welche Eigenschaften ich\nuntersuchen will.\n\n
Bei der Auswahl oder Gestaltung eines Modells gilt es zwei Gefahren zu\nvermeiden.\nBilde ich ein unwesentliches Merkmal mit ab, dann wird das Modell zu\nkomplex und macht es schwerer die wesentlichen Punkte zu erkennen.\nLasse ich wesentlichen Aspekte aus, ist es möglich, dass ich die falschen\nSchlüsse ziehe.
\n

Entscheidungsbaum

\n\n

Wenn ich auf ein neues Problem treffe, versuche ich es so schnell wie\nmöglich zu charakterisieren, um die nächsten Schritte zu seiner Behebung\nherauszufinden.\nDabei helfen mir Entscheidungsbäume.\nProgrammierer kennen so etwas auch als Programmablaufplan.

\n\n

Mein grundlegender Entscheidungsbaum bei der Fehlersuche sieht so aus,\nwie im folgenden Bild.\nGrundsätzlich werde ich nur tätig, wenn eine der Fragen mit nein beantwortet\nwird.\nDamit decke ich fast alle Probleme ab, lediglich intermittierende\nProbleme erfasst der Entscheidungsbaum nicht.

\n\n

\n $\"Allgemeiner$

Allgemeiner Entscheidungsbaum

\n\n

Die erste Frage geht danach, ob überhaupt noch etwas funktioniert oder ob\nes sich um einen Totalausfall handelt.\nDiese Frage erscheint vielleicht trivial, aber das ist letztendlich der\nZweck eines Entscheidungsbaumes: das die richtigen Fragen im richtigen Moment\ngestellt werden.\nManchmal berichtet ein Anwender, dass eine Funktion eines Programmes nicht\nfunktioniert und irgendwann stellt sich heraus, dass der ganze Rechner\neingefroren ist und zwar noch den letzten Bildschirm zeigt, aber weder auf\nTastatur, Maus noch Netzwerkzugriffe reagiert.\nEin anderes Mal kommt die Meldung, dass das Internet nicht geht (Totalausfall)\nund auf die Bitte, ein oder zwei andere Websites zu besuchen,\nstellt sich heraus, dass nur die Startseite des Browsers betroffen ist.\nDarum versuche ich mit den ersten Fragen herauszufinden, ob es sich um einen\nTotalausfall handelt, den ich anders behandeln muß als einen Teilausfall.

\n\n

Liegt kein Totalausfall vor, frage ich als nächstes, ob\nalle für das Problem relevanten Dienste funktionieren.\nEs erfordert schon einige Detailkenntnisse zur Problemzone, um zu entscheiden,\nob ein Dienst für das Problem relevant ist oder nicht.\nIm Zweifelsfall kontrolliere ich lieber einen Dienst mehr.\nHier geht es vor allem darum, einen Überblick zu bekommen, was funktioniert und\nwas nicht und sich dann über Abhängigkeiten der Teilsysteme an den oder die\nUrheber des Problems heranzutasten.\nDabei gilt es immer im Hinterkopf zu behalten, dass es zwar meist einen\nkonkreten Auslöser für ein Problem gibt, aber oft mehrere Ursachen.\nEine Möglichkeit, diese Frage zu beantworten, ist, verschiedene Funktionen einer\nSoftware auszuprobieren, verschiedene Netzdienste und Netzziele zu testen.\nHierbei kann ein Monitoringsystem wie Nagios gute Dienste leisten, wenn es\nentsprechend aufgesetzt ist.

\n\n

Funktionieren alle notwendigen Dienste prinzipiell,\nkann ich die nächste Frage stellen: ob es schnell genug ist.\nDiese Frage ist nicht leicht zu beantworten, da jeder seine eigene\nVorstellung von schnell genug hat.\nGibt es SLA, können diese vielleicht bei der Beantwortung der Frage helfen.\nBei nicht interaktiven Aufgaben, wie Datensicherungen oder Batchjobs kann ich\ndie Gesamtlaufzeit betrachten und an Hand dieser entscheiden, ob es schnell\ngenug ist, oder nicht.\nBei Dateiübertragungen kann ich an Hand von Datenübertragungsrate, Netzauslastung und\nÜbertragungsdauer überschlagen, ob es Performanceprobleme gibt oder nicht.\nBei interaktiven Programmen oder Netzwerkdiensten zählt meist nur die\nAntwortzeit des Systems, die im Bereich von Sekundenbruchteilen liegen sollte.\nKomme ich zu dem Schluss, dass es sich um ein Performanceproblem handelt,\ngehe ich dieses an.\nAnderenfalls begründe ich, warum es sich meiner Meinung nach um kein\nPerformanceproblem handelt.\nDabei kann mir eine Baseline helfen.

\n\n

Alles in allem habe ich mit den drei Fragen dieses Entscheidungsbaumes eine\nRichtschnur, die mir hilft, ein Problem herunterzubrechen und mich dem\nwichtigsten Bereich zu widmen, bevor ich mich in den Details verliere.

\n\n

Dabei muss ich den Entscheidungsbaum nicht zwangsläufig von oben nach unten\nverwenden.\nWenn mir ein Netzwerk-Performanceproblem gemeldet wird, überzeuge ich mich\nzunächst davon, dass alle für das Problem relevanten Dienste auch funktionieren.\nIch gehe in diesem Fall von unten - dem gemeldeten Performanceproblem -\neinen Schritt nach oben um sicher zu sein, dass meine folgenden Überlegungen\nauf einer gesicherten Basis stehen. Zum Beispiel kann ein ausgefallener\nDNS-Server durch Redundanz zwar kompensiert werden, aber trotzdem zu\nVerzögerungen durch Timeouts führen, die dann als Performanceproblem\nwahrgenommen werden.

\n\n

Außer den drei Hauptfragen gibt es eine vierte Frage, die ich ständig\nim Hinterkopf behalten muss.\nDas ist die Frage nach intermittierenden Fehlern und nach der\nReproduzierbarkeit des Problems, beziehungsweise meiner Beobachtungen.\nHabe ich es mit intermittierenden Fehlern zu tun, kann ich nicht mit\nSicherheit sagen, ob das Problem wirklich gelöst ist.\nNicht einmal, ob meine bisherigen Überlegungen überhaupt zutreffen.\nStattdessen hatte ich es vielleicht gerade mit einer komplikationsfreien\nZeit zu tun und kurz danach kommt das Problem wieder.\nBei intermittierenden Problemen bleibt mir nur, Daten zu sammeln und über\nKorrelation eine Idee zu bekommen, was das Problem auslösen könnte.\nJede Idee, die mir dazu einfällt, muss ich dahingehend prüfen, ob sie\ndas Problem stabil vorhersagbar macht oder nicht.

\n\n

Bisektion

\n\n

Die Bisektion, auch Intervallhalbierungsverfahren genannt, verwende ich um\neine Fehlerstelle, die in einem Intervall auftritt, schneller zu finden.\nDas Intervall kann örtlich sein - zum Beispiel bei einer Datenübertragung\nüber mehrere Hops - oder zeitlich - zum Beispiel, wenn sich der Fehler in\nLogfiles zeigt und ich den Zeitpunkt des ersten Auftretens über viele\nLogdateien hinweg suche.

\n\n

Das Verfahren selbst ist sehr einfach.\nAnstatt das Intervall sequentiell in einer Richtung abzusuchen, halbiere ich\nes und untersuche von den entstehenden Teilintervallen dasjenige,\ndessen Grenzen sich unterscheiden.\nBei diesem fahre ich mit der Bisektion fort.

\n\n

Stellen wir uns einen Stapel Papier vor, der auf dem Tisch liegt und auf den ein\nTropfen einer sehr aggressiven Flüssigkeit gefallen ist.\nUm die guten von den beschädigten Blättern zu trennen, kann ich die\nbeschädigten Blätte oben entfernen.\nAlternativ teile ich den Stapel in der Mitte auf und schaue nach, ob die\nBlätter unten beschädigt sind.\nSind sie beschädigt, werfe ich alle abgehobenen Blätter weg und teile den\nverbliebenen Stapel wieder bei der Hälfte.\nSind sie nicht beschädigt, sichere ich die untere Hälfte und teile die oberen\nBlätter wieder bei der Hälfte.\nSo fahre ich fort, bis ich zum ersten unbeschädigten Blatt komme.\nIn den meisten Fällen ist dieses Verfahren schneller, als wenn ich von oben\nnach unten durchgeblättert hätte.

\n\n

Wenn ich zum Beispiel einen Rechner in einem weit entfernten Netz zwar via\nPing erreichen kann, aber nicht mit Port 25, dann kann ich \nzunächst untersuchen, ob Datenpakete zu Port 25 beim Sender abgehen und\nob sie beim Empfänger ankommen.\nKann ich die Datenpakete beim Sender nachweisen, aber beim Empfänger nicht,\ndann suche ich etwa auf der Hälfte der Strecke, ob diese Datenpakete\nnachzuweisen sind.\nJe nachdem, ob sie dort auftreten oder nicht, halbiere ich danach die Strecke\nzum Empfänger oder zum Sender.

\n\n

Die Bisektion ist nur dann langsamer als die sequentielle Suche, wenn die\ngesuchte Stelle sich gleich am Anfang des Intervalls befindet.

\n\n

Statistische Verfahren, Korrelation

\n\n

Statistische Verfahren liefern keine Belege für Ursache-Wirkung-Beziehungen.\nSie können mir nur helfen, Ansatzpunkte für Hypothesen zu finden, die ich\nmit gezielten Tests bestätigen oder widerlegen kann.\nDabei muss ich mir vorher im klaren sein, ob ein bestimmter Test darauf\nangelegt ist, eine Hypothese zu widerlegen und damit von der weiteren\nBetrachtung auszuschließen oder die Hypothese zu bestätigen, so dass ich davon\nmeine weiteren Handlungen leiten lassen kann.

\n\n

Ein statistisches Verfahren ist die Korrelation.\nMit dieser kann ich eine Beziehung zwischen zwei oder mehreren\nMerkmalen, Ereignissen oder Zuständen beschreiben.\nDabei muss ich immer beachten, dass diese Beziehung kausal sein kann aber\nnicht muss.\nIm mathematischen Sinne beschreibt die Korrelation einen statistischen\nZusammenhang im Gegensatz zur Proportionalität, die einen festes Verhältnis\nbeschreibt.

\n\n

Will ich den Vierfelder-Korrelationskoeffizient $\"\\phi\"$ \nfür ein Merkmal und den Fehler ermitteln, stelle ich eine Kontingenztafel auf,\nin der ich die gemeinsame Häufigkeit der Merkmale eintrage.

\n\n\n\n\n \n \n \n\n\n \n \n \n\n\n \n \n \n

	kein Fehler	Fehler
Merkmal trifft zu	A	B
Merkmal trifft nicht zu	C	D

A, B, C, D stehen für die Anzahl der Ereignisse, bei den der Fehler auftrat\nbeziehungsweise nicht auftrat und das Merkmal zutraf oder nicht.\nAls Werte für A, B, C und D kann ich Zeiträume summieren, oder zu regelmäßigen\nZeitpunkten ermitteln, welcher Fall zutrifft und die entsprechende Variable\nhochzählen.

\n\n

Der Phi-Koeffizient ermittelt sich dann aus:

\n\n $\"\\phi$

Im einfachsten Fall kann ich eine Korrelation selbst sehen, zum Beispiel, wenn\nimmer die Verbindung zum Netz A wegfällt, sobald ich die Verbindung zum Netz B\numschalte.\nDas sagt zwar nichts aus über die Ursache, es gibt mir aber die Möglichkeit,\ndas Problem kurzfristig temporär aus dem Weg zu schaffen und, wenn die Zeit\ngeeignet ist, das Problem hervorzurufen, um es gründlich zu studieren.

\n\n

Intermittierende Probleme, die sich dem Zugang entziehen,\nsind eine Klasse von Problemen, bei welchen Korrelationen hilfreich sind.\nBei diesen Problemen hilft mir am Anfang nur, so viele Daten wie möglich über\ndas betroffene Gesamtsystem zu sammeln.\nBei der Analyse dieser Daten hilft mir dann die Kovarianzanalyse, das heisst,\nich vergleiche jeweils paarweise verschiedene beobachtete Systemvariablen und\nermittle den Korrelationskoeffizienten.

\n\n

Wichtig dabei ist, dass ich immer die zusammengehörigen Daten in Beziehung\nsetze.\nDa ich den Zusammenhang meist über die Uhrzeit herstelle, sorge ich also\nentweder im Vorfeld für gleichlaufende Uhren, oder ich muss den Zeitoffset\nbestimmen und heraus rechnen.

\n\n

Ein Programm, das sehr hilfreich für die Kovarianzanalyse ist, wurde in\n[WSA2011] beschrieben.

\n\n

Wichtig bei Korrelationsanalysen ist, sich vor Augen zu halten, dass\nunabhängige Merkmale eine Kovarianz nahe 0 haben.

\n\n

Abkürzungen und Umwege

\n\n

Im Laufe der Zeit, wenn ich Erfahrungen mit den Systemen gesammelt\nhabe, kann ich bei etlichen Fehlern intuitiv sagen, woran es liegt.\nDas erspart mir erhebliche Zeit bei der Fehlersuche.\nIch muss jedoch immer im Auge behalten, ob meine Annahmen auf einer realen\nGrundlage beruhen, oder ob mich meine Intuition hier in die Irre führt.

\n\n

Das heißt, dass ich jedes Mal, wenn ich eine Abkürzung nehme, mich\nvergewissern muss, dass die Voraussetzungen dafür stimmen.

\n\n

Abkürzungen

\n\n

Eine Möglichkeit, die Fehlersuche abzukürzen, ist durch simple Korrelation.\nBei der Aufnahme des Fehlers frage ich, wann der Fehler das erste Mal bemerkt\nwurde und wann es das letzte Mal funktioniert hatte.\nIm Rahmen der Fehlersuche, schaue ich nach, was am System in diesem Zeitraum\ngeändert wurde und überlege für jede Änderung, ob diese den beschriebenen\nFehler hervorrufen könnte.\nDazu benötige ich natürlich eine aussagefähige Protokollierung der Änderungen\nam System.\nUnd der Fehler sollte so schnell wie möglich gemeldet werden, damit der\nZeitraum, den ich in Betracht ziehe, nicht zu groß wird.

\n\n

Eine weitere Abkürzung passiert implizit, wenn ich ähnliche Probleme bereits\nhatte.\nDann konzentriere ich mich automatisch auf die Punkte, die beim letzten Mal\nzur Lösung geführt hatten.\nNatürlich muss ich mich fragen, ob die gleichen Voraussetzungen zutreffen.

\n\n

Umwege

\n\n

Und damit bin ich schon bei den Umwegen, weil ich, anstatt sofort auf die\nLösung zuzustürmen, erst einmal die genauen Umstände prüfe.

\n\n

Man sagt, Umwege verbessern die Ortskenntnis.\nIch interpretiere das so, dass ein Umweg eine Investition in die Zukunft ist,\nwenn ich damit, neben dem eigentlichen Ergebnis, gleichzeitig eine Annahme über\ndas Gesamtsystem überprüfen kann.\nDann ist der Zeitverlust durch den Umweg der Preis für eine Erkenntnis über das\nSystem.

\n\n

Probe und Gegenprobe

\n\n

Jeder Test, der erfolgreich ist, sollte durch eine geeignete Gegenprobe\nevaluiert werden, die bestätigt, dass der Test auch versagen kann. Das gleiche\ngilt für fehlgeschlagene Tests. Diese müssen evaluiert werden, ob sie\nfunktionieren können.

\n\n

Ist ein Verbindungsversuch auf einem Rechner fehlgeschlagen, versuche ich den\ngleichen Versuch auf einem anderen Rechner, um nachzuweisen, dass er hätte\nfunktionieren können. Das hat mich schon oft davor bewahrt, einen\nNetzwerkfehler zu vermuten, wenn lediglich ein Paketfilter\ndie Verbindung unterbunden hatte.

\n\n

\n2. Herangehen

\n\n

Neben dem geistigen Rüstzeug, das ich im vorigen Kapitel besprochen habe,\nbestimmt die Art und Weise, wie ich an ein Problem herangehe, den Erfolg.

\n\n

Natürlich gibt es kein Patentrezept, das ich unverändert auf alle\nProbleme anwenden kann.\nJe nach Wichtigkeit und Dringlichkeit werde ich vielleicht in einem Fall auf\neine schnelle, dafür nicht sehr gründliche Lösung hinarbeiten und mir in einem\nanderen Fall die Zeit nehmen, ein Problem ein für alle Mal aus der\nWelt zu schaffen.

\n\n

\n3. Nachbereitung

\n\n

Manchen Leuten scheint es gegeben, häufiger als andere richtige Voraussagen\nzu machen und damit Probleme schneller zu lösen.\nBeobachtet man diese Leute genauer, stellt man fest, das sie\nkeine Voraussagen über die Zukunft machen, sondern aus der Vergangenheit.\nDer Volksmund nennt dieses Phänomen auch Erfahrung.

\n\n

Nach dem letzten Fehler wird es einen nächsten geben.\nDarum ist die Nachbereitung immer auch eine Vorbereitung auf kommende\nFehlersuchen.

\n\n

Manchmal folgt der nächste Fehler so schnell, dass kaum Zeit für die Rückschau\nbleibt.\nTritt dieser Umstand häufiger auf, ist das ein Zeichen dafür, dass eine\nRückschau umso nötiger ist.\nDann kann ich mir wenigstens eine Liste oder Tabelle anlegen, in der ich die\naufgetretenen Fehler zusammen mit ihrem Schweregrad festhalte.\nSo habe ich später eine Entscheidungsgrundlage, wenn Zeit da ist, sich einem\nThema intensiver zu widmen.

\n\n

\nII Lokale Probleme

\n\n

\n4. Grundlagen Linux

\n\n

Ein paar Grundlagen benötige ich immer wieder, wenn ich die Vorgänge in einem\nLinux-System verstehen will.

\n\n

Von diesen halte ich im Zusammenhang mit Fehlersuche für besonders wichtig:

\n\n

die Bedeutung von Dateien und Verzeichnissen bei UNIX und Linux
das UNIX-Prozessmodell
die Schnittstellen über die ein Prozess mit seiner Umgebung interagiert

Darauf gehe ich in den folgenden Abschnitten ein.

\n\n

\n5. Totalausfall

\n\n

Ein Totalausfall bedeutet für mich zuallererst: der Rechner selbst ist keine\nHilfe bei der Fehlersuche.\nDas muss nicht heißen, dass der Rechner überhaupt nicht mehr reagiert, aber\nauf jeden Fall stehen mir nicht alle Werkzeuge zur Verfügung, die ich sonst\nzur Analyse einsetzen könnte.

\n\n

Ich betrachte die folgenden Probleme als Totalausfall eines Rechners.

\n\n

Hardwarefehler, der Rechner reagiert überhaupt nicht beim Einschalten.\nAbgesehen von dem Tipp, den Stromanschluss zu überprüfen, gehe ich darauf\nhier nicht weiter ein.
Boot-Probleme, zwar passiert etwas, die Hardware scheint größtenteils in\nOrdnung, aber das Betriebssystem wird nicht gestartet.\nIch analysiere den Bootprozess Schritt für Schritt, beobachte, wie\nweit das System kommt und versuche die Ursache zu ermitteln.
Einfrieren, der Rechner war normal gestartet, hat eine Zeit lang\ngearbeitet, aber jetzt reagiert er nicht mehr.\nIch versuche zunächst den Rechner mit Magic SysRequest geordnet neu zu\nstarten und nachträglich zu analysieren.\nFalls möglich, werte ich die mit SysRequest gewonnenen Erkenntnisse aus.
Überlast, Swapping, Thrashing. Ich sehe oder höre, dass der Rechner\nintensiv arbeitet.\nTrotzdem reagiert er sehr langsam.\nAuf Grund von Timeouts kann ich mich nicht einmal mehr anmelden, in einer\nShell bekomme ich kein Programm gestartet.\nWenn ich die Last nicht auf anderem Weg vom Rechner nehmen kann, bleibt mir\nnur, den Rechner neu zu starten.\nAnschließend versuche ich zu ermitteln, was die Überlast ausgelöst hatte.
Ausfälle bei virtuellen Maschinen.\nDas sind die gleichen Fehler wie bei “echten” Maschinen aus Blech.\nHinzu kommen Probleme mit der Virtualisierungsschicht.\nIm Gegenzug bekomme ich mehr Diagnosemöglichkeiten an die Hand.\n
Neben dem Totalausfall des Gastsystems gibt es noch die Möglichkeit,\ndas das Wirtssystem ausgefallen ist. Diesen Fehler behandle ich, wie oben\nbeschrieben.
\n\n
Bei den Gastsystemen sind meine Optionen abhängig von der verwendeten\nVirtualisierungslösung und deren Werkzeugen zur Diagnose.\nManchmal kann ich einfach die Festplattenpartitionen des Gastsystems im\nHostsystem oder einem anderen Gastsystem einhängen und dort untersuchen.\nDamit stehen mir zusätzliche Werkzeuge zur Verfügung.
\n

\n6. Partieller Ausfall

\n\n

Bei einem teilweisen Ausfall auf einem Server sind nur einzelne Dienste des\nSystems betroffen.\nDann steht mir, im Gegensatz zum Totalausfall, meist die gesamte Vielfalt an\nWerkzeugen zur Diagnose zur Verfügung.

\n\n

Bevor ich mich wegen eines Problems an einem Server anmelde, habe ich bereits\neinige Informationen gesammelt.

\n\n

Wie äußert sich das Problem?
Wann wurde es zuerst bemerkt?
Ist es reproduzierbar?
Gibt es zeitliche Muster?
Sind alle betroffen oder nur ein Teil der Nutzer?

Damit habe ich schon eine gewisse Vorstellung, wonach ich schauen werde, wenn\nich mich anmelde.

\n\n

\n7. Performance des Rechners

\n\n

Der Rechner funktioniert zwar, aber alles erscheint zäh und in Zeitlupe\nabzulaufen. Jobs brauchen eine gefühlte Ewigkeit, die Tastatur scheint mit\n8 Baud angeschlossen. Irgendwo sind Engpässe, aber wo?

\n\n

Oft ist es einfach nur eine Überlast, das heißt, das System erhält temporär\nmehr Aufgaben, als es bewältigen kann.\nDann werde ich zunächst alles tun, um die Last zu reduzieren.\nAnschließend mache ich mir Gedanken, wie ich die zu erwartende Last bewältigen\nkann.

\n\n

Die drei wesentlichen Engpässe beim Betrieb eines Rechners sind CPU,\nHauptspeicher und I/O.\nWelcher von diesen drei im Moment gerade den Betrieb hemmt, bekomme ich sehr\nschnell mit dem Befehl vmstat heraus.\nDamit weiß ich allerdings erst, wo ich suchen will, die eigentliche Ursache\nmuss ich noch ermitteln.

\n\n

Mit dem Programm top kann ich etwas genauer hinschauen.\nJe nach dem, was ich mit vmstat herausbekommen habe, kann ich interaktiv mit\nP die Prozesse nach prozentualer Nutzung der CPU und mit M nach der\nprozentualen Nutzung des Speichers sortieren lassen.\nMit 1 zeigt das Programm in den Kopfzeilen für jede einzelne CPU an, wie sie\nihre Zeit verbringt.\nMit f, gefolgt von j und <Enter> zeigt das Programm in einer\nzusätzlichen Spalte, welcher Prozess auf welcher CPU läuft.

\n\n

Wenn ich es ganz genau wissen will, erstelle ich ein Lastprofil meines Systems\nmit Accounting-Software wie sysstat.\nZwar belastet diese das System zusätzlich, doch\nich kann die Ergebnisse meiner Analyse dann nutzen, um gezielt in neue\nHardware zu investieren, ein oder mehrere leistungsstärkere Prozessoren,\nmehr RAM, schnellere Festplatten und Netzwerkkarten.\nOder ich verteile die Last auf mehrere Systeme.

\n\n

Als Einführung in das Gebiet empfehle ich Loukides1996,\ndas mittlerweile in neuer Auflage erschien.

\n\n

\n8. Werkzeuge zur lokalen Fehlersuche

\n\n

Linux stellt mir eine Unmenge an Werkzeugen für die Fehlersuche zur Verfügung.\nEtliche davon kommen mir sowohl bei Total- als auch bei Partialausfällen\nzu gute.\nAndere bei Performanceproblemen.\nEinige sind so nützlich, dass ich sie immer wieder bei den unterschiedlichsten\nProblemen einsetze.

\n\n

Da es mir schwerfällt, die einzelnen Werkzeuge bestimmten Kategorien\nzuzuordnen, stelle ich sie nachfolgend in alphabetischer Reihenfolge vor.\nDas erleichtert zumindest das Wiederfinden, wenn ich nur etwas\nnachschlagen möchte.

\n\n

\nIII Netzwerkprobleme

\n\n

\n9. Grundlagen IP-Netzwerke

\n\n

Ein paar Grundlagen benötige ich immer wieder, wenn ich die Vorgänge in einem\nIP-Netzwerk verstehen will.

\n\n

Insbesondere halte ich bei der Fehlersuche die Kenntnis folgender Themen für\nwichtig:

\n\n

Das OSI-Referenzmodell, mit dessen Hilfe ich die Position eines Protokolls\nim Protokoll-Stack bestimmen und seine Bedeutung einschätzen kann.
ARP, weil es die Lücke schließt zwischen dem Internet-Protokoll und der\nNetzzugangsschicht, wie zum Beispiel Ethernet.
Die Bestimmung von IPv4-Netzmasken.
Die Zustände von TCP-Verbindungen.
Zwei wesentliche Algorithmen bei Routing-Protokollen:\nDistanz-Vektor und Link-State.

Auf diese Themen gehe ich in den folgenden Abschnitten ein, damit wir sie im\npositiven Sinne vergessen können.

\n\n

\n10. Totalausfall des Netzwerks

\n\n

Habe ich an einem Rechner überhaupt keine Verbindung zum Netz, oder kann ich\nein ganzes Netzsegment nicht erreichen, spreche ich von einem Totalausfall.

\n\n

Dabei unterscheide ich zwei Arten, je nachdem, von wo ich das Problem\nbetrachte.\nUntersuche ich es von einem Rechner, der überhaupt keine Verbindung hat,\ndann sehe ich das Problem von innen, weil ich versuche, mit dem Rechner\ninnerhalb eines Segments eine Verbindung zu bekommen.\nKann ich ein ganzes Netzsegment nicht mehr erreichen, dann betrachte ich das\nProblem von außen, da ich mich in einem anderen Segment befinde und\nandere Rechner erreichen kann, nur dieses Netzsegment und die Rechner darin\nnicht.

\n\n

Bei der Betrachtung von innen, überprüfe ich die Schichten des OSI-Modells von\nunten nach oben.\nDas heißt, ich fange bei der Kabelverbindung zum Switch an und arbeite mich zur\nIP-Konfiguration hoch, bis ich Kontakt zu mindestens einem anderen Rechner\nbekomme.

\n\n

Bei der Betrachtung von außen muss ich die Topologie des Netzwerks kennen.\nDann überprüfe ich den Weg zum nicht erreichbaren Segment und kontrolliere\nauf dem letzten erreichbaren Gateway dorthin die physikalische Verbindung\nund die Routen.\nAuf diese Weise arbeite ich mich bis zum ausgefallenen Netzsegment vor.

\n\n

\n11. Partieller Ausfall des Netzes

\n\n

Ich spreche von einem Teilausfall im Netz, wenn wenigstens die Grundfunktionen\nbis OSI-Schicht 4 funktionieren und ich alle Netzsegmente erreichen kann.\nIn diesem Fall kann ich das Netz selbst zur Fehlersuche einsetzen und\nbrauche mir nicht die Schuhsohlen ablaufen, um vor Ort nach dem Rechten zu\nsehen oder via Telefon zu debuggen.

\n\n

Was also kennzeichnet einen Teilausfall im Netz?

\n\n

Da ist zunächst der Ausfall essentieller Dienste im Netz, wie DHCP, DNS, NTP,\nKerberos und weiterer.\nDer Ausfall einiger dieser Dienste kann Auswirkungen haben, die die Kunden\nals Totalausfall wahrnehmen.\nDas muss ich bereits bei der Aufnahme des Problems berücksichtigen.\nFür den Kunden macht es keinen Unterschied, ob er das Netz nicht nutzen kann,\nweil ein Kabel unterbrochen ist, oder weil sein Rechner keine IP-Adresse\nzugewiesen bekam.\nFür mich, der ich den Fehler beseitigen will, ist der Unterschied durchaus von\nBelang.

\n\n

Weiterhin betrachte ich als Teilausfall, wenn ich einzelne Rechner oder\neinzelne Dienste auf bestimmten Rechnern nicht erreichen kann.\nIm Laufe der Untersuchung wird daraus vielleicht ein Total- oder\nTeilausfall des Rechners; dann behandle ich das, wie in\nTeil 2 dieses Buches beschrieben.

\n\n

Als drittes zähle ich partielle Einschränkungen von funktionierenden\nDiensten dazu.\nDarunter verstehe ich zum Beispiel Mengenbeschränkungen beim Upload auf\nWebserver oder beim Versand von E-Mail, Zugriffsbeschränkungen für einzelne\nNetzsegmente und ähnliches.\nDiese lassen sich in vielen Fällen auf die Konfiguration des betreffenden\nDienstes zurückführen.

\n\n

Schließlich besteht die Möglichkeit, dass ein Dienst absichtlich gestört wird.\nAngriffe von Dritten und deren Abwehr sind jedoch nicht Thema dieses Buches\nund werden höchstens am Rande behandelt.

\n\n

Bei der Behebung des Teilausfalls lasse ich mich wieder vom grundlegenden\nEntscheidungsbaum leiten.\nDas heißt, ich versuche zuerst festzustellen, ob überhaupt etwas funktioniert,\nalso ob ich den Server, auf dem der Dienst läuft, erreichen kann.\nEventuell muss ich hier noch einen Schritt zurück und sehen, ob ich andere\nRechner im gleichen Netzsegment erreichen kann.\nKann ich den Server erreichen, untersuche ich, ob alles funktioniert.\nBekomme ich Kontakt zum Dienst, antwortet er korrekt laut Protokoll?\nSchließlich untersuche ich, ob der Dienst schnell genug antwortet.

\n\n

\n12. Netzwerkperformance

\n\n

Manchmal scheint alles in Ordnung zu sein und trotzdem sind die Kunden nicht\nzufrieden. Performance ist ein heikles Thema, weil jeder seine eigene\nVorstellung davon hat, was ausreichende Performance ist.\nSo heikel, dass mancher sein Heil in immer “dickeren” Leitungen mit immer\nhöherer Datenübertragungsrate sucht, um sich nicht näher mit dem eigentlichen\nProblem beschäftigen zu müssen.

\n\n

Was die Sache so schwierig macht, ist, dass ein Performance Problem sehr viele\nAspekte haben kann.

\n\n

Da gibt es mitunter eine Diskrepanz zwischen wahrgenommener Performance und\nrealer Performance.\nEin Kunde ruft an, weil “sein E-Mail-Programm nicht funktioniert”.\nEr schreibt die E-Mail, drückt auf Senden und dann friert das Programm ein.\nBei genauer Betrachtung stellt sich heraus, dass da ein Anhang von mehreren MB\nan der E-Mail hängt und die Leitung beim Upload nur eine maximale\nDatenübertragungsrate von ein paar hundert kBit/s hat.\nEin kurzes Nachrechnen von verfügbarer Datenübertragungsrate und zu sendenden\nDaten ergibt bereits eine Dauer von mehreren Minuten bei alleiniger Nutzung\nder Leitung durch diesen Upload.

\n\n

Aber auch reale Performance-Probleme können vielfältige Ursachen haben, die es\neinzugrenzen gilt.\nOft genug sind diese Probleme intermittierend, dass heißt, in einem\nMoment da und im nächsten weg.\nDarum ist die Fehlersuche bei Problemen mit der Performance fast immer mit dem\nSammeln von Daten verbunden.

\n\n

Wenn ich ein Performance-Problem untersuche, beginne ich zunächst die\nCharakteristiken des Problems so genau wie möglich zu bestimmen.

\n\n

Dann versuche ich das Problem grob zu klassifizieren:

\n\n

Ist es ein normales Problem, weil zu viele Daten gesendet werden sollen?
Ist es vielleicht ein DNS-Problem mit Verzögerung am Anfang?
Gibt es Probleme mit dem Durchsatz bei längeren Downloads?
Liegt das Problem eher an der Latenz bei interaktiven Programmen?

Auch die Art des verwendeten Protokolls kann Hinweise auf mögliche Probleme\ngeben.\nSo gehen bei datagrammorientierten Protokollen wie UDP Daten einfach verloren,\nwährend bei datenflussorientierten Protokollen wie TCP Zeit verloren geht,\nwährend das Protokoll die Daten nochmals sendet.

\n\n

Bei der Klassifizierung hilft es mir, wenn ich bereits bei der Aufnahme des\nProblems nach Anzeichen für mögliche Ursachen Ausschau halte, um in der\nbetreffenden Richtung detaillierter nachzufragen.

\n\n

\n13. Werkzeuge zur Fehlersuche im Netzwerk

\n\n

Verschiedene Werkzeuge eignen sich zur Fehlersuche im Netz.\nEinige verwende ich immer wieder bei den unterschiedlichsten Problemen, andere\nsind spezialisiert auf bestimmte Fragestellungen.

\n\n

Hier stelle ich diejenigen, die ich am häufigsten einsetze, in\nalphabetischer Reihenfolge vor.

\n\n

\n14. Literatur

\n\n

Bücher

\n\n

Csikszentmihalyi2014

Csikszentmihalyi, Mihaly; FLOW und Kreativität;\nKlett-Cotta Verlag, Stuttgart 2014
\nISBN: 978-3-608-94882-6

\n\n

Bereits 1975 beschrieb M. Csikszentmihalyi das Konzept des Flow, das bei\neinigen Menschen auftritt, die offensichtlich Freude an bestimmten Tätigkeiten\nhaben. In diesem Buch fasst er dieses Konzept mit Erkenntnissen aus Interviews\nkreativer Menschen und Hinweisen zur Förderung der persönlichen Kreativität\nzusammen.

\n\n

CT2000

Christiansen, Tom and Torkington, Nathan;\nPerl Kochbuch; O’Reilly, Köln, 2000;
\nISBN: 3-89721-140-8

\n\n

Neben dem Kamel-Buch ist dieses für mich das\nwichtigste Buch bei der Arbeit mit Perl.\nDer Vorteil dieses Buches ist die\nDarbietung als anwendungsbereite Rezepte, so dass ich mich auf das zu\nlösende Problem konzentrieren kann und nicht auf die subtilen Feinheiten\nder Programmiersprache umschalten muss.

\n\n

Edwards2012

\n\n

Edwards, Betty;\nDas neue GARANTIERT ZEICHNEN LERNEN: Die Befreiung unserer schöpferischen\nGestaltungskräfte; Rowohlt, Reinbek bei Hamburg, 2012;
\nISBN: 978-3-498-01669-2

\n\n

Dieses Buch hat vordergründig nichts mit Fehlersuche zu tun.\nBetty Edwards gibt in diesem Buch einige Tipps zum Umschalten der\nverschiedenen Gehirn-Modi, konkret zwischen dem logisch-analytischen und dem\nbildlich-intuitiven Denken.\nFür die erfolgreiche Fehlersuche insbesondere bei schwierigen Problemen ist es\nvorteilhaft mit beiden Modi souverän umzugehen.\nDas zu lernen, kann dieses Buch helfen.

\n\n

Foessmeier1991

\n\n

Fößmeier, Reinhard;\nDie Schnittstellen von UNIX-Programmen: Tips zur Programm-Organisation unter\nUNIX; Springer, Berlin Heidelberg New York London Paris Tokyo Hong Kong\nBarcelona, 1991;
\nISBN: 3-540-53521-7

\n\n

Eigentlich eher für Programmierer, die Software für UNIX schreiben, gedacht,\nwar dieses Buch eine Offenbarung für mich um zu verstehen, wie Programme\nunter UNIX und Linux kommunizieren.

\n\n

Kahneman2011

\n\n

Kahneman, Daniel;\nThinking, fast and slow;\nAnchor Canada, 2013;
\nISBN: 978-0-385-67653-3

\n\n

Noch ein Buch, das sich mit den Gegebenheiten und Wechselwirkungen der\nverschiedenen Gehirn-Modi befasst.\nNicht direkt zum Thema Fehlersuche, aber sehr erhellend darüber, warum und wie\nman sich immer wieder selbst an der Nase herumführt.

\n\n

Loukides1996

\n\n

Loukides, Mike Kosta;\nSystem Performance Tuning;\nO’Reilly, Sebastopol, 1996;
\nISBN 0-937175-60-9

\n\n

Dieses Buch führt grundlegend in das Gebiet des\nPerformance-Tuning von UNIX-Systemen ein. 2002 gab es eine zweite Auflage mit\nGian-Paolo D. Musumeci als Koautor.

\n\n

Malhotra2002

\n\n

Malhotra, Ravi;\nIP Routing\nO’Reilly, Sebastopol, 2002\nISBN: 0-596-00275-0

\n\n

Dieses Buch führt in die Grundlagen und Feinheiten des IP Routing ein, wie es\nin Cisco-Routern implementiert ist. Da es sich nicht auf die Konfiguration\nbeschränkt, sondern auch die Mechanismen und die gesendeten Datagramme\nerläutert, ist es insbesondere zur Analyse von Routingprotokollen\neine große Hilfe. Mit der Routingsoftware Quagga lassen sich die\nKonfigurationsbeispiele auch unter Linux nachvollziehen, da sich deren\nBenutzerschnittstelle stark an IOS von Cisco orientiert.

\n\n

Polya2010

\n\n

Pólya, George;\nSchule des Denkens: Vom Lösen mathematischer Probleme;\nNarr Francke Attempto Verlag, 2010;\nISBN 978-3-7720-0608-1

\n\n

Dieses Buch ist schon sehr alt, das merkt man beim Lesen am heute teilweise\nunüblichen Sprachgebrauch. Außerdem geht es um das Lösen mathematischer\nProbleme. Wer sich davon nicht abschrecken läßt, kann daraus wunderbare\nInspirationen für das Lösen von Problemen ziehen. Pólya geht von vier Phasen\nder Problemlösung aus, die er in seinem Buch dann ausführlich erläutert. \nDie vier Phasen sind: 1. verstehe die Aufgabe, 2. mache einen Plan, 3. führe\nden Plan aus, 4. prüfe die erhaltene Lösung.

\n\n

Roam2009

Roam, Dan;\nAuf der Serviette erklärt, Mit ein paar Strichen schnell überzeugen statt\nlange präsentieren;\nRedline Verlag, 2009;
\nISBN 978-3-86881-016-5

\n\n

Der Autor beschreibt in diesem Buch, wie man mit wenig Aufwand Probleme\nvisualisieren kann und damit seine eigenen Gedanken besser ordnen sowie das\nProblem anderen verständlich erklären kann.\nObwohl das Buch, laut Klappentext, Hilfe für das Visualisieren von\nGeschäftsideen geben soll, sind die Prinzipien und Ideen bei der Fehlersuche\nmindestens ebenso hilfreich.

\n\n

Sloan2001

\n\n

Sloan, Joseph D.;\nNetwork troubleshooting tools;\nO’Reilly, Sebastopol, 2001;
\nISBN 978-0-596-00186-5

\n\n

Dieses Buch stellt etliche Werkzeuge für die Fehlersuche vor und zeigt wie man\nmit relativ einfachen Werkzeugen komplexe Fragen beantworten kann.

\n\n

Taleb2012

\n\n

Taleb, Nassim Nicholas;\nAntifragile, Things that Gain from Disorder\nPenguin, London, 2012;\nISBN 978-0-141-03822-3

\n\n

In diesem Buch geht es nicht um Fehlersuche, sondern um Systeme, die durch\nStörungen stärker werden.\nEs ist nicht für den Anfänger, der so schnell wie möglich einen Fehler\nbeseitigen will, obwohl auch dieser davon profitieren könnte.\nVielmehr geht es darum unter welchen Umständen Systeme von kleinen Störungen\nprofitieren können und wie man den Zufall zu einem Verbündeten statt zu einem\nGegner machen kann.

\n\n

WCS1997

Larry Wall, Tom Christiansen and Randal L. Schwartz;\nProgrammieren mit Perl;\nO’Reilly, Köln 1997;
\nISBN 3-930673-48-7

\n\n

Die Einführung in die Programmiersprache Perl.\nIn dem Buch wird nicht nur die Sprache selbst kurzweilig vorgestellt, sondern\nauch ein Einblick in Hintergründe und die mit dieser Programmiersprache\nverbundene Kultur gegeben.\nDie zweite deutsche Auflage führt Jon Orwant statt Randal Schwartz als Autoren\nauf.

\n\n

Weidner2012

Weidner, Mathias; Linux kopflos mit PC Engines ALIX;\nLulu Press, Raleigh, 2012;
\nISBN 978-1-4717-2849-5

\n\n

Ein Buch über kleine lüfterlose Rechner, auf denen man mit Linux verschiedene\nProjekte realisieren kann.\nDas Buch geht unter anderem auf verschiedene Probleme unter dem Aspekt\nbegrenzter Ressourcen ein und beschreibt einige Protokolle und Mechanismen\nausführlicher.

\n\n

Artikel in Zeitschriften, Proceedings, …

\n\n

acmqCM2010

Millsap, Cary; Thinking Clearly about Performance;\nACM Queue, Volume 8 Issue 9, September 2010,
http://queue.acm.org/detail.cfm?id=1854041

\n\n

Der Autor geht in diesem Artikel auf die praktische Performanceanalyse von\nProgrammen ein und erläutert den Zusammenhang von Antwortzeit, Durchsatz\nsowie den Einfluss der Auslastung bei der Nutzung paralleler Ressourcen.

\n\n

acmqFM2005

Fall, Kevin, McCanne, Steve; You Don’t Know Jack About Network Performance;\nACM Queue, Volume 3 Issue 4, May 2005, Pages 54-59
http://queue.acm.org/detail.cfm?id=1066069

\n\n

Die Autoren gehen in diesem Artikel vor allem auf die Performance von TCP ein,\ninsbesondere auf den Einfluss von Bandbreite, Latenz und Window Size auf die\nÜbertragungsgeschwindigkeit.

\n\n

Bartsch2013

Bartsch, Michael; Service Level Agreements - rechtliche Aspekte;\nInformatik-Spektrum, Volume 36, Ausgabe 5, Oktober 2013, S. 449ff;
\nDOI 10.1007/s00287-013-0712-1

\n\n

In diesem Beitrag für Nichtjuristen geht der Autor in verständlicher Form auf\ndie rechtlichen Aspekte von Service Level Agreements als Bestandteil von\nIT-Verträgen ein.

\n\n

Bonwick1994

Bonwick, Jeff; The slab allocator: an object-caching kernel memory\nallocator; Proceedings of the USENIX Summer 1994 Technical Conference on\nUSENIX Summer 1994 Technical Conference - Volume 1, S. 6

\n\n

In diesem Artikel stellte der Autor ein effizientes Verfahren zur\nSpeicherverwaltung für SunOS vor. Das Verfahren, Slab Allocator, gelangte\n1999 in den Linux-Kernel.

\n\n

ctDiedrich2012

Diedrich, Dr. Oliver; Zugriffschutz - Dateiüberwachung mit Fanotify;\nc’t Magazin für Computertechnik 2012 Heft 9, S. 174ff;\nISSN 0724-8679

\n\n

Der Autor stellt in diesem Artikel die Möglichkeiten der\nFanotify Systemschnittstelle vor.

\n\n

ctZivadinovic2012

Dušan Zivadinović; Blindflug mit Full Speed - Wie die TCP/IP-Flusskontrolle\nfunktioniert;\nc’t Magazin für Computertechnik 2012 Heft 10, S. 188ff;\nISSN 0724-8679

\n\n

Der Autor erläutert in diesem Artikel leicht verständlich, wie die in TCP\nenthaltene Flusskontrolle dazu beiträgt, die Datenübertragungsrate einer Verbindung\nmöglichst optimal auszunutzen.

\n\n

ctHM2013

Hillier, Gernot, Mauerer, Dr. Wolfgang; Linux durchleuchtet - Perf als\nUniversalschnittstelle für Performance-Analysen unter Linux;\nc’t Magazin für Computertechnik 2013, Heft 3, S. 166ff;\nISSN 0724-8679

\n\n

Dieser Artikel geht auf die Möglichkeiten der Performance-Analyse mit Hilfe\nder Performance-Counter der CPU ein und stellt das Programm perf vor, dass\neine einheitliche Schnittstelle dafür unter Linux bereitstellt.

\n\n

ctTZ2013a

Michael Tremer, Dušan Zivadinović; Kürzungsmaßnahme - Internet-Tuning:\nPuffercontrolle mit CoDel;\nc’t Magazin für Computertechnik 2013, Heft 13, S. 184ff;\nISSN 0724-8679

\n\n

In diesem Artikel erläutern die Autoren die Wirkungsweise des CoDel-Verfahrens\nzum Router-Queue-Management bei Bufferbloat.

\n\n

ctTZ2013b

Michael Tremer, Dušan Zivadinović; Paketbeschleuniger - Internet-Tuning mit\nIPFire und CoDel;\nc’t Magazin für Computertechnik 2013, Heft 13, S. 188f;\nISSN 0724-8679

\n\n

Dieser Praxis-Artikel zeigt, wie man mit der Firewall-Appliance IPFire erste\nErfahrungen mit dem CoDel-Verfahren zum Router-Queue-Management bei\nBufferbloat machen kann.

\n\n

Gregg2013

Gregg, Brendan; Thinking Methodically about Performance;\nCACM Vol. 56, No. 2, February 2013, pp 45 ff.;\nISSN 0001-0782

\n\n

Koenig2012

König, Harald; strace für Linux-Versteher; UpTimes - Mitgliederzeitschrift\nder German Unix User Group; Ausgabe 2012/1, S. 61ff

\n\n

Harald König zeigt in seinem Artikel welche Informationen über ein\nLinux-Programm er mit strace gewinnen kann.

\n\n

Shepard1991

Shepard, Timothy Jason; TCP Packet Trace Analysis; MIT/LCS/TR-494

\n\n

Die Masterarbeit von Tim Shepard geht ausführlich auf die Analyse des\nVerhaltens von TCP-Verbindungen ein.\nEr zeigt darin die Vorzüge von Sequenz-Zeit-Diagrammen für die Analyse und\nstellt das Programm xplot vor, welches die interaktive Analyse dieser\nDiagramme erleichtert.

\n\n

WSA2011

Weigend, Johannes and Siedersleben, Johannes and Adersberger, Josef;\nDynamische Analyse mit dem Software-EKG; Informatik-Spektrum, Volume 34,\nAusgabe 5, Oktober 2011, S. 484ff;
\nDOI 10.1007/s00287-011-0541-z

\n\n

In diesem Papier zeigen die Autoren, wie man komplexe heterogene Systeme\nanalysieren kann, wenn man mit einfachen Methoden nicht weiter kommt.

\n\n

Online-Quellen

\n\n

AppArmor

Die Seiten des AppArmor-Projekts.
http://apparmor.net/
\nAufgerufen: 2014-05-21

\n\n

Bei der Dokumentation finden sich Handbuchseiten, HowTos, Tutorials und eine\nAnleitung, wie man bestimmt, ob AppArmor ein Problem verursacht.

\n\n

Bad block HOWTO for smartmontools

This article describes what actions might be taken when smartmontools detects\na bad block on a disk.
http://smartmontools.sourceforge.net/badblockhowto.html
\nAufgerufen: 2014-06-02

\n\n

Der Artikel erläutert, wie man eine Festplatte “reparieren” kann, für die die\nsmartmontools fehlerhafte Blöcke gemeldet haben. Obwohl von 2007, ist der\nArtikel immer noch brauchbar, wenn man gezwungen ist, eine Festplatte mit\nfehlerhaften Blöcken weiter zu betreiben.

\n\n

Bullet Journal

For the list-makers, the note-takers, the Post-It note pilots, the\ntrack-keepers, and the dabbling doodlers.
http://bulletjournal.com/
\nAufgerufen: 2014-05-04

\n\n

Ich hatte schon jahrelang Laborbücher in A5-Kladden geführt.\nMit diesem System habe ich es auf eine höhere Stufe gehoben.

\n\n

IETF Tools

IETF-related tools, standalone or hosted on tools.ietf.org
http://tools.ietf.org/
\nAufgerufen: 2014-05-03

\n\n

Die Quelle für RFCs und Internet Standards von der Internet Engineering Task\nForce.

\n\n

Leanpub

Leanpub - Publish Early, Publish Often
https://leanpub.com/
\nAufgerufen: 2014-05-03

\n\n

Autoren und Herausgeben können Leanpub nutzen, um fertige Bücher und Bücher in\nBearbeitung zu veröffentlichen.\nDieses Buch selbst ist bei und mit Leanpub entstanden.

\n\n

Performance Analysis Methodology

Verschiedene Methoden zur Performanceanalyse
http://www.brendangregg.com/methodology.html
\nAufgerufen: 2014-08-24

\n\n

Brendan Gregg stellt hier verschiedene Methoden und Anti-Methoden für die\nPerformanceanalyse vor.\nNeben diesen finden sich auf seiner Website ausführliche Vorstellungen einiger\nVisualisierungstechniken nebst ihrer Anwendung bei der Performanceanalyse.\nFür die Performanceanalyse von Linuxsystemen sind vor allem die\nGrundlagenartikel unter Linux Perf sowie die Checkliste für die USE-Methode\nbei Linux hilfreich.

\n\n

Perf Wiki

Perf Wiki
https://perf.wiki.kernel.org/
\nAufgerufen: 2014-05-22

\n\n

In diesem Wiki finden sich viele nützliche Informationen für die\nPerformanceanalyse mittels CPU Performance Counter und perf.

\n\n

POSIX.1-2008

IEEE and The Open Group; The Open Group Technical Standard Base\nSpecifications, Issue 7;\nPOSIX.1-2008 / IEEE Std. 1003.1™-2008
http://pubs.opengroup.org/onlinepubs/9699919799/
\nAufgerufen: 2013-11-29

\n\n

POSIX.1-2008 definiert eine Standardschnittstelle und -umgebung für\nBetriebssysteme, einschließlich eines Befehlsinterpreters (Shell) und\nallgemeiner Hilfsprogramme um die Portabilität von Anwendungen auf der Ebene\ndes Quellcodes zu unterstützen.

\n\n

POSIX.FileCap

Chris Friedhoff;\nPOSIX Capabilities & File POSIX Capabilities
http://www.friedhoff.org/posixfilecaps.html
\nAufgerufen: 2013-12-20

\n\n

Dieser Artikel, 2008 geschrieben, führt mit praktischen Beispielen in den\nUmgang mit POSIX Capabilities ein.

\n\n

SELinux

Die Projektseite des SELinux-Projektes.
http://selinuxproject.org/
\nAufgerufen: 2014-05-21

\n\n

Von grundlegenden Konzepten bis anwendbaren Rezepten findet sich hier eine\nMenge Information zu SELinux

\n\n

Wayback Machine

Internet Archive Wayback Machine
https://archive.org/web/
\nAufgerufen: 2014-05-04

\n\n

Eine der besten Erfindungen gegen die Flüchtigkeit des Internet.\nMit der Wayback Machine lassen sich ältere Versionen von bestehenden und\nbereits vergangenen WWW-Seiten betrachten.\nNatürlich sind nicht alle Seiten und erst recht nicht alle Versionen der\neinzelnen Seiten enthalten.\nTrotzdem ist es den Versuch wert, wenn eine irgendwo beworbene URL nicht mehr\nerreichbar ist.

\n\n

\n15. Kolophon

\n\n

Dieses Buch ist im Markdown-Format mit Erweiterungen von Leanpub geschrieben.\nAnschließend wurden aus den Markdown-Quelldateien\ndie PDF-, EPUB- and MOBI-Versionen erzeugt.

\n\n

Den Entscheidungsbaum im ersten Kapitel habe ich mit\nyEd gezeichnet und für die\nBucherstellung im PNG-Format exportiert.

\n\n

Die TCP-Sequence-Diagramme im neunten Kapitel habe ich mit\nUMLet gezeichnet, in das SVG-Format exportiert und\nanschließend mit Inkscape in das PNG-Format für\ndas Buch umgewandelt.

\n\n

Der Router-Graph im neunten Kapitel ist mit dem Programm dot von der\nGraphViz Software erzeugt.

\n\n

Revision

\n\n

Die Markdown-Quellen dieses Buches werden im verteilten\nRevisionsverwaltungssystem monotone gespeichert.

\n\n

Diese Ausgabe basiert auf Revision
\ndae6dbf2676ca6fcb5e2b72c0ac1c1d509a3132a von 2014-10-24.

\n\n

\nhttp://lexikon.stangl.eu/1963/heuristik/↩\n

\n\n","tocStructure",[223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252],{"_80":74,"_43":70,"_71":-5,"_75":76,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":70,"_71":-5,"_75":76,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":86,"_71":-5,"_75":87,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":92,"_71":-5,"_75":93,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":95,"_71":-5,"_75":96,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":74,"_43":98,"_71":-5,"_75":99,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":102,"_71":-5,"_75":103,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":106,"_71":-5,"_75":107,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":109,"_71":-5,"_75":110,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":112,"_71":-5,"_75":113,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":115,"_71":-5,"_75":116,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":118,"_71":-5,"_75":119,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":122,"_71":-5,"_75":123,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":74,"_43":126,"_71":-5,"_75":127,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":130,"_71":-5,"_75":131,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":134,"_71":-5,"_75":135,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":138,"_71":-5,"_75":139,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":142,"_71":-5,"_75":143,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":146,"_71":-5,"_75":147,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":74,"_43":150,"_71":-5,"_75":151,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":154,"_71":-5,"_75":155,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":158,"_71":-5,"_75":159,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":162,"_71":-5,"_75":163,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":166,"_71":-5,"_75":167,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":170,"_71":-5,"_75":171,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":174,"_71":-5,"_75":175,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":178,"_71":-5,"_75":179,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":181,"_71":-5,"_75":182,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":184,"_71":-5,"_75":185,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":187,"_71":-5,"_75":188,"_73":74,"_88":-5,"_89":-5,"_90":-5},"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]