Mise en place d'un bridge sous Debian/Ubuntu

Dans ma quête perpétuelle de la mise en place de truc qui fonctionne à moitié, j'ai eu la chance de me frotter aux bridges ethernets et aux interfaces ethernets virtuelles de l'ami Linux.

Mais qu'est ce qu'un bridge ethernet allez-vous me dire et pourquoi vouloir en mettre un en place ?

Un bridge ethernet est l'équivalent d'un switch virtuel au niveau système. L'idée est d'utiliser une interface réelle (mettons eth0) pour faire transiter du trafic des interfaces virtuelles (généralement tap0, tap1 etc.).

Pour ce qui est de l'utilité, vous en avez plusieurs avec notamment les deux exemples suivants :

• Exposer une machine virtuelle sur un réseau réelle ;
• Mettre en place un bridge ethernet pour openvpn.

Dans mon cas, je fais ça pour openvpn mais on peut également l'utiliser pour kvm par exemple.

Mise en place d'un bridge

Avant toute chose, il va nous falloir installer deux packages qui vous serons utiles pour gérer les bridges et les interfaces virtuelles (et puis, que serait un article sur Debian sans l'utilisation d'apt-get) :

apt-get install uml-utilities bridge-utils

Ici, rien de bien extraordinaire, nous allons d'abord déclarer un bridge (br0) dans le fichier /etc/network/interfaces, y ajouter notre interface ethernet (eth0) et enfin rattacher l'adresse dhcp au bridge. Ci-dessous, vous trouverez un exemple de fichier avant modification :

auto lo

iface lo inet loopback

auto eth0

iface eth0 inet dhcp

Après modification, le fichier devrait ressembler à ça :

auto lo

iface lo inet loopback

auto eth0

iface eth0 inet manual

auto br0

iface br0 inet dhcp

        bridge_ports eth0

        bridge_fd 9

        bridge_hello 2

        bridge_maxage 12

        bridge_stp off

Faîtes ensuite un restart networking pour prise en compte. La commande ifconfig devrait vous renvoyer ce qui suit :

# ifconfig

br0       Link encap:Ethernet  HWaddr 7e:68:47:11:36:c9  

          inet adr:192.168.0.34  Bcast:192.168.0.255  Masque:255.255.255.0

          adr inet6: fe80::7c68:47ff:fe11:36c9/64 Scope:Lien

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Packets reçus:3193 erreurs:0 :0 overruns:0 frame:0

          TX packets:1289 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 lg file transmission:0 

          Octets reçus:273039 (273.0 KB) Octets transmis:331151 (331.1 KB)

lo        Link encap:Boucle locale  

          inet adr:127.0.0.1  Masque:255.0.0.0

          adr inet6: ::1/128 Scope:Hôte

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          Packets reçus:312 erreurs:0 :0 overruns:0 frame:0

          TX packets:312 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 lg file transmission:0 

          Octets reçus:32926 (32.9 KB) Octets transmis:32926 (32.9 KB)

eth0      Link encap:Ethernet  HWaddr c8:60:00:e2:c9:2b  

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Packets reçus:4925 erreurs:0 :0 overruns:0 frame:0

          TX packets:1289 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 lg file transmission:1000 

          Octets reçus:679553 (679.5 KB) Octets transmis:331151 (331.1 KB)

On voit ici que c'est le bridge qui a une adresse IP. Ceci est important pour permettre le fonctionnement correcte de notre machine. Dans le cas contraire, on pourrait avoir des comportements bizarre de notre ami le serveur. Il faut bien voir que notre interface ethernet est simplement considéré comme un connecteur vers le monde réel.

Pour les plus curieux, il est possible de consulter l'état de notre bridge avec la commande brctl :

# brctl show br0

bridge name     bridge id               STP enabled     interfaces

br0             8000.7e68471136c9       no              eth0

Passons maintenant à la déclaration d'une interface virtuelle.

Déclaration d'une interface virtuelle et rattachement au bridge

Maintenant que notre bridge est fonctionnel, nous allons rattacher une interface virtuelle (tap0). Pour se faire, rien de plus simple, modifions de nouveau notre fichier /etc/network/interfaces de la manière suivante :

auto lo

iface lo inet loopback

auto eth0

iface eth0 inet manual

auto tap0

iface tap0 inet manual

        pre-up tunctl -t tap0

        up ifconfig tap0 up

        down ifconfig tap0 down

auto br0

iface br0 inet dhcp

        bridge_ports eth0 tap0

        bridge_fd 9

        bridge_hello 2

        bridge_maxage 12

        bridge_stp off

Les lignes concernant tap0 contiennent l'utilisation de la commande tunctl qui va déclarer l'interface. Une fois déclarée, cette interface sera rattachée automatiquement au bridge à l'aide de la ligne bridge_ports.

Pour s'en convaincre, une fois que le réseau a été redémarré (restart networking), il suffit de relancer la commande brctl show br0. Ce dernier devrait renvoyer le résultat suivant :


# brctl show br0
bridge name     bridge id               STP enabled     interfaces
br0             8000.1c6f65217bc0       no              eth0
                                                        tap0

Mécanisme de hook de SVN

Je sais, vous allez me dire que SVN est vieillot et que de toute façon, en bon geek qui se respecte, ça fait longtemps que vous êtes passé sous git.

Mais voilà, si vous n'êtes pas encore complètement convaincu que SVN n'est pas une solution si mauvaise que ça et que vous utilisez ça chez votre client/employeur, j'ai quelques astuces pour vous.

Tout d'abord, les hooks sont présent dans le répertoire hooks de votre repository. De base, votre repository SVN, à sa création, vient avec un template pour toutes les opérations de hooks possible sous SVN. Ça se présente sous la forme suivante :


ls *.tmpl
post-commit.tmpl
post-unlock.tmpl
pre-revprop-change.tmpl
post-lock.tmpl
pre-commit.tmpl
pre-unlock.tmpl
post-revprop-change.tmpl
pre-lock.tmpl
start-commit.tmpl

Comme vous pouvez le constater, toutes les opérations possible et imaginable sont disponible. Personnellement, j'ai eu l'occasion d'en mettre deux en oeuvre :

• pre-revprop-change : lancé avant une modification sur une révision ;
• post-commit : lancé au moment de la fin d'un commit.

Ces hooks vont servir à changer/régler le comportement de votre repository à l'aide de script. Pour les mettre en place, rien de plus simple :

• Faîtes un script dans le langage qui vous amuse (même si j'aurais tendance à privilégier un script shell Unix tout simple) ;
• Copier/lier ce script dans le répertoire du hooks en respectant le nom de l'opération à laquelle vous voulez le lier.

Exemple de hooks SVN : pre-revprop-change

Prenons le cas du pre-revprop-change. Ce script est lancé pour vérifier que l'opération de modification d'une révision de votre repository est bien autorisé. Je sais, vous aller me dire que ce type de demande vous parez étrange. Mais comme chacun sait, le client est roi et à coeur vaillant, rien d'impossible !

Dans le cas présent, nous allons justement restreindre cette opération à la modification du message de log de votre révision. Nous allons également interdire que cette modification puisse se faire par un autre utilisateur que celui à l'origine de la modification.

Sans plus attendre, voici donc le fameux script en charge de cette modification :

#!/bin/bash
REPOS="$1"
REV="$2"
USER="$3"
PROPNAME="$4"
ACTION="$5"

if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:log" ] && \
   [ `svnlook author -r "$REV" "$REPOS"` = "$USER" ]; then
  exit 0
fi

echo "Changing revision properties other than svn:log is prohibited" >&2
exit 1

Le principe est simple :

• On vérifie bien que nous n'allons modifier que le message de la révision (PROPNAME=svn:log) ;
• L'action est une modification (ACTION=M) ;
• Enfin, l'auteur de la modification est bien celui à l'origine du commit (svnlook author ... = $USER).

De là, si ces conditions sont remplies, on renvoie un exit 0 et SVN considère que l'opération est valide.

Dans les autres cas, nous renvoyons exit 1 et SVN refusera de lancer la modification.

Couplage avec Jenkins à l'aide d'un événement de post-commit

Prenons maintenant un autre cas : vous voulez coupler votre repository SVN avec un moteur d'intégration continue (type Jenkins) afin de lancer automatiquement vos constructions sans pour autant avoir à poller régulièrement votre repository SVN tout le temps. Ici, l'utilisation d'un évènement de post-commit fera parfaitement l'affaire et pourra lancer automatiquement votre job de construction.

Pour se faire, nous allons créer le script suivant que nous lierons ensuite dans le répertoire hooks avec comme nom post-commit (bien s'assurer également qu'il est exécutable) :

#!/bin/bash

log="/tmp/post_commit.log"

url_jenkins="http://127.0.0.1:8080/job/makeApp-generic/buildWithParameters?token=makeApp"

REPOS="$1"

TRANS="$2"

exec  > $log

exec 2> $log

repository=$(basename $REPOS)

# Définition des paths des différents binaires

for tag in $(svnlook changed -r $TRANS $REPOS | \

             sed 's/tags\//' | awk '{ print $2 }' | \

             sed 's/\/.*//g' | sort -u)

do

  if [ $tag = "trunk" ]; then tag=HEAD ; fi

  echo "Lancement de la construction de '$repository' (tag='$tag')."

  curl "$url_jenkins&application=$repository&tag=$tag" 2> /dev/null

done

NB : Il va sans dire qu'il faudra que votre serveur Jenkins soit en mesure d'accepter le job qui s'appelle makeApp-generic et surtout que vous ayez créé un token d'appel associé pour pouvoir le lancer avec un curl. Tient, je sens que je vais faire un article sur Jenkins dans peu de temps :).

En gros, le script va simplement regarder les répertoires des fichiers qui vont être modifié et, en fonction de ça, lancer une construction (avec les appels curl) auprès de Jenkins. Dans notre exemple, si la modification se fait sur le trunk, le tag est changé en HEAD.

Il ne nous reste plus maintenant qu'à faire une modification dans notre repository et vérifier que le build s'est bien passé en consultat la log /tmp/post_commit.log :

cat /tmp/post_commit.log

Lancement de la construction de 'test' (tag='HEAD').

Voilà, ça sera à peu près tout pour aujourd'hui. A bientôt pour de nouvelle aventure !

Configuration de squidguard comme contrôle parental

Ayant de jeunes enfants à la maison, j'ai commencé à me poser la question de mettre en place un contrôle parental afin d'éviter d'amener mes enfants sur des pages que je n'aurais pas voulu qu'il voit (porno, jeux d'argent, violences etc.).

Bref, vous l'aurez compris, papa geek c'est posé la question de savoir qu'est ce qu'il pourrait bien mettre en oeuvre pour faire ce travail. J'ai rapidement trouvé une réponse au travers de l'outil squidguard. Nous allons donc voir ensemble comment rapidement le configurer afin de répondre à ce besoin.

Il va sans dire que papa geek utilise une distribution Linux (ici une Debian like) mais que ces instructions s'appliquent à n'importe quelle distribution Linux (voir à - j'ai du mal à le dire mais tant pis - à MacOS X - herk !).

Installation de squid et squidguard

La première phase est relativement rapide - pour peu que vous utilisiez une distribution Linux - et consiste à installer le package correspondant. Ceci se fait tout naturellement avec apt-get/aptitude/yum :

apt-get install squidguard

Il faut savoir qu'à ce moment, vous allez installer deux produits : squid et squidguard. Squid est un simple proxy HTTP mais qui a la particularité de pouvoir faire appel à des programmes externes pour procéder à des réécritures de contenu. Ici, le programme de réécriture externe est squidguard.

C'est très bien vous allez me dire mais squidguard vient sans aucune règle de configurer : le vilain ne filtre rien du tout ! Nous allons donc voir comment faire pour rajouter un filtrage dans squidguard avec les blacklists de l'université de Toulouse.

Configuration de squidguard

Récupération des blacklists

Rendons nous maintenant dans le répertoire /var/lib/squidguard/ et supprimons le répertoire db (en principe vide) :

rmdir /var/lib/squidguard/db

Récupérons maintenant une archive de la dernière version des blacklists :

cd /tmp/
wget http://dsi.ut-capitole.fr/blacklists/download/blacklists.tar.gz

Décompressons maintenant l'archive :

cd /var/lib/squidguard
tar xfv /tmp/blacklists.tar.gz

Renommons tout ça et attribuons les bons droits :

mv blacklist db

chown -R proxy:proxy /var/lib/squidguard/db

Il faut maintenant modifier le contenu du fichier /etc/squid3/squid.conf avec le contenu suivant :

url_rewrite_program /usr/bin/squidGuard -c /etc/squidguard/squidGuard.conf
url_rewrite_children 10

http_port 3128 transparent

Et faire suivre tout ceci d'un arrêt/relance :

/etc/init.d/squid3 restart

Voyons maintenant comment mettre en place les blacklists.

Mise en place des blacklists

Nous allons maintenant configurer notre squidguard afin qu'il prenne en compte les listes que nous venons de récupérer. Il faudra également choisir les listes que nous allons vouloir activer. Pour info, pour savoir à quoi correspond chacune des listes, il suffit d'ouvrir le fichier global_usage. Chaque catégorie y est présenté comme suit :


NAME: adult
DEFAULT_TYPE: black
SOURCE: http://squidguard.univ-tlse1.fr
DESC EN: Some adult site from erotic to hard pornography.
DESC FR: Des sites adultes allant de l'érotique à la pornographie dure.
NAME EN: Adult (X)
NAME FR: Adulte (X)
NAME IT: Siti per adulti (XXX)
NAME NL: 18+ (X)
NAME RU: Эротика
NAME DE: Porno


Charge à vous de sélectionner les catégories qui vous intéressent et de les ajouter sous cette forme dans le fichier /etc/squidguard/squidGuard.conf :

# Emplacement de la définition de la blacklist :

dbhome /var/lib/squidguard/db
logdir /var/log/squidguard

# Définition des différentes catégories
dest adult {
  domainlist adult/domains
  urllist adult/urls
}

dest sect {

  domainlist sect/domains

  urllist sect/urls

}

dest malware {

  domainlist malware/domains

  urllist malware/urls

}

dest remote-control {

  domainlist remote-control/domains

  urllist remote-control/urls

}

# Règle à appliquer en fonction des catégories définies ci-dessus

acl {

  default {

    pass !adult !sect !malware !remote-control all

    # Page de redirection. Changer là par ce que vous voulez

    redirect http://localhost/block.html

  }

}

Sauvegarder votre fichier et procéder maintenant à une mise à jour des bases de squidguard (soyez patient, c'est un peu long) :

update-squidguard

Attention ! Les espaces en début du fichier de configuration doivent être des tabulations ! Dans le cas  où vous auriez fait une bêtise dans votre fichier, le script se bloquera sans aucun message et sans activité CPU. N'hésitez pas à consulter le contenu du fichier /var/log/squidguard/squidGuard.log ou lancer la commande suivante pour obtenir des informations complétementaires :

squidGuard -d -b -P -C all

Reste maintenant à configurer votre navigateur afin de pointer sur le proxy.

Configuration du navigateur

Ici, rien d'extraordinaire : se rendre dans les paramètres de votre navigateur, dans les paramètres réseaux, rentrer l'adresse de votre proxy (ip : 127.0.0.1 et port : 3128) et c'est parti.

Mutualisation du proxy

Dans le cas où vous voudriez mutualiser votre proxy, il faudra pour cela accepter les connexions depuis votre réseau local. Tout ceci se fait en rajoutant les directives suivantes dans votre fichier /etc/squid3/squid.conf :

acl localnet src 192.168.0.0/16

http_access allow localnet

Reste maintenant à relancer squid pour prendre en compte la modification (/etc/init.d/squid3 restart). Il faudra également renseigner l'adresse IP de la machine qui vous servira de proxy dans les différents navigateurs de vos différentes machines clientes.

A noter que si vous utilisez un serveur DHCP, il est possible de préciser l'adresse de votre proxy. La configuration se fera alors automatiquement.

Je n'ai donc plus qu'à vous souhaiter un bon surf sans trop de saleté pour vos gamins !

Utilisation de webdav en ligne de commande

Depuis quelques temps, j'ai comme projet de faire un serveur de publication. Ce dernier doit héberger des sources et autres RPM mais malheureusement, il n'est pas accessible en SSH et nous devrons passer par du WebDAV (en https).

Voici donc en quelques lignes comment le mettre en oeuvre sur un serveur apache sous RedHat Enterprise/Centos 6.

Configuration du serveur apache

Premier point, nous allons créer un nouveau point webdav pour notre serveur. Pour se faire, rien de bien compliquer, il faut créer un fichier /etc/httpd/conf.d/test-webdav.conf avec le contenu suivant :

Alias /test-webdav /var/www/webdav

<Directory "/var/www/webdav">
  Dav On
  Options Indexes
  AllowOverride None
  Order allow,deny
  Allow from all
</Directory>

Bien penser à alimenter notre fichier de mot de passe (/mon/fichier/htpasswd) à l'aide de l'outil htpasswd. Par la suite, nous utiliserons un utilisateur webdav_access avec xxx comme mot de passe.

Créons maintenant notre répertoire et attribuons les droits à l'utilisateur apache (ou www-data dans le cas d'une debian) :

mkdir /var/www/webdav
chown apache:apache /var/www/webdav

Un arrêt relance de notre serveur apache et tout est prêt pour la suite. Pour s'assurer que nous n'avons rien oublier, nous pouvons essayer d'y accéder à l'aide de curl :

curl -u webdav_access:xxx http://localhost/test-webdav/

Voyons maintenant la suite du programme

Maintenant que notre nouveau contexte fonctionne, nous allons essayer d'uploader un fichier à l'aide de curl. Pour se faire, il faut utiliser l'option -T suivi du fichier à uploader. Ci-dessous un exemple :

curl -u webdav_access:xxx -T welcome.html \
     http://localhost/test-webdav/

Le serveur devrait vous renvoyer une réponse en HTML vous indiquant la réussite de l'opération sous la forme du message suivant :

Resource /test-webdav/welcome.html has been created.

C'est bien beau mais on voudrait également gérer des sous répertoires. Il faut dans ce cas utiliser l'option -X MKCOL. Ci-dessous un exemple :

curl -u webdav_access:xxx -X MKCOL \
     http://localhost/test-webdav/new_dir

Le message suivant devrait vous indiquer que ça s'est bien passé :

Collection /test-webdav/new_dir has been created.

Reste ensuite à rajouter un fichier dans ce répertoire :

curl -u webdav_access:xxx -T welcome.html \
     http://localhost/test-webdav/new_dir/

Utilisation en point de montage

Nous avons vu les possibilités de notre serveur. Sachez qu'il est également possible de monter un serveur webdav sur un serveur Linux. Ci-dessous un exemple de montage de notre point de partage :

mount -t davfs http://localhost/test-webdav/ /mnt
Please enter the username to authenticate with server
http://localhost/test-webdav/ or hit enter for none.
  Username:webdav_access
Please enter the password to authenticate user  with server
http://localhost/test-webdav/ or hit enter for none.
  Password:xxx

Rendons nous maintenant sur le point de montage /mnt et faisons quelques tests.

• Lister le contenu du répertoire :

# cd /mnt/
# ls
lost+found  new_dir  test_webdav.txt  un  welcome.html

• Supprimer un répertoire :

rmdir new_dir

• Copier un fichier :

cp /etc/hosts /mnt/

Bref, vous l'aurez compris, tout ceci se comporte comme un FS normal.

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é :