Bücher Troubleshotting

[vnn]

Hallo,

ich bin auf der Suche nach Büchern wo man in das Troubleshooting sich einlesen kann.
Bei Amazon habe ich schon welche gefunden weiss aber nicht zu welcher Distribution gehören.

Kennt jemand welche die für Debian sehr ansprechend sind?

Kennt jemand auch kostenlose Bücher zu diesem Thema?

Gruss

vnn

[HZB]

Was willst Du "Troubleshooten" ??

[vnn]

Das Grundsätzliche erlernen, also für einen Debian Server.

[HZB]

Ein ganz guter Einstieg ist mmn sicherlich:

https://www.debian.org/doc/manuals/debian-handbook/

und

https://www.debian.org/doc/manuals/debi ... ex.de.html

sowie

https://www.debian.org/doc/manuals/secu ... ex.de.html

Da bekommt man schon eine Menge an Infos.

Käuflich erwerben könnte man:

https://www.rheinwerk-verlag.de/debian-gnulinux_3847/

Allerdings findest Du diese Infos auch auf oben erwähnten Seiten.

Wenn es ein wenig genereller sein soll würde ich mich mal über LPIC schlau machen.
https://www.lpi.org/study-resources/

Hier werden eher grundlegende Linuxkenntnisse gefordert bzw. vermittelt.

lG

[vnn]

Hallo,
ich habe folgende Bücher gefunden.
Kennt jemand diese?
Sind diese zu empfehlen?
Nach den Bewertungen bei Amazon sind die wohl nicht übel.



http://www.amazon.de/Linux-Troubleshoot ... o_pC_S_img


http://www.amazon.de/Fehlerdiagnose-Pro ... _pC_nS_img


http://www.amazon.de/DevOps-Troubleshoo ... o_pC_S_img

[uname]

Statt Bücher zu lesen sollten du erst mal Probleme erzeugen (mehrere Testsysteme) und diese z.B. mit Hilfe des Internets lösen. Solltest du selbst keine Probleme haben löse die Probleme anderer Leute. Hier im Forum gibt es dazu leider viel zu selten gute Beispiele. Liegt wohl daran, dass Debian das falsche Betriebssystem für ernsthafte Probleme ist.

[TomL]

ich bin auf der Suche nach Büchern wo man in das Troubleshooting sich einlesen kann.
Bei Amazon habe ich schon welche gefunden weiss aber nicht zu welcher Distribution gehören.

Kennt jemand welche die für Debian sehr ansprechend sind?
Kennt jemand auch kostenlose Bücher zu diesem Thema?

Mein bescheidene Meinung dazu ist, das ist weder Geld noch Zeit wert, sich damit zu beschäftigen. Mittlerweile weiss ich, dass das vermutlich den gleichen Bedeutungswert hat, wie ein Troubleshooting-Buch " Was mache ich, wenn mein Hund *das* macht und ich nicht will, dass er *das* tut? Es taugt allein dazu, dem Verlag und dem Autor Gewinne zu erwirtschaften... dem Hundehalter helfen tuts in keinster Ẃeise.

Das Problem ist, was für die eine Distribution gilt, muss noch lange nicht für eine andere Distribution gelten. Was für eine Version einer Distribution gilt, muss ebenfalls noch lange nicht für eine andere Version der gleichen Distribution gelten (sysvinit und systemd). Was für eine Version einer Distribution zum CLI gilt, kann trotzdem noch für etliche nicht zu beantwortende Schwierigkeiten sorgen (Bash und Dash-Unterschiede).

Linux ist kein Hexenwerk.... es ist nur vielfältig. Also einfach mal anfangen, mit einfachen Desktop-Anforderungen und schauen, welche Probleme auftauchen und wie man im Laufe der Zeit diese Probleme löst. Dazu hier (bzw. in passenden Foren) fragen, Suchen im Web, selber experimentieren. Das scheint mir das bessere Vorgehen zu sein.

j.m.2.c.

[eggy]

Ich hab keins der drei gelesen.

Zu Buch eins: http://www.computerwissen.de/linux/linu ... ystem.html und Leseproben des Autors http://www.computerwissen.de/unsere-exp ... acker.html - falls das Buch dem Rest des Angebots gleicht, würde ich sagen zu oberflächlich.
Buch zwei: "Verlag: SuSE; Auflage: 2 (Juli 2004)" halte ich auch für eher wenig Erfolg versprechend, inbesondere des Alters wegens.
Zum Dritten Buch ne Übersicht des Inhalts gibts da http://www.pearsoned.co.uk/bookshop/det ... 20Contents hab aber leider keine Leseprobe finden können (gibts nicht? übersehn?). Ob das die Sachen sind, die Dich interessieren, musst Du selbst wissen, mir wärs nicht genug.

Wir hatten hier schon ne paar Threads zu Buchempfehlungen, im Wiki ist auch einiges verlinkt.

Ich denke "das Buch" zu dem Thema wirst Du nicht finden. Nimm Dir ein Themengebiet, und versuche Dich durch die Dokumentation zu arbeiten. Dabei merkt man recht schnell was wo hängt. Ohne praktisches Üben wird das eh nix, und nach Schema f lassen sich leider auch nur die wenigstens Probleme lösen. Wichtig ist in erster Linie ein Gefühl dafür zu entwickeln, wie die einzelnen Komponenten zusammenspielen. Und das bekommt man ganz allein durch Übung.
Ein guter Ratschlag ist aber immer "dokumentiere was Du gelernt hast" - gern auch in Form eines Wiki Artikels - hier gibts genug Leute die "gegenlesen" - und gegebenenfalls verbessern

[vnn]

Danke für Eure Antworten.
Das man am besten lernt wenn man runfrickelt ist wirklich wahr.
Ich hoffe daß ich duch solche Bücher aber auch gewisse nuetzliche Kniffe rausfinde.
Die beiden Buecher habe ich mir bestellt und da diese gebraucht sind ist es auch nicht so teuer gewesen.
Mal sehen wie diese beiden Bücher mich weiterbringen.

Ich habe mit viel Lernen die LPIC 1 geschafft aber gesehen dass da noch ein weiter Weg ist wenn man Linux Server betreuen möchte.

Gruss

vnn

[uname]

Ich habe mit viel Lernen die LPIC 1 geschafft aber gesehen dass da noch ein weiter Weg ist wenn man Linux Server betreuen möchte.

Herzlichen Glückwunsch dazu. Am besten ist es wenn man selbst Server betreut bzw. aufbaut und Dinge ausprobiert. Auch ist es ratsam hier im Forum einfach alle Beiträge mitzulesen und die aufgeführten Probleme nachzuvollziehen oder gleich zu lösen. Hierbei sollte man über den Tellerrand schauen und genauer alles analysieren auch wenn es nicht zielführend ist. Schreibt z.B. jemand irgendwas zu "cat" so macht es Sinn im Internet zu suchen und z.B. https://www.socallinuxexpo.org/scale5x/ ... aumann.pdf zu finden und durchzuarbeiten. Zwar kein Troubleshotting aber recht unterhaltsam und es löst Probleme, die man selbst nicht hat.

[vnn]

Hallo,
ich habe mir nun zwei Bücher bestellt.
Eins ist leider voll daneben da es sich um Ubuntu handelt und nur mit der grafischen Oberfläche zu tun hat.
Nennt sich Troubleshooting mit Linux und es ist Tux abgebildet. Bei der Bestellung war nichts zu lesen das es sich um Ubuntu handelt.
Habe nur 2 Euro bezahlt daher kein grosser Verlust.
Tortzem Finger weh!
http://www.amazon.de/Linux-Troubleshoot ... ting+linux

Da zweite Buch ist schon besser.
Meine Version ist veraltet (Stand Woody) aber enthält einige gut Hinweise.
Das Buch ist von Mathias Kettner

Habe noch ein weiteres Buch entdeckt aber weiss noch nicht wie dies ist.
https://www.amazon.de/Fehlersuche-bei-L ... 1_1&sr=8-1

Gruss

vnn

[uname]

Das letzte Buch scheint eher den theoretischen als den praktischen Ansatz zu beschreiben. Es mag ja interessant sein zu lesen wie irgendwelche Leute eine Problemlösung angehen. Nur leider hilft dir das alles nur wenn du auch entsprechendes UNIX-, Linux- bzw. Debian-Wissen hast. Sammel entsprechendes Wissen in Textdateien, einem eigenen Blog oder einem eigenen Wiki.

[vnn]

Das selber sammeln ist natuerlich immer besser.
Zum eigenen Wiki fehlt leider die Zeit.

Gruss

vnn

[eggy]

Zum eigenen Wiki fehlt leider die Zeit.

... famous last words.

Nimm Dir die Zeit das Gelernte zu dokumentieren. Und sei es nur ganz knapp. Im "Fall der Fälle" fehlt oftmals die Zeit für langwieriges "wie war das nochmal".

[uname]

Ich nutze Textdateien und als Editor natürlich Vim. Gut für Cut-and-Paste, Suche, Upload, Backup, ... Dateiname z.B. vim.txt, awk.txt, backup.txt, dpkg.txt, ...

[ThorstenS]

Wenn du nicht dokumentierst, ist das Üben und Problemnachstellen Zeitverschwendung, dann laß es gleich sein.
Nimm dir Zeit für die Dokumentation. Das erneute Niederschrieben übt und festigt das Gelernte.

Ich mache es seit viiieln Jahren auch so wie uname. Wobei ich mittlerweile von Text zu markdown übergegangen bin und bei einigen Dokumenten restructured text (rest) benutze. Ist halt universeller und läßt sich einfach in HTML, PDF oder epub überführen und trotzdem ist es leicht im $EDITOR zu tippen.
Diese Wissensbasis habe ich in einem git-repository, welches auf jedem meiner Arbeitssysteme (und dem vserver) verfügbar ist.

Darüber habe eine cli-Volltextsuche (ich nutze glimpse dazu) und bin bestens gewappnet mein Wissen auch nach Jahren wieder auszubuddeln.

Daneben liegen etliche Scripte und Snippets sowie mittlerweile einige ansible playbooks und Rollen, damit ich wiederkehrende Dinge automatisiert installieren/konfigurieren kann.

Ich habe in meinen Anfängen Mailinglisten abonniert und versucht möglichst viele der beschriebenen Fehler nachzustellen und zu lösen. Dazu habe ich das gedruckte Handbuch von SuSE komplett gelesen. Das ist bis heute die Basis meines Tuns.

Ein schlauer Satz dazu: Das Fundament ist die Basis für jede Grundlage.

[Radfahrer]

Ich dokumentiere meinen Kram mit TiddlyWiki.
Das ist, wenn man sich mal ein klein wenig eingearbeitet hat, sehr leicht zu machen und das gesamte Wiki besteht nur aus einer einzigen html-Datei.
Die habe ich auch einem USB-Stick, der an meinem Schlüsselbund hängt. Und außerdem zuhause in einer Netzfreigabe.

Egal, ob Linux, Windows, Mac Os.... was auch immer.... lässt sich überall anzeigen und bearbeiten.

[ThorstenS]

TiddlyWiki hab ich auch mal evaluiert, kann aber schon gut 8 Jahre her sein. Das hat halt Grenzen.
Meine Statistik sagt „304 directories, 2235 files“ das ist einfach zu viel für eine HTML Seite mit JS

[Radfahrer]

OK, so viel ist das bei mir nicht.
Sollte ich mal an die Grenzen stoßen, muss ich mir wohl was anderes überlegen.

[Colttt]

hallo vnn,

an sich ist das ein sehr interessante Sache, aber ein allgemeines HowTo gibts nicht, hast du denn ein bestimmtes Szenario wie du da rauf kommst? Oder wo man dir sagen könnte geh doch mal so und so vor??

In der Regel guckt man eh zuerst top, iotop und iftop an um da komische sachen fest zu stellen und dann gehts weiter..

[uname]

In der Regel guckt man eh zuerst top, iotop und iftop an um da komische sachen fest zu stellen und dann gehts weiter..

Interessant ist auch einfach mal die Verzeichnisse /usr/bin, /usr/sbin, /bin und /sbin durchzuschauen. Und wenn man über ein Programm stolpert einfach mal links und recht schauen. Mit "dpkg -S" und "dpkg -L" kannst du sehen zu welchem Paket ein Programm gehört und welche weiteren Dateien zu dem Paket gehören. Z.B. würdest du feststellen, dass /bin/cat zu coreutils gehört. Die zugehörigen Programme sind auch z.B. unter https://packages.debian.org/jessie/i386 ... s/filelist zu finden. Diese werden ähnlich interessant wie /bin/cat sein. Das Manual (man) sagt dir wiederum was die Befehle machen. Ein bisschen Google-Suche nach dem Befehl in Verbindung mit dem Wort Debian zeigt dir Beispiele. Dabei findest du neue Programme und weitere Pakete usw.

[Colttt]

und wenn du wissen willst in welchem paket ein bestimmtes programm oder datei drin ist: "apt-file search "

aber ok, ist das troubleshooting?

[ralli]

Zum eigenen Wiki fehlt leider die Zeit.

... famous last words.

Nimm Dir die Zeit das Gelernte zu dokumentieren. Und sei es nur ganz knapp. Im "Fall der Fälle" fehlt oftmals die Zeit für langwieriges "wie war das nochmal".

Früher habe ich auch alles umfassend dokumentiert. Davon bin ich mittlerweile wieder ab. Der Grund ist ein ganz einfacher. Da ich mich auf meine Dokumentation verlassen habe, wurde ich tatsächlich denkfaul. Weil es ja irgendwo steht, habe ich mein Langzeitgedächtnis nicht mehr benutzt. Heute mache ich wirklich jede Installation aus dem Kopf. Das ist zumindest für mich viel effektiver. Und wenn ich einen Fehler mache, prägt sich das Richtige erst recht ein. Zumindest ist das meine Erfahrung.