Catégorie : Open-source

Catégories
Open-source

Un client SIP en ligne de commande

PJSip est un framework (C et Python) open-source permettant de développer simplement des applications de VoIP basées sur le protocole SIP. PJSip est fourni en standard avec PJsua, un client SIP en ligne de commande que nous allons aborder dans ce billet.

Installation

Pour installer PJSip (et donc PJsua) sur votre système (exemple sous Ubuntu), il faut saisir les lignes de commandes suivantes:

# wget http://www.pjsip.org/release/1.0.1/pjproject-1.0.1.tar.bz2
# bzip2 -d pjproject-1.0.1.tar.bz2
# tar xvf pjproject-1.0.1.tar
# cd pjproject-1.0.1
# ./configure
# make dep
# make
# sudo make install
# sudo cp ./pjsip-apps/bin/pjsua-i686-pc-linux-gnu /usr/local/bin/pjsua

Premier lancement de PJsua

PJsua est un client SIP en ligne de commande (CLI) qui utilise les librairies PJSip.

Pour lancer le logiciel, il faut utiliser la commande suivante:

# pjsua

Le menu suivant devrait apparâitre:

Enregistrement d’un compte SIP

Nous allons commencer par nous enregistrer sur notre serveur SIP:

>>> +a
Your SIP URL: (empty to cancel): sip:login@monserveur.mondomaine.com
URL of the registrar: (empty to cancel): sip:monserveur.mondomaine.com
Auth Realm: (empty to cancel): login
Auth Username: (empty to cancel): login
Auth Password: (empty to cancel): password

Je n’utilise pas cette interface textuelle. Culture BSD oblige, je préfère passer les paramètres en ligne de commande de la manière suivante:

# pjsua –id sip:login@monserveur.mondomaine.com –registrar sip:monserveur.mondomaine.com –realm * –username login –password password

ou, encore mieux, par un fichier de configuration:

# vi login.cfg

–id sip:login@monserveur.mondomaine.com
–registrar sip:monserveur.mondomaine.com
–realm *
–username login
–password password

# pjsua –config-file login.cfg

Remarque: si vous souhaitez lancer PJsua directement sur votre serveur SIP il faut ajouter une option pour lui dire de fonctionner sur un autre port SIP (en effet le port par défaut 5060 est utilisé par votre serveur SIP).

# pjsua –local-port=5080 –config-file login.cfg

Nous allons maintenant simuler notre premier appel SIP

Pour simuler un appel entre notre compte « login » (défini dans le fichier login.cfg) et le compte « login2 » , il faut saisir en ligne de commande:

# pjsua –config-file login.cfg sip:login2@monserveur.mondomaine.com

Simuler un appel à partir d’un fichier .WAV

Si vous souhaitez simuler un appel non pas avec un péripherique d’entrée audio mais à partir d’un fichier .wav, il suffit de

# pjsua –config-file login.cfg –play-file=./monficher.wav sip:login2@monserveur.mondomaine.com

Conclusion

Nous avons abordés une infime partie des fonctionnalités proposées par PJSip. Je vous conseille la lecture des documentations officielles.

Catégories
Gstreamer Open-source

J’ai streamé avec GStreamer

Après une introduction à GStreamer qui vous, je l’espère, donné l’eau à la bouche, nous allons poursuivre la découverte de ce superbe framework en nous focalisant sur les fonctions de streaming audio et vidéo.

Avant de commencer à jouer, il faut installer GStreamer et ses composants sur votre machine. Je vous conseille d’installer GStreamer en suivant ce tutoriel. Vous disposerez ainsi des dernières versions des codecs.

Premier streaming vidéo: Theora et UDP

Nous allons dans ce premier exemple diffuser un flux vidéo (venant d’une Webcam) en utilisant le protocole UDP. Nous utiliserons le codec libre Theora (wiki) pour compresser la vidéo.

Sur la machine cliente (celle qui va recevoir et afficher le flux vidéo), il faut saisir la ligne suivante:

# gst-launch -v udpsrc port=1234 ! theoradec ! autovideosink

En clair, GStreamer va écouter le flux vidéo sur le port UDP/1234 (avec udpsrc) puis décompressé le flux Theora (theoradec) et enfin l’afficher sur l’écran (autovideosink).

Sur le serveur (la machine sur laquelle la Webcam est connectée et accessible par /dev/video1), nous allons saisir:

# gst-launch -v v4l2src device=/dev/video1 ! ffmpegcolorspace \
! videoscale method=1 ! video/x-raw-yuv,width=320,height=240,framerate=\(fraction\)15/1 \
! theoraenc bitrate=150 ! udpsink host=127.0.0.1 port=1234

Plusieurs remarques sur cette ligne de commande. On utilise la fonction videoscale pour redimensionner le format d’entrée de la vidéo (en taille et en nombre d’images par seconde) afin de limiter la bande passante. Je force ainsi dans ce cas le codec Theora à 150 Kbps. Enfin, la fonction udpsink permet de diffuser en UDP sur le réseau (port 1234 et adresse destination 127.0.0.1 – celle du client).

Remarque importante: il faut que le client soit lancé avant le serveur.

Streaming vidéo: Theora et TCP

Nous allons modifier légèrement notre premier exemple pour utiliser le protocole TCP en lieu et place du protocole UDP.

Le framework au niveau du client (le poste qui va recevoir le flux vidéo) est:

gst-launch -v tcpserversrc host=127.0.0.1 port=1234 ! decodebin ! autovideosink

GStreamer lance un serveur TCP (en écoute sur le port 1234 de l’adresse 127.0.0.1) et affiche le résultat (on peut utiliser decodebin à la place de theoradec) sur l’écran.

Sur le serveur (la machine avec la WebCam) on lance la commande:

gst-launch -v v4l2src device=/dev/video1 ! ffmpegcolorspace \
! video/x-raw-yuv,width=320,height=240,framerate=\(fraction\)10/1 \
! theoraenc bitrate=200 ! oggmux \
! tcpclientsink host=127.0.0.1 port=1234

On utilise la fonction
videoscale pour redimensionner le format d’entrée de la vidéo (en
taille et en nombre d’images par seconde) afin de limiter la bande
passante. Je force ainsi dans ce cas le codec Theora à 150 Kbps. Enfin,
la fonction tcpclientsink permet de diffuser en TCP sur le réseau (port 1234 et adresse destination 127.0.0.1 – celle du client).

Remarque importante: il faut que le client soit lancé avant le serveur.

Streaming vidéo: Theora et RTP/RTCP

On va compliquer encore un peu plus notre système de streaming en utilisant les protocoles RTP (pour les données) et RTCP (pour les flux de contrôle de ces données).

Contrairement aux deux premiers exemples, il faut lancer le client après le serveur. En effet, il est nécessaire de renseigner, au niveau du client, une chaine de configuration (caps) généré par le serveur.

gst-launch -v  v4l2src \
! videoscale method=1 ! video/x-raw-yuv,width=320,height=240,framerate=\(fraction\)15/2 \
! theoraenc ! rtptheorapay \
! .send_rtp_sink gstrtpsession name=session .send_rtp_src ! udpsink port=5000 host=127.0.0.1  \
session.send_rtcp_src ! udpsink port=5001 host=127.0.0.1

Le serveur va encoder le flux vidéo avec le codec Theora, ajouter les entêtes RTP Theora (rtptheorapay) puis diffuser le flux en UDP (RTP/UDP sur le port 5000) grâce aux plugins gstrtpsession et udpsink. En parallèle, un serveur RTCP (RTCP/UDP) est lancé. Il envoie les information RTCP vers le port 5001 de la machine cliente (127.0.0.1).

Notez le paramètre -v passé à gst-launch. Il est nécessaire pour l’obtention de la chaine de configuration (caps).

Lors du lancement de cette commande, un grand nombre de messages va s’afficher. Il faut récupérer la dernière occurence du type:

caps = application/x-rtp, media=(string) video … seqnum-base=(guint)39194

Nous pouvons alors lancer notre client:

gst-launch udpsrc port=5000 caps= »application/x-rtp, media=(string) video … seqnum-base=(guint)39194 » \
! .recv_rtp_sink gstrtpsession name=session .recv_rtp_src \
! rtptheoradepay !  theoradec ! xvimagesink \
udpsrc port=5001 caps= »application/x-rtcp » ! session.recv_rtcp_sink

Le client écoute le flux de donnée vidéo sur le port UDP/5000. Grâce aux informations fournies dans le champs caps, il peut décoder le flux. On enlève l’entête RTP (rtptheoradepay) puis on décode le flux théora (theoradec) et on affiche. En parallèle, on écoute les flux de contrôle de ces données (RTCP) sur le port 5001 et on les injectent dans le gestionnaire RTP (gstrtpsession).

Streaming vidéo: H.264 et RTP/RTCP

Nous allons modifier l’exemple précedant en remplacant le codec H.264 au lieu de Theora. Pour celà, nous allons utiliser le plugins X.264 (développé par l’équipe VideoLAN).

Contrairement au codec Theora, il n’est pas nécessaire de passer la chaine de configuration « caps » du serveur vers le client.

On a donc la configuration suivante au niveau du serveur (à lancer en premier). Vous pouvez récupérer le script shell correspondant à ici:

WEBCAM_DEV= »/dev/video0″
WEBCAM_WIDTH=352
WEBCAM_HEIGHT=288
WEBCAM_FPS=24
SERVER_IP=$1
SEND_RTP_PORT=5000
SEND_BUFFER=0
X264_BITRATE=600
X264_PARAM= »byte-stream=true bframes=4 ref=4 me=hex subme=4 weightb=true threads=0 sliced-threads=1 vbv-buf-capacity=300″
# With RTCP
SEND_RTCP_PORT=5001
RECV_RTCP_PORT=5002
gst-launch -v  gstrtpbin name=rtpbin \
v4l2src device=$WEBCAM_DEV \
! queue ! videoscale method=1 ! video/x-raw-yuv,width=\(int\)$WEBCAM_WIDTH,height=\(int\)$WEBCAM_HEIGHT \
! queue ! videorate ! video/x-raw-yuv,framerate=\(fraction\)$WEBCAM_FPS/1 \
! queue ! x264enc bitrate=$X264_BITRATE $X264_PARAM ! rtph264pay \
! rtpbin.send_rtp_sink_0 \
rtpbin.send_rtp_src_0 ! udpsink port=$SEND_RTP_PORT host=$SERVER_IP \
rtpbin.send_rtcp_src_0 ! udpsink port=$SEND_RTCP_PORT host=$SERVER_IP sync=false async=false \
udpsrc port=$RECV_RTCP_PORT ! rtpbin.recv_rtcp_sink_0

La seule différence avec l’exemple du chapitre précedant est l’utilisation de l’encodeur X.264 (x264enc qui génére un flux H.264). Pour une description des nombreux paramètres de ce plugin, je vous conseille la lecture de la documentation:

gst-inspect x264enc

La ligne de commande du client est la suivante (la encore vous pouvez récupérer le script shell ici):


RECV_RTP_PORT=5000
RECV_BUFFER=300
CLIENT_IP=$1
RECV_RTCP_PORT=5001
SEND_RTCP_PORT=5002
gst-launch -tv gstrtpbin name=rtpbin latency=$RECV_BUFFER \
udpsrc caps= »application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96″ port=$RECV_RTP_PORT \
! rtpbin.recv_rtp_sink_0 \
rtpbin. ! rtph264depay ! ffdec_h264 ! ffmpegcolorspace ! autovideosink \
udpsrc port=$RECV_RTCP_PORT ! rtpbin.recv_rtcp_sink_0 \
rtpbin.send_rtcp_src_0 ! udpsink port=$SEND_RTCP_PORT host=$CLIENT_IP sync=false async=false

gst-launch -tv gstrtpbin name=rtpbin latency=$RECV_BUFFER \ udpsrc caps= »application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96″ port=$RECV_RTP_PORT \ ! rtpbin.recv_rtp_sink_0 \ rtpbin. ! rtph264depay ! ffdec_h264 ! ffmpegcolorspace ! autovideosink \ udpsrc port=$RECV_RTCP_PORT ! rtpbin.recv_rtcp_sink_0 \ rtpbin.send_rtcp_src_0 ! udpsink port=$SEND_RTCP_PORT host=$CLIENT_IP sync=false async=false


On utilise le décodeur H.264 fourni par FFMpeg (ffdec_h264).

Streaming audio et vidéo: H.264, Speex et RTP/RTCP

Dernier exemple de ce billet qui va streamer un flux vidéo et un flux audio (venant du périphérique de capture standard de votre système). La vidéo sera encodé en H.264 et la vidéo en Speex. Le tout en utilisant le protocole RTP/RTCP.

Le serveur (à lancer en premier). Il faut récupérer la chaine « caps » pour la partie audio Speex.

gst-launch -v  gstrtpbin name=rtpbin \
v4l2src ! videoscale method=1 ! video/x-raw-yuv,width=640,height=480,framerate=\(fraction\)15/2 \
! queue ! x264enc byte-stream=true bitrate=300 vbv-buf-capacity=300 me=0 subme=3 ! rtph264pay \
! rtpbin.send_rtp_sink_0 \
rtpbin.send_rtp_src_0 ! udpsink port=5000 host=127.0.0.1 \
rtpbin.send_rtcp_src_0 ! udpsink port=5001 host=127.0.0.1 sync=false async=false \
udpsrc port=5002 ! rtpbin.recv_rtcp_sink_0 \
alsasrc \
! queue ! speexenc ! rtpspeexpay \
! rtpbin.send_rtp_sink_1 \
rtpbin.send_rtp_src_1 ! udpsink port=5003 host=127.0.0.1 \
rtpbin.send_rtcp_src_1 ! udpsink port=5004 host=127.0.0.1 sync=false async=false \
udpsrc port=5005 ! rtpbin.recv_rtcp_sink_1

Et le client:

gst-launch-0.10 -v gstrtpbin name=rtpbin latency=200 \
udpsrc caps= »application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, profile-level-id=(string)4d4033, sprop-parameter-sets=(string)Z01AM6tAUB7YCIAAAAMBAAADAA9HjBlQ, ssrc=(guint)614294178, payload=(int)96, clock-base=(guint)3718899905, seqnum-base=(guint)59615″ port=5000 \
! rtpbin.recv_rtp_sink_0 \
rtpbin. ! rtph264depay ! ffdec_h264 ! xvimagesink \
udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 \
rtpbin.send_rtcp_src_0 ! udpsink port=5002 host=127.0.0.1 sync=false async=false \
udpsrc caps= »application/x-rtp, media=(string)audio, clock-rate=(int)44100, encoding-name=(string)SPEEX, encoding-params=(string)1, ssrc=(guint)419764010, payload=(int)110, clock-base=(guint)3478167082, seqnum-base=(guint)57894″ port=5003 \
! rtpbin.recv_rtp_sink_1 \
rtpbin. ! rtpspeexdepay ! decodebin ! alsasink \
udpsrc port=5004 ! rtpbin.recv_rtcp_sink_1 \
rtpbin.send_rtcp_src_1 ! udpsink port=5005 host=127.0.0.1 sync=false async=false

Bon stream à vous !

Catégories
Open-source

Actualité open-source de la semaine #49

L’actualité open-source de la semaine…

L’image de la semaine

OOoLiberezVousBlog.png

Un poster de promotion de OpenOffice (à afficher dans votre bureau)

Tout le monde en parle, sauf moi…

L’actualité du libre et de l’open source en vrac:

Autres choses ?

Catégories
Open-source

Introduction à GStreamer, le framework multimedia

Depuis l’intégration dans le noyau de Gnome 2.2, GStreamer est devenu un « framework » multimédia très à la mode. Contrairement à la musique, être à la mode peut être compatible avec qualité. Nous allons dans ce billet aborder cet outil très pratique à partir du moment ou vous voulez développer des applications gérants du son et de la vidéo.

Introduction

GStreamer est une boite à outil permettant de gérer des données multimédia (son et vidéo) de bout en bout: de l’acquisition de la source (fichier, flux réseau, webcam, micro…) au traitement (effet vidéo, audio, encodage) à la diffusion (sur l’écran, dans un fichier, sur le réseau).

Un exemple:

Ce dernier est développé en C (note du Troll: le seul et unique language pour faire ce genre de chose) mais il existe de nombreuse librairie pour appeller GStreamer à partir de logiciel développé dans d’autres languages (C, Java, Perl, Python…et autres). GStreamer existe sous GNU/Linux, BSD et Windows (voir ici la procédure pour compiler GStreamer sous Windows).

Il se base sur une architecture modulaire composé d’un coeur (GStreamer) et de plugins (Base, Good, Ugly, Bad).

Installation de GStreamer

Voici les lignes de commandes à saisir pour installer GStreamer et les plugins sur une distribution GNU/Linux Ubuntu:

# sudo apt-get install gstreamer0.10-tools gstreamer0.10-plugins-base gstreamer0.10-plugins-good gstreamer0.10-plugins-ugly gstreamer0.10-plugins-bad gstreamer0.10-ffmpeg

Pour vérifier que l’installation est ok, vous pouvez lancer la commande suivante qui devrait afficher la liste des plugins disponibles:

# gst-inspect
…
Nombre total : 168 greffons, 762 fonctionnalités

Un premier exemple

Pour tester notre Framework avant de l’intégrer dans votre logiciel, il existe une ligne de commande très pratique: gst-launch.

Nous allons par exemple utiliser GStreamer pour ouvrir un fichier vidéo au format OGG et l’afficher sur notre écran (les bases d’un lecteur multimédia… sans le son ;)):

# gst-launch filesrc location=./Vidéos/big_buck_bunny_480p_stereo.ogg ! oggdemux ! theoradec ! xvimagesink

et le résultat:

Détaillons un peu cette ligne:

 

# gst-launch filesrc location=./Vidéos/big_buck_bunny_480p_stereo.ogg ! oggdemux ! theoradec ! xvimagesink

La commande gst-launch permet de tester un framework en ligne de commande.

# gst-launch filesrc location=./Vidéos/big_buck_bunny_480p_stereo.ogg ! oggdemux ! theoradec ! xvimagesink

Nous appelons en premier le plugin filesrc qui est un plugin qui prend en entrée un fichier multimédia (dont le nom est passé par le paramètre location).

Pour avoir une documentation précise du plugin (et des ses paramètres), vous pouvez utilsier la commande suivante:

# gst-inspect filesrc

# gst-launch filesrc location=./Vidéos/big_buck_bunny_480p_stereo.ogg ! oggdemux ! theoradec ! xvimagesink

Le deuxième plugin utilisé (il faut utiliser le ! entre deux plugins, c’est un peu l’équivalent d’un | pour les commandes Unix) est oggdemux, qui prend en entrée un flux vidéo OGG (fourni dans notre cas par filesrc) et qui de décode.

# gst-launch filesrc location=./Vidéos/big_buck_bunny_480p_stereo.ogg ! oggdemux ! theoradec ! xvimagesink

Ensuite on utilise le plugin theoradec pour décoder la vidéo dont le format est Theora.

# gst-launch filesrc location=./Vidéos/big_buck_bunny_480p_stereo.ogg ! oggdemux ! theoradec ! xvimagesink

Ce dernier plugin (xvimagesink) prend en entrée un flux video décodé (format RAW) et l’affiche sur l’écran en utilisant Xv (XFree86 Video).

Comme on peut le voir, cette logique d’enchaînement de tâches est très intuitive.

Ainsi, si l’on souhaite que notre lecteur vidéo redimmensionne l’image avant de l’afficher, il suffit d’ajouter les plugins suivants (videoscale):

# gst-launch filesrc location=../Vidéos/big_buck_bunny_480p_stereo.ogg ! oggdemux ! theoradec ! videoscale ! video/x-raw-yuv,height=240 ! xvimagesink

Simple non 🙂 ?

D’autres exemples…

Récupération d’un flux venant d’une caméra (sur /dev/video0), redimensionnement en 240 lignes et affichage sur l’écran:

# gst-launch v4l2src ! videoscale ! video/x-raw-yuv,height=240 ! xvimagesink

Récupération d’un flux venant d’une caméra (sur /dev/video0), redimensionnement en 240 lignes, application d’un filtre EffectTV (quarktv qui rend flou les objets en mouvement) et affichage sur l’écran:

# gst-launch v4l2src ! videoscale ! video/x-raw-yuv,height=240 ! ffmpegcolorspace ! quarktv ! ffmpegcolorspace ! xvimagesink

Dans nos premiers exemples, nous avons traités notre flux de manière séquentielle. Si nous voulons, par exemple, ajouter l’audio à notre lecteur multimédia il faut que GStreamer gére la vidéo et le son en parallèle. On va utiliser le plugin queue qui a pour fonction de créer un nouveau « thread » GStreamer.

Notre lecteur multimédia devient donc:

# gst-launch filesrc location=./Vidéos/big_buck_bunny_480p_stereo.ogg ! oggdemux name=demux \
demux. ! queue ! vorbisdec ! audioconvert ! audioresample ! osssink \
demux. ! queue ! theoradec ! xvimagesink

On peut améliorer le lecteur en laissant GStreamer sélectionner lui même les sorties audio et vidéo (autodetect):

# gst-launch filesrc location=./Vidéos/big_buck_bunny_480p_stereo.ogg ! oggdemux name=demux \
demux. ! queue ! vorbisdec ! audioconvert ! audioresample ! autoaudiosink \
demux. ! queue ! theoradec ! autovideosink

Je m’arrête là pour ce premier article sur GStreamer. Nous reviendrons bientôt sur ce passionnant sujet notamment en abordant l’encodage audio et vidéo et le streaming sur le réseau.Je vous laisse consulter la longue liste des plugins pour trouver votre bonheur. N’hésitez pas à proposer vos framework GStreamer en ligne de commande dans les commentaires 😉

Catégories
Open-source

Mise à jour de Nagios en version 3.1.0

Ce week-end est sortie la version 3.1.0 de Nagios, notre outil de supervision libre favori. Si vous avez suivi la série d’articles suivants pour installer votre serveur Nagios, alors nous allons voir comment mettre à jour Nagios dans cette dernière version.

Attention, à l’heure actuelle (26/01/2009) cette version est une version de développement/test. A ne pas mettre sur un serveur de production.

Nagios.jpg

Les nouveautés de cette version 3.1.0

Le « changelog » traduit en Français est disponible ici. A noter que cette version est mineure et prépare le terrain pour la future version 3.2.0. Au niveau de l’interface Web à noter l’utilisation du langage PHP.

Mise à jour de Nagios 3.1.0 depuis une version 3.0.x

Backup de l’ancienne version

Il est préférable de sauvegarder son ancienne configuration… au cas ou..

   # cd /tmp

# tar zcvfh ./nagios-backup.tgz /usr/local/nagios –exclude var/archives

ATTENTION: mettre deux – avant le exclude

Si quelque chose se passe mal au niveau de la mise à jour, il sera toujours possible de revenir en arrière en saisissant les commandes suivantes:

   # cd /tmp

   # tar zxvf ./nagios-backup.tgz

Téléchargement de la dernière version

Il faut au préalable des opérations suivantes, se loguer en tant qu’utilisateur nagios afin que les fichiers soient générés avec les bons droits.

Sur Ubuntu ou Debian:

   # sudo -s nagios

Puis télécharger la dernière version stable (3.1.0 au moment de l’écriture de ce billet).

   # mkdir src

   # cd src

# wget http://switch.dl.sourceforge.net/sourceforge/nagios/nagios-3.1.0.tar.gz

Compilation et installation

On décompresse puis on lance la compilation:

# tar zxvf nagios-3.1.0.tar.gz

# cd nagios-3.1.0

# ./configure –with-command-group=nagios

ATTENTION: mettre deux – avant le with

   # make all

Si la compilation se termine sans erreur, vous pouvez l’installer sur votre système, sinon je vous conseille de poster votre erreur dans le forum officiel de Nagios:

# make install

# rm -rf /usr/local/nagios/share

# make install-html

Vérification de la configuration et redémarrage de Nagios

On va dans un premier temps vérifier que nos fichiers de configurations sont compatibles avec cette nouvelle version:

   # /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

   Si vous avez ce rapport à la fin:

   Total Warnings: 0

   Total Errors: 0

   C’est bon pour vous 😉

Finalement on relance Nagios (en repassant en mode root) dans la nouvelle version:

Sur Ubuntu ou Debian:

# /etc/init.d/nagios restart

Et voilà le travail !

Catégories
Open-source

Actualité open-source de la semaine #48

L’actualité open-source de la semaine…

L’image de la semaine

linux-birthday.jpeg (Image JPEG, 150x150 pixels).jpg
Bon anniversaire (10 ans déjà…) à Lea-Linux

Tout le monde en parle, sauf moi…

L’actualité du libre et de l’open source en vrac:

  • Vous cherchez un webmail open-source ? ce billet devrait vous intéresser.
  • LemonLDAP (le SSO libre) passe en version 0.9.3
  • Bruxelles se penche enfin sur Internet Explorer
  • MLO, une distribution Linux pour migrer facilement depuis Windows
  • Adobe va libérer le protocole RTMP: on va enfin voir des lecteurs FLV libre et stable
  • FDN premier FAI full IPv6

Autres choses ?

Catégories
Nagios Open-source Reseau Systeme

Le serveur de supervision libre – PART 4

Nous arrivons bientôt à la fin de l’installation de notre serveur de supervision. Avec Nagios et Centreon il est parfaitement opérationnel. Je trouve cependant qu’il manque encore à Centreon des fonctions de graphes évoluées. C’est pour cela que je propose d’ajouter sur notre bébé un serveur Cacti.

PART 1 – Installation du système d’exploitation GNU/Linux
PART 2 – Installation de Nagios
PART 3 – Installation de Centreon
PART 4 – Installation de Cacti

Lire la suite « Le serveur de supervision libre – PART 4 »
Catégories
Nagios Open-source Reseau Systeme

Le serveur de supervision libre – PART 3

Les deux premiers billet de cette série nous ont permis d’installer le coeur de notre serveur de supervision: le logiciel Nagios. Nous allons donc maintenant nous occuper de l’enrobage: l’interface Web d’administration Centreon.

PART 1 – Installation du système d’exploitation GNU/Linux
PART 2 – Installation de Nagios
PART 3 – Installation de Centreon
PART 4 – Installation de Cacti

Centreon offre à Nagios une nouvelle interface et lui apporte de nouvelles fonctionnalités. Il va rendre la configuration de Nagios plus facile et d’avoir une interface graphique améliorée. C’est une interface qui pour moi n’est pas obligatoire mais qui peut s’avérer utile dans certains cas:

  • si une équipe doit gérer le serveur Nagios, il sera plus facile de les former en utilisant Centreon
  • si vous êtes allergique aux fichiers de configuration au format texte
  • si vous êtes un “accro” aux interfaces Web

Attention toutefois, Centreon va générer des fichiers de configuration de Nagios à sa manière. Vous allez donc perdre tout le contrôle sur ces fichiers… Bref si vous êtes un administrateur système soigneux, qui prend soit de commenter/archiver voir gérer en configuration ce type de fichiers, je vous conseille de passer votre chemin et d’attendre le prochain billet de cette série.

Lire la suite « Le serveur de supervision libre – PART 3 »

Catégories
Nagios Open-source Reseau Systeme

Le serveur de supervision libre – PART 2

Attention:

avant de suivre ce tutoriel, il faut avoir effectuer toutes les étapes
de la première partie de tutoriel (PART1) qui est disponible ici.

Actuellement le couple NDO / Centreon n’est pas compatible avec Nagios 4.

Dans un premier billet, nous avons installé un serveur GNU/Linux. Il est maintenant temps de passer au chose sérieuse en installant le coeur de notre système: Nagios.

A l’heure ou je rédige ce billet, la dernière version de Nagios est la 3.5.1, hors si on regarde la version disponible dans les packages apt d’Ubuntu, on voit qu’ils sont un peu en retard au niveau des version. C’est donc pour cette raison que je préfère compiler Nagios depuis les sources afin de disposer de la dernière version sur notre serveur de supervision.

Lire la suite « Le serveur de supervision libre – PART 2 »
Catégories
Nagios Open-source Reseau Systeme

Le serveur de supervision libre – PART 1

Cela fait maintenant un petit moment que ce blog existe. Il aborde bien des sujets autours des logiciels libres mais il y en a un qui suscite plus d’intérêt que les autres: la supervision système et réseau. La complexité de ces logiciels et la faible documentation Francophone (bien que ce soit en train de changer) y est surement pour quelque chose.

Je propose donc de commencer une série de billets sur l’installation d’un serveur de supervision basé uniquement sur des solutions libres.

PART 1 – Installation du système d’exploitation GNU/Linux
PART 2 – Installation de Nagios
PART 3 – Installation de Centreon
PART 4 – Installation de Cacti

Les caractéristiques de ce serveur seront les suivantes:

  • Système d’exploitation: GNU/Linux Ubuntu Server Edition 8.10 ou supérieure
  • Nagios 3.4.1
  • Centreon 2.3.8
  • Cacti 0.8.7i

Trêve de blabla, entrons directement dans le vif du sujet avec l’installation du système d’exploitation et des pré-requis systèmes qui vont servir de base à notre serveur de supervision.

Lire la suite « Le serveur de supervision libre – PART 1 »