EyesOfNetwork on Zwindler's Reflection

Installer 3 plugins Nagios dans EON 1.2, coupé d’Internet, level 3

Wed, 15 Sep 2010 08:47:41 +0000

Pour le dernier plugin, check_mssql_health, j’ai vraiment dû faire face à de gros ennuis. Ce script Perl, très bien fait une fois installé, permet de vérifier à peu près tout ce qu’on pourrait vouloir vérifier dans une base de donnée MS SQL. C’est vraiment très impressionnant, et assez bien documenté une fois qu’on est sur le site officiel, heureusement en anglais (certains sites ne référencent que la partie allemande de l’aide, ce qui peut s’avérer particulièrement inutile quand on ne connait pas plus d’Allemand que quelques paroles de Rammstein).

Même si c’est probablement dû à mon cas particulier, j’ai souvent dû faire face à des documentations incomplètes pour l’installation des différents composants. J’ai passé un bon moment à tâtonner, chercher de la doc à droite à gauche, tester, râler… C’est pourquoi un passage en revue de tous les aspects de la chaine me parait utile.

D’abord, commençons par redire qu’il s’agit d’un script Perl. Pour fonctionner, celui-ci nécessite plusieurs choses. D’abord, il utilise un module Perl permettant de communiquer avec des bases de données. Mais ce module nécessite bien sûr d’un client de base de données, et enfin, ce client de base de données nécessite les bibliothèque qui vont bien pour s’installer.

Voyons cela plus en détails… Le plugin check_mssql_health nécessite du module DBD::Sybase, qui est en fait un module permettant de s’interfacer avec des base de données Sybase, en passant par l’intermédiaire d’un client fournit par Sybase. On pourrait se dire que c’est un choix curieux sachant qu’on veut communiquer avec une base MSSQL, mais en fait, le module permet également d’utiliser un autre client, FreeTDS (qui est une réimplémentation ce précédent client), qui gère également les bases MSSQL 2000 ou supérieure (le vCenter 2.5 utilise une base de données MS SQL Server 2005 Express).

La première chose à faire est d’installer le client FreeTDS. Pour ce faire, il faut d’abord ajouter les paquets suivant avec Yum :

# yum install unixODBC
# yum install unixODBC-devel

Si vous vous en tenez à la documentation de FreeTDS, vous ne lirez nulle part qu’il faut installer unixODBC-devel, et si vous ne le faites pas, le script d’installation continuera inlassablement à vous indiquer que vous n’avez pas installé unixODBC (alors que si!).

Une fois que ceci est fait, il faut télécharger les sources de freetds, car le DVD d’EyesOfNetwork qui nous sert de répository local ne contient pas le paquet pour l’installer. Pour fonctionner correctement, notre script Perl nécessitera au moins la version 6.2 de FreeTDS, sachant que je n’ai testé que la version que la 8.2. De préférence, choisir la version dite stable.

# tar xvzf freetds-stable.tgz
#cd freetds-[version_stable]
# ./configure
# make
# make install

Maintenant que FreeTDS est installé, il faut le configurer. Si on lit la documentation de check_mssql_health, il est indiqué que pour des raisons de sécurité, il vaut mieux passer le protocole de communication de FreeTDS de la version 4.2 (par défaut) à la version 8.0. Pour ma part, ce n’est pas un conseil, c’est une obligation. check_mssql_health n’a jamais fonctionné tant que je n’ai pas modifié de paramètre. Et ce n’est pas plus mal, quand on sait que cette version 4.2 du protocole envoie votre mot de passe en clair sur le réseau, lors des authentifications avec la base de données (O_o).

Pour changer cette version de protocole, éditez le fichier /etc/freetds.conf pour qu’il ressemble à ça :

[global]
#TDS protocol version
tds version = 8.0
[...]

Maintenant que nous disposons du client, que celui-ci est correctement configuré, il faut installer les dépendances Perl. Par rapport à la dernière fois, il ne m’en manquait que deux :

DBD::Sybase
- DBI

Par contre, avant de pouvoir installer DBD::Sybase, il est nécessaire de le configurer (contrairement aux autres modules Perl installés jusqu’à présent). Dans les fichiers d’aide README et README.freetds contenus dans l’archive DBD::Sybase, il est indiqué que le chemin vers FreeTDS doit être connu par le script Makefile.PL. Cette valeur doit normalement être renseignée en enregistrant le chemin vers FreeTDS dans la variable d’environnement SYBASE.

Pour des raisons qui me sont totalement inconnues, je n’ai jamais réussi à faire fonctionner ce script avec cette méthode. La variable n’était jamais prise en compte, et même si l’installation continuait, le module n’était pas fonctionnel, puisqu’il n’avait pas accès au client. Pour contourner ce problème, j’ai utilisé une solution radicale et pas très élégante. Dans Makefile.PL, j’ai remplacé les lignes

Sub configure{
my $sybase_dir = $ENV{SYBASE};
[...]

par

Sub configure{
my $sybase_dir = '[chemin_vers_freetds]';

Après cela, l’installation du module s’est déroulée sans encombres, et le script à pu être compilé :

# tar xvzf check_mssql_health_[version].tar.gz
# cd check_mssql_health_[version]
# ./configure --prefix'/srv/eyesofnetwork/nagios-3.0.6' --with-nagios-group=eyesofnetwork
# make
# make install

Une fois encore, il est important de ne pas mettre de / final dans le chemin indiqué dans la ligne ./configure. Une fois les commandes exécutées avec succès, le script est installé dans le dossier /srv/eyesofnetwork/nagios-3.0.6/libexec.

Ca y est ? Non…

Même si maintenant tout est correctement configuré et installé côté plugin, il est encore nécessaire de configurer votre base MSSQL pour qu’elle accepte les connexions. Je ne traiterai pas de l’aspect création d’un utilisateur avec des droits suffisant pour lire l’état de la base, je ne suis vraiment pas un expert, et j’imagine qu’on trouve de très bon tutos sur le net, expliquant bien chaque type de droit, et la manière de bien le faire. Vous pouvez soit chercher du côté de MS SQL Server Management Studio, soit effectuer les autorisations manuellement via le tuto du site de mssql_health_check.

Pour que la base accepte les connexions distantes de notre client FreeTDS, il faut d’abord s’assurer que le pare feu Windows laisse bien entrer les connexions TCP sur le port 1433, et que le serveur les accepte, lui aussi.

Pour se faire, il suffit d’utiliser l’utilitaire SQL Server Configuration Manager, installé par défaut avec la base de données, puis d’aller dans Configuration du réseau SQL Server 2005/Protocole pour [nom_base_données]/TCP/IP. Dans l’onglet Protocoles, choisir Oui pour la valeur Activer. Le serveur doit ensuite être redémarré pour que les modifications soient bien prises en compte.

Ouf… Il ne reste plus qu’à lancer vos sondes depuis Nagios, maintenant!

Installer 3 plugins Nagios dans EON (Eyes of Network) 1.2, coupé d’Internet, level 2

Wed, 08 Sep 2010 12:16:33 +0000

Maintenant que la première partie (check_esxi_wbem.py) s’est passée sans encombres, nous allons pouvoir passer à quelque chose d’un peu plus fun : check_esx3. Je rappelle que cet article n’est utile que pour les gens qui se tirent vraiment une balle dans le pied, en utilisant pour des raisons divers un Eyes Of Network 1.2 (EON) et qui n’ont pas accès à Internet sur leur machine de supervision.

Comme son nom l’indique, il s’agit d’un plugin Nagios pour superviser des produits VMware à partir de la version 3. Comme son nom ne l’indique pas, il s’agit d’un plugin en Perl. Joie et bonne humeur, CPAN.org nous voilà…

[Edit]Si vous avez une version de ce plugin antérieure à mai 2010, vous serez peut être heureux d’apprendre que la communauté à retravaillé ce script. Il semblerait que celui ci souffrait de redondances lors des requêtes. Après avoir jeté un œil aux remarques de la communauté, l’éditeur du script a effectué les modifications, et sur une machine peu performante, j’arrive à avoir des gains très significatifs entre les deux versions (2 secondes au lieu de 6 pour une sonde sur l’usage cpu/mémoire), ce qui la soulage beaucoup. Peut être que les gains ne seront pas aussi important pour des machines plus récentes, mais ça ne peut pas faire de mal de mettre ce plugin à jour…[/Edit]

Si vous êtes familier avec Perl, vous saurez que les scripts en Perl utilisent souvent des modules qui peuvent eux même dépendre d’autres modules, et ainsi de suite. Pour régler simplement ces problèmes de dépendance, il existe d’autres modules Perl qui permettent d’automatiser ce processus, en gérant récursivement les dépendances et en les téléchargeant sur Internet, un peu comme un gestionnaire de paquets. Seulement voilà, nous sommes offline, pas d’Internet sur notre serveur de supervision! Damnation…

Bon, commençons par le plus simple… Il arrive que ces modules Perl nécessitent des paquets rpm pour fonctionner. Ici c’est le cas pour notre script, qui nécessite au moins les outils suivants :

gcc
libxml2
libxml2-devel

Pour éviter de devoir se payer l’installation des dépendances des rpms à la main, je vous invite à vous reporter sur « l’astuce » du dépôt local de RPM, disponible ici.

Ça, c’est fait. Passons maintenant aux modules Perl nécessaires qui ne sont pas préinstallés sur notre EON 1.2 :

Nagios::Plugin
- Class::Accessor
- Config::Tiny
- Math::Calc::Units
- Params::Validate
  - Module::Build
    - ExtUtils::CBuilder
    - ExtUtils::Manifest
    - ExtUtils::ParseXS
    - TestHarness
  - Attribute::Handlers
VIPerlToolkit
- XML::LibXML
  - XML::SAX
- Class:MethodMaker
- SOAP::Lite
  - URI

Wa-hou… Sacrée liste… Vous aurez remarqué que j’ai respecté une hiérarchie entre les modules. Ce sont les niveaux de dépendances. Ainsi, XML::LibXML nécessite XML::SAX pour pouvoir fonctionner, et XML::SAX doit donc être installé avant XML::LibXML.
La plupart des modules Perl listés ci-dessus sont disponibles en téléchargement sur le site Internet CPAN.org, et le VI Perl Toolkit est disponible sur le site de téléchargement de VMware.

Je n’ai pas trouvé de moyen d’installer ces modules d’une seule commande sans passer par Internet. On aurait pu imaginer un genre de mécanisme de repository local, comme pour l’astuce avec Yum, qui se chargerait de tout installer d’un coup, où au moins une partie. J’ai quand même du mal à y croire et si quelqu’un à la solution, je serai très content d’avoir votre retour là dessus.

A la place, j’ai du installer un à un tous les modules en respectant l’ordre des dépendances. Comme si ça ne suffisait pas, la procédure pour installer un module Perl diffère selon le module d’installation que son développeur à choisit -_-.

Si vous trouvez un fichier Makefile.PL dans l’archive téléchargée, c’est que le module utilise le module Perl Makefile pour faire les installation :

# tar xvzf [module_perl].tar.gz
# cd module_perl
# perl Makefile.PL
# make
# make test
# make install

Mais si en revanche vous trouvez un fichier Build.PL, c’est que le module s’installe grâce au module Perl Module::Build (qui est d’ailleurs dans les listes des modules non présents de base dans EON)

# tar xvzf [module_perl].tar.gz
# cd module_perl
# perl Build.PL
# ./Build
# ./Build install

Deux possibilités : soit vous le savez, soit vous tâtonnez comme un idiot jusqu’à trouver les bonnes commandes. J’ai choisi la seconde solution, je vous le déconseille, donc…

Une fois tous les modules installés, il ne reste plus qu’à utiliser ./check_esx3 en temps qu’utilisateur nagios. Plus de détails sur l’utilisation de ce script franchement génial sur le site d’OP5.

La même chose avec un CentOS 5

Sur un CentOS classique (avec le DVD par défaut), la liste des dépendances manquantes sans Internet est malheureusement plus longue. Jugez par vous même

Builder-0.05
Nagios-Plugin-0.36
- Math-Calc-Units-1.07
- Config-Tiny-2.14
- Params-Validate-1.06
  - Module-Build-0.4001
    - ExtUtils-ParseXS-3.15
    - ExtUtils-MakeMaker-6.62
    - ExtUtils-Manifest-1.60
    - ExtUtils-CBuilder-0.280205
      - PathTools-3.33
      - IPC-Cmd-0.78
        
        Locale-Maketext-Simple-0.21
        
        Module-Load-Conditional-0.50
        
        Module-Load-0.22
        
        Module-CoreList-2.68
        
        Params-Check-0.36
        
        Perl-OSType-1.002
        
        Test-Simple-0.98
    - Test-Harness-3.25
    - Module-Metadata-1.000009
  - Class-Accessor-0.34
  - Attribute-Handlers-0.93
SOAP-Lite-0.714
- URI-1.60
Class-MethodMaker-2.18
XML-LibXML-2.0002
- XML-SAX-0.99
  - XML-SAX-Base-1.08
Module-Implementation-0.06
- Try-Tiny-0.11
- Test-Fatal-0.010
- Test-Requires-0.06
- Module-Runtime-0.013

Pour le fun, voici ma « procédure d’installation » hors ligne pour ce plugin (160 lignes, quand même !).

for i in `ls -1`; do tar xzf $i; done
/Builder-0.05
perl Makefile.PL
make
make install
cd ../ExtUtils-MakeMaker-6.62
perl Makefile.PL
make
make install
cd ../PathTools-3.33
perl Makefile.PL
make
make install
cd ../Test-Simple-0.98
perl Makefile.PL
make
make install
cd ../Perl-OSType-1.002
perl Makefile.PL
make
make install
cd ../Locale-Maketext-Simple-0.21
perl Makefile.PL
make
make install
cd ../Params-Check-0.36
perl Makefile.PL
make
make install
cd ../Module-Load-0.22
perl Makefile.PL
make
make install
cd ../Module-CoreList-2.68
perl Makefile.PL
make
make install
cd ../ExtUtils-Manifest-1.60
perl Makefile.PL
make
make install
cd ../Module-Load-Conditional-0.50
perl Makefile.PL
make
make install
cd ../IPC-Cmd-0.78
perl Makefile.PL
make
make install
cd ../ExtUtils-CBuilder-0.280205
perl Makefile.PL
make
make install
cd ../ExtUtils-ParseXS-3.15
perl Makefile.PL
make
make install
cd ../Attribute-Handlers-0.93
perl Makefile.PL
make
make install
cd ../Math-Calc-Units-1.07
perl Makefile.PL
make
make install
cd ../Config-Tiny-2.14
perl Makefile.PL
make
make install
cd ../Class-Accessor-0.34
perl Makefile.PL
make
make install
cd ../URI-1.60
perl Makefile.PL
make
make install
cd ../SOAP-Lite-0.714
perl Makefile.PL
make
make install
cd ../Class-MethodMaker-2.18
perl Makefile.PL
make
make install
cd ../XML-SAX-Base-1.08
perl Makefile.PL
make
make install
yum install libxml2 libxml2-devel
cd ../XML-LibXML-2.0002
perl Makefile.PL
make
make install
cd ../XML-NamespaceSupport-1.11
perl Makefile.PL
make
make install
#ou yum install perl-XML-NamespaceSupport.noarch
cd ../XML-SAX-0.99
perl Makefile.PL
make
make install
cd ../Test-Harness-3.25
perl Makefile.PL
make
make install
cd ../Module-Metadata-1.000009
perl Makefile.PL
make
make install
cd ../Try-Tiny-0.11
perl Makefile.PL
make
make install
cd ../Test-Fatal-0.010
perl Makefile.PL
make
make install
cd ../Test-Requires-0.06
perl Makefile.PL
make
make install
cd ../Nagios-Plugin-0.36
perl Makefile.PL
make
make install
cd ../Archive-Tar-2.02
perl Makefile.PL
make
make install
cd ../ExtUtils-Install-2.04
perl Makefile.PL
make
make install
cd ../Module-Build-0.4001
perl Makefile.PL
make
make install
cd ../Module-Runtime-0.013
perl Makefile.PL
./Build
./Build install
cd ../Module-Implementation-0.06
perl Makefile.PL
make
make install
cd ../Params-Validate-1.06
perl Build.PL
./Build
./Build install
yum install perl-Crypt-SSLeay.x86_64
cd ..
tar xzf VMware-vSphere-SDK-for-Perl-4.0.0-161974.x86_64.tar.gz
cd vmware-vsphere-cli-distrib/
perl Makefile.PL
make
make install
cd ..
#necessite aussi le module perl UUID (prérequis, pas optionnel) mais fonctionne quand même sans
tar xzf check_vmware_api-1aae4f6.tar.gz && check_vmware_api-1aae4f6

Installer 3 plugins Nagios dans EON 1.2, coupé d’Internet, level 1

Fri, 03 Sep 2010 12:47:18 +0000

J’aimerai vous faire partager certains de mes déboires pour installer 3 malheureux plugins Nagios sur mes deux EyesOfNetwork en production. Évidemment, dans un environnement bien maitrisé, connecté à Internet, ce serait risible d’écrire un article pour si peu. Malheureusement, EyesOfNetwork, surtout dans sa version 1.2, impose certaines limitations, et le fait d’être coupé d’Internet en impose encore plus.

Bon alors, c’est sûr, cet article ne va pas toucher beaucoup de monde. Le nombre d’utilisateurs d’EyesOfNetwork 1.2 (2.15 FTW!) dans un environnement offline ne doit pas atteindre des sommets, et la plupart de ces personnes-là sont probablement capables de se débrouiller seules. Mais bon, qui sait…

Comme vous le savez très certainement si vous avez décidé de lire la suite de cet article, Nagios, ou plutôt son cœur, a pour but d’ordonnancer une série de vérifications à effectuer sur votre matériel et les services qui en dépendent. Ces vérifications sont faites, non pas par Nagios lui-même, mais par une foultitude de petits scripts et autres outils (sondes, ou plugins).

Et c’est là toute la force de Nagios : Si un équipement ou un service un peu exotique n’a pas son plugin pré-installé avec Nagios, qu’à cela ne tienne! Un utilisateur de la communauté a probablement écrit un plugin lui correspondant. Et au pire, vous pouvez toujours en modifier un similaire si vos besoins ne sont pas satisfait, ou même en écrire un autre (en utilisant SNMP, une api spécifique au produit…).

Pour mes besoins personnels, j’ai voulu ajouter les trois sondes suivantes :

check_esxi_wbem.py (lien mort, j’utilise Internet Archive)) (vérification du hardware d’un serveur VMware ESXi)
check_esx3 (lien mort, j’utilise Internet Archive) (outils très complet pour superviser plusieurs variables tels que la charge CPU, mémoire, réseau, pour toutes les VMs, Serveurs, Fermes VMware)
check_mssql_health (lien mort, j’utilise Internet Archive) (sonde de vérifications diverses pour les bases de données Microsoft SQL Server 2000 ou mieux, utile pour la base MSSQL Express d’un petit vCenter, par exemple)

Dans ce premier article, le vais commencer simple, avec check_esxi_wbem.py, histoire de se mettre en jambe. Déjà, il peut être intéressant de savoir à quoi sert de plugin. Vous l’aurez surement remarqué si jamais vous disposez d’un serveur VMware, il existe un onglet dans le client vSphere (ou VI Client pour Infrastructure) qui permet de superviser en temps réel une série de paramètres hardware de votre serveur. Habituellement, on irait chercher ses paramètres en discutant aimablement avec le serveur en SNMP de l’hyperviseur (comme pour ESX, par exemple).

Cependant, (je ne sais pas si c’est une limitation complète ou juste pour la version gratuite), VMware à simplement désactivé le support de SNMP dans ESXi. Je dis bien « désactivé », car pour ceux qui connaissent un peu ou qui ont lu mes précédents articles, ESXi n’est en fait qu’une distrib Linux minimaliste (Busybox modifié), mais pas minimaliste au point de ne pas supporter SNMP ! Je n’ai pas essayé, mais les premiers liens dans Google pour la recherche « activer snmp esxi » vous indiqueront très certainement comment faire.

Bon… SNMP est désactivé, mais vSphere client arrive bien à avoir des informations, lui!?! Comment fait il ? Tout simplement comme tout le reste de ce qu’il fait : en utilisant l’API VMware pour donner des ordres aux hyperviseurs (création de VM, allumage/extinctions de VMs, du serveur, ajout d’un disque virtuel…).

Dans votre pseudo-console de configuration de ESXi (si si, l’espèce de mocheté, jaune et grise, après l’install!), vous aurez probablement déjà vu la ligne « Restart Management Agents ». Management agents fait référence à un démon (au sens Unix du terme, hein…) appelé hostd. En fait, ce n’est ni plus ni moins qu’un serveur web un peu spécial. Il est utilisé par le client vSphere pour commander le serveur ESXi via des requêtes HTTPS sur le port 8333. Mais là où ça nous intéresse, c’est que les outils vCLI et PowerCLI utilisent le démon, avec le même protocole. En théorie, il est donc possible de faire tout ce qu’on peut faire dans le client vSphere (dont le monitoring du hardware du serveur) en ligne de commandes.

Je vois déjà les yeux de tous les « scripteurs fous » s’allumer de désir. Calmez vos ardeurs, gens du monde du libre, la version non licenciée de ESXi (comprendre « gratuite ») est bridée aux actions en lecture seule pour tout ce qui est scripting. Oui, c’est très frustrant!

Relativisons cependant, pour lire l’état d’un serveur, « Lecture Seule » reste suffisant. En partant de ce principe, la communauté nous a pondu un script en python, qui nous permet de superviser le hardware nos ESXi! Cependant, pour fonctionner, ce script nécessite l’installation d’un module python complémentaire, que nous allons devoir télécharger depuis un autre réseau, puisque nous sommes offline sur notre EON 1.2! Le module à télécharger s’appelle pywbem. Une fois copié sur votre EON, l’installation est plutôt simple (d’où le level 1, il n’y a jamais de challenge au level 1).

# tar xvzf pywbem-[version].tar.gz
# cd pywbem-version
# python setup.py build
# python setyp.py install

Une fois ce module installé, le script peut être utilisé. Pour ceux qui débutent avec EON, l’ensemble des outils sont installés dans le répertoire /srv/eyesofnetwork/, ce qui n’est pas du tout un dossier d’installation « standard » pour la plupart des outils que nous voudront installer plus tard, d’où d’éventuels micmacs lors des installations. Le script check_esxi_wbem.py est donc à placer dans le dossier /srv/eyesofnetwork/nagios-[version]/plugins/.

Certaines personnes préfèrent séparer les plugins officiels (ceux fournit lors de l’install de Nagios) des plugins additionnels, et préfèrent les installer dans le dossier /srv/eyesofnetwork/nagios/libexec. A vous de décider une fois pour toutes, dès le début, puis de s’y tenir après. C’est vrai que c’est plus « propre », mais est-ce vraiment utile ?

Maintenant, vous pouvez admirer le résultat (il est préférable de tester le script avec l’utilisateur nagios, pour éviter les bêtes problèmes de droits) :

# su nagios
$ ./check_esxi_wbem.py [@IP_serveur_ESXi] [login_ESXi] [password_ESXi] [dell | hp]

Le dernier paramètre doit impérativement être dell ou hp, car le script ne gère que ces deux constructeurs (à l’heure actuelle), et va chercher des informations qui sont spécifiques au constructeur choisit.

Une fois que le retour de la sonde est correct

$ exit

Bon… pourquoi je râle ? Après tout, ce n’était pas si dur, juste un petit module de rien du tout à installer ! Rigolez si vous voulez, le prochain level ne sera pas aussi marrant…

Ah oui, pour finir, j’aimerais rappeler le petit tuyau d’Huggy :

Pour profiter de TOUTES les informations sur le hardware de votre serveur, votre ESXi (dans sa version 4, je ne suis pas trop sûr que ça soit encore exact) doit avoir être été installé avec la version de l’iso d’ESXi spécifique à votre constructeur.
Ainsi, pour un serveur HP, si vous avez la version « normale » d’ESXi 4.0 ou 4.0 U1, vous n’aurez par exemple pas l’état des disques du RAID, ce qui est dommage, vous en conviendrez.

Configurer Yum pour qu’il fouille ici plutôt qu’ailleurs (repository local)

Fri, 02 Jul 2010 14:01:28 +0000

Dans ma vie de tous les jours, installer des paquets compatibles avec ma version d’EyesOfNetwork (rappel: CentOS modifié) sans accès à Internet a été une petite souffrance. D’abord, vous êtes content quand vous avez trouvé qu’un paquet RPM pour CentOS (pour Red Hat Package manager) s’installe tout bêtement avec la commande « rpm -hiv [path_du_rpm.rpm] ». Après, vous vous amusez follement à installer les paquets qu’il vous manque un par un, en en trouvant par chance sur Internet qui ont la bonne version. Enfin ça c’est la méthode brutale. Ça marche, mais bon, ça marche surtout dans des cas simple avec des paquets pas trop regardant au niveau dépendances. Si jamais vous devez installer une version plus récente de la libxml sans aucun compilateur C, ça devient tout de suite un peu fastidieux…

Si comme moi vous êtes « heureux » de travailler offline, vous serez peut être quand même content d’apprendre comment installer des RPMs depuis un média quelconque (DVD de votre distrib, avec tous les paquets optionnels dessus, par exemple), comme si celui ci allait sur Internet.

Pas besoin d’être parfait pour être perfectionniste. Si vous voulez un tuto détaillé où qui fait tout bien dans les règles de l’art, vous trouvez probablement sur le web d’autres tutos écrit par des gens plus au point que moi (j’avais un lien à donner mais je n’arrive pas à le retrouver, bien sûr). Cela dit, ce que je propose est une méthode simple et efficace, et même si ce n’est pas tout à fait la même chose, le problème et la façon de le résoudre seront assez similaires.

Voyons donc plutôt une méthode rapide, sans entrer dans des considération trop techniques. Une fois l’ISO connecté (notamment dans le cas d’une machine virtuelle) ou le DVD inséré dans votre lecteur de galettes (EyesOfNetwork ou tout autre distrib utilisant Yum/des RPM), il faut le monter :

mount /dev/hdc /media/cdrom

Super! Maintenant que c’est fait, on va éditer les fichiers de configuration de Yum pour lui expliquer que le Net c’est mal. Pour cela, ouvrir avec votre éditeur de texte préféré (pour moi comme je suis en ssh ça sera VI, mais rien ne vous empêche de vous éclater avec sed et des regexp, si vous trouvez ça fun) /etc/yum.repos.d/CentOS-Base.repo, et pour chaque entrée (nom de dépôt délimité par [nom_dépôt]) ajouter enabled = 0 (ou modifier le cas échéant).

Maintenant que c’est fait, on va dire à Yum qu’il doit chercher localement en modifiant les lignes contenant enabled = 0 par enabled = 1 en éditant le fichier /etc/yum.repos.d/CentOS-Media.repo

Enfin, tapez

rpm-import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

Maintenant, vous pouvez tenter des « yum update », « yum install gcc », et tout s’installera en douceur. Ce très cher yum se chargera de vous débarrasser de cette tâche aussi harassante qu’inutile qui est de chercher à résoudre manuellement des dépendances entre paquets!

« Et là, le miracle s’accomplit »
« Ça vous épate hein? »
[Les inconnus - Jésus II, le retour]

Recyclage de plugins Nagios pour nourrir Cacti

Wed, 30 Jun 2010 17:39:13 +0000

Aujourd’hui j’aimerais revenir sur ce que j’aifaits, et ça va parler de Nagios et de Cacti. Je plante le décor…

Je suis censé finir la mise en place du monitoring des réseaux que j’administre. L’an dernier, mon prédécesseur avait fait une grosse partie de l’aspect c**ant dans le monitoring, créer les templates des équipements et des services qui vont bien, puis rentrer une à une toutes les machines. Pour ce faire, il a utilisé une distribution appelée EyesOfNetwork. En gros, il s’agit d’un frontend pour Nagios (principalement) qui se compose d’une distrib CentOS modifiée, d’un Lamp, d’un Mysql, d’un Nagios et d’un Cacti, le tout enrobé dans une interface graphique (plus ou moins pratique). Pour de plus amples informations je vous conseille d’aller jeter un œil ici.

J’ai pas mal bossé sur les divers plugins qui étaient utilisés par la communauté pour monitorer VMWare, notamment les VM et les hosts. En voici deux que je conseille tout particulièrement, même si j’ai pas mal galéré pour installer la multitude de dépendances offline (et oui, je travaille coupé du monde) et que d’autres plugins sont probablement très bien aussi :

check_esx3 pour avoir accès à tout ce qui est CPU, RAM, Disques, …
check_esxi_wbem.py (lien mort, j’utilise Internet Archive) pour les checks hardware

J’en parlerai probablement un peu plus une autre fois…

Bon, mais une fois que j’ai intégré avec succès ces plugins à mon Nagios préféré, je me suis penché vers le Cacti d’EyesOfNetwork pour générer mes beaux graphiques. Une fois que j’ai réussi à comprendre l’interface graphique de Cacti (ça m’a pris un peu de temps, mais une fois qu’on est tombé sur cette page de la documentation officielle (lien mort, j’utilise Internet Archive), et plus particulièrement sur la partie “data input methods”, rien ne peut plus vous arrêter, plus d’excuses), j’ai compris que j’allais devoir trouver un moyen simple d’adapter mes bons vieux plugins Nagios. Mais comment faire?

Pour ceux qui n’auraient pas totalement percuté où je veux en venir, je vais tout de suite mettre le doigt là où ça fait mal. Prenons l’exemple d’une bête vérification que va chercher la charge CPU de votre ESXi préféré :

Une sortie Nagios est de cette forme CHECK_ESX3 OK cpu_usage=33.33 % | cpu_usage=33.33%;80;90
Une sortie compatible avec Cacti c’est… 33.33

Mais WTF me direz vous ! Bon j’exagère un peu. On peut spécifier plusieurs sorties comme ceci « cpu_usage:33.33 mem_usage:2311 ». Toujours est il que c’est très moche et que l’on va devoir sortir notre boite à outils.

Ma première idée a été sed. Pourquoi sed? Pourquoi pas. Sur le moment ça m’a paru une bonne idée de juste donner à manger à Cacti le path de mon script Nagios. Bon même si je ne suis pas forcément très à l’aise avec les regexp, un petit bruteforce des possibilités envisageables m’a permis de me remettre dans le bain et de produire un truc correct qui marche notamment pour le script check_esx3 dans le cadre d’un appel à un serveur ESX(i) pour obtenir le « cpu usage »…

/usr/bin/perl <path_cacti>/scripts/ln-s_to_nagios/plugins/check_esx3 -H xxx.xxx.xxx.xxx -u user -p pass -l cpu -s usage | sed 's/.*=([0-9]*.[0-9]*).*/1/'

Il est très possible que cette solution ne soit pas la meilleure que l’on puisse trouver, mais j’étais content de moi, car dans mon shell, ça marchait très bien. Les experts qui me lisent sont en train de se dire « qu’il est naïf ! ». Effectivement… ça ne marche pas du tout. Je ne sais pas si c’est le lien symbolique ou le pipe qui bloque, mais cacti ne trouve pas ce qu’il faut, et enregistre misérablement un NaN toutes les 5 minutes.

Du coup, je me suis tourné vers ma 2ème passion dans la vie, et j’ai écrit un mini script perl dont le but ultime était d’appeler le script check_esx3, puis de récupérer la sortie et d’y appliquer la même regexp. Alors si vous voulez faire comme moi et que vous ne vous êtes pas trop demandé comme Cacti fonctionne, je vais vous épargner un petit moment « débogage en aveugle ».

En fait, Cacti utilise le cron pour ordonnancer toutes les 5 minutes ses checks, et c’est bien normal si on y réfléchit un peu. Du coup, le cron exécute avec l’utilisateur cacti, mais dans un tout autre contexte que le contexte courant. Au début naïvement j’avais écrit un script du genre :

#!/usr/bin/perl
$res = `./check_esx3 blablabla`;

« Ça n’est pas du tout la bonne réponse ! » Il faut absolument mettre des chemins absolus, et ne pas utiliser de liens symboliques. Une fois que vous aurez respecté ces indications, vous devriez pouvoir adapter vos scripts préférés pour qu’ils soient compatibles Cacti.

Juste un p’ti lien vers un script qui marche pour l’exemple cité dans l’article ici.

Un dernier questionnement : est ce que le mieux ça ne serait pas d’utiliser le module PNP pour Nagios, plutôt que de multiplier inutilement vos checks (et d’adapter vos scripts)? A suivre.