2383578

Hilfe bei Hoster-Abstürzen: Schutz für Ihre Linux-Server

24.10.2018 | 15:03 Uhr | David Wolski

Linux-Server bei Webhostern wie Strato oder 1&1 sollten zuverlässig und lange ihren Dienst tun. Trotzdem: Damit kleine oder größere Pannen den Server nicht permanent außer Betrieb setzen, sind Kontrolle und eine Notfallstrategie zu empfehlen.

Es sind nicht immer Fehler in der Administration oder äußere Einflüsse, die ein Serversystem in die Knie zwingen. Hardware, die am Ende ihrer Lebenserwartung angekommen ist, aber weiterhin im Rack des Hostingunternehmens steckt und an Neukunden vermietet wird, sorgt auch mal für spontane Ausfälle.

So erging es etwa der LinuxWelt-Redaktion mit einem Hostingpaket bei einem renommierten Hoster im Mai 2018: Auf einem frisch angemieteten Rootserver bereitete eine der Festplatten in einem Raid-Verbund Probleme. Der genaue Blick zeigte, dass die Festplatte eine stattliche Power-on-Time von 58 580 Stunden hatte, was etwa 6,5 Jahren entspricht. Laut SMART-Protokoll der Festplatte traten die ersten Fehler schon nach fünf Jahren auf. Faktisch waren die Festplatten also schon defekt, als der Servermietvertrag begann. Das Hostingunternehmen tauschte alle Festplatten des Servers nach einer Reklamation umgehend aus. Ohne gute Vorbereitung und eine solide Backupstrategie wäre dieser Server zum Datengrab geworden.

Die Schwierigkeit im Falle versehentlich herbeigeführter Pannen oder plötzlicher Hardware-Havarien auf Servern ist, dass man üblicherweise nur per SSH auf das System kommt und alle Reparaturen mit dem Notfallsystem des Hosters ausführen muss. Im Fall der Fälle gilt es, möglichst schnell das Problem einzugrenzen und den Server wieder flottzubekommen, um die Downtime kurz zu halten. Im Folgenden protokollieren wir Missgeschicke und Fehlerszenarien mit ihren Lösungen auf typischen Mietservern. Die meisten genannten Analysewerkzeuge sind natürlich auch für lokale Linux-Systeme einschlägig.

Tipp: Serverkauf - darauf müssen Sie achten

Diagnose: Die Probleme eingrenzen

In jedem Problemfall wird es darum gehen, die Fehlerbilder zunächst durch einen Blick in die Logdateien auszuwerten. Eine der wichtigsten Logdateien eines Linux-Systems ist das Kernel-Protokoll, das ein Linux-System ab dem Bootvorgang anlegt. Hier informiert der Kernel auch über erkannte Hardware, Laufwerke und Aktionen von Treibern. Stürzen Prozesse wegen fehlerhafter Treiber oder defekter Hardware ab, dann wird der Kernel dies auch in diesem Protokoll melden. In der Shell dient der handliche Befehl

dmesg -T  

dazu, alle Kernel-Meldungen mit Zeitstempel anzuzeigen. Neben allgemeinen Infos finden sich in der langen Liste auch Fehlermeldungen und Warnhinweise. Besser ist deshalb dieses Kommando:

dmesg -T -l err  

Es reduziert die Ausgabe auf Fehler und blendet alle anderen Meldungen aus. Mit

dmesg -T -l warn  

lassen sich unkritische Warnhinweise anzeigen.

Hardwarefehler: CPU und RAM

Speicherfehler in CPU und RAM können auch auf einem gesunden System auftreten und müssen nicht immer gleich zu Abstürzen führen. Moderne Prozessoren haben einen internen Mechanismus, der über Checksummen korrumpierte Speicherbereiche erkennt und dann eine „Machine Check Exception“ auslöst, die sich protokollieren lässt. Dazu ist die Installation des Pakets „mcelog“ nötig, das in allen verbreiteten Linux-Distributionen bereitsteht und in Debian/Ubuntu/Mint mittels

sudo apt-get install mcelog  

installiert wird und in Cent-OS und Red Hat mit diesem Befehl:

sudo yum install mcelog  

Ab jetzt werden unter diesem System die MCE-Fehlermeldungen in der Datei „/var/log/mcelog“ protokolliert. Auf Linux-Systemen mit dem Journald als Loggingdienst überprüft man mit dem Kommando

journalctl _SYSTEMD_UNIT=mcelog.service  

das Mcelog. Treten dort Fehler nicht nur sporadisch, sondern regelmäßig auf, so weist das auf defekte Hardware oder ein überhitztes System hin.

Datenträger: Smarter mit SMART

Nahezu alle Festplatten geben über SMART bereitwillig Auskunft über den eigenen Zustand. SMART steht kurz für „Self-Monitoring, Analysis, and Reporting Technology“ und bietet über die Firmware der Festplatte eine permanente Überwachung wichtiger Leistungsdaten, um drohende Havarien frühzeitig zu erkennen. Auf Servern ohne Desktop gibt es das Kommandozeilentool smartctl, das Linux-Distributionen im Paket „smartmontools“ mitliefern. Damit ist ein Blick auf die SMART-Parameter eines Laufwerks mit

sudo smartctl -a /dev/sd?  

möglich, wobei „?“ für die Laufwerkskennung steht. Da es mehr als nur eine Handvoll relevanter SMART-Werte gibt, ist die Interpretation nicht immer einfach. Mit jedem Parameter sind die drei Eigenschaften „Value“, „Worst‘‘ und „Threshold“ verknüpft. Der momentane Wert ist in der Eigenschaft „Value“ untergebracht, „Worst“ ist der bisher schlechteste aufgezeichnete Wert. „Threshold“ bezeichnet den Schwellenwert: Ist dieser für einen kritischen Parameter bald erreicht, so ist es Zeit, den Kundendienst des Hosters zu informieren und die Festplatte nach einem Backup austauschen zu lassen.

Tipps & Tricks: Der richtige Platz für Server

Datenträger: Zugriff per Notfallsystem

Anmeldung am Notfallsystem.
Vergrößern Anmeldung am Notfallsystem.

Neben dem installierten Serversystem liefern Hoster auf ihren Rootservern meist noch minimale Notfallsysteme aus, die sich als Livesystem über die Verwaltungskonsole im Web booten lassen. Häufig ist dies die einzige Methode, Reparaturen und Konfigurationsänderungen am Hauptsystem auszuführen, wenn die Anmeldung wegen eines vorangegangenen Fehlers scheitert. Das laufende Notfallsystem kann die Datenträger des Hauptsystems oft nicht einfach einhängen, denn auf Servern kommt üblicherweise ein Partitionsschema mit dem Logical Volume Manager (LVM2) zum Einsatz. Dieser erlaubt die fortgeschrittene Partitionierung wie die Verteilung einer einzigen Partition auf mehrere Blockgeräte.

Die Administration wird damit aber auch ein Stück anspruchsvoller, denn Partitionen mit Volumes können Sie nicht gewohnt mit dem Mount-Befehl einhängen. Der Befehl gibt bei einem Versuch die Meldung „unknown filesystem type LVM2_member“ aus. Der erste Schritt im Notfallsystem ist es, mit dem Logical Volume Manager nach Volumen zu suchen:

vgscan --mknodes
vgchange -ay  

Der Befehl gibt den Namen der Volumengruppe aus, den Sie im nächsten Befehl brauchen. Die beiden Befehle finden die Volumengruppe und geben deren Volumennamen aus, beispielsweise „ubuntuvg“ bei einem Ubuntu-System.

Das Kommando

sudo lvdisplay  

listet jetzt alle Volumen mit exaktem Pfad auf, der im nächsten Schritt wichtig ist: Um bei einem Ubuntu-System die Wurzelpartition „root“ in der Volumengruppe einzuhängen, sind diese zwei Befehle nötig:

mkdir -p /mnt/ubuntu
mount /dev/ubuntu-vg/root /mnt/ubuntu 

Der Gerätepfad hinter „/dev/“ ist bei unterschiedlichen Distributionen abweichend, wird aber stets von lvdisplay angezeigt.

Auf Raid-Systemen: Viele Server arbeiten mit einem Raid 0, das Beschleunigung ohne Redundanz bereitstellt. In einem Notfallsystem zeigt der Befehl

cat /proc/mdstat  

die erkannten Raids mit den einzelnen Datenträgerpfaden an. Einen Raid-Verbund kann das Kommando

mount /dev/md2/mnt/ubuntu  

einhängen, in diesem Beispiel nach „/mnt/ ubuntu“. Sofern das Raid intakt ist, kümmert sich das Mdadm-Tool (Multiple Disk Administration) des Notfallsystems dann automatisch um das Zusammenfügen des Verbunds.

Current Pending Sector Count

Anzahl der instabilen Sektoren, die auf eine Verschiebung in den reservierten Bereich warten

Disk Shift

zeigt bei Festplatten an, ob sich wegen Schockeinwirkungen eine messbare Umwucht gebildet hat

Erase Fail Count

zeigt bei SSDs, wie viele Löschvorgänge bereits scheiterten, und weist auf Alterserscheinungen hin

G-Sense Error Rate

G-Sense ist ein Schock-Sensor, der heftige Erschütterungen im Betrieb misst

Program Fail Count

zeigt bei SSDs die Anzahl der gescheiterten Flashvorgänge und indiziert damit Alterserscheinungen

Raw Read Error Rate

weist auf unkorrigierbare Lesefehler hin und damit auf Probleme mit Platten oder Leseköpfen

Reallocated Sector Count

zählt die bereits genutzten Reservesektoren von Festplatten/SSDs und indiziert damit Laufwerksprobleme

Reallocation Events Count

protokolliert jeden Versuch der Festplatte/SSD, Sektoren umzumappen, auch wenn dies nicht gelingt

Recalibration Retries

zeigt an, wie oft eine Platte ihre Schreib-Lese-Köpfe neu kalibrieren musste, und indiziert mechanische Fehlfunktionen

Seek Error Rate

zählt die Fehler bei Lesevorgängen und weist auf Probleme mit Leseköpfen oder der Plattenoberfläche hin

Soft Read Error Rate

zählt, wie oft das Betriebssystem die gelesenen Daten als fehlerhaft verworfen hat

Spin Retry Count

zeigt, wie oft der Motor anlaufen musste, damit die Platte ihre betriebstypische Umdrehungszahl erreicht

Througput Performance

misst den Datendurchsatz: Niedrige Werte indizieren, dass die Platte/SSD nicht mehr in vollem Tempo arbeitet

UltraDMA CRC Error Rate

nennt die Prüfsummenfehler bei der Datenübertragung, kann auch auf defekte SATA-Kabel hinweisen

Uncorrectable Sector Count

nennt die Anzahl fehlerhafter Sektoren, welche die Controllerlogik nicht restaurieren konnte

Used Reserved Block Count

zählt bei SSDs, wie viele reservierte Speicherblöcke als Ausweichlösung bereits genutzt wurden

Write Error Rate

zählt die Fehler, die beim Schreiben von Sektoren bislang aufgetreten sind

Ausgesperrt: Passwort und sudo-Rechte

Gibt es Raid-Laufwerke?
Vergrößern Gibt es Raid-Laufwerke?

Hat man sich lange nicht mehr auf einem Server angemeldet oder ist nach einem Personalwechsel das root-Passwort nicht bekannt, dann kann man dieses über das Notfallsystem neu setzen. Im Falle Ubuntus gibt es keinen root-Account, sondern eines oder mehrere Benutzerkonten, das für die Verwendung von sudo legitimiert ist.

Nach dem Einhängen der Systempartition im Notfallsystem nach „/mnt“ lässt man sich dort mit dem Befehl

cat /mnt/etc/passwd  

den Inhalt der Benutzerdatenbank ausgeben. Hier erfährt man, wie die eingerichteten Benutzerkonten heißen. Die eigentlichen Passwörter stehen allerdings nicht in dieser Datei, sondern verschlüsselt in der Passwortdatenbank „/etc/shadow“ auf der eingehängten Systempartition. Diese Datei öffnet man (mit root-Recht) in einem Texteditor. Hier sind jetzt die Benutzereinträge wie „benutzername:$1$aB7mx0L[...]: 16301:0:99999:7:::“. Die lange Zeichenfolge hinter dem Benutzernamen ist das verschlüsselte Passwort. Die Zahlen dahinter enthalten Infos darüber, wann das Passwort zuletzt geändert wurde und ob das Benutzerkonto aktiv ist.

Diese Teile kann man ignorieren, zum Löschen des vergessenen Passworts ist nur die lange Zeichenkette zwischen den Doppelpunkten von Bedeutung. Im Texteditor kann man diese Zeichenkette einfach löschen, die Doppelpunkte müssen aber unbedingt bestehen bleiben! Die Zeile kann danach so aussehen:

benutzername::16301:0:99999:7::: 

Nach dem Speichern der Datei und dem Neustart des Hauptsystems kann man sich ohne Passwort am geänderten Benutzerkonto anmelden und danach mit passwd ein neues Passwort vergeben.

Fehlende sudo-Rechte: In Ubuntu kann es vorkommen, dass man sich versehentlich durch einen misslungenen Befehl aus der Gruppe „sudo“ wirft und dann von der Systemadministration ausgeschlossen ist, weil sudo nicht mehr funktioniert. Der einfachste Weg, dieses Problem über das Notfallsystem zu beheben, ist eine Anpassung der Datei „/etc/sudoers“ mit einem Texteditor. Am Ende der Datei trägt man den gewünschten Benutzernamen ein:

benutzername ALL=(ALL:ALL) ALL  

Ab dem nächsten Neustart des Serversystems darf dieser Benutzer sudo dann wieder verwenden.

Fallstudie Serverreinigung: So vermeiden Sie den Server-Burnout

Firewall und SSH: Lass mich rein!

Firewall durchlässig machen.
Vergrößern Firewall durchlässig machen.

Tückisch und in der Aufbauphase eines Servers leicht zu übersehen sind zu restriktive Firewallregeln, die eine Anmeldung per SSH am Server verhindern. Wer die Firewallregeln selbst mit einem Script erstellt, muss dieses ausfindig machen und dafür sorgen, dass der Port 22 von SSH nicht mehr per DROP von den iptables geblockt wird.

In Debian und Ubuntu ist das eine eigene Herausforderung, denn dort kümmert sich meist das Tool ufw um die Firewallregeln beim Absichern des Servers. Die von Administratoren hinzugefügten Regeln speichert das Tool in der Datei „/etc/ufw/user.rules“ für IPv4 sowie in der Datei „/etc/ufw/user6.rules“ für IPv6. Meist genügt es, die Datei IPv4 im Notfallsystem in einem Texteditor zu öffnen und zu ändern. Dort sucht man nach dieser Zeile:

-A ufw-user-input -p tcp --dport 22 -j DROP  

Dies blockt den Port 22 für SSH und muss daher gelöscht werden. Um Port 22 zu erlauben, fügt man stattdessen an gleicher Stelle diese Zeile ein:

-A ufw-user-input -p tcp --dport 22 -j ACCEPT  

Nach einem Neustart des Serversystems akzeptiert dieses wieder SSH-Anmeldung per IPv4 auf Port 22.

Dateisystem: Systemdateien restaurieren

Systemdateien finden und neu installieren.
Vergrößern Systemdateien finden und neu installieren.

Selten, aber sehr ärgerlich ist versehentliches Löschen oder Überschreiben von Systemdateien nach fehlerhaften Befehlen in der Shell. Wenn eine Systemdatei, beispielsweise eine ausführbare Binary, fehlt, wird es nicht lange dauern, bis andere Prozesse scheitern oder Scripts nicht mehr korrekt ablaufen.

In den meisten Fällen sind fehlende Systemdateien aber durch die Reinstallation des Pakets aus den Paketquellen schnell wiederhergestellt.

Angenommen, es fehlt das Programm ping, so gilt es, im laufenden Serversystem zuerst herauszufinden, in welchem Paket das Programm steckt: In Debian/Ubuntu dient dazu dieses Kommando:

dpkg -S /bin/ping  

Der Befehl wird den Paketnamen „inetutilsping“ zurückgeben und der Befehl

sudo apt-get --reinstall install iputils-ping  

anschließend das Paket nochmals installieren. Auf Cent-OS- und Red-Hat-Systemen sucht der Befehl

yum provides /bin/ping
sudo yum reinstall iputils  

nach dem richtigen Paket und installiert es nach. In Open Suse helfen die beiden folgenden Kommandos

zypper search -f /bin/ping
sudo zypper -S iputils  

weiter.

Vorsorge: Logwatch behält alles im Blick

Für eine gezielte Fehlersuche hilft die manuelle Auswertung von Logdateien. Um ein Serversystem aber systematisch zu überwachen, ist eine andere Vorgehensweise nötig. Eine schnell eingerichtete automatische Auswertung von Logs liefert das Programm Logwatch, das sich als täglicher Cronjob installiert. Es erstellt einen jederzeit abrufbaren verkürzten Bericht als Zusammenfassung. Auf Servern mit einem Mailserver wie Postfix/ Sendmail/Exim2 kann es den Bericht auch per Mail an einen Empfänger senden. Soll ein Benutzer wie root auf dem System die Zusammenfassung im lokalen Postfach erhalten, so genügt dazu auch ein lokaler Mailserver ohne Verbindung zu einem anderen SMTP-Server im Internet.

Logwatch analysiert die Protokolldateien des Systems.
Vergrößern Logwatch analysiert die Protokolldateien des Systems.

Debian, Raspbian, Ubuntu, Fedora, Open Suse und Arch bieten alle das Paket „logwatch“ in ihren Paketquellen. In Debian und seinen Derivaten wird es beispielsweise mit

sudo apt-get install logwatch  

installiert. In seinen Standardeinstellungen trägt sich Logwatch unter „/etc/cron.daily“ ein.

Das Kommando

sudo logwatch  

präsentiert im Terminal eine Übersicht zu ungewöhnlichen Ereignissen. Möchte man den täglichen Bericht per Mail erhalten, so ist noch die Konfigurationsdatei „/usr/share/logwatch/default.conf/logwatch.conf“ anzupassen. Diese Datei öffnet man als root oder per sudo in einem Texteditor, geht zur Zeile „MailTo = root“ und trägt dort statt „root“ die gewünschte Mailadresse oder bei einem lokalen Mailserver den Benutzernamen des Administrators ein. Zum Lesen der lokalen Mail eignet sich im Terminal das Programm mutt, das in allen Linux-Distributionen über das gleichnamige Paket installiert werden kann.

PC-WELT Marktplatz

2383578