Turb(l)o(g)

Pour changer un peu des kiosques à journaux, un petit article à propos d’administration système. Cet article est très orienté DELL et FreeBSD. Je n’ai pas testé le résultat de cette config sur d’autres marques de machine ou avec d’autres OS.

Ayant déjà déployé puppet (administration centralisée de parc) et nagios (monitoring) avec son fidèle compagnon nrpe (qui sert à remonter à nagios les résultats de plugins locaux sur les serveurs), je cherchais un moyen simple de centraliser les informations hardware & software de l’ensemble de mes ouailles.

Le principe adopté est un peu barbare mais a l’avantage de ne pas avoir a déployer d’autre logiciel.

Il se base sur les résultats fournis par dmidecode, qui contiennent, entre autre, le numéro de série de la machine, la composition hardware et tout un tas d’infos rigolottes.

Puppet, quant à lui, retourne déjà, via facter, pas mal d’informations sur l’OS installé. Il parle déjà avec dmidecode mais n’en extrait pas toute la quintessence.

L’idée était donc d’apprendre à facter a discuter un peu plus avec dmidecode pour qu’il retoune l’ensemble des infos que je voulais. En se basant sur les scripts existants pour facter, j’ai donc crée un dmidecode.rb dans le dossier /usr/local/lib/ruby/site_ruby/1.8/facter :

# dmidecode.rb
# Facts related to hardware
#
#

require ‘facter/util/manufacturer’

query = {
‘(Chassis Information|system enclosure or chassis)’ => [
{ ‘Power Supply State:’ => ‘powersupply’ },
{ ‘Thermal State:’ => ‘thermalstate’ },
{ ‘Height:’ => ‘racksize’ }
],
‘Processor Information’ => [
{ ‘Family:’ => ‘CPUfamily’ },
{ ‘Current Speed:’ => ‘CPUspeed’ },
{ ‘Version:’ => ‘CPUversion’ }
],
}

Facter::Manufacturer.dmi_find_system_info(query)

Vous pouvez aussi patcher directement le fichier manufacturer.rb, mais je préfère quelque chose qui ne risque pas d’être écrasé par une mise à jour ultérieure de facter.

Vous remarquez très bien, même si, comme moi, vous n’êtes pas un grand amateur de ruby, qu’on retrouve assez vite ses petits dans le script en question.

Admettons que vous vouliez, en plus, récupérer le mode de fonctionnement du cache, vous ajouteriez un ‘Cache Information’ => [ { »Operationnal Mode:’ => ‘CacheMode’}],

Une fois que ceci est fait, si vous lancez facter, vous y trouverez les nouvelles infos demandées, pour peu que dmidecode les retourne lui-même, en l’occurrence, pour ma part, je cherchais l’état des alimentations, de la température interne, la hauteur du châssis, le type, la version et la vitesse du CPU.

Vous me direz « fort bien, facter retourne les infos, et maintenant, comment on les centralise ? ». Si vous avez bien développé votre infrastructure puppet, il doit y avoir moyen de les récupérer directement via le puppet central. Pour ma part, je souhaitais que cet outil fonctionne même si puppet était HS, j’ai donc ajouté, dans la configuration de nrpe, une simple petite ligne :

command[facter]=/usr/local/bin/sudo /usr/local/bin/facter -y

et, pour que dmidecode puisse récupérer toutes les infos, dans le /usr/local/etc/sudoers

nagios ALL=NOPASSWD: /usr/local/bin/facter

Vous pouvez être tenté, si facter retourne beaucoup d’infos, de faire un grep dans l’appel situé dans la configuration nrpe, celui-ci limitant a je-ne-sais-combien-de-caractères la réponse qu’il fourni. Le -y force facter à faire une réponse en YAML, plus simple à parser par la suite.

Pour finir, un petit script central, sur la même machine que votre nagios, ira tour a tour questionner toutes les machines et consigner les résultats en base de données (ou générer une alerte, dans le cas d’une alim HS par exemple) via un simple appel :

/usr/local/libexec/nagios/check_nrpe -H IP_de_la_machine -c facter

Evidemment, pour que tout ça fonctionne, il faut déjà avoir une base de données avec le listing de ses machines.

Toutes ces configurations peuvent être faites directement par puppet, évitant ainsi un long et laborieux déploiement.