Security ist ein stets aktuelles Thema in der IT. Deshalb widmet sich das ADMIN-Magazin 04/2012 speziell Sicherheitsaspekten und gibt Antworten auf die Fragen: ... (mehr)

Test-Crash

Wer unsicher ist, kann sich durch einen Blick in »/proc/iomem« davon überzeugen, dass der geschützte Speicherbereich markiert ist (siehe Listing 1 ). Ist alles korrekt verlaufen, kann das Start-Skript von »kdump« den Crash-Kernel in den Speicher laden. Typischerweise bindet der Admin dies in den regulären Boot-Prozess ein, für die ersten Gehversuche reicht aber auch eine manuelle Aktivierung.

Listing 1

Vorbereitungen für den Kernel-Dump

 

An dieser Stelle gilt es, das konfigurierte Setup zu überprüfen, sprich künstlich einen Kernel-Crash auszulösen, der dann automatisch das Schreiben des Dumps starten sollte. Dafür schaltet man über »echo 1 > /proc/sys/kernel/sysrq« zunächst die sogenannten Magic Sysrequest Keys ein. Im Normallfall ist das schon erledigt, wenn der Admin die Distributionswerkzeuge zum Einrichten des Kernel-Dumps verwendet hat.

Ein beherztes »echo c > /proc/sysrq-trigger« löst jetzt einen Kernel-Panic aus. Wenn alles funktioniert, startet das System dann den Crash-Kernel, der wiederum »kdump« beziehungsweise »makedumpfile« auslöst ( Abbildung 2 ).

Abbildung 2: Der Crash-Kernel in Aktion.

Jeden Dump legt das System in einem mit dem Erzeugungsdatum versehenen Verzeichnis ab. Stürzt das System mehrfach ab, werden bereits gespeicherte Informationen so nicht überschrieben. Noch eine Nebenbemerkung für die Suse-Anhänger: Sie können den Kernel-Panic auch über das Laden des Modules »crasher.ko« auslösen. Dies stammt übrigens aus der Feder von Btrfs-Entwickler Chris Mason, als er noch bei Suse arbeitete [8] .

De Luxe

Waren die ersten Dump-Versuche erfolgreich, kann es an das Tuning gehen. Da wäre zunächst die Speicher-Reservierung für den Crash-Kernel. Die allgemeine Anweisung lautet »crashkernel=Bereich1:Grösse1[,Bereich2:Grösse2,...][@Adresse]« . Im konkreten Fall von »crashkernel=512M-2G:64M,2G-:128M« heißt das: Für einen RAM-Ausbau von 512 MByte bis 2 Gyte reserviert das System 64 MByte und 128 MByte bei mehr als 2 GByte Hauptspeicher. Das vereinfacht die Konfiguration des Bootloaders für eine heterogene Hardware-Umgebung. Unabhängig vom Hauptspeicher bleibt der »crashkernel« -Eintrag immer derselbe. Bei Suse macht Yast das automatisch. Die Angaben von Größe und Bereich können laut Kernel-Dokumentation auch in KByte erfolgen, allerdings ist dies für die Praxis nicht relevant.

In der Standard-Konfiguration speichert das System den Kernel-Dump der lokalen Platte. Bei Systemen mit üppigem Hauptspeicher kann es da schnell zu Problemen kommen. Glücklicherweise erlaubt das Kexec/Kdump-Gespann auch das Speichern über das Netzwerk. Der Admin hat dabei die Wahl zwischen NFS und SSH/SCP. Tabelle 1 listet die verfügbaren Optionen auf.

Tabelle 1

Ablagemöglichkeiten für den Kernel-Dump

Variante

Beschreibung

raw /dev/sdc1

Schreibt den Dump mit »dd« auf die Partition »/dev/sdc1« .

ext3 /dev/sdc1

Hängt »/dev/sdc1« als Ext3-Dateisystem ein und speichert dort den Dump.

ext4 LABEL=/dump

Hängt das Dateisystem mit diesem Label ein und legt den Dump dort ab.

net mynfs.server.com:/export/dump

Integriert das entsprechende NFS-Share des Servers und schreibt den Dump dorthin.

net mailto:user@my.ssh.server.com

Speichert den Dump über SCP als entsprechenden Nutzer auf dem Server.

Das Schreiben über SSH/SCP setzt eine nicht-interaktive Authentisierung beispielsweise über Schlüssel voraus. Es empfiehlt sich daher, einen separaten und recht eingeschränkten Ziel-Benutzer zu konfigurieren.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023