Perl on Zwindler's Reflection

NaviSecCLI pour piloter ses baies EMC² VNX depuis Linux

Tue, 18 Apr 2017 11:35:31 +0000

NaviSecCLI : à quoi bon snapshoter nos LUNs si on ne peut pas le scripter ?

Lorsque j’ai intégré mes premières baies EMC² VNX (lien mort, pas dispo sur Internet Archive) 5300 en 2012, on m’a présenté les avantages de la baies (et notamment la possibilité de réaliser des clones et des snapshots comme toutes les autres baies) , la première chose que j’ai demandé c’est « Oui mais est ce qu’on peut le scripter ». Et heureusement la réponse a été « Oui avec NaviCLI » (ou la version « sécurisée » NaviSecCLI).

Note : Vous connaissez peut être NaviCLI (la CLI Navisphere) disponible sur les CLARiiON, sachez qu’elle a été remplacée par NaviSecCLI. La version non sécurisée ne fonctionnera pas sur les VNX mais rassurez vous, les commandes sont identiques !

Quelques exemples de ce que j’avais en tête et que nous avons mis en production assez rapidement :

Créer un script permettant de disposer d’une préproduction ISO-prod en terme de données, rafraichie toutes les semaines tout en limitant l’interruption pour la production ET la préproduction. Ce script par une brève coupure de la base de données de production pendant une fenêtre de maintenance, créé un snapshot de baie et monte la préproduction dessus
Créer un script Nagios pour vérifier qu’il reste des RLP (Reserved LUN Pool) pour que les snapshots de la préproduction ne se bloquent pas en cas d’écriture intensive côté production (ou préproduction)
…

Le but de cette procédure est de lister les étapes permettant d’installer la NaviSecCLI sur un serveur Redhat Entreprise Linux.

Installation

Pour une installation de la CLI sous Redhat, EMC² propose un RPM (c’est sympa de leur part). Enfin bon, encore faut il le trouver ! EMC² a vraiment du travail à faire pour simplifier la recherche de fichiers sur leur site… Je ne me risquerais pas à vous fournir un lien, j’ai peur qu’il ne soit pas valide longtemps. Sachez qu’il faut trouver un fichier du type « NaviCLI-Linux-64-x86-xxx.rpm ».

yum install NaviCLI-Linux-64-x86-en_US-7.32.0.5.54-1.x86_64.rpm #version compatible sur les RHEL 5
yum install NaviCLI-Linux-64-x86-en_US-7.33.3.0.72-1.x86_64.rpm #version nécessaire pour les RHEL 6

Normalement, le RPM est assez basique et il y a peu de chance que l’opération échoue. Une fois installé, il faut ensuite sélectionner le niveau de sécurité que l’on souhaite appliquer sur le serveur en question. Pour être parfaitement honete, je ne suis pas complètement certain de comprendre les différence entre les deux niveaux proposés (moyen ou élevé). J’imagine qu’il s’agit probablement de paramètres disponibles pour assurer de la rétrocompatibilité avec des matériels plus anciens.

/opt/Navisphere/bin/setlevel_cli.sh

Il faut ensuite rajouter des variables d’environnement dans le fichier .profile de l’utilisateur que l’on souhaite utiliser pour lancer les scripts. Voici les lignes à intégrer dans un fichier (type .bashrc par exemple si l’utilisateur utilise bash comme interpréteur de commandes)

PATH=/usr/sbin:$PATH:/sbin:/home/root:/opt/Navisphere/bin
SHLIB_PATH=$SHLIB_PATH:/opt/Navisphere/lib/seccli
NAVI_SECCLI_CONF=$NAVI_SECCLI_CONF:/opt/Navisphere/seccli

Enfin, toujours sur le même utilisateur, il faut initialiser un fichier de sécurité (certificat) qui permettra de ne pas spécifier en clair les mots de passes des baies (dans un script, par exemple) à chaque utilisation

naviseccli -user admin_de_la_baie -password passwordpassecure -scope 0 -AddUserSecurity

Pour tester si NavisecCLI peut adresser la baie sans mettre le user/password. Le contrôleur interrogé renverra des informations :

naviseccli –h 10.1.1.10 getagent

Aller plus loin

Et bien maintenant il ne vous reste plus qu’à écrire vos scripts ! L’ensemble des commandes disponibles sont listées dans ce guide d’utilisation disponible sur le site d’EMC (lien mort, j’utilise Internet Archive).

Si vous voulez un exemple de script utilisant la NaviSecCLI pour surveiller le nombre de RLP encore disponible et compatible avec Nagios, je vous invite sur mon Github check_emc_rlp.pl.

Utiliser le gestionnaire d’extension Perl CPAN derrière un proxy

Wed, 29 Mar 2017 12:00:26 +0000

Aaaah, CPAN, un vrai bonheur

Ceux qui me suivent savent que, bien qu’il m’arrive d’utiliser Perl de temps en temps (et même de coder un peu de Perl, ce qui m’a fait acheter Learning Perl et Programing Perl de chez O’Reilly), je passe surtout la plupart de mon temps à pester contre le CPAN (voir cet article où je détaille entièrement comment installer un simple plugin Nagios sans accès à Internet).

Car CPAN et les modules/dépendances Perl, c’est bien, mais c’est quand même mieux quand on a accès à Internet !

Pas d’Internet dans mon DC (ou presque)

Il n’est pas rare que je n’ai pas accès à Internet lorsque j’installe un serveur, et c’est généralement dans ce genre de cas qu’on essaye de trouver des bidouilles.

Par exemple, dans les DC qui n’ont accès qu’à un proxy avec authentification NTLMv2 (Microsoft), je n’hésite pas à installer cntlm (ou avant ntlmaps). C’est crade, mais ça me permet d’avoir mon proxy pour Yum, wget, etc… qui ne seraient pas (ou mal) gérés autrement. Et ça m’a sauvé bien des fois !

Dans le cas qui nous concerne dans cet article sur CPAN, j’ai découvert avec stupeur qu’il existe un « shell » CPAN, auquel on peut tout simplement ajouter une configuration particulière, notamment pour lui donner un proxy !

Voilà de quoi régler une partie de mes problèmes !

Pour activer le shell CPAN, deux méthodes (similaires) :

perl -MCPAN -e shell
#ou
cpan

Configurer le proxy pour CPAN

o conf init /proxy/
If you're accessing the net via proxies, you can specify them in the
CPAN configuration or via environment variables. The variable in
the $CPAN::Config takes precedence.
<ftp_proxy>
Your ftp_proxy? [] @IP:<port>
<http_proxy>
Your http_proxy? [] @IP:<port>
<no_proxy>
Your no_proxy? [] @IP:<port>
Please remember to call 'o conf commit' to make the config permanent!

Et comme nous sommes disciplinés, nous n’oublierons pas d’enregistrer les modifications avec la commande indiquée plus haut

o conf commit

Désactiver le proxy

o conf no_proxy 1

Et on sauvegarde !

o conf commit

Bonus track : forcer le proxy HTTP plutôt que FTP

Je me suis retrouvé avec CPAN qui essayait à un moment donner de passer par FTP pour télécharger les packages alors que je n’avais qu’un proxy HTTP. Et pour ce problème particulier, je suis tombé sur cette page sur serverrfault qui donne quelques clés pour s’en sortir :

Simplest way of having it not use FTP is to shove HTTP URLs on the front of your urllist - or replace it completely like sebastionopilla said.

Pour afficher les URLs utilisées

o conf urllist
urllist
0 [http://example.org/]
1 [http://example.org/]
2 [http://example.org/CPAN/]

Exclure une URL de la configuration (un miroir par exemple)

o conf urllist unshift http://example.org/here/

Pour tout vider

o conf urllist -
o conf urllist shift

Source : serverfault.com/questions/130690/force-cpan-to-download-via-http/292696

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

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.