GuiguiAbloc

En voila du titre bien décousu

En fait, j’ai passer quelques semaines a mettre en place différentes solutions dans mon environnement domotique et plutôt que d’en faire plein de petits billets, j’ai décidé de tout regrouper en un, à vous de piocher dedans

Pour résumer la situation, je voulais d’abord que mon serveur Domotique « parle » (ça c’est plutôt simple), que lorsque j’allume mon portable au sous-sol, j’entende les messages audio du serveur (la ça se complique, si comme moi, vous ne souhaitez pas faire du multicast dans votre LAN), et enfin, comble du geekissime domotique, je voulais récupérer en temps réel les alarmes Zoneminder dès la détection d’un mouvement dans le champ de la caméra et que mon serveur Domotique me l’annonce de sa douce voix (la, ça se complique beaucoup, vous verrez…)

Bref, après plusieurs semaines, tout cela fonctionne, voyons comment.

• SYNTHESE VOCALE ou comment faire parler une machine

Pour l’installation d’un synthèse vocale sur un serveur Linux, rien de plus simple.

Plutôt que de refaire un énième billet a ce sujet, je vous renvoie vers le blog de Christophe Nowicki dont je vous avez déjà parler, qui explique très bien la façon de le faire :

http://www.csquad.org/2009/08/27/text-to-speech-avec-espeak-mbrola-et-speech-dispatcher/

Il existe bien sûr d’autre tutos, mais Christophe a beaucoup travailler sur le « son » en Domotique et son blog regorge d’infos intéressantes.

Bilan après installation, un système de synthèse vocale installé sous /opt/mbrola

et bien sûr, les commandes essentielles à la création et gestion des « voix » :

(ps : fr4 est une voix française féminine, bizarrement je préfère :-p )

(NB: a l’attention de Fred, je n’arrive pas a reproduire la voix de Karen Cheryl… Désolé… (ou tant mieux pour nous…)

- Convertir le texte écrit dans le fichier « texte » en un phonème compréhensible par Mbrola

espeak -x -v mb/mb-fr4 -f texte > texte.pho

- Faire parler le serveur en lisant le phonème

mbrola -t 1.0 -e -C « n n2″ /opt/mbrola/fr4/fr4 texte.pho -.au | aplay

- Convertir la phrase lue par mbrola en un fichier Wav

mbrola -e -C « n n2″ /opt/mbrola/fr4/fr4 texte.pho texte.wav

(pour les options mbrola que j’utilise, t = la vitesse de lecture, voir la doc officielle)

Pour lire le wav en ligne de commande, mplayer est votre ami.

• PULSEAUDIO ou le son en réseau

Voila la partie où j’ai passer le plus de temps.

Je souhaitais récupérer le son émis par mon serveur sur mon portable connecté en Wi-Fi.

Le premier serveur de son qui m’est venu a l’esprit fut bien sur Pulseaudio.

C’est là que les complications sont arrivées…

Pulseaudio peut fonctionner en multicast, comprendre que le son est diffusé dans tout le LAN, il peut même s’intégrer a Avahi (le mDNS type « Bonjour »).

Sauf que moi le multicast, j’aime pas ça (va comprendre Charles…) et qui plus est, j’ai un LAN segmenté par VLAN et centralisé par du Cisco, et la conf multicast sous Cisco, ca me fait mal au crâne

Donc, out le multicast, je veux de l’unicast TCP (bah oui, j’aime bien les trames réseaux bien proprettes )

L’installation de Pulseaudio sous Debian Lenny passe par un apt-get install tout simple (n’oubliez pas pulseaudio-utils)

Côté configuration sur le serveur Domotique :

srvdomotique:/etc/pulse# cat default.pa
#!/usr/bin/pulseaudio -nF
.nofail
load-sample-lazy pulse-hotplug /usr/share/sounds/startup3.wav
.fail
.ifexists module-hal-detect.so
load-module module-hal-detect
.else
load-module module-detect
.endif
### Load several protocols
.ifexists module-esound-protocol-unix.so
load-module module-esound-protocol-unix socket="/tmp/.esd/socket"
.endif
load-module module-native-protocol-unix
load-module module-esound-protocol-tcp auth-anonymous=1
load-module module-native-protocol-tcp listen=192.168.43.100 auth-anonymous=1
load-module module-tunnel-sink server=192.168.8.201 sink_name=copie
load-module  module-combine sink_name=combined master="copie" slaves="alsa_output.pci_10de_3f0_alsa_playback_0"
.ifexists module-gconf.so
.nofail
#load-module module-gconf
.fail
.endif
### Automatically restore the volume of playback streams
load-module module-volume-restore
load-module module-default-device-restore
load-module module-rescue-streams
load-module module-suspend-on-idle
.ifexists module-x11-publish.so
.nofail
load-module module-x11-publish
.fail
.endif
set-default-sink combined

Petite explication.

La ligne : « load-module module-native-protocol-tcp listen=192.168.43.100 auth-anonymous=1″ signifie que vous écoutez sur l’ip 102.168.43.100 et que vous autorisez les connexions anonymes (on va filter au niveau ACL du cisco)

La ligne : « load-module module-tunnel-sink server=192.168.8.201 sink_name=copie »

désigne le « client » qui va écouter les sons émis par le serveur domotique (en fait le client est le serveur domotique qui va émettre le son vers un serveur pulseaudio distant à l’ip 192.168.8.201…)

La ligne : « load-module  module-combine sink_name=combined master= »copie » slaves= »alsa_output.pci_10de_3f0_alsa_playback_0″ »

génère un « sink » (une destination audio si vous préférez), qui comprend ET le pc a l’adresse 192.168.8.201 (alias copie) ET la carte son du serveur Domotique.

Flux par défaut : set-default-sink combined

Ce qui veut dire que tout son émis doit être diffusé simultanément sur la carte son du serveur Domotique (je peux donc l’entendre par les enceintes branchées dessus) et sur les enceintes du PC client.

C’est clair ?

Sur le serveur Domotique, dont le système de son est géré par ALSA, je spécifie que tout les sons doivent être envoyés au démon PulseAudio grace au fichier /etc/asound.conf

srvdomotique:/etc# more asound.conf
pcm.pulse {
type pulse
}
 
ctl.pulse {
type pulse
}
 
pcm.!default {
type pulse
}
 
ctl.!default {
type pulse
}

Reste à lancer pulsaudio (ou par la commande pulseaudio -Cvvv pour voir ce qui se passe ou par la commande pulseaudio -D pour le daemoniser en arrière plan).

Les sons émis par votre serveur doivent être audible sur les enceintes de celui-ci.

Sur le PC client (mon portable en l’occurence), installation de pulseaudio normale, puis un default.pa comme suit :

#!/usr/bin/pulseaudio -nF
.ifexists module-hal-detect.so
load-module module-hal-detect
.else
load-module module-detect
.endif
.ifexists module-esound-protocol-unix.so
.endif
load-module module-native-protocol-unix
load-module module-esound-protocol-tcp auth-anonymous=1
load-module module-native-protocol-tcp listen=192.168.8.201 auth-anonymous=1
.ifexists module-gconf.so
.nofail
.fail
.endif
load-module module-volume-restore
load-module module-default-device-restore
load-module module-rescue-streams
load-module module-suspend-on-idle
.ifexists module-x11-publish.so
.nofail
load-module module-x11-publish
.fail
.endif

Rien d’autre (pas de fichier /etc/asound.conf, pas de données dans client.conf)

Lancer pulseaudio sur le client puis lancer pulseaudio sur le serveur Domotique. Les sons émis par le serveur domotique arrive sur le pc portable (même dans KDE pour ma part…)

Oui, MAIS !!!

Le gros problème est que si le PC portable se connecte APRES le démarrage de PulseAudio sur le serveur Domotique et bien, cela ne fonctionne plus !!!!

J’ai passé des jours a chercher et je n’ai pas réussi a comprendre pourquoi le serveur Domotique ne voyait pas le portable se connecter… J’ai tourner dans tout les sens, impossible de le faire marcher comme cela donc si vous avez une solution, je suis preneur !!!

Mais je n’allais pas en rester la et donc pour réussir ce tour de force, j’ai décider de forcer l’enregistrement du pc portable sur le serveur son Domotique via quelques scripts.

Alors, un peu de compassion pour moi, je ne suis pas développeur et c’est sûrement très crado comme code mais au moins ça marche :-p

- Technique d’enregistrement d’un client PulseAudio via socket en Python.

Sur le serveur Domotique, on va faire tourner un petit serveur codé en Python qui écoute sur le port tcp 12345 :

srvdomotique:~# cat pulseserver.py
#!/usr/bin/python
import socket
import subprocess
import sys
import os
servsock = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
 
try:
    servsock.bind(('',12345))
 
except socket.error:
        print "Relance Pulse"
        pidpulse = subprocess.Popen("ps acx | grep pulseaudio | awk '{print $1}'", shell=True, stdout=subprocess.PIPE)
        pid = pidpulse.stdout.read()
        print pid
        os.kill(int(pid), 9)
        pidpulse.stdout.close()
        subprocess.call(["pulseaudio -D"],shell=True)
        servsock.bind(('',12345))
 
servsock.listen(1)
while True:
sock,addr = servsock.accept()
echo = sock.recv(1024)
subprocess.call(["/home/scripts/enregistrement_station.sh"],shell=True)
sock.send(echo)
sock.close()

Quand le client se connecte, le serveur domotique lance le script enregistrement_station.sh :

#!/bin/bash
PIDPULSE=` ps acx | grep pulseaudio | awk '{print $1}'`
kill -9 $PIDPULSE
pulseaudio -D
sleep 2
mplayer /opt/sound/notify.wav
mbrola -t 1.1 -e -C "n n2" /opt/mbrola/fr4/fr4 /opt/mbrola/enregistrement_station.pho -.au | aplay

Dans /etc/rc.local, vous n’avez plus qu’a rajouter la ligne :
/cheminduscript/pulseserver.py &
pour le lancer au boot du serveur.

Côté PC portable, le script de connexion.sh :

#!/bin/bash
PIDPULSE=` ps acx | grep pulseaudio | awk '{print $1}'`
# On allume le haut-parleur a 80%
amixer -q set Master 80%,80%  unmute
if  test -n "$PIDPULSE"
then
echo "pulseaudio actif"
else
pulseaudio -D
fi
sleep 1
python /home/guiguiabloc/pulseclient.py
exit 0

Et le client en python (pulseclient.py)

#!/usr/bin/python
import socket
client = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
host = 'srvdomotique'
port = 12345
print 'Connexion sur ', host, port
client.connect((host, port))
client.close

Je vous le conçois, c’est bourrin…
Quand le portable lance le script « connexion.sh », il lance pulseaudio en local, se connecte au serveur domotique sur le port 12345 qui kill son pulseaudio et le relance, puis fait dire au serveur domotique une phrase annonçant l’enregistrement de la station.
Mais au moins ça marche…

Donc si vous avez d’autres solutions, je suis à votre écoute

• ZONEMINDER et xAP (avec un soupçon de SEC)

Dernière étape de mon travail, mon zoneminder.

ZoneMinder, c’est « vachement » bien, ça fait plein de truc par défaut mais il me manquait une fonction essentielle.

Quand l’on positionne ses caméras en mode « Modect », il détecte les mouvements dans la zone que vous avez définie et enregistre la séquence. Une fois achevée, il vous envoie un email pour vous prévenir d’un mouvement et vous donne le lien vers le « film ».

Super, mais entre le moment où ZoneMinder déclenche l’enregistrement, l’achève après un temps pré-défini (j’utlilise un buffer de 10 secondes avant et 30 secondes après), et vous envoie le mail, bah il se passe plusieurs secondes, voir minutes.

Ce que je voulais c’est que dès qu’un mouvement était détecté par la caméra, ZoneMinder me prévienne d’une manière ou d’une autre. Dans mon cas, en me l’annonçant de sa douce voix (via mbrola).

Ce n’est pas natif dans les fonctions de ZoneMinder et mon bonheur je l’ai trouvé (après moults recherches je vous l’avoue), chez xAP.

Pour résumer, xAP est un protocole open dédié a l’automatisation. C’est la première fois que j’en entendais parler et les fonctionnalités sont nombreuses et puissantes.

Et l’une de ses nombreuses fonctionnalités justement, c’est sa possibilité d’intégration avec ZoneMinder, via un script perl nommé ZMXAP.

En fait, au fin fond du WiKi Zoneminder, on trouve un article dessus :

http://www.zoneminder.com/wiki/index.php/Zmxap

Ni une ni deux, on se télécharge le bazar ici :

http://www.limings.net/xap/zmxap/zmxap-v0.9.tar.gz

La conf est trivial, juste a spécifier nohub=1 dans le zmxap.conf et surtout, pour le besoin que j’avais, générer un fichier de log avec la variable log_file = /tmp/zmxap.log

Car  zmxap est capable d’intéragir directement avec Zoneminder et donc de recevoir en temps réel les informations qui en découlent.

Petit test pour le vérifier :

On lance Zmxap.pl avec la variable du path :

/opt/scripts/zmxap/zmxap.pl -path=/opt/scripts/zmxap &

On passe la caméra en mode « Modect », on passe devant elle et on regarde ce qui se passe dans le fichier /tmp/zmxap.log

24.08.2010 19:32:08 [INFO] (main::loadMonitors): Loading monitors
######## in sendAlarmEvent
####### state=2 and cause=Motion
###### starting fetch of event_data
###### completed fetch of event_data
######## completed sendAlarmEvent
24.08.2010 19:36:03 [INFO] (checkState) Sous_Sol - initiating alarm state
######### completed sendTrackingEvent
24.08.2010 19:36:18 [INFO] (checkState) Sous_Sol - resuming idle state
######## in sendAlarmEvent
####### state=0 and cause=Motion
###### starting fetch of event_data
###### completed fetch of event_data

Magique !!!

ZMXAP a détecté immédiatement le passage (initiating alarm state) puis on voit l’enregistrement se faire.

Ne reste plus qu’a analyser ce fichier de log en temps réel pour remonter l’info.

Et qui a-t-il de mieux pour analyser un fichier de log temps réel ? hein ? Pourtant je vous en avez déjà parler :

http://blog.guiguiabloc.fr/index.php/2009/03/18/interception-des-erreurs-applicatives-dans-nagios-avec-sec-et-prelude-lml/

SEC bien sûr !!!

Allez hop, on se configure notre sec.conf :

type=single
ptype=RegExp
pattern=Sous_Sol(.+)alarm
desc=$0
action=shellcmd  /opt/scripts/AUDIO_alarme_soussol.sh

le script AUDIO_alarme_soussol.sh ne fait que lire une phrase disant « attention y’a un méchant monsieur au sous-sol » (ou autre chose hein…)

Ne reste qu’a lancer tout cela ensemble :

#!/bin/bash
/opt/scripts/zmxap/zmxap.pl -path=/opt/scripts/zmxap &
/usr/local/bin/sec/sec.pl -conf=/usr/local/bin/sec/etc/sec.conf -input=/tmp/zmxap.log -log /var/log/sec.log &

Et voilà, désormais, en plus d’enregistrer les mouvements détectés, ZoneMiner vous prévient immédiatement dès qu’il détecte un mouvement !

C’est pas beau ça ?

Voila un tour de ce que j’ai mis en oeuvre ses dernières semaines, j’avoue que pulseaudio m’a beaucoup coûter en temps, essayant de lui faire recharger sa configuration quand il voyait le portable mais sans succès.

En tout cas, désormais, tout fonctionne à merveille et après tout, c’est tout ce que l’on en attend.

Amusez vous bien

Ce billet est né d’une demande de mon ami « Poupinade » qui connaissant mon goût pour les challenges divers et variés, me demanda avec fourberie innocemment comment je ferais, moi, pour intercepter des erreurs applicatives dans Nagios.

Nagios est un outil de surveillance système et réseau. Largement éprouvé, il est déployé fréquemment pour monitorer les équipements, services etc…

Pour moi, il reste un outil d’alerte et doit être utilisé comme tel. Je ne pense pas que ce soit à lui de remonter des informations détaillées sur un problème quelconque, mais de permettre au « superviseur » de débrancher sur un autre outil s’il veut peaufiner la cause de la panne/alerte (ceux qui utilisent un Nagios avec plus de 1000 hôtes et une dizaine de services par machine me comprendront aisément ).

Je ne m’étendrais pas sur Nagios ici, encore moins sur son installation et son paramétrage.

Vous trouverez de nombreuses références et tutos sur le Nain Ternet pour vous aider à sa mise en place.

La problématique qui se pose ici est de permettre d’être informer rapidement en cas d’erreur dans les logs d’une application.

Car oui on peut surveiller le bon fonctionnement du serveur httpd, de la Base de Données, du lien réseau etc… , mais il peut arriver qu’un autre problème surgisse et que Nagios ne supervise pas.

Je simplifie à l’extrême le concept « application » et prenant comme exemple une application « web », libre à vous d’adapter ce billet à autre chose.

Dans les exemples qui suivront et pour la maquette d’architecture choisie, j’ai pris un simple site en php (en l’occurrence un FlySpray ) qui me sert au suivi de mes « travaux » (a la manière d’OVH).

Les erreurs rencontrées par une « application » sont dans la majorité des cas lisibles dans un fichier de log dédié.

Première chose, faire « tomber » les erreurs php dans le log d’erreur du Vhost d’apache :

Edition du php.ini :
 
error_reporting  =  E_ALL & ~E_NOTICE
display_errors = On
 
Configuration du vhost :
 
ServerName application.guiguiabloc.fr
DocumentRoot /var/www/application
ErrorLog /var/log/apache2/application-error.log
LogLevel warn
CustomLog /var/log/apache2/application-access.log combined

Toujours a des fins de test, je simule une erreur critique, la perte de liaison avec le serveur de base de données.
En l’occurrence, j’ajoute une entrée dans le /etc/hosts du serveur httpd avec une fausse adresse IP vers le serveur Mysql, ce qui génère l’erreur suivante :

[Sun Mar 15 17:27:09 2009] [error] [client 192.168.0.2] PHP Warning:  mysqli_real_connect():
(HY000/2003): Can't connect to MySQL server on 'mysql-serveur' (113) in /var/www/application/adodb/drivers/adodb-mysqli.inc.php on line 108

Erreur je l’avoue très sournoise, Nagios me disant que mon serveur Mysql répond très bien et que le réseau entre le serveur applicatif et le serveur de base de données est opérationnel.

Comment surveiller ce genre de fichier et alerter Nagios quand quelque chose se produit ?

• SEC Simple Event Correlator

SEC est un programme écrit en Perl, extrêmement puissant et configurable à souhait, qui permet de scruter des fichiers de logs et d’y détecter des événements divers et variés.

Le site est ICI

Côté installation sur le serveur applicatif, pas de soucis :

srv-appli:/usr/local/src# wget http://prdownloads.sourceforge.net/simple-evcorr/sec-2.5.1.tar.gz
srv-appli:/usr/local/src# tar xzvf sec-2.5.1.tar.gz
srv-appli:/usr/local/src# cd sec-2.5.1
srv-appli:/usr/local/src/sec-2.5.1# mkdir /usr/local/bin/sec
srv-appli:/usr/local/src/sec-2.5.1# mkdir /usr/local/bin/sec/etc
srv-appli:/usr/local/src/sec-2.5.1# cp sec.pl /usr/local/bin/sec/

Une configuration toute simple :

srv-appli:/usr/local/bin/sec/etc# cat sec.conf
type=Single
ptype=RegExp
pattern=error
desc=$0
action=shellcmd  /opt/nagios/libexec/eventhandlers/submit_check_result_via_nsca srv-appli  'Application' 2 "$0"

Ici, nous demandons à SEC de réagir sur la chaîne « error » (bien évidemment, vous pouvez affiner vos expression régulières…) et en cas de détection, d’exécuter la commande « /opt/nagios/libexec/eventhandlers/submit_check_result_via_nsca  » avec en paramètre, le nom du host dans Nagios, le nom du service, le code retour Nagios et le message d’erreur.

Auparavant, vous avez ajouté une entrée de type « Passive » dans Nagios :

# NSCA
define service{
        use         passive_checkservice
        host_name    srv-appli
        service_description    Application
        # ici la commande check_smtp n'a aucune signification particuliere
        # c'est simplement que sans check_command cela ne marche pas !
        check_command                check_smtp
      }

Et oui, ce type de fonctionnement implique que vous utilisez NSCA sur le serveur d’application (surveillance passive de Nagios, c’est le serveur d’appli qui envoie l’alerte)

Vous devez sur votre Nagios, avoir une entrée de ce genre

Ne reste plus qu’à lancer le script SEC :

srv-appli:/# perl -w /usr/local/bin/sec/sec.pl -conf=/usr/local/bin/sec/etc/sec.conf -input=/var/log/apache2/application-error.log -log /var/log/sec.log
SEC (Simple Event Correlator) 2.5.1
Reading configuration from /usr/local/bin/sec/etc/sec.conf
1 rules loaded from /usr/local/bin/sec/etc/sec.conf
Stdin connected to terminal, SIGINT can't be used for changing the logging level

On provoque l’erreur

Executing shell command '/opt/nagios/libexec/eventhandlers/submit_check_result_via_nsca srv-appli  'Application' 2 "[Tue Mar 17 11:13:34 2009] [error] [client 192.168.99.14] PHP Warning:  mysqli_real_connect(): (HY000/2003): Can't connect to MySQL server on 'mysql-serveur' (113) in /var/www/application/adodb/drivers/adodb-mysqli.inc.php on line 108"'
Child 10131 created for command '/opt/nagios/libexec/eventhandlers/submit_check_result_via_nsca srv-appli  'Application' 2 "[Tue Mar 17 11:13:34 2009] [error] [client 192.168.99.14] PHP Warning:  mysqli_real_connect(): (HY000/2003): Can't connect to MySQL server on 'mysql-serveur' (113) in /var/www/application/adodb/drivers/adodb-mysqli.inc.php on line 108"'
1 data packet(s) sent to host successfully.

Et l’alerte remonte dans Nagios :

Alerte Nagios

Cela fonctionne mais bon…

Premier point bloquant, cela signifie que l’on utilise la surveillance Passive de Nagios (NSCA) sur le srv-appli, ce qui n’est pas forcément le cas.

Deuxième point bloquant, si une deuxième erreur surgit à la suite (pas de chance hein :-p), c’est celle ci qui sera affichée dans Nagios.
Je peux très bien acquitter l’alarme et passer à côté d’un problème plus crucial…

Pour le test :

srv-appli:/# echo « [Mon Mar 17 14:25:42 2009] [error] Une autre erreur » >> /var/log/apache2/application-error.log

Donc, obligation d’aller sur le serveur, de vérifier le /var/log/Sec.log….

Autre solution

• PRELUDE IDS

Prelude est un « Security Information Management » (SIM) Universel. Prelude collecte, normalise, catégorise, agrège, corrèle et présente tous les événements sécurité indépendamment de la marque ou de la licence du produit dont ces événements sont issus : il est « Agentless ».

Cela tombe très bien, j’avais déjà écrit un billet sur Prelude l’année dernière

http://blog.guiguiabloc.fr/index.php/2008/01/27/installer-et-configurer-prelude/

Vous ne serez pas pas dépaysé.

Pour scruter nos logs, nous allons utiliser un des modules de Prelude : Prelude-lml

Ce n’est pas le rôle premier de ce logiciel (qui est surtout un centralisateur d’alertes IDS/NIDS), mais rien nous interdit de le détourner de sa voie.

Je vous passe l’installation du module sur le serveur d’application ainsi que son enregistrement dans le Prelude Manager, tout est expliqué dans le billet précité.

srv-appli:/# prelude-adduser register prelude-lml "idmef:w admin:r" IP_Prelude_Manager --uid 1000 --gid 1000
prelude-manager:/:# prelude-adduser registration-server prelude-manager
 
... - prelude-lml registration to IP_Prelude_Manager successful

Une configuration succincte pour nos tests :

prelude-lml.conf :
 
file = /var/log/apache2/application-error.log
 
/etc/prelude-lml/ruleset/pcre.rules :
 
regex=(\[error\]);              include = appli.rules;
include = single.rules;
 
/etc/prelude-lml/ruleset/appli.rules :
 
#LOG:[Sun Mar 15 17:27:09 2009] [error] [client 192.168.0.1] PHP Warning:  mysqli_real_connect(
):
 
regex=\[error\] \[client ([\d\.]+)\] ; \
 classification.text=server error; \
 id=44100; \
 revision=1; \
 analyzer(0).name=Appli; \
 analyzer(0).manufacturer=blog.guiguiabloc.fr; \
 analyzer(0).class=Service; \
 assessment.impact.severity=high; \
 assessment.impact.completion=failed; \
 assessment.impact.type=other; \
 assessment.impact.description=Erreur applicative; \
 source(0).node.address(0).category=ipv4-addr; \
 source(0).node.address(0).address=$1; \
 source(0).service.iana_protocol_name=tcp; \
 source(0).service.iana_protocol_number=6; \
 target(0).service.iana_protocol_name=tcp; \
 target(0).service.iana_protocol_number=6; \
 last;

Je ne m’étendrais pas sur les expressions régulières, ni sur les normes IDMEF utilisées (cela prendrait un billet complet) et je vous invite à consulter ses pages :

https://trac.prelude-ids.org/wiki/PreludeLml

http://www.rfc-editor.org/rfc/rfc4765.txt

http://www.gscore.org/blog/index.php/post/2007/08/13/IDMEF-for-dummies-part-1

On reproduit de nouveau l’erreur qui maintenant est interceptée par Prelude-lml et envoyée au Manager

Report Prelude

Déjà plus classieux comme système de centralisations, non

Et là vous me dites « Et comment je le sais tout cela dans Nagios ????? »

Grâce à la communauté Nagios

http://www.nagiosexchange.org/cgi-bin/page.cgi?g=Detailed%2F2287.html;d=1

Vous y trouverez le check_prelude.pl , fonctionnant en NRPE, qui vous permet d’aller vérifier le nombre d’entrées HIGH ou MEDIUM dans la base Mysql Prelude

Nagios remontera donc une alerte Critique ou Warning que vous acquitterez (ou pas :-p) avant d’aller vous connecter sur le Prelude Manager et vérifier la teneur exacte du message d’erreur applicatif et de le supprimer dès sa résolution.

Tout ceci est bien sûr un simple exercice de style, à prendre comme une piste de travail.
Je suis certain que vous trouverez d’autres solutions à mettre en oeuvre.

Amusez vous bien