Kernel-Dumps mittels kdump auf Remote-Maschinen sichern
Stürzt der Linux-Kernel ab, so kann dank eines Mechanismus namens kdump ein Abbild des Speicherinhalts (auch vmcore genannt) erstellt werden. Dieses ist vor allem dann nützlich, wenn der Support in Anspruch genommen werden soll, um die Problemursache zu eliminieren. Standardmäßig legt dieser Mechanismus den vmcore unterhalb /var/crash ab. Wenn der Kernel jedoch nicht mehr in der Lage ist, auf das Storage zuzugreifen (beispielsweise aufgrund fehlerhafter Storage- oder HBA-Treiber), bleibt der nützliche Abzug des Arbeitsspeichers aus. In so einem einem Fall wäre das Speichern des Dumps auf einem anderen Host im Netzwerk hilfreich. Glücklicherweise ist kdump auch in der Lage, diese Informationen per SSH bzw. SCP auf andere Systeme zu kopieren.
Ich hatte kürzlich genau diesen Anwendungsfall und habe daher eine virtuelle Maschine für die Speicherung von Kerneldumps erstellt.
Die Kernel-Dumps sollten in meinem Fall auf einem dedizierten LVM-Speicher abgelegt werden. Daher habe ich eine dedizierte LVM-Volumengruppe und ein logisches Volume erstellt. Damit dieses nach dem Booten zur Verfügung steht, wird es in der Datei /etc/fstab eingetragen. Verloren gegangene SELinux-Flags habe ich wiederhergestellt:
1# pvcreate /dev/sdb
2# vgcreate vg_data /dev/sdb
3# lvcreate --extents 100%FREE vg_data --name lv_crash
4# mkfs.ext4 /dev/mapper/vg_data-lv_crash
5# vi /etc/fstab
6...
7/dev/mapper/vg_data-lv_crash /var/crash ext4 defaults 1 2
8
9ESC ZZ
10
11# mount -a
12# restorecon -v /var/crash
Es empfiehlt sich für die SSH-Kommunikation zwischen den registrierten Systemen und dem Kerneldump-Host einen dedizierten Benutzer anzulegen:
1# useradd --comment "Kernel Dump-User" kdump
2# passwd kdump
Sofern Passwort-Alterung aktiv ist, ist es ratsam die Alterung für den eben angelegten Benutzer zu deaktivieren:
1# chage -M 99999 kdump
Damit der Benutzer schreibenden Zugriff auf das Verzeichnis /var/crash erhält ist es eine gute Idee, Access Control Lists (ACL) zu aktivieren und eine entsprechende Regel für den Benutzer anzulegen:
1# tune2fs -o acl /dev/mapper/vg_data-lv_crash
2# mount -o remount,acl /var/crash
3# setfacl -R -m u:kdump:rwx /var/crash
Auf den anderen Systemen wird nun die kdump-Konfiguration angepasst. Dabei wird die path-Zeile deaktiviert und eine weitere eingefügt:
1# chkconfig kdump on
2# cp /etc/kdump.conf /etc/kdump.conf.initial
3# vi /etc/kdump.conf
4...
5#path /var/crash
6net kdump@mymachine.localdomain.loc
7
8ESC ZZ
Anschließend wird pro System das Passwort des angelegten kdump-Benutzers angegeben. Im Falle eines Kerneldumps wird dieser Benutzer verwendet, um eine Verbindung zum Kerneldump-Server herzustellen und die Daten zu platzieren:
1# service kdump propagate
2Using existing keys...
3The authenticity of host 'mymachine.localdomain.loc (xxx.xxx.xxx.xxx)' can't be established.
4RSA key fingerprint is xxx.
5Are you sure you want to continue connecting (yes/no)? yes
6kdump@mymachine.localdomain.loc's password:
7/root/.ssh/kdump_id_rsa has been added to ~kdump/.ssh/authorized_keys on mymachine.localdomain.loc
Abschließend ist es ratsam, den kdump-Dienst neuzustarten und die korrekte Konfiguration zu überprüfen:
1# service kdump restart
2# service kdump status
3Kdump is operational
Abweichende Ausgaben deuten hier auf einen Fehler hin. Der Test überprüft jedoch nicht, um der angegebene Benutzer eine SSH-Verbindung zum Kerneldump-Server herstellen kann. Diese Funktionalität muss also über einen anderen Weg getestet und überwacht werden - beispielsweise durch entsprechende Checks durch ein Monitoringsystem.
Es ist auch möglich, dass folgende Ausgabe erscheint:
1Warning: There might not be enough space to save a vmcore.
2 The size of kdump@mymachine.localdomain.loc:/var/crash/tmp.XSGZ0jMgsd should be greater than 132159368 kilo bytes.
In diesem Fall ist das Dateisytem auf dem Kerneldump-Server zu klein, um ein vollständiges Arbeitsspeicherabbild zu enthalten. Im ungünstigen Fall ist das Speicherabbild genau so groß wie der Arbeitsspeicher (in diesem Fall 128 GB).