Logiciel de gestion du matériel pour un club de plongée

J'ai commencé depuis quelques temps à faire de la plongée (j'en avais fait un petit peu il y a très longtemps mais j'avais arrêté pendant pas mal de temps). A cette occasion j'ai passé une formation de technicien TIV (technicien d'inspection visuelle) afin d'aider mon club dans les inspections des bouteilles.

Pour les non-initiés, le travail d'inspection consiste - comme son nom l'indique - à inspecter l'intérieur des bouteilles de plongée une fois par an. L'opération se fait en vidant ces dernières de leur air (il vaut mieux !), suivi d'un démontage de la robinetterie pour enfin accéder à l'intérieur de la bouteille. De là, l'inspecteur doit regarder s'il y trouve d'éventuel défaut (rouille, état de la robinetterie etc.).

En France, la législation qui entoure tout ça est relativement rigoureuse (heureusement d'ailleurs !) et vous devez impérativement procéder à une ré-épreuve tous les deux ans (pour un particulier) ou tous les cinq ans (dans le cadre d'un club de plongée). Cette opération de ré-épreuve est confiée à des organismes habilités et consiste à soumettre la bouteille à 1,5 fois ça pression de service (ie 300 bars de pression de réépreuve pour une bouteille de 200 bars). Par ailleurs, cette opération ne se fait pas avec du gaz (risque d'explosion en cas de rupture de l'enveloppe de la bouteille) mais avec un liquide.

Dans le cas d'un club, ces ré-épreuves toutes les 5 ans sont donc conditionnées par au moins une inspection visuelle annuelle pour s'assurer qu'aucun problème de corrosion grave n'est en train d'apparaître pendant ce laps de temps.

Bref, vous l'avez deviné, il faut gérer un stock de bouteille et s'assurer qu'aucune n'a été oubliée et surtout ne pas oublier de passer les bouteilles en ré épreuve tous les cinq ans.

Bref, quand j'ai voulu donner un coup de main sur ce sujet, je me suis rendu compte que le club n'avait rien pour le faire automatiquement (seulement une feuille de tableur et des papelards).

Je me suis donc mis en recherche d'une solution et c'est à cette occasion que j'ai constaté qu'aucun logiciel libre n'existait sur le marché pour ce type de besoin (il existe une seule application mais qui se base sur OpenOffice et qui se présente sous la forme d'un binaire pour Windows).

Comme il se trouve que j'ai eu un peu de temps libre pendant cette été, j'ai proposé à mon club d'en faire une petite application Web à base de PHP/MySQL. Je viens donc aujourd'hui vous en faire part pour ceux que ça pourrait intéresser. L'application est téléchargeable à l'adresse suivante : http://code.google.com/p/gestion-bloc-tiv/downloads/list

Concernant l'installation du logiciel en lui même, plutôt que de me répéter, je préfére vous renvoyer directement aux instructions originales : http://code.google.com/p/gestion-bloc-tiv/source/browse/trunk/tiv/README (je vous rassure, c'est relativement simple : import d'un schéma + modification de deux fichiers).

L'interface du logiciel en lui même est relativement simple et n'est pas protégé. Je vous recommande d'ailleurs de faire appel à des fichiers .htpasswd et .htaccess afin de ne pas trop laisser ces données accessibles à tout un chacun (c'est quand même des informations relativement sensible).

Elle se présente sous la forme d'onglet :

• Accueil vous donnera un résumé des blocs ayant besoin d'une réépreuve ou d'une inspection visuelle ;
• Administration vous permettra de procéder à la création de nouveaux objets dans votre base (bloc, détendeur, inspecteur TIV etc.) ;
• Matériel vous permettra de consulter votre matériel ;
• Personnes / inspecteurs TIV vous donnera un accès aux personnes et inspecteurs du club ainsi qu'aux prêts en cours ;
• En fin l'onglet Status des blocs vous donnera une vision de vos différents blocs.

Le reste de l'interface reste relativement simple (à mes yeux) : vous cliquez sur les éléments qui vous intéressent, vous modifiez, vous appuyez sur le bouton modifier et voilà.

Une partie relativement intéressante vient dans l'onglet Administration (section préparation d'un TIV) puisque vous pourrez depuis ce point procéder à la création des fiches TIVs nécessaire à votre inspection. Vous pourrez à cette occasion récupérer un fichier PDF que vous pourrez imprimer (et éventuellement stocker dans un coin) et qui fera une pré-affectation des tous les blocs aux différents inspecteurs TIV dans votre club.

L'application en est pour l'instant à la 0.2 (téléchargement par ici) et je n'ai pas prévu de faire de gros ajout. Les retours et demandes d'évolution seront les bienvenues.

Pour info, elle a été testée sur Ubuntu et l'hébergeur 1and1.

Sur ceux, bon TIV !

Thruk une alternative à l'interface Web de Nagios

Il était une fois un moteur nagios ...

Si comme moi vous avez été amené a mettre en oeuvre plusieurs nagios, vous avez sûrement dû vous frotter a son interface Web a base de cgi et de fichier plat exporter toutes les 10 secondes.

Ne crachons pas dans la soupe, cette interface reste très bien pour une petite installation.

Malheureusement, avec l'évolution des besoins en supervision, il devient de plus en plus difficile de se contenter de cette interface. En vrac, on va donner les éléments suivants :

• Interface vieillissante qui (en dehors des nouveaux CSS des dernières version de nagios) n'a plus évolué depuis de nombreuses années ;
• Nécessité d'héberger les CGI sur la même machine que le moteur nagios ;
• Overhead d'écriture du fichier status.dat ;
• Désynchronisation de l'interface avec le moteur nagios (pour lancer un test immédiat - même dans le cas d'un test très court - l'interface vous rend la main tout de suite et vous devez attendre le lancement du test + le temps de rafraîchissement du fichier status.dat) ;
• Explosion des temps de réponse dans le cas d'une grosse installation ;
• Dans le cas où vous auriez plusieurs nœuds nagios, vous devez vous connecter sur la bonne interface pour consulter votre serveur.

Origine de Thruk

Thruk est donc un projet qui a démarré sur ce constat afin d'offrir une alternative sans pour autant dérouté complètement les utilisateurs en reprenant - dans les grandes lignes - l'aspect de l'ancienne interface. En réalité, cette interface apporte des améliorations très intéressantes par rapport à l'ancienne interface avec notamment les points suivants :

• Possibilité de déporter l'interface de consultation sur un serveur distant ;
• Possibilité de fédérer plusieurs noeuds nagios dans la même interface ;
• Compatibilité avec n'importe quel moteur du moment que ce dernier supporte Livestatus (Shinken, Icinga, centreon engine, check_mk).

Quelques pré-requis de fonctionnement

L'installation de Livestatus se fait en rajoutant un broker à votre moteur nagios. Pour plus de détail, vous pouvez vous reporter à l'article suivant : setting up and using Livestatus. A noter que check_mk et Shinken viennent nativement avec ce support.

Autre point, dans le cas d'un accès déporter, il sera peut-être nécessaire de mettre en place un outil vous permettant d'exposer votre socket Unix sur le réseau. La documentation officiel fait appel à l'outil Unixcat (qui vient avec nagios). Pour ma part, j'ai préféré utiliser l'outil socat qui m'a donné des connexions plus stable et plus rapide. Ci-dessous un exemple de commande pour lancer socat :

socat TCP-LISTEN:1958,interface=lo,reuseaddr,keepalive,nodelay,fork,crnl \
      UNIX-CLIENT:/var/lib/nagios3/rw/live,keepalive

Installation de Thruk

Le gros défaut de Thruk est tout de même la ribambelle de plugin perl CPAN qu'il a comme dépendance. Heureusement, l'auteur du plugin propose un package tout prêt pour la plupart des plateformes disponibles (Debian, RedHat, Ubuntu, etc.). Pour se faire, il faut se rendre sur la page de téléchargement du projet, choisir le package qui vous convient et procéder à l'installation du package.

A noter que le produit a tout de même besoin de quelques dépendances au niveau système (plugin fastcgi pour apache notamment). Il faudra donc bien penser à installer ces dernières sous peine d'avoir des erreurs au moment de l'installation du package.

Une fois l'installation terminée, Thruk va créer un fichier htpasswd avec comme administrateur par défaut thrukadmin (mdp thrukadmin). Dans le cas où vous auriez déjà un fichier de mot de passe, bien penser à modifier le fichier /etc/apache2/conf.d/thruk.conf afin de pointer sur le bon. Bien penser également à modifier le fichier /etc/thruk/cgi.cfg dans ce cas là afin de définir les droits adéquates.

Enfin, il vous faudra  modifier le fichier /etc/thruk/thruk_local.conf afin de pointer sur votre noeud de supervision. Ci-dessous un exemple d'interfaçage avec un moteur Shinken :

######################################
# Backend Configuration, enter your backends here
<Component Thruk::Backend>
  <peer>
      name   = Shinken
      type   = livestatus
      <options>
          peer    = 127.0.0.1:50000
     </options>
  </peer>
</Component>

Un petit arrêt/relance du serveur apache et nous devrions être en mesure d'utiliser Thruk.

Tour du propriétaire

Connectez-vous sur l'interface Thruk (http://MONSERVEUR/thruk/). On devrait vous demander un mot de passe (thrukadmin/thrukadmin par défaut).

Au premier lancement, vous devriez avoir à attendre quelques secondes (ce comportement est normal puisque apache va devoir instancier les process fastcgi de Thruk à ce moment là). Ce délais d'attente passé, vous devriez arriver sur l'interface de Thruk. Par la suite, les process étant déjà là, vous n'aurez pas ce temps d'attente.

Comme indiqué un peu plus haut, l'interface est quasi la même que celle des CGIs si on exclue la map graphique (mais elle est avantageusement remplacé par une grille qui est plus fonctionnelle).

Du côté des améliorations, on peut noter les points suivants :

• Champ de recherche plus efficace (utilisation d'ajax pour vous proposer des solutions lors de le champ de recherche avec proposition de choix de hostgroup, nom des services et bien sûr machine) ;
• Lors du lancement d'un test, l'interface se bloque tant que le moteur nagios n'a pas récupéré le résultat du test (plus besoin de faire de rafraîchissement) ;
• Intégration des graphiques de PNP ;
• Présence de lien permettant des exports au format Excel (je sais, je suis pas forcément fan mais c'est quand même pratique).

Globalement, l'interface est plus jolie, plus réactive et vous avez également d'autres raffinements auxquels je ne pense pas forcément (générateur de rapport, gestion de la conf etc.).

Bref, comme dirait l'autre, l'essayer c'est l'adopter !

Plugin de suivi des PDUs

Il y a peu de temps de ça, j'ai eu à mettre en place un suivi des PDUs (Power Distribution Unit) pour un de mes clients. En faisant bien attention de ne pas réinventer la roue, je me suis donc appuyé sur le script développé par boreal labs (http://www.boreal-labs.com/joomla/index.php/en/downloads-menu/view.download/18-pdu/9-checkpwnetrpduload.html). Ci-dessous un petit exemple d'exécution de ce dernier :


./check_pwnet_rpdu_load.pl -H 192.168.0.1 -C public -b 1,2 -m A -w n,12 -c 16,o
PWNET_RPDU_LOAD OK - PDU 'PDU-IT-R5-A' bank #1 load = 3.3A; bank #2 load = 0.0A; | PDUBank1Load=3.3A;13.0;16.0;0;16 PDUBank2Load=0.0A;12.0;16.0;0;16


Une fois intégré dans nagios, mon ami PNP a commencé à produire le résultat suivant :

Seulement voilà, certains PDUs avaient un capteur de température/humidité et j'avais besoin de faire un suivi là dessus. C'est donc à cette occasion, j'ai écrit un script permettant de remonter ces informations. Ce script est disponible à l'adresse suivante : http://code.google.com/p/plugin-nagios-yannig/source/browse/trunk/pdu/check_pdu_sensors.pl

Il vous faudra récupérer la mib du constructeur (le fichier powernet405.mib) et le rendre disponible à snmpwalk (en renseignant son emplacement avec la variable d'environnement MIBDIRS par exemple). Ci-dessous un exemple de test de communication :


./check_pdu_sensors.pl -H 192.168.0.1 -C public 
Temperature/Humidity sensor status is OK - temperature = 22.4°C, humidity = 56%|temperature=22.4 humidity=56%


Ce dernier va vous renvoyer la température et/ou l'humidité (fonction du type de capteur sur votre matériel) à un instant T de votre PDU. Le résultat prend la forme suivante :

J'ai ensuite intégré tout ceci dans nagios et l'ami PNP a commencé à produire des graphiques assez sympas. En voici ci-dessous un petit exemple de suivi sur 2 semaines de l'humidité :

Mise en place selenium

Ces derniers temps, on m'a demandé de mettre en place de scénario de surveillance sur une application typiquement horrible : code HTML horrible, Internet Explorer only etc.

Bref, j'ai donc commencé à vouloir faire ça en cucumber mais je me suis rapidement frotté à des problèmes mon cher concombre masqué refusant catégoriquement mes noms de formulaires fantaisiste (il faut dire qu'on trouve des dollars ('$') dedans ...).

Bien triste, j'ai commencé à chercher quelque chose d'autre qui pourrait répondre à mon besoin et je suis tombé sur selenium (http://seleniumhq.org/) et son IDE (qui est une simple extension à installer dans firefox).

J'ai commencé à faire joujou avec l'IDE et - malgré un rendu HTML catastrophique - j'ai réussi à faire un scénario de test avec Firefox.

En trifouillant un peu, j'ai vu qu'il existait un serveur selenium (un process java) et qu'il pouvait tourner dans un serveur X virtuel. Devant tant de beauté, j'ai donc commencé à mettre ça en place :D.

Pré-requis python

Comme par la suite je vais générer des scripts au format python, nous allons devoir installer la librairie python permettant de communiquer avec selenium. Ici, rien de bien compliqué, un coup de apt-get pour installer le nécessaire :

apt-get install python-pip python-dev build-essential

Maintenant que nous avons pip, nous pouvons procéder à l'installation de la librairie selenium :

pip install -U selenium

Passons maintenant à la suite (et y'a du monde !)

X11 Virtual frame buffer (miam !)

Ce cher Xvfb ! Toujours un petit moment émouvant quand je le croise ! Pour le lancer, il faut simplement utiliser la ligne de commande suivante :

DISPLAY=:1 Xvfb :1 -screen 0 1024x768x24

Bien penser à le rendre utilisable depuis n'importe où avec la commande xhost :

DISPLAY=:1 xhost +

ATTENTION : L'utilisation de xhost + va rendre le serveur X visible depuis l'extérieur !!! Il est conseillé de mettre en place un parefeu pour bloquer les accès externes.

L'installation se fait avec un apt-get install xvfb (et x11-server-utils pour disposer de l'utilitaire xhost)

Installation de Firefox

Par la suite, nous utiliserons firefox pour faire nos tests. Donc rien de bien fameux si ce n'est un apt-get install firefox (à remplacer par iceweasel si vous êtes sur Debian).

Mise en place de Selenium

On arrive enfin au coeur du sujet. Selenium est un serveur qui s'appuie sur un jar java pour se lancer. Donc de manière logique, il va vous falloir un java fonctionnel. Je vous passe les détails, vous faîtes comme vous voulez.

Récupérer ensuite la dernière version de selenium serveur sous la forme d'un JAR. Vous pouvez ensuite le lancer avec la ligne de commande suivante :

export DISPLAY=:1
java -Djava.security.egd=file:/dev/./urandom \
     -jar /path/to/jar/selenium-server-standalone-2.25.0.jar \
     -browserSessionReuse

A noter la présence de l'option -browserSessionReuse qui permet d'éviter de relancer le navigateur à chaque lancement de scénario et l'option biscornu java.security.egd qui permet de passer du device aléatoire /dev/random (qui est lent) à /dev/urandom qui lui n'utilise pas l'entropie du système pour fonctionner mais un générateur de nombre aléatoire.

Test de notre premier scénario

À l'aide de l'IDE selenium, nous avons enregistré notre scénario. Nous allons maintenant exporter ce dernier au format Python 2 / unittest / Remote Control. Voici ce à quoi ça devrait ressembler :

from selenium import selenium
import unittest, time, re

class sites(unittest.TestCase):
    def setUp(self):
        self.verificationErrors = []
        self.selenium = selenium("localhost", 4444, "*chrome", "http://monsite/")
        self.selenium.start()
    
    def test_sites(self):
        sel = self.selenium
        sel.open("/ma_page")
        sel.type("id=un_champ", "une_valeur")
        sel.type("id=un_autre_champ", "une_autre_valeur")
        sel.click("id=id_d_un_lien")
        sel.wait_for_page_to_load("30000")
    
    def tearDown(self):
        self.selenium.stop()
        self.assertEqual([], self.verificationErrors)

if __name__ == "__main__":
    unittest.main()

Lançons maintenant ce beau script depuis la machine faisant tourner selenium :

python mon_scenario.py
.
----------------------------------------------------------------------
Ran 1 test in 4.051s
OK

Magnifique non ? Tout à fait mais ça ne vous dit pas ce que vous allez en faire dans votre nagios.

(Des)intégrations dans nagios/Shinken

Comment ça, vous voulez le script qui analyse la sortie de tout ça et l'insert directement dans nagios ? Je vous trouve un peu exigeant quand même !

Bon, si vous insistez ... Il faut récupérer le script check_selenium.pl et lancer ensuite la sonde de la manière suivante :

/emplacement/scripts/check_selenium.pl --script \
      /emplacement/de/mon/scenario.py  \
      --label "Le test de ma super application"

De là, vous devriez obtenir la sortie suivante :

Selenium test OK (Le test de ma super application)|time=3.180s test_count=1

Elle est pas belle la vie ?

Suivi des interfaces d'un switch CISCO sous Nagios/Shinken

Depuis quelques jours, je travaille sur la mise en place d'un Shinken chez un client. A cette occasion, on m'a demandé de faire un suivi des switchs de la boîte et notamment le débit de chaque port.

Comme je suis quelqu'un de relativement paresseux (je n'avais pas trop envie de me déclarer les 48 ports des 200 switchs à la main). J'ai donc rapidement pensé à un script qui me permettrait de déclarer automatiquement ces surveillances. Et comme je suis un mec super sympas qui adore raconter sa vie, je vais vous en faire profiter bande de veinards !

Pour se faire, nous allons utiliser les MIBs SNMP des switchs CISCO qui ont la bonne idée de proposer tout un tas de chose vachement intéressante (oui, enfin ... pour un administrateur d'outils de surveillance). Nous allons voir notamment l'OID 1.3.6.1.2.1.2.2.1.2 qui va nous renvoyer la liste des interfaces du switch :

$ snmpwalk -c ecalyptus -v 2c 10.1.1.1 1.3.6.1.2.1.2.2.1.2
iso.3.6.1.2.1.2.2.1.2.1 = STRING: "FastEthernet1"
iso.3.6.1.2.1.2.2.1.2.2 = STRING: "TenGigabitEthernet1/1"
iso.3.6.1.2.1.2.2.1.2.3 = STRING: "TenGigabitEthernet1/2"
iso.3.6.1.2.1.2.2.1.2.4 = STRING: "TenGigabitEthernet1/3"
iso.3.6.1.2.1.2.2.1.2.5 = STRING: "TenGigabitEthernet1/4"
iso.3.6.1.2.1.2.2.1.2.6 = STRING: "GigabitEthernet3/1"
iso.3.6.1.2.1.2.2.1.2.7 = STRING: "GigabitEthernet3/2"
iso.3.6.1.2.1.2.2.1.2.8 = STRING: "GigabitEthernet3/3"
iso.3.6.1.2.1.2.2.1.2.9 = STRING: "GigabitEthernet3/4"
iso.3.6.1.2.1.2.2.1.2.10 = STRING: "GigabitEthernet3/5"
iso.3.6.1.2.1.2.2.1.2.11 = STRING: "GigabitEthernet3/6"
iso.3.6.1.2.1.2.2.1.2.12 = STRING: "GigabitEthernet3/7"
iso.3.6.1.2.1.2.2.1.2.13 = STRING: "GigabitEthernet3/8"
iso.3.6.1.2.1.2.2.1.2.14 = STRING: "GigabitEthernet3/9"
iso.3.6.1.2.1.2.2.1.2.15 = STRING: "GigabitEthernet3/10"
[...]

Nous allons nous servir de cette sortie pour générer notre surveillance. Pour cela, nous allons utiliser le script perl suivant :

#!/usr/bin/perl
use strict;

open(MODEL, "modele.txt");
mkdir("modeles") if(!-d("modeles"));
while() {
  chomp();
  my($modele, $ip) = split(/;/);
  my @interfaces = `snmpwalk -c ecalyptus -v 2c $ip 1.3.6.1.2.1.2.2.1.2`;
  open(MODEL_CFG, ">modeles/switch-$modele.cfg");
  foreach(@interfaces) {
    if(/iso.3.6.1.2.1.2.2.1.2.(\d+) = STRING: "(.*Ethernet.*)"/) {
      my ($id, $interface) = ($1, $2);
      print MODEL_CFG "define service {
  hostgroup_name       $modele
  use                  generic-service
  service_description  $interface
  check_command        check_port_usage!$id!6000!8000
}
\n";
    }
  }
  close(MODEL_CFG);
}
close(MODEL);

Ce script attend en entrée un fichier de paramètre (modele.txt) et nous donne en sortie des fichiers de configuration au format nagios dans le sous-répertoire modeles. Il nous reste maintenant à prendre ces fichiers et les intégrer dans la configuration de notre nagios/Shinken.

Ci-dessous un exemple de surveillance sur un switch CISCO (du type WS-C2960-24PC-L) :

define service {
  hostgroup_name       WS-C2960-24PC-L
  use                  generic-service
  service_description  FastEthernet0/1
  check_command        check_port_usage!10001!6000!8000
}
[...]
define service {
  hostgroup_name       WS-C2960-24PC-L
  use                  generic-service
  service_description  GigabitEthernet0/2
  check_command        check_port_usage!10102!6000!8000
}

Il reste ensuite à déclarer un hostgroup ad-hoc avec un template de serveur comme suit :

define hostgroup{
  hostgroup_name  WS-C2960-24PC-L
  alias           Switchs Cisco WS-C2960-24PC-L
}

define host {

  name            switch-WS-C2960-24PC-L

  use             generic-switch

  alias           Ensemble des switchs Cisco WS-C2960-24PC-L

  hostgroups      Switch,WS-C2960-24PC-L

  icon_image      vendors/cisco.png

  register        0

}

Et nous pouvons déclarer maintenant des switchs utilisant le template switch-WS-C2960-24PC-L. Ces derniers viendront directement avec la surveillance automatique de tous leurs ports.

Petit timelapse de fond étoilé

Ah ! La Corse. Super destination pour les vacances ! Des jolies plages, des paysages sauvages et surtout ... un ciel très clair avec très peu de pollution lumineuse. C'était donc le moment de sortir mon trépied avec mon appareil photo reflex équipé d'un timer pour commencer un petit timelapse ...

Ah oui, j'allais oublier, tout ceci sera réalisé à l'aide d'outil sous Linux. Dans l'ordre, j'utiliserai convert (de la suite ImageMagick), darktable et enfin mencoder.

Acquisition des photos

Première étape : prendre les photos du fond étoilé. Ici, je me sers d'un Canon EOS 550D avec un objectif 18-55 mm positionné sur grand angle (18mm), l'ouverture maximum (f/3.5), un temps d'exposition de 30" et une sensibilité très forte (trop ?) de 1600 voir 3200 ISO.

Pour éviter des problèmes de mise au point, j'ai également désactivé l'autofocus (qui sinon pédalerait dans la semoule pour faire le point) ainsi que le stabilisateur qui ici n'a pas d'utilité.

Petite astuce, pour faire le point, je vise une source lumineuse qui se trouve suffisamment loin (plus de 30m) afin de faire le point et je désactive à ce moment l'autofocus.

Pour en revenir à ce qui nous intéresse, sachez que certaines vidéos que vous verrez un peu plus loin représente la mise bout à bout de 400 à 600 clichés. A noter que pour que l'appareil puisse prendre autant de photo, j'utilise un grip qui contient deux batteries. Dans le cas où vous n'auriez qu'une seule batterie, vous ne devriez pouvoir prendre qu'environ 350 photos (avec une batterie neuve).

Bref, une fois que vous avez fait vos séances de photos, vous obtenez des images sympathiques mais très bruité du fait qu'il y ai peu de lumière. Ci-dessous un détail mettant en avant le bruit de la photo sans traitement :

Donc bof bof. On va voir comment réduire tout ça afin d'avoir quelque chose d'un peu plus uni avant d'en faire une vidéo de timelapse.

Post-traitement des photos

Comme nous l'avons vu, nous avons un bruit relativement important et nous allons essayer de réduire ce dernier à l'aide de l'outil darktable. Mais avant ça, afin de gagner du temps sur le post-traitement, nous allons tout d'abord réduire la taille de nos photos. En effet, nous travaillons sur des images qui seront ensuite utilisé dans une vidéo. Rien ne sert donc de travailler sur les images originales de l'appareil.

Réduire la taille des photos

Ici, rien de bien compliqué, il faut créer un sous répertoire du nom que vous voulez (ici, j'ai été très original en lui donnant le nom 'resize') et lancer la ligne de shell suivante :

mkdir resize && cd resize
for i in ../*.JPG; do   echo $i;   convert -resize 1440 $i $(basename $i); done

Vous attendez un petit peu et au bout de quelques minutes, vous devriez obtenir vos photos au format qui vous intéresse. A noter que rien ne vous empêche de procéder à une redécoupe de vos photos à l'aide de l'option -crop (ex : -resize 1920 -crop 1920×1080+0+10 pour retailler l'image au format d'une vidéo full HD 1920×1080 avec un offset de décalage de x=0, y=10).

Import des photos dans darktable

Maintenant que nos images sont retaillées, nous allons les importer dans darktable. Cette étape est assez longue et peut réclamer quelques minutes.

Vient ensuite le travail de trouver le bon filtre à appliquer sur mes images afin de supprimer au maximum ce bruit sans pour autant trop dénaturer notre image.

Application du filtre

Pour commencer l'édition d'une photo, il faut donc double-cliquer sur une image. Après quelques tâtonnements, je tombe sur le filtre de suppression de bruit (filtre bilateral) qui me donne des résultats intéressants (réglage : rayon = 30, rouge = 0.06, vert = 0.025, bleu = 0.026). Ci-dessous un exemple du résultat que j'obtiens sur une de mes photos.

Une fois que je suis satisfait de mes retouches sur une photo référence, je vais revenir en arrière (double clique sur la photo) et cliquer sur le bouton copier (sur la droite de l'écran de darktable) :

De là, je vais sélectionner l'ensemble de mes photos (Ctrl-A) et appuyer sur le bouton coller dans le même panneau de contrôle. Darktable se chargera ensuite d'appliquer cet effet à toutes les photos.

Développer les images

Après quelques temps, le logiciel me rend la main et je peux maintenant exporter mes photos au format que je veux. Je vais ensuite donner ça à manger à mon ami mencoder.

Ici, le développement se fait en cliquant sur le bouton exporter dans le panneau d'exportation (toujours sur la droite de l'écran de darktable) :

A noter au passage qu'il est possible de changer le nom des fichiers (dans le champ de saisie contenant $(FILE_DIRECTORY)/...) et que ce dernier sauvegardera nos fichiers en '.jpg' (l'appareil photo a ses photos originales en '.JPG').

Assemblage des photos afin de créer le timelapse

Ici, rien de bien sorcier, le lancement de la commande suivante devrait donner le résultat attendu :

mencoder "mf://*.jpg" -mf fps=25:type=jpg -ovc x264 -o timelapse.flv

Ne reste plus qu'à prendre votre lecteur de vidéo préféré pour apprécier le résultat !

Le résultat !

Comme je manque d'imagination, j'ai uploadé ces vidéos sur youtube. Mes vacances m'ont permis de réunir de la matière pour 3 timelapses :

• Le premier timelapse pris le 18 juillet 2012 entre 00h25 et 03h53 du matin.

• Le second pris le 18/19 juillet 2012 entre 23h35 et 5h30 du matin.

• Enfin le dernier pris le 26/27 juillet 2012 entre 23h17 et 6h20 du matin avec au début de la vidéo un coucher de Lune.

Et voilà ! Je n'ai plus qu'à vous souhaiter un bon timelapse à tous !

Création d'un point d'automontage pour backuppc

Suite à la mise en place d'un outil de sauvegarde (backuppc) pour un de mes clients, j'ai dû mettre en place un automonteur en direction d'un NAS. Comme j'ai un peu tâtonné, je me suis dit que ça ferait un petit article intéressant sur cette drôle de bête :)


Par la suite, je m'appuierai sur une Debian Squeeze mais rien n'empêche de transposer ces instructions sur une *ubuntu.


Vous pourriez vous poser la question du pourquoi de ce point d'automontage. Tout vient du fait que je n'avais pas de volumétrie suffisante pour mes sauvegardes sur la machine Linux. Comme je disposais d'un NAS, j'ai voulu stocker les fichiers de sauvegarde de backuppc dessus. Ainsi, pas de soucis de volumétrie et en cas de perte de la machine Linux, je n'ai qu'à recréer le point de montage du NAS sur un nouveau serveur et le tour est joué !


NB : je ne saurais trop vous conseiller de disposer d'un lien gigabit entre votre serveur Linux et votre NAS !


Deuxième question : pourquoi passer par un automonteur alors qu'il serait plus simple de modifier le fichier /etc/fstab ? Pour deux raisons :

• Éviter d'introduire une dépendance trop forte entre la machine Linux et le NAS ;
• Mais également pour fiabiliser mon infrastructure en cas de perte du NAS.

En effet, si jamais le NAS est indisponible au moment du démarrage du serveur Linux (ou plus tard suite à une rupture réseau), le fstab ne remontera pas automatiquement mon FS. Dans le cas de l'automonteur, ce montage se fait à la demande évitant les opérations manuelles.

Après ces quelques petites explications, passons maintenant à la mise en place de ce point d'auto-montage. Premier point, il faut installer l'automonteur avec la commande apt-get install autofs (si ça n'est pas déjà le cas).


De là, nous allons modifier le fichier /etc/auto.master afin d'y ajouter (à la fin du fichier) la ligne suivante :


[...]
/- /etc/auto.backuppc


Cette ligne sert à dire à l'automonteur que nous allons déclarer des points d'automontages supplémentaires dans le fichier /etc/auto.backuppc. C'est ce que nous allons faire en renseignant ce fichier avec la ligne suivante  :


/var/lib/backuppc -rw 192.168.xx.xx:/backuppc


Tout est en place mais avant de redémarrer l'automonteur, nous allons arrêter backuppc et renommer l'ancien répertoire :


/etc/init.d/backuppc stop
mv /var/lib/backuppc /var/lib/backuppc.orig


De là, redémarrons l'automonteur et vérifions que ce dernier a bien pris en compte la modification :


/etc/init.d/autofs restart
root@backuppc:/etc/backuppc# cd /var/lib/backuppc
root@backuppc:/var/lib/backuppc# df -k .
Sys. de fichiers      1K-blocs   Utilisé    Dispo. Uti% Monté sur
192.168.xx.xx:/backuppc
                     2879673344 1363423488 1516249856  48% /var/lib/backuppc

De là, recopions les données de l'ancien répertoire de backuppc :

rsync -av /var/lib/backuppc.orig/. /var/lib/backuppc/.

Enfin, nous pouvons démarrer backuppc :

/etc/init.d/backuppc start

Et voilà ! Notre automonteur pour backuppc est en place ! Nous allons pouvoir utiliser la volumétrie du NAS pour faire nos sauvegardes !

Quelques tests du mod_gearman avec nagios

J'ai dernièrement travaillé sur la mise en place d'une nouvelle infra nagios se basant sur une Redhat EL5.5 à la place de ma zone Solaris (youpi ! enfin du Linux sur notre infra !). A cette occasion, j'ai voulu voir ce que donné le mod gearman. Avant de le mettre en production, je l'ai activé sur mon poste (Debian/Kubuntu). J'en décris ici les principales étapes ainsi que les résultats de quelques tests.

Compilation

Ici, rien de très compliqué, il faut récupérer la dernière version (1.2.4 au moment de la rédaction de l'article mais la 1.2.6 est sortie entre temps) à l'adresse suivante : http://labs.consol.de/wp-content/uploads/2010/09/mod_gearman-1.2.4.tar.gz
Avant compilation, installons quelques pré-requis :

apt-get install gearman libgearman-dev

Vient ensuite le temps de la compilation :

# Décompression
tar xfv mod_gearman-1.2.4.tar.gz && cd mod_gearman-1.2.4
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
make
make install

Intégration de gearman dans nagios

De là, vous devriez obtenir un binaire /usr/lib/mod_gearman/mod_gearman.o que vous pouvez maintenant référencer de la manière suivante dans votre fichier /etc/nagios3/nagios.cfg :

broker_module=/usr/lib/mod_gearman/mod_gearman.o localhostgroups=local-server server=localhost:4730 key=Found@nor1g1nalK3y$ eventhandler=yes services=yes hosts=yes

Ici, il faut surtout noter les points suivants :

• L'option localhostgroups donne le nom des groupes de machine sur lesquelles nous ne déléguerons pas les appels. Il est de bon goût d'y mettre les machines de votre infra nagios afin d'être sûr de détecter les problèmes sur vos services gearman ;
• L'option server donne l'adresse d'écoute du démon gearman ;
• L'option key permettant de gérer le chiffrement des communications entre les process gearman ;
• Enfin les options eventhandler=yes services=yes hosts=yes permettant d'indiquer ce que nous pouvons faire faire à nos workers gearman.

Il  ne nous reste plus qu'à lancer les workers gearman et faire recharger la configuration à notre moteur nagios :

/etc/init.d/mod_gearman_worker start
Starting mod_gearman_worker...OK
/etc/init.d/nagios3 reload
 * Reloading nagios3 monitoring daemon configuration files nagios3

Lancement d'un petit bench

Maintenant que notre conf est prête, voyons l'impact de gearman sur le fonctionnement de notre moteur nagios. Tout d'abord, un test en désactivant gearman pour avoir une idée de la capacité native de notre moteur nagios.

A propos de la machine et du bench

Rien de particulier à signaler, il s'agit d'un processeur quadri-coeur (AMD Phenom(tm) II X4 965) avec 4 Go de mémoire.
Concernant la conf nagios du bench, elle consiste à créer des fichiers de configuration contenant les éléments suivants :

define host{
        use                     generic-host
        process_perf_data       0
        host_name               @HOST@
        alias                   @HOST@
        address                 127.0.0.1
        }

define service{
        use                             generic-service         ; Name of service template to use
        host_name                       @HOST@
        service_description             dummy1
        check_interval                  1
        check_command                   return-ok
}
[...]

Sans mod_gearman

Voici grosso modo les temps forts au niveau du changement de conf :

Heure	nb machines	nb services	interval
20h45	400	5600	5min
20h55	400	5600	1min
21h25	600	8400	1min
21h40	800	11200	1min

Tout ceci a entraîné le comportement suivant au niveau de la machine de bench :

• Latence du moteur nagios :

•  Consommation CPU de la machine

La consommation avoisine en pointe les 92 % avec une moyenne - pour la fin du test - dans les 75%. La latence se situe dans les 500ms en fin de test.

Avec mod_gearman

Passons maintenant la même configuration avec gearman actif. Tout d'abord les évènements du bench :

Heure	nb machines	nb services	interval
22h00	400	5600	1min
22h20	600	8400	1min
22h40	800	11200	1min
23h02	1000	14000	1min
23h22	1200	16800	1min

Et maintenant le comportement du serveur pendant cette même période :

• Latence du moteur nagios :

• Consommation CPU :

Non seulement la consommation CPU n'a jamais dépassé 37 % en pointe (on est plutôt à 25% de moyenne) mais en plus, on a pu faire 50 % de tests en plus sans impact particulier au niveau de la machine et en gardant une latence inférieur à 400ms.

Pour conclure ...

Comme on peut le voir, l'utilisation de gearman fait grandement baisser la consommation CPU de notre serveur. D'autant plus que gearman offre également la capacité de distribuer nos surveillances sur plusieurs machines différentes. Vous pouvez également déporter la génération des graphiques sur une autre machine (à l'aide du mode gearman de PNP4Nagios par exemple).

Si vous combinez tout ceci,  nous sommes face à un outil apportant une très grande souplesse à ce vieux moteur nagios. Non seulement vous réduisez votre consommation CPU mais tout en vous laissant la possibilité de distribuer très facilement vos éléments de surveillance/métrologie en fonction de vos besoins.

Pour aller plus loin, je vous conseille de faire un tour sur le site de gearman qui présente pas mal de possibilité d'architecture.

Gestion des mots de passe de l'interface web de shinken

Shinken est sortie il y a peu de temps en version 1.0rc1. J'ai voulu l'installer et utiliser la nouvelle interface web. Comme j'ai eu quelques difficultés et qu'il semblerait que d'autre ai eu le même problème que moi (merci à David pour ton aide !), je me permets de déposer quelques éléments sur le sujet.

Pour l'installation, il faut tout d'abord télécharger l'archive à l'adresse suivante :https://github.com/naparuba/shinken/tarball/1.0rc1

Vous obtiendrez alors l'archive naparuba-shinken-1.0rc1-0-g5a2075e.tar.gz. Une fois l'archive décompressé, vous pourrez lancer l'installation à l'aide de la commande suivante :

sudo python setup.py install --install-scripts=/usr/bin/

De là, lancez shinken avec la commande /etc/init.d/shinken start

Si vous jetez un oeil au process shinken de votre machine, vous devriez obtenir les choses suivantes :

root@robert:/home/drayan/dev/naparuba-shinken-5a2075e# ps -fu shinken
UID        PID  PPID  C STIME TTY          TIME CMD
shinken  15495 30036  0 00:15 ?        00:00:00 /usr/bin/python /usr/bin//shinken-reactionner -d -c /etc/shinken/reactionnerd.ini
shinken  30009     1  0 Feb25 ?        00:00:56 /usr/bin/python /usr/bin//shinken-scheduler -d -c /etc/shinken/schedulerd.ini
shinken  30019 30009  0 Feb25 ?        00:00:00 /usr/bin/python /usr/bin//shinken-scheduler -d -c /etc/shinken/schedulerd.ini
shinken  30021     1  0 Feb25 ?        00:00:51 /usr/bin/python /usr/bin//shinken-poller -d -c /etc/shinken/pollerd.ini
shinken  30031 30021  0 Feb25 ?        00:00:21 /usr/bin/python /usr/bin//shinken-poller -d -c /etc/shinken/pollerd.ini
shinken  30036     1  0 Feb25 ?        00:00:40 /usr/bin/python /usr/bin//shinken-reactionner -d -c /etc/shinken/reactionnerd.ini
shinken  30046 30036  0 Feb25 ?        00:00:07 /usr/bin/python /usr/bin//shinken-reactionner -d -c /etc/shinken/reactionnerd.ini
shinken  30051     1  0 Feb25 ?        00:00:54 /usr/bin/python /usr/bin//shinken-broker -d -c /etc/shinken/brokerd.ini
shinken  30061 30051  2 Feb25 ?        00:05:53 /usr/bin/python /usr/bin//shinken-broker -d -c /etc/shinken/brokerd.ini
shinken  30063     1  0 Feb25 ?        00:00:22 /usr/bin/python /usr/bin//shinken-receiver -d -c /etc/shinken/receiverd.ini
shinken  30073 30063  0 Feb25 ?        00:00:00 /usr/bin/python /usr/bin//shinken-receiver -d -c /etc/shinken/receiverd.ini
shinken  30079     1  0 Feb25 ?        00:01:11 /usr/bin/python /usr/bin//shinken-arbiter -d -c /etc/shinken/nagios.cfg -c /etc/shinken/shinken-specific.cfg
shinken  30080 30079  0 Feb25 ?        00:00:03 /usr/bin/python /usr/bin//shinken-arbiter -d -c /etc/shinken/nagios.cfg -c /etc/shinken/shinken-specific.cfg
shinken  30087 30079  0 Feb25 ?        00:00:00 /usr/bin/python /usr/bin//shinken-arbiter -d -c /etc/shinken/nagios.cfg -c /etc/shinken/shinken-specific.cfg
shinken  30109 30021  0 Feb25 ?        00:00:04 /usr/bin/python /usr/bin//shinken-poller -d -c /etc/shinken/pollerd.ini
shinken  30116 30021  0 Feb25 ?        00:00:04 /usr/bin/python /usr/bin//shinken-poller -d -c /etc/shinken/pollerd.ini
shinken  30124 30021  0 Feb25 ?        00:00:04 /usr/bin/python /usr/bin//shinken-poller -d -c /etc/shinken/pollerd.ini
shinken  30140 30051  1 Feb25 ?        00:03:26 /usr/bin/python /usr/bin//shinken-broker -d -c /etc/shinken/brokerd.ini
shinken  30149 30051  0 Feb25 ?        00:00:14 /usr/bin/python /usr/bin//shinken-broker -d -c /etc/shinken/brokerd.ini
shinken  30170 30021  0 Feb25 ?        00:00:04 /usr/bin/python /usr/bin//shinken-poller -d -c /etc/shinken/pollerd.ini

Vous pouvez maintenant vous rendre sur l'interface web de shinken sur l'url suivante : http://localhost:7767/

Un utilisateur vous sera demandé. Il s'agira par défaut de admin/admin.

A ce sujet, il faut savoir que le système d'authentification s'appuie sur la configuration contenu dans le fichier shinken-specific.cfg (dans le répertoire /etc/shinken) et notamment sur le passage suivant :

# The WebUI broker module
define module{
       module_name      WebUI
       module_type      webui
       
       host             0.0.0.0       ; mean all interfaces
       port             7767

[...]
       modules          Apache_passwd,ActiveDir_UI,Cfg_password
[...]
}

Comme indiqué, l'interface essaye d'authentifier l'utilisateur avec 3 modules différents. Le premier qui y arrive arrête le mécanisme.

Dans le cas présent, nous allons tout d'abord essayer de nous authentifier avec un fichier htpasswd apache (toujours dans shinken-specific.cfg) :

define module{
       module_name      Apache_passwd
       module_type      passwd_webui

       #  WARNING : put the full PATH for this value!
       passwd           /etc/shinken/htpasswd.users

}

Vient ensuite le module active directory :

# Check authentification for WebUI using a Active Directory
define module{
       module_name      ActiveDir_UI
       module_type      ad_webui

#   UNCOMMENT this line to really enable this module and allow it to
#   connect!
#        ldap_uri         ldaps://myserver
       username         user
       password         password
       basedn           DC=google,DC=com

}

Enfin, dans le cas de l'interface web de shinken (avec sa conf par défaut), ce dernier va s'appuyer sur ces fichiers de configuration. Dans le cas de l'utilisateur admin, il s'agit d'un contact (au sens nagios) définie dans les fichiers de configuration (par défaut, fichier contacts.cfg). Le mot de passe est par ailleurs définie de la manière suivante :

define contact{
        use                                     generic-contact
        contact_name                            admin
        email                                   shinken@localhost
        pager                                   0600000000   ; contact phone number
        password                                admin
        is_admin                                1
}

De là, vous pouvez changer le mot de passe et le faire prendre en compte par shinken. Il ne reste plus maintenant qu'à configurer vos services !