![InCloudUs - if [ "$UNIX" == "true" ]; then echo "Youpi \o/"; fi](https://blog.incloudus.com/wp-content/uploads/2013/09/Little-tux-b-w.sh-600x6001-e1382623229226.png)
Il n’y a rien de plus facile !
Dans un précédent article je parlais de l’utilisation de Kdump sous Debian, aujourd’hui je vais passer à la pratique. Dans un premier temps il est nécessaire d’ajouter le dépôt InCloudUs afin d’obtenir le paquet kdump-install.
|
1 |
# aptitude install kdump-tools kdump-install |
La première fenêtre demande quel est le type de noyau actuellement utilisé. Si c’est le noyau Debian par défaut alors cela ne posera aucun problème par contre si le noyau utilisé est un noyau personnalisé (installé depuis les sources par exemple) alors il vous faudra configurer le fichier /etc/kdump-install/kdump-install.conf pour lui indiquer par exemple ou aller chercher le fichier de debug.
La seconde fenêtre demande ou doit être sauvegardé le core généré, trois méthodes (pour le moment) possibles :
- En local sur le disque dur (par défaut dans le répertoire /var/crash)
- Sur un serveur NFS dans le répertoire de votre choix
- Sur un serveur SFTP dans le répertoire de votre choix
Le choix par défaut est le premier. Si vous souhaitez utiliser la méthode SFTP alors il sera nécessaire de déployer la clé publique (de l’utilisateur root) du client sur le serveur qui recevra le core auquel cas un mot de passe sera demandé.
Une fois les paquets installés il suffit de lancer la commande kdump-install, le résultat est le suivant :
Le serveur doit obligatoirement être redémarré pour que le noyau puisse démarrer avec le paramètre crashkernel=X@Y.
Voici à quoi ressemble le fichier /etc/default/kdump-tools en ayant choisi un noyau Debian par défaut ainsi que la méthode « local ».
|
1 2 3 4 5 6 7 8 9 |
USE_KDUMP=1 KDUMP_RUNLEVEL="1" KDUMP_SAVEDIR="file:///var/crash" KDUMP_NET="" KDUMP_SYSCTL="kernel.panic_on_oops=1" KDUMP_COREDIR="/var/crash" KDUMP_FAIL_CMD="reboot -f" DEBUG_KERNEL=/usr/lib/debug/boot/vmlinux-3.2.0-4-amd64 MAKEDUMP_ARGS="-c -d 31" |
On cra[sh|che] [le|sur] serveur
Le serveur redémarré, configuré aux petites oignons, kexec ayant chargé le module en mémoire, il ne reste plus qu’à faire crasher le serveur et sacrifier un poulet pour que ce dernier génère un core !
|
1 |
# echo c > /proc/sysrq-trigger |
Une fois le serveur redémarré et si tout s’est correctement déroulé, vous devriez trouver un joli petit répertoire de ce genre YYYYMMDDhhmm dans /var/crash avec à l’intérieur un fichier dump.YYYYMMDDhhmm. Victoire \o/
Valide ou pas (le core)
Simple à savoir :
|
1 |
# cd /var/crash/dump.YYYYMMDDhhmm ; crash kernel_link dump.201302102031 |
Résultat :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
crash 6.0.6 Copyright (C) 2002-2012 Red Hat, Inc. Copyright (C) 2004, 2005, 2006 IBM Corporation Copyright (C) 1999-2006 Hewlett-Packard Co Copyright (C) 2005, 2006 Fujitsu Limited Copyright (C) 2006, 2007 VA Linux Systems Japan K.K. Copyright (C) 2005 NEC Corporation Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc. Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc. This program is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Enter "help copying" to see the conditions. This program has absolutely no warranty. Enter "help warranty" for details. GNU gdb (GDB) 7.3.1 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu"... KERNEL: kernel_link DUMPFILE: dump.201302102031 [PARTIAL DUMP] CPUS: 2 DATE: Sun Feb 10 20:30:55 2013 UPTIME: 00:01:08 LOAD AVERAGE: 0.03, 0.01, 0.01 TASKS: 76 NODENAME: bakasable RELEASE: 3.2.0-4-amd64 VERSION: #1 SMP Debian 3.2.35-2 MACHINE: x86_64 (2000 Mhz) MEMORY: 3 GB PANIC: "[ 68.733165] Oops: 0002 [#1] SMP " (check log for details) PID: 2308 COMMAND: "bash" TASK: ffff8800ba1b3650 [THREAD_INFO: ffff88003781e000] CPU: 1 STATE: TASK_RUNNING (PANIC) crash> |
Le core généré est exploitable… Il ne reste plus qu’à l’analyser, have fun !
Liens
Gaëtan Trellu (goldyfruit)
Derniers articles parGaëtan Trellu (goldyfruit) (voir tous)
- systemd-networkd, l’âge de la maturité ? - 13 mars 2018
- Hyper-V, Nova, VxLAN et Open vSwitch, enfin une belle histoire ! - 31 décembre 2017
- iPXE et la fameuse erreur 0x040ee119 qui rend fou ! - 17 avril 2017
kdump-tools et kdump-install, par l’exemple… par Gaëtan Trellu (goldyfruit) est sous Licence Creative Commons Internationale Attribution 4.0.