Kdump un standard en devenir (si si si)

Il va de soit que c’est un avis personnel mais à mon sens, avoir un serveur sans Kdump c’est comme rouler en voiture sans feux de croisement (superbe analogie, non ?).

Pour une petite piqûre de rappel sur ce qu’est Kdump et à quoi il sert, je vous invite à parcourir les liens suivants :

Les liens ci-dessus traitent de l’installation manuelle de Kdump sur une distribution Debian GNU/Linux, c’est bien, c’est fonctionnel mais quid de l’industrialisation du déploiement de Kdump sur l’ensemble d’un parc informatique ?

Et pourquoi pas avec Puppet ?

Il existe plusieurs outils d’industrialisation, dont voici la liste des plus utilisés : Chef, Puppet, Ansible, Compkit (SGCIB joke 😛 )

Dans le cadre de ce billet, je vais utiliser Puppet (et puis de toute façon je ne connais pas les autres…). Sur le serveur Puppet (puppetmaster), il sera nécessaire d’installer quelques modules supplémentaires :

Le module goldyfruit-kdump gère ses dépendances tout seul comme un grand. Pour installer les modules il suffit de passer par la commande puppet qui se charge de récupérer les modules sur la forge Puppet.

L’installation des modules ne prend que quelques secondes.

# puppet module install goldyfruit-kdump
# puppet module install fiddyspence-sysctl

Si vous utilisez Apache pour distribuer Puppet, alors il sera certainement nécessaire de relancer ce dernier pour que les nouveaux modules soient pris en charge.

Une recette de famille

Puppet fonctionne avec un système de recette (manifests). Comme son nom l’indique, une recette est une liste d’ingrédients devant être présents sur le serveur. Concrètement, dans notre recette nous souhaitons avoir les ingrédients suivants :

Un GRUB demandant au noyau de démarrer avec l’option crashkernel=128M
Un Kdump qui dump toute la mémoire dans le répertoire /var/crash/
Un sysctl configuré pour faire crasher le noyau lors de la réception d’un NMI

Appétissant n’est-ce pas ? 😯

La recette en question

Voici à quoi ressemble la recette (manifest) Puppet en utilisant les modules cités plus haut :

node 'kant.incloudus.com' {

  class { 'grub2':
    cmdline_linux_default     => 'quiet crashkernel=128M nmi_watchdog=0 console=tty0 console=ttyS1,115200n8',
    update_grub               => true,
  }

  class { 'kdump':
    install_kdump             => true,
    use_kdump                 => true,
    core_dir                  => '/var/crash',
    debug_path                => '/usr/lib/debug/boot/vmlinux-3.2.0-4-amd64',
    kernel_debug              => 'linux-image-3.2.0-4-amd64-dbg',
    fail_cmd                  => 'reboot -f',
    makedump_args             => '-c -d 31',
    net_proto                 => 'none',
    run_level                 => '1',
    save_dir                  => 'file:///var/crash',
    sysctl_args               => 'kernel.panic_on_oops=1',
  }

  sysctl { 'kernel.panic_on_oops':
    ensure    => 'present',
    permanent => 'yes',
    value     => '1',
  }

  sysctl { 'kernel.unknown_nmi_panic':
    ensure    => 'present',
    permanent => 'yes',
    value     => '0',
  }

  sysctl { 'kernel.panic_on_unrecovered_nmi':
    ensure    => 'present',
    permanent => 'yes',
    value     => '1',
  }

  sysctl { 'kernel.panic_on_io_nmi':
    ensure    => 'present',
    permanent => 'yes',
    value     => '1',
  }

}