Einen Überblick verschaffen

Hier, da steht das Ding. Machen Sie mal, das das wieder geht!

Können Sie mir sagen, welche Distribution installiert ist und was nicht geht?

Distri.. was? Woher soll ich das wissen, das hat immer unser EDVler gemacht mit dem Linuxzeug da, der is aber nicht mehr da. Mails gehen halt nicht mehr.

Und schon geht der Los, der Linuxadmin-Spaß.

Eine graue Kiste, eine nicht wirklich hilfreiche Fehlerbeschreibung und dann auch noch keinerlei Hinweise, welche Linuxdistribution der ehemalige Administrator denn installiert hat. Panik ist hier fehl am Platz, mit Ruhe und etwas Planung lässt sich recht einfach an die Sache rangehen. Das es sich bei dem Computer um einen PC handelt, ist beim Anblick des Gehäuses recht schnell klar. Linux ist also auch installiert, soviel steht fest. Für den Anfang sollte man sich einen generellen Systemüberblick verschaffen:

• Um welche Art Hardware handelt es sich (32/64 bit, CPU, PCI-Karten usw.)
• Welche Distribution ist installiert und welche Version
• Welche Version des Linuxkernels läuft
• Welcher Mail-Daemon ist installiert und in welcher Version liegt dieser vor

Die verwendete Kernelversion lässt sich einfach durch einen Aufruf von uname -a anzeigen. Hier schlagen wir auch gleich zwei Fliegen mit einer Klappe und können die prinzipielle Systemarchitektur gleich mit auslesen. Zwei Beispiele für eine Kernelversion:

Beim ersten Beispiel können wir neben der Kernelversion 2.6.23.11 noch gleich erkennen, das wir es hier mit einem 64bit AMD-System zu tun haben, welches höchstwahrscheinlich zwei oder mehr CPUs besitzt. Das zweite Beispiel verrät leider nur, das es sich hier um ein 32bit Pentium-System mit möglicherweise 2 oder mehr CPUs handelt. Sollte im zweiten System eine 64bit CPU verbaut sein, so wird sie dennoch nur im 32bit Modus benutzt (erkennbar durch i686). Eine genaue Angabe über die Systemarchitektur hält das /proc Dateisystem für uns bereit. Ein cat /proc/cpu liefert für das erste System folgende Informationen (gekürzt):

Es ist also ein Dualcore AMD Athlon X2 4200+ verbaut, diese CPU hat 2 Kerne, welche von 0 bis 1 durchnummeriert sind. Das zweite System erknen wir nun auch als Dualcore, diesmal stammt die CPU allerdings von Intel und ist ein Pentium 4:

Den zur Verfügung stehenden Hauptspeicher sehen wir durch den Aufruf von free -m :

und

Das erste System ist also ein Dualcore AMD System mit 2 Gigabyte Hauptspeicher mit 64bit Betriebssystem, das zweite ein Dualcore Pentium 4 mit 1 Gigabyte Hauptspeicher mit 32bit Betriebssystem. Das war der einfache Teil. Das Herausfinden der verwendeten Distribution gestaltet sich schon etwas schwieriger. Glücklicherweise speichern die meisten Distributionen ihre Versionsnummer in einer Datei im /etc Verzeichnis, der Dateiname ist zumeist in der Form disitributionsname-version aufgebaut. Eine Datei “redhat-version”, “SuSE-version” oder “debian_version” entlarft unsere Distribution also, die Versionsnummer selbst sollte in der Datei gespeichert sein. In unserem Fall ist das zweite System ein “Debian 4.0” System, das erstze allerdings weist keine Datei auf, welche einen Hinweis geben könnte.

Leider speichert nicht jede Distribution ihre Version und Name wie oben beschrieben ab, aus welchen Gründen auch immer.

Nun beginnt die Suche nach dem Maildaemon. Ich konzentriere mich hier auf die 3 meist verbreitetsten: qmail, postfix und sendmail. Eine detaillierte Fehleranalyse ist nicht teil dieses Artikels, es geht hier nur darum, den verwendeten Mailserver zu erkennen. qmail ist durch das vorhandensein der Programme und Prozesse “qmail-send”, “qmail-smtpd” oder “qmail-clean” zu erkennen. Postfix verrät sich durch “/usr/lib/postfix/master” oder “qmgr”, Sendmail durch “sendmail” .. wer hätte das gedacht. Ich selbst setze derzeit nur qmail auf verschiedenen Systemen ein, ein behandeln dieses Mailservers könnte also durchaus als Blogbeitrag anstehen.

Nach nur wenigen Minuten wissen wir also über das zu grunde liegende System bescheit. Wir kennen die Hardwarearchitektur, die Distribution, den verwendeten Kernel und den Mailserver, welcher anscheinend Probleme bereitet. Der weitaus längere Teil besteht aus der Fehlererkennung und Fehlerbeseitigung. Es sollte bei der entsprechenden Firma angemerkt werden, das eine Systemdokumentation in diesem Fall vermutlich etliche Stunden Arbeit erspart hätte.