Nagios, que j’aborde souvent dans ce blog, débarque en version 3.0. La liste des nouveautés est très longue, je vous invite à la consulter ici.
Concernant l’installation de cette nouvelle version , je vous rappelle que j’avais écrit un billet dessus il y a quelques temps (la procédure reste la même). Je reparlerai vite des nouvelles fonctions dans un prochain billet.
Le but de ce tutoriel est de créer un tunnel IPSec entre deux réseaux privées (chez vous et chez un pote pas exemple) reliés par une connexion Internet publique. La solution proposée se base sur OpenSwan (exemple de configuration sous Ubuntu mais applicable sous n’importe quel Unix et BSD like)
Infrastructure servant de base au tutoriel:
PRIVEE_A — ROUTEUR VPN A — PUBLIQUE_A — INTERNET — PUBLIQUE_B — ROUTEUR VPN B — PRIVEE_B
Installation de OpenSwan
# sudo apt-get install openswan
Génération des clés:
Si vous utilisez Iperf pour calculer les performances de votre réseau, le programme XJperf vous intéressera sûrement. Reprenant une interface existante (Jperf), l’auteur du programme a considérablement améliorer les fonctionnalités et la stabilité de cette interface utilisateur.
XJperf permet donc de prendre en main très rapidement l’application Iperf, sans avoir à en connaître par coeur les (nombreuses) options. C’est un moyen idéal pour connaître la bande passante, le délais de transit et la gigue entre deux équipements réseaux.
PS: l’auteur de ce programme écrit également quelques billets pour « Le blog de Nicolargo ».
Ce billet a pour but de détailler l’installation et la configuration d’un serveur SNMP sous Linux. J’ai choisi d’utiliser la solution open-source net-snmpd.
Celle-ci dispose d’une communauté de développeurs très active. De plus cette solution est disponible sous de nombreux OS (Linux, BSD mais aussi Mac OS X et même Windows !).
Vous voulez tester la bande passante entre votre ordinateur et n’importe quel point du globe ? Le site SpeedTest est fait pour vous !
Il permet le calcul des débits montant, descendant et du temps de latence moyen entre votre ordinateur et une liste impressionnante de serveurs de test répartis sur notre belle planète.
Attention: Apple a choisi de migrer de IPFW vers PF à partir de OS X Lion (ce qui en soit un un bon choix…).
La syntaxe est complètement différente. Pour effectuer une limite de bande passante avec PF il faut passer par un module externe (à voir si il est installé par défaut sous OS X Lion) nommé altq.
Je conseille la lecture des billets suivants:
– De IPFW à PF (sur ce blog)
– Packet Queueing and Prioritization
– Bandwidth Limiting with pf and ALTQ
Attention: « DAHDI is the new name for ‘Zaptel’ as of May 19th 2008 »
/etc/zaptel.conf devient /etc/dahdi/system.conf
/etc/asterisk/zapata.conf devient /etc/asterisk/chan_dahdi.conf
Les cartes Digium sont indissociables d’Asterisk. Elles permettent la gestion de liaisons téléphoniques de type E1/T1, ISDN ou PSTN.
Nous allons dans ce billet détailler l’installation d’une carte Digium TE220 (compatible E1/T1) sous Linux.
Installation de la carte
Une fois la carte déballée, il faut vérifier que le jumper de sélection entre les normes T1 (US) et E1 (Europe) est bien positionné. Pour une liaison RNIS Européenne (E1), il faut que les jumpers soient fermés.
Une fois la carte installée physiquement dans le serveur (slot PCI-X), nous allons, dans un premier temps, vérifier qu’elle est bien identifiée par Linux:
# dmesg
…
Found a Wildcard: Wildcard TE220 (4th Gen)
…# lspci -n
…
04:08.0 0780: d161:0220 (rev 02)
…
On récupère sur le site de Digium la dernière version des librairies PRI:
# wget http://downloads.digium.com/pub/telephony/libpri/libpri-1.4.5.tar.gz
PS: Remplacer 1.4.5 par la dernière version disponible.
puis on les installe:
# tar zxvf libpri-1.4.5.tar.gz
# cd libpri-1.4.5
# make
# sudo make install
On enchaîne avec le téléchargement des drivers Zaptel:
# wget http://downloads.digium.com/pub/telephony/zaptel/zaptel-1.4.11.tar.gz
PS: Remplacer 1.4.11 par la dernière version disponible.
et leur installation:
# tar zxvf zaptel-1.4.11.tar.gz
# cd zaptel-1.4.11
# ./install_prereq test
=> On vérifie que les pre-requis sont OK (sinon on lance ./install_prereq install)
# ./configure
# make
# make install
# make config
La carte TE200 partage les mêmes drivers que les TE400 (module wct4xxp). Afin d’optimiser le démarrage des modules, j’ai également modifié le fichier /etc/sysconfig/zaptel en suppriment toutes les occurrences MODULES et en laissant la ligne suivante:
…
MODULES= »$MODULES wct4xxp »
…
Nous pouvons redémarrer le serveur pour vérifier que le module est bien lancé au démarrage. Pour vérifier:
# lsmod
…
wct4xxp 400512 0
zaptel 190852 3 wct4xxp
…
Attention: il faut installer libpri AVANT d’installer Asterisk sinon le driver ne sera pas généré. Si vous avez déjà Asterisk installé sur votre système, il faudra le réinstaller….
Configuration de la carte
Nous allons d’abord définir les caractéristiques de la carte dans le fichier /etc/asterisk/zapata.conf. Pour une liaison E1 PRI (standard en Europe), vous pouvez utiliser la configuration suivante (voir ici http://docs.tzafrir.org.il/dahdi-tools pour une liste complète des paramètres):
group=1
signalling=pri_cpe
switchtype=euroisdn
context=incoming
channel=>1-15,17-31
Puis les caractéristiques de la liaison E1/T1 utilisée. Pour cela, il faut éditer le fichier /etc/zaptel.conf:
span=1,1,0,ccs,hdb3
bchan=1-15,17-31
dchan=16
Initialisation de la carte
Si vous n’avez pas rebooter votre serveur depuis l’installation des drivers, il faut commencer par charger le driver Zaptel dans le noyau Linux:
# modprobe wct4xxp
Ensuite, on doit lancer la configuration (une fois la liaison E1 connectée sur la carte):
# ztcfg -vv
Vérification de l’état des liaisons E1
Le plus simple est d’utiliser l’utilitaire zttool qui affiche l’état des liaisons:
# zttool
Il est également possible de vérifier si les liaisons sont bien montées en lançant Asterisk en mode debug:
# asterisk -vvvr
Et voilou, et à bientôt pour voir comment utiliser ces liaisons avec Asterisk…
Nous commençons l’année 2008 avec un billet regroupant des exemples d’utilisation d’IPerf, l’outil en ligne de commande indispensable pour tester un réseau informatique.
Pour rappel, IPerf est un logiciel client/serveur, il faut donc deux machines positionner aux deux extremités du réseau à tester pour fonctionner (pour l’installation et une rapide introduction, vous pouvez consulter ce billet).
Dans les exemples ci-dessous, nous allons considérer que nous allons utiliser deux machines nommées C (avec comme adresse IP: IPC) et S (avec comme adresse IP: IPS).
Attention, cette méthode mesure la bande passante au moment du test. Ce dernier dure par défaut 10 secondes et utilise le protocole TCP sur le port 5001.
Sur la machine S: # iperf -s
Sur la machine C: # iperf -c IPS
Résultat (à lire sur la machine S):
————————————————————
Server listening on TCP port 5001TCP window size: 56.0 KByte (default)
————————————————————
[ 6] local 192.168.29.1 port 5001 connected with 192.168.29.157 port 54334
[ 6] 0.0-10.0 sec 112 MBytes 93.7 Mbits/sec
On génère ici un flux en utilisant le protocole UDP et en fixant la bande passante à 1 Megabits par seconde. Le test dure par défaut 10 secondes.
Il est possible de choisir l’unité de mesure de débit avec l’option -b et en collant les lettres suivantes aux débits:
pour un débit en octets par seconde, il faut utiliser ces lettres en majuscule)
Sur la machine S: # iperf -s -u
Sur la machine C: # iperf -c IPS -u -b 4m
Résultat (à lire sur la machine S):
————————————————————
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 41.1 KByte (default)
————————————————————
[ 5] local 192.168.29.1 port 5001 connected with 192.168.29.157 port 49617
[ 5] 0.0-10.0 sec 4.77 MBytes 4.00 Mbits/sec 0.066 ms 0/ 3403 (0%)
Il peut être utile de générer un flux réseau plus long pour tester par exemple une liaison Internet pendant les heures d’utilisation. Nous allons donc utiliser l’option -t pour fixer la durée du test précédent à 10 heures (10*3600=36000 secondes).
Sur la machine S: # iperf -s -u
Sur la machine C: # iperf -c IPS -u -b 4m -t 36000
Résultat (à lire sur la machine S):
————————————————————
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 41.1 KByte (default)
————————————————————
[ 5] local 192.168.29.1 port 5001 connected with 192.168.29.157 port 49617
[ 5] 0.0-36000.0 sec 4.77 MBytes 4.00 Mbits/sec 0.066 ms 0/ 999403 (0%)
Il est également possible d’ajouter l’option -i 3600 pour avoir un rapport intermédiaire toutes les heures (1*3600=3600 secondes).
Sur la machine S: # iperf -s -u
Sur la machine C: # iperf -c IPS -u -b 4m -t 3600
Résultat (à lire sur la machine S):
————————————————————
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 41.1 KByte (default)
————————————————————
[ 5] local 192.168.29.1 port 5001 connected with 192.168.29.157 port 49617
[ 5] 0.0-3600.0 sec 4.77 MBytes 4.00 Mbits/sec 0.066 ms 0/ – (0%)
[ 5] 3600.0-7200.0 sec 4.77 MBytes 4.00 Mbits/sec 0.066 ms 0/ – (0%)…
[ 5] 0.0-36000.0 sec 4.77 MBytes 4.00 Mbits/sec 0.066 ms 0/ 999403 (0%)
Il est parfois utile de générer plusieurs flux UDP simultanément pour simuler une application. IPerf permet cela grâce à l’option -P et en donnant le nombre de flux à générer. L’exemple suivant génère 4 flux TCP entre S et C (simulation d’un serveur Web par exemple).
Sur la machine S: # iperf -s
Sur la machine C: # iperf -c IPS -P 4
Résultat (à lire sur la machine S):
————————————————————
Server listening on TCP port 5001
TCP window size: 56.0 KByte (default)
————————————————————
[ 6] local 192.168.29.1 port 5001 connected with 192.168.29.157 port 64978
[ 7] local 192.168.29.1 port 5001 connected with 192.168.29.157 port 64979
[ 8] local 192.168.29.1 port 5001 connected with 192.168.29.157 port 64980
[ 9] local 192.168.29.1 port 5001 connected with 192.168.29.157 port 64981
[ 7] 0.0-10.0 sec 28.0 MBytes 23.5 Mbits/sec
[ 8] 0.0-10.0 sec 28.0 MBytes 23.4 Mbits/sec
[ 9] 0.0-10.0 sec 28.1 MBytes 23.5 Mbits/sec
[ 6] 0.0-10.0 sec 28.1 MBytes 23.5 Mbits/sec
[SUM] 0.0-10.0 sec 112 MBytes 93.8 Mbits/sec
Le protocole TCP, bien que capable pour s’adapter aux réseaux large bande, a été conçu lorsque les débits étaient beaucoup moins important. Les valeurs par défaut des fenêtres TCP (taille des paquets envoyé dans des trames TCP) ne sont pas forcement adapté aux réseaux actuels. IPerf permet de jouer avec la taille de ces fenêtres avec l’option -w. L’exemple suivant génère un flux TCP avec une taille de fenêtre de 130 kilo octets.
Sur la machine S: # iperf -s
Sur la machine C: # iperf -c IPS -w 128k
Résultat (à lire sur la machine S):
————————————————————
Client connecting to 192.168.29.1, TCP port 5001
TCP window size: 128 KByte (WARNING: requested 130 KByte)
————————————————————
[ 3] local 192.168.29.157 port 65066 connected with 192.168.29.1 port 5001
[ 3] 0.0-10.0 sec 112 MBytes 93.5 Mbits/sec
Le MTU est la taille maximale du paquet pouvant être transmis sur la couche réseau sans être segmenté. La découverte de cette valeur peut être utile à l’optimisation de votre réseau et des applications qui tourne dessus. IPerf permet d’obtenir cette valeur grâce à l’option -m (à lancer sur le serveur).
Sur la machine S: # iperf -s -m
Sur la machine C: # iperf -c IPS
Résultat (à lire sur la machine S):
————————————————————
Client connecting to 192.168.29.1, TCP port 5001
TCP window size: 56.0 KByte (default)
————————————————————
[ 3] local 192.168.29.157 port 65066 connected with 192.168.29.1 port 5001
[ 3] 0.0-10.0 sec 112 MBytes 93.5 Mbits/sec[ 3] MSS size 1448 bytes (MTU 1500 bytes, ethernet)
Les paquets de type voix sur IP on les caractéristiques suivantes: protocole UDp et taille des paquets petites (bien inférieure au MTU). Le meilleur moyen de tester un flux de type VoIP avec IPerf est d’utiliser les options -l (taille du datagram) et -w (taille maximale du buffer recevant les datagras) en fixant une valeur de datagram inférieure à celle du buffer.
Sur la machine S: # iperf -s -u -l 32 -w 128k -i 1
Sur la machine C: # iperf -c IPS -u -b 1m -l 32 -w 128k
Résultat (à lire sur la machine S):
————————————————————
Server listening on UDP port 5001
Receiving 32 byte datagrams
UDP buffer size: 128 KByte
————————————————————
[ 3] local 192.168.29.157 port 5001 connected with 192.168.29.125 port 32778
[ 3] 0.0- 1.0 sec 96.0 KBytes 786 Kbits/sec 0.003 ms 0/ 3 (0%)
[ 3] 1.0- 2.0 sec 128 KBytes 1.05 Mbits/sec 0.008 ms 0/ 4 (0%)
[ 3] 2.0- 3.0 sec 128 KBytes 1.05 Mbits/sec 0.017 ms 0/ 4 (0%)
[ 3] 3.0- 4.0 sec 128 KBytes 1.05 Mbits/sec 0.021 ms 0/ 4 (0%)
[ 3] 4.0- 5.0 sec 128 KBytes 1.05 Mbits/sec 0.023 ms 0/ 4 (0%)
[ 3] 5.0- 6.0 sec 96.0 KBytes 786 Kbits/sec 0.022 ms 0/ 3 (0%)
[ 3] 6.0- 7.0 sec 128 KBytes 1.05 Mbits/sec 0.152 ms 0/ 4 (0%)
[ 3] 7.0- 8.0 sec 128 KBytes 1.05 Mbits/sec 0.142 ms 0/ 4 (0%)
[ 3] 8.0- 9.0 sec 128 KBytes 1.05 Mbits/sec 0.115 ms 0/ 4 (0%)
[ 3] 9.0-10.0 sec 128 KBytes 1.05 Mbits/sec 0.098 ms 0/ 4 (0%)
[ 3] 0.0-10.5 sec 1.25 MBytes 1.00 Mbits/sec 0.116 ms 0/ 40 (0%)
Remarque: bien que Iperf soit disponible sur de nombreuses plate-forme (Linux, BSD, Mac, Windows), l’option -l ne fonctionne pas toujours quand vous utiliser des OS différents entre le client et le serveur.
Par défaut, Iperf utilise le numéro de port 5001 (TCP et/ou UDP). Selon votre configuration (notamment au niveau des ACL des routeurs/firewalls), il peut être utile d’utiliser un autre port, pour cela, il faut passer par l’option -p. L’exemple suivant permet de générer un flux réseau TCP entre S et C sur le port 80 (port Web standard).
Sur la machine S: # iperf -s -p 80
Sur la machine C: # iperf -c IPS -p 80
Résultat (à lire sur la machine S):
————————————————————
Server listening on TCP port 80
TCP window size: 56.0 KByte (default)
————————————————————
[ 6] local 192.168.29.1 port 5001 connected with 192.168.29.157 port 54334
[ 6] 0.0-10.0 sec 112 MBytes 93.7 Mbits/sec
Voici donc quelques exemple d’utilisation d’Iperf, si vous en avez d’autres, les commentaires sont ouverts !
J’ai dû me pencher sur le cas suivant: utilisation d’une carte Osprey 100 (carte de capture/encodage vidéo) sous Linux Ubuntu. Bonne nouvelle pour ceux que cela intéresse, la carte Osprey (construite autout chipset bt878) est maintenant reconnue en standard. Plus besoin donc de passer par une fastidieuse installation de driver.
La configuration que j’utilise est la suivante:
Nous allons donc dans un premier temps vérifier que la carte est bien reconnue, puis la tester avec le bien connu client VideoLAN (VLC).
Vérifier que votre carte est reconnue
Après l’installation de la carte dans un port PCI de votre machine, il faut lancer la commande dmesg et vérifier que les lignes « bttv » sont bien présentes.
# dmesg
…
[ 25.223280] bttv: driver version 0.9.17 loaded
[ 25.223285] bttv: using 8 buffers with 2080k (520 pages) each for capture
[ 25.223332] bttv: Bt8xx card found (0).
[ 25.223345] ACPI: PCI Interrupt 0000:07:09.0[A] -> GSI 21 (level, low) -> IRQ 17
[ 25.223363] bttv0: Bt878 (rev 2) at 0000:07:09.0, irq: 17, latency: 32, mmio: 0xf0800000
[ 25.223374] bttv0: detected: Osprey-100 [card=82], PCI subsystem ID is 0070:ff00
[ 25.223376] bttv0: using: Osprey 100/150 (878) [card=82,autodetected]
[ 25.223399] bttv0: gpio: en=00000000, out=00000000 in=00ffffff [init]
[ 25.248231] bttv0: osprey eeprom: card=82 name=Osprey 100/150 (878) serial=1516003
[ 25.248234] bttv0: using tuner=-1
[ 25.248237] bttv0: i2c: checking for TDA9887 @ 0x86… not found
[ 25.248910] bttv0: registered device video0
[ 25.248934] bttv0: registered device vbi0
[ 25.248956] bttv0: PLL: 28636363 => 35468950 .<6>tpm_inf_pnp 00:0b: Found TPM with ID IFX0102…
Puis ensuite confirmer grâce à la commande lspci:
# lspci | grep 878
07:09.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 02)
07:09.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 02)
Tester la carte
Pour tester, nous allons utiliser VLC. Si votre carte est assignée au device video0 (comme pour moi), alors il suffit de lancer VLC, cliquer sur Fichier/Ouvrir un périphérique de capture, renseigner les champs Nom du périphérique (avec /dev/video0) et Norme (avec PAL) puis cliqer sur OK. VLC devrait, si tout va bien afficher la video capturée par la carte Osprey.
Exemple équivalent en ligne de commande pour streamer depuis la caméra vers une adresse IP 192.168.0.1:
# vlc v4l:// :v4l-vdev= »/dev/video0″ :v4l-adev= »/dev/dsp » :v4l-norm=0 :v4l-frequency=-1 –sout ‘#transcode{vcodec=mp4v,vb=768,scale=1}:duplicate{dst=display,dst=std{access=udp,mux=ts,dst=192.168.29.157:1234}}’
Il ne vous reste plus qu’a suivre un des nombreux tutorial disponible sur le Web pour streamer votre video en IP sur votre réseau.
—
Cette procédure est obsolète (écrite pour la version 0.4.x de Pnp4Nagios).
=> Merci de consulter cette procédure
—
PNP is not PerfParse est un module permettant à Nagios de stocker dans une base RRD et d’afficher via une interface Web des données provenant de vos plugins Nagios. Actuellement en version de développement (0.4.14 au moment de l’écriture de ce billet), PNP comble un manque important dans Nagios: la génération de graphiques personnalisés intégrés à l’interface Web.
Nous allons dans ce billet installer PNP sur une configuration Nagios existante (cliquez ici pour accèder à des tutoriels d’installation de Nagios).
Update du 24/08/2009: Mise à jour de la procédure pour PNP version 0.4.14 et suppression des informations concernant la version 2.x de Nagios.
On récupère la dernière version des sources et on décompresse (en root):
# cd /usr/src
# wget http://downloads.sourceforge.net/pnp4nagios/pnp-0.4.14.tar.gz
# tar zxvf pnp-0.4.14.tar.gz
# cd pnp-0.4.14
Puis on configure:
# ./configure
General Options:
————————- ——————-
Nagios user/group: nagios nagios
Install directory: /usr/local/nagios
HTML Dir: /usr/local/nagios/share/pnp
Config Dir: /usr/local/nagios/etc/pnp
Location of rrdtool binary: /usr/bin/rrdtool Version 1.2.15
RRDs Perl Modules: FOUND (Version 1.2015)
RRD Files stored in: /usr/local/nagios/share/perfdata
process_perfdata.pl Logfile: /usr/local/nagios/var/perfdata.log
Perfdata files (NPCD) stored in: /usr/local/nagios/var/spool/perfdata/
Il faut vérifier que le résultat de cette configuration correspond à votre système, puis ensuite seulement lancer la compilation:
# make all
# make install
# make install-config
Il existe 3 méthodes pour intégrer PNP à Nagios. Dans ce billet, nous allons aborder la seconde (appelée « bulk-mode ») qui est un bon compromis entre la complexité d’installation et les performances obtenues.
Dans cette installation « bulk-mode », les données de vos futurs graphes sont collectés dans un fichier temporaire. Ce fichier est traité de manière à intervalles réguliers par le script perl process_perfdata.pl.
La première chose à faire est d’éditer le fichier nagios.cfg et de modifier la configuration:
# sudo vi /usr/local/nagios/etc/nagios.cfg
process_performance_data=1
#
# service performance data
#service_perfdata_file=/usr/local/nagios/var/service-perfdata
service_perfdata_file_template=DATATYPE::SERVICEPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tSERVICEDESC::$SERVICEDESC$\tSERVICEPERFDATA::$SERVICEPERFDATA$\tSERVICECHECKCOMMAND::$SERVICECHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$\tSERVICESTATE::$SERVICESTATE$\tSERVICESTATETYPE::$SERVICESTATETYPE$
service_perfdata_file_mode=a
service_perfdata_file_processing_interval=15
service_perfdata_file_processing_command=process-service-perfdata-file#
# host performance data
#host_perfdata_file=/usr/local/nagios/var/hostperfdata
host_perfdata_file_template=DATATYPE::HOSTPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tHOSTPERFDATA::$HOSTPERFDATA$\tHOSTCHECKCOMMAND::$HOSTCHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$
host_perfdata_file_mode=a
host_perfdata_file_processing_interval=15
host_perfdata_file_processing_command=process-host-perfdata-file
Reste à éditer le fichier commands.cfg (/usr/local/nagios/etc/objects/commands.cfg sous Nagios 3):
# sudo vi commands.cfg
define command{
command_name process-service-perfdata
command_line $USER1$/process_perfdata.pl –bulk=/usr/local/nagios/var/service-perfdata
}define command{
command_name process-host-perfdata-file
command_line $USER1$/process_perfdata.pl –bulk=/usr/local/nagios/var/host-perfdata
}
Reste à vérifier votre configuration et à relancer Nagios:
# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart
Remarque, si vous rencontrez l’erreur suivant:
Error: Unable to write to temp_path (‘/usr/local/nagios/var/spool/checkresults’) – Permission denied
Error: Unable to write to check_result_path (‘/usr/local/nagios/var/spool/checkresults’) – Permission denied
Il faut modifier les droits sur le répertoire en faisant:
# sudo chmod -R 777 /usr/local/nagios/var/spool/checkresults
Puis pour Nagios 3:
# sudo chown -R nagios:nagios /usr/local/nagios/var/hostperfdata
Maintenant que l’installation est terminé, vous pouvez accéder à l’interface Web via l’URL suivante: http://AdresseServeurNagios/nagios/pnp/
Voici un aperçu de l’interface:
Après installation on a donc deux interfaces Web distinctes: celle de Nagios et celle de PNP. Pour intégrer PNP dans Nagios, il faut utiliser les action_url.
Sous Nagios 3, c’est dans le fichier template.cfg qu’il faut faire les ajouts:
define host {
name nomdutemplatehost
…
action_url /nagios/pnp/index.php?host=$HOSTNAME$
}define host {
name nomdutemplateservice
…
action_url /nagios/pnp/index.php?host=$HOSTNAME$&srv=$SERVICEDESC$
}
Une fois Nagios redémarré, une nouvelle icône (
) devrait apparaître à coté des hosts et services concernés:
Vous avez donc maintenant un nouvel outil bien utile intégré à Nagios. Pour aller plus loin (notamment si vous souhaitez écrire vos propres templates), le mieux est de se rendre sur le site officiel de PNP.