Je prends 3 semaines de vacance pour profiter de la vie en général et de ma famille en particulier. On se retrouve fin août pour la suite des aventures…

“L’optimiste se dit qu’un travailleur a droit à 5 semaines de congé par an.
Le pessimiste, lui, se dit que des tas de braves gens sont obligés d’interrompre chaque année leurs vacances pendant 47 semaines pour aller bosser.”

Philippe Geluck

Quelques exemples de services pour Nagios. N’hésitez pas à donner d’autres exemples via les commentaires ou ma fiche de contact.

J’intégrerai les exemples les plus pertinents au billet.

On menu du jour:

• superviser un serveur Web (HTTP)
• superviser un serveur Web sécurisé (HTTP over SSL)
• superviser un serveur de messagerie (mail)
• superviser un serveur VoIP (sip)
• superviser un serveur de fichiers (samba)
• superviser un serveur annuaire (LDAP)
• superviser un serveur de base de données (mySQL ou pgSQL)
• superviser un serveur réseau (DHCP et DNS)

< tous les plats sont accompagnés de frites et de salade >

Superviser un serveur Web

Nous utilisons pour cela le plugin check_http qui permet de tester si un serveur HTTP est bien lancé sur la machine à superviser.

Exemple:

define command{

command_name check_http

command_line $USER1$/check_http -I $HOSTADDRESS$ $ARG1$

}

define host{

use generic-host

host_name monserveur

alias Serveur Web

address 192.168.0.100

}

define service{

use generic-service

host_name monbeauserveur

service_description HTTP

check_command check_http

}

Pour aller plus loin:

Le plugin utilise par défaut une requête sur le port TCP/80. Pour changer ce port, vous pouvez utiliser l’option -p et créer une nouvelle commande (à utiliser dans le check_command de votre nouveau service):

define command{

command_name check_http_8080

command_line $USER1$/check_http -I $HOSTADDRESS$ $ARG1$-p 8080

}

Superviser un serveur Web sécurisé

Si votre serveur Web est sécurisé avec le protocole SSL. Il faut créer une nouvelle commande basée sur check_http.

Exemple:

define command{

command_name check_http

command_line $USER1$/check_http -S -I $HOSTADDRESS$ $ARG1$

}

define host{

use generic-host

host_name monserveur

alias Serveur Web

address 192.168.0.100

}

define service{

use generic-service

host_name monbeauserveur

service_description HTTPs

check_command check_https

}

Superviser un serveur de messagerie

Pour surveiller un serveur Mail proposant les protocoles SMTP, POP3 et IMAP (merci Dovecot), nous allons utiliser les plugins check_smtp, check_pop et check_imap.

Exemple:

define host{

use generic-host

host_name monserveur

alias Serveur de messagerie

address 192.168.0.100

}

define service{

use generic-service

host_name monserveur

service_description SMTP

check_command check_smtp

}

define service{

use generic-service

host_name monserveurmail

service_description POP

check_command check_pop

}

define service{

use generic-service

host_name monserveurmail

service_description IMAP

check_command check_imap

}

Superviser un serveur Asterisk

Pour surveiller un serveur SIP (par exemple votre serveur Asterisk), nous allons utiliser le plugin check_sip. n’étant pas fourni en standard, il faut d’abord l’installer puis le configurer avant de pouvoir l’utiliser comme service.

Installation:

cd /usr/src

wget http://www.bashton.com/downloads/nagios-check_sip-1.2.tar.gz

tar zxvf nagios-check_sip-1.2.tar.gz

cd nagios-check_sip-1.2

cp check_sip /usr/local/nagios/libexec/

chown apache:nagios /usr/local/nagios/libexec/check_sip

Configuration (à ajouter dans votre fichier commands.cfg de Nagios):

###### SIP#####

define command{

command_name check_sip

command_line $USER1$/check_sip -H $HOSTADDRESS$ -u sip:user@mondomaine.com

}

Il faut penser à mettre un nom d’utilisateur valide après l’option -u.

Et enfin un exemple de service:

define host{

use generic-host

host_name monserveur

alias Serveur SIP

address 192.168.0.100

}

define service{

use generic-service

host_name monserveur

service_description SIP

check_command check_sip

}

Superviser un serveur de fichiers

Un serveur de fichier peut se baser sur de nombreux protocoles. Nous allons nous focaliser sur un serveur Windows ou Linux (avec Samba), souvent utilisé en entreprise grâce au protocole SMB.

Configuration (à ajouter dans votre fichier commands.cfg de Nagios):

###### SMB #####

define command{

command_name check_smb

command_line $USER1$/check_tcp -H $HOSTADDRESS$ -p 445

}

Et enfin un exemple de service:

define host{

use generic-host

host_name monserveur

alias Serveur de fichiers

address 192.168.0.100

}

define service{

use generic-service

host_name monserveur

service_description SMB

check_command check_smb

}

Superviser un serveur LDAP

Un serveur est souvent le coeur d’un système d’information. C’est donc un poihnt critique à surveiller dans Nagios. Nous allons pour celà utiliser le service check_ldap qui prend en paramètres l’adresse du serveur LDAP ainsi que le DN à tester.

Configuration (à ajouter dans votre fichier commands.cfg de Nagios):

###### LDAP #####

define command{

command_name check_ldap

command_line $USER1$/check_ldap -H $HOSTADDRESS$ -b $ARG1$

}

Exemple de service:

define host{

use generic-host

host_name monserveur

alias Serveur LDAP

address 192.168.0.100

}

define service{

use generic-service

host_name monserveur

service_description LDAP

check_command check_ldap!”dc=mondomaine,dc=com”

}

Superviser un serveur de base de données

MySQL et pgSQL sont des serveurs de base de données open-source très répandus. Il existe donc deux plugins spécifiques check_mysql et check_pgsql disponible en standard avec Nagios. Personnellement, je n’utilise pas ces deux plugins car ils peuvent présenter une faille dans votre réseau. En effet, il utilise une requête SQL nécessitant un login/password. Hors ce couple apparaîtra dans la liste des processus lors de l’éxecution du plugin par Nagios.

Je préfère donc utiliser des plugins basés sur check_tcp.

Configuration (à ajouter dans votre fichier commands.cfg de Nagios):

###### SQL #####

define command{

command_name check_pgsql

command_line $USER1$/check_tcp -H $HOSTADDRESS$ -p 5432

}

define command{

command_name check_mysql

command_line $USER1$/check_tcp -H $HOSTADDRESS$ -p 3306

}

Exemple de service:

define host{

use generic-host

host_name monserveur

alias Serveur MYSQL

address 192.168.0.100

}

define service{

use generic-service

host_name monserveur

service_description MYSQL

check_command check_mysql

}

Superviser un serveur réseau

DHCP et DNS sont la base de votre infrastructure réseau. Nous allons donc utiliser les plugins check_dns et check_dhcp pour les surveiller de prêt.

Configuration (à modifier dans votre fichier commands.cfg de Nagios):

###### DNS #####

define command{

command_name check_dns

command_line $USER1$/check_dns -H www.google.fr -s $HOSTADDRESS$

}

###### DHCP #####

define command{

command_name check_dhcp

command_line sudo -u root $USER1$/check_dhcp -s $HOSTADDRESS$

}

Pour le check_dns, Je vous conseille de mettre un serveur qui ne risque pas de disparaître du jour au lendemain dans les DNS mondiaux en paramètre -H.

Pour le check_dhcp, la commande doit être exécuté avec les droits root. Il faut donc ajouter la ligne suivante au fichier /etc/sudoers:

nagios ALL=NOPASSWD: /usr/local/nagios/libexec/check_dhcp *

Exemple de service DNS:

define host{

use generic-host

host_name monserveur

alias Serveur DNS

address 192.168.0.100

}

define service{

use generic-service

host_name monserveur

service_description DNS

check_command check_dns

}

Exemple de service DHCP:

define host{

use generic-host

host_name monserveur

alias Serveur DHCP

address 192.168.0.100

}

define service{

use generic-service

host_name monserveur

service_description DHCP

check_command check_dhcp

}

A vous de jouer et de proposer de nouveaux exemples de services !

L’actualité open-source de la semaine…

L’image de la semaine

Et voilà Solo, à abuser de nmap et de john the ripper, on a des problèmes…

Tout le monde en parle, sauf moi…

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

• Go-OO, le vrai concurrent de Open-Office ?
• Firefox 3.1 arrive en alpha
• Après Microsoft, c’est au tour de gOOgle d’investir dans l’open-source
• Apple propose une libraire pour créer des plug-ins iSync pour nos chers téléphones protables…
• … et corrige enfin la faille DNS de Bind
• Aller les têtes de cochons, finalement Vista c’est pas si mal… non ?

Autres choses ?

Si vous avez comme moi votre bibliothèque musicale stockée dans l’iTunes de votre Mac OS X et que vous souhaitez y accéder depuis votre PC Linux, alors ce billet est fait pour vous…

Comment ça marche ?

Nous allons utiliser DAAP (Digital Audio Access Protocol), un protocole commun entre votre Mac OS X qui va partager votre bibliothèque et votre lecteur audio sous Linux. Ce protocole se rapproche en fait du bien connu protocole HTTP (mais en écoute sur le port TCP/3689, avis aux utilisateurs de firewall…) permettant de partager des listes de lectures et de “streamer” des musiques (quelques soit le format/codec) sur le réseau.

Pour une description précise du protocole, vous pouvez consulter ce document.

Configuration du serveur DAAP sur le Mac OS X

Depuis iTunes 7.0, Apple (le vilain) a changé le protocole d’authentification des clients tiers. Il n’est donc plus possible d’accéder à une bibliothèque partager par iTunes 7.0 depuis un lecteur audio Linux comme Amarok, Banshee ou Rhytmbox.

Heureusement, la communauté open-source propose une solution alternative et que je trouve plus élégante: Fire Fly Media Server. Ce petit serveur DAAP (anciennement nommé mt-daap) est disponible sous Mac OS X.

Avant d’installer Fire Fly Media Server, on commence donc par vérifier que le partage est désactivé dans iTunes 7.0 afin qu’il n’y est pas de conflit entre les deux systèmes.

On peut alors passer à l’installation de Fire Fly Media Server. Il faut pour cela se rendre sur cette page et télécharger la dernière “nighly-build”.

Une fois installé, un nouvel icône est disponible dans les préférences systèmes:

La configuration est très simple. On entre le nom du partage qui sera diffusé sur le réseau (1), le mot de passe (2) et si le serveur est lancé au démarrage de la session (3).

Ensuite, dans l’onglet Avancé, on configure le répertoire ou se trouve la bibliothèque musicale (/Users/<login>/Music pour partager votre bibliothèque iTunes):

Configuration du client DAAP sous Linux

J’utilise le lecteur audio Banshee sous ma station Linux Ubuntu. La procédure pour accéder au partage est la suivante.

On commence par activer le plugin Partage de musique:

Le nom du partage devrait alors apparaître automatiquement dans la liste des Musique partagée de Banshee. Une fois sélectionné (1), il faut saisir le mot de passe (2).

Vous avez alors accès à votre bibliothèque. Lors de l’écoute d’un morceau, les données sont “streamées ” entre le Mac et le Linux. Ainsi, aucun fichier n’est stocké sur votre Linux.

Conclusion

Vous pouvez donc partager vos fichiers audio (MP3 ou autres) de manière très simple. L’avantage de cette solution par rapport à un simple partage iTunes (en dehors du fait que cela marche;) ) est qu’il n’est pas nécessaire de lancer iTunes pour accéder à vos musiques.

En cadeau bonux, Firefly Media Server dispose d’une interface Web d’administration accessible par défaut par l’adresse http://localhost:1024/index.html.

Pour vérifier que vos serveurs DNS ne sont pas touchés par la faille DNS Caching Poisoning (DNS CP), un simple test via la ligne de commande de votre système est possible. Nous allons dans ce billet voir comment réaliser et interpréter ce test puis détailler les actions à prendre au cas ou ce test serait positif.

Faire le test

On va utiliser l’utilitaire dig, fourni en standard dans tout OS qui se respecte.On lance la commande suivante (remplacer dns par l’adresse IP de votre serveur DNS):

dig +short @dns porttest.dns-oarc.net TXT

Si le résultat est:

z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
“dns is GOOD: 26 queries in 4.4 seconds from 26 ports with std dev 20195.32″

Alors vous pouvez pavoiser, pas la peine d’aller plus loin, votre DNS est protégé contre ce type d’attaque.

Par contre si le résultat est le suivant:

porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
“dns is POOR: 26 queries in 4.3 seconds from 1 ports with std dev 0″

Il faut vite penser à mettre à jour votre DNS en suivant les conseils du paragraphe suivant.

Mettre à jour son serveur DNS

Sous FreeBSD

On commence par mettre à jour les ports en suivant cette procédure. Puis on tape les commandes:

cd /usr/ports/dns/bind9
make deinstall
make reinstall

Sous Linux Ubuntu

On passe par le gestionnaire de package apt-get:

sudo apt-get update
sudo apt-get upgrade

Sous Linux Fedora

On passe par le gestionnaire de package yum:

su - root
yum update

Configurer son serveur DNS

Si vous avez une architecture DNS avec un primaire et un secondaire (par exemple si vous avez suivi ce tutorial). Il peut être bon d’avoir une configuration différente entre le primaire (celui qui est le plus exposé aux attaques venant d’Internet et le secondaire qui sera uniquement utilisé par les clients de votre réseau local).

Source: SecureWorks

Sur le serveur primaire (”Authoritative nameserver”) il est conseillé de désactivé la résolution des requêtes par récursion (option allow-recursion) et d’activer le changement dynamique du port réseau de réponse du serveur DNS (option dnssec-enable).

Sur ce premier serveur, la section options di fichier named.conf ressemblera donc à:

options {
…
allow-recursion { none; };
dnssec-enable yes;
}

Selon la criticité de votre réseau vous pouvez également appliquer cette configuration sur le serveur secondaire (”caching nameserver”).

Il ne reste plus qu’a relancer le serveur DNS et à recommencer le test du premier chapitre.

Une petite astuce pour surveiller facilement avec Nagios, l’espace disque disponible sous ses serveurs Windows ou Samba (protocole SMB).

La première chose à faire est de tester le plugin en ligne de commande. Par exemple pour surveiller l’espace disque monpartage du serveur monserveur (\\monserveur\monpartage) en utilisant le couple login/password monuser/monpassword:

/usr/local/nagios/libexec/check_disk_smb -H monserveur -s monpartage -u monlogin -p monpassword

On commence par éditer le fichier commands.cfg pour ajouter le plugin:

define command{
command_name    check_disk_smb
command_line    $USER1$/check_disk_smb -H $HOSTADDRESS$ -s $ARG1$ -u $ARG2$ -p $ARG3$
}

Puis on utilisera la définition de service suivante (à mettre par exemple dans le fichier objects/servers.cfg):

define service{
use                     generic-service
host_name               monserveur
service_description     Disk space
check_command           check_disk_smb!servernas!monpartage!monuser!monpassword
}

Un alerte d’avertissement (warning) sera générée si l’espace disque est inférieur à 15%, une alerte critique (critical) si cette valeur passe à 5%.

Comme tout le monde je viens de créer ma brute pour affronter virtuellement ceux qui oseraient s’y attaquer… Mais ma brute à un plus que les autres n’ont pas…

C’est en fait la plus mauvaise brute de la blogosphére. Elle se prend tannée sur tannée….

Alors si toi aussi tu veux lui foutre une bonne branlée et gagner facilement quelques points d’expériences il suffit de cliquer sur ma brute:

La brute de Nicolargo

PS: si tu sors de ta grotte et que tu ne connais pas La brute, clique ici pour créer ton personnage.

Comme vous le savez tous (ou pas), Nagios est composé d’un coeur (Nagios le bien nommé actuellement en version 3.x) et de packages d’extensions (NDO, Nagios-plugins…).

Voici une simple procédure à suivre pour mettre à jour les plugins dans Nagios. C’est un complément de l’article sur la mise à jour de Nagios.

Téléchargement des plugins

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

su -l nagios

Sur Ubuntu ou Debian:

sudo -s nagios

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

mkdir src
cd src
wget http://heanet.dl.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.12.tar.gz
tar zxvf nagios-plugins-1.4.12.tar.gz
cd nagios-plugins-1.4.12

Mise à jour des plugins

On commence par compiler les plugins:

./configure
make

puis on installe en lieu et place des anciens plugins:

make install
exit

Redémarrage de Nagios

Afin que les plugins soit pris en compte, il faut redémarrer Nagios en utilisant les commandes suivantes:

Sur Fedora:

service nagios restart

Sur Ubuntu ou Debian:

/etc/init.d/nagios restart

Et voili…

WP Comment Remix est un plugin Wordpress (testé avec WP 2.6) qui ajoute quelques fonctions intéressantes aux commentaires de votre blog:

• ajout d’un bouton “Répondre” en bas de chaque commentaire (celà va automatiquement insérer un lien vers  le commentaire en question dans le commenatire que vous êtes en train de rédiger)
• ajout d’un bouton “Citer” en bas de chaque commentaire (pour citer un commentaire d’une autre personne)
• gestion des tags par commentaires
• mise à disposition d’un widget pour afficher les derniers commentaires
• mise à disposition d’un widget pour afficher les derniers trackbacks
• mise à disposition d’un widget pour afficher les billets les plus commentés
• mise à disposition d’un widget pour afficher les commenatires les plus actifs

Après installation, il suffit de ce rendre dans les options pour configurer le plugin selon vos besoins (notamment pour changer les mots clès de l’Anglais vers le Francais).

Celà donne cela sur votre blog:

C’est le genre de plugin tout en un que je trouve assez pratique.

A télécharger ici.

L’actualité open-source de la semaine…

Tout le monde en parle, sauf moi…

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

• Les vidéos de la conférence du libre (RMLL 2008) sont disponibles en ligne.
• Nouvelle version pour MacFusion, le compagnon de MacFuse !
• Wordpress disponible sous IPhone v2…
• GNU/Linux se donne 2 ans pour dépasser Mac OS X en terme d’interface utilisateur
• DragonFLY, le “fork” FreeBSD 4.x passe en version 2.0
• Thunderbird (client de messagerie open-source) est disponible en version 2.0.0.16

Autres choses ?

Vous venez de développer un “super_daemon_de_la_mort_qui_tue” qui doit se lancer au boot de votre machine Ubuntu mais vous ne savez absolument pas comment écrire un script de démarrage en bonne et due forme (et pas “en bonnet du forme”…) ?

Heureusement, Robert Peclot’s (merci à Mumbly pour la découverte) propose un petit script en ligne permettant de générer celà pour vous.

Il faut ce rendre à l’adresse suivante puis saisir le formulaire:

Puis le résultat (facilement téléchargeable):

#! /bin/sh
#
# This script was generated by The Ubuntu Linux Startup Script Builder
# version 1.7 located at http://rob.pectol.com/startup_scriptbuilder/.
#
# Generated: Fri Jul 25 05:18:02 MDT 2008
#
# super_daemon_de_la_mort_qui_tue.sh - Script de démarrage pour super_daemon
#
##################################################

set -e
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

if [ -r /lib/lsb/init-functions ]; then
. /lib/lsb/init-functions
logbegin=”log_begin_msg”
logend=”log_end_msg”
else
logbegin=”echo -n”
logend=`printf “echo .\n”`
fi

# Exit if the daemon binary is NOT available, executable, etc.
test -x /usr/bin/super_daemon || exit 0

# Read config file if it is present.
if [ -r /etc/default/super_daemon.conf ]; then
. /etc/default/super_daemon.conf
fi

# Start function
d_start() {
start-stop-daemon –start –pidfile /var/run/super_daemon –exec /usr/bin/super_daemon — -d
}

# Stop function
d_stop() {
start-stop-daemon –stop –pidfile /var/run/super_daemon –name super_daemon
}

# SigHup function
d_reload() {
start-stop-daemon –stop –pidfile /var/run/super_daemon –name super_daemon –signal 1
}

case “$1″ in
start)
$logbegin “Starting super_daemon…”
d_start
$logend $?
;;
stop)
$logbegin “Stopping super_daemon…”
d_stop
$logend $?
;;
reload)
$logbegin “Reloading configuration for super_daemon…”
d_reload
$logend $?
;;
restart)
$0 stop
sleep 1
$0 start
;;
*)
log_success_msg “Usage: $0 {start|stop|reload|restart}”
exit 1
;;
esac
exit 0

SwarpPlayer est un logiciel open-source permettant de streamer des vidéos sur une réseau P2P (bittorent pour ne pas le nommer).

Le but de ce logiciel est de combiner les fonctions suivantes:

• télécharger une vidéo pour la regarder plus tard (p2p)
• regarder la vidéo pendant le téléchargement (streaming)
• regarder une vidéo pendant qu’elle est généré, par exemple depuis une Webcam (live)

Les développeurs (P2P-NeXt consortium) sont en phase de test et demande l’aide de la communauté afin de tester la monté en charge de leur solution.

Donc acte…

Installation de SwarmPlayer

Cette procédure est donnée pour une Ubuntu Hardy. Il existe également une version Windows de SwarmPlayer téléchargeable ici.

cd /usr/src
sudo wget http://ubuntu.p2p-next.org/dists/hardy/main/binary-i386/swarmplayer_1.0.1-1ubuntu1_all.deb
sudo apt-get install python-m2crypto python-wxgtk2.8
sudo apt-get -f install
sudo dpkg -i swarmplayer_1.0.1-1ubuntu1_all.deb

L’installation semble prévu pour une version Anglaise d’Ubuntu, si comme moi votre Ubuntu est en Francais, il faut également changer les droits d’un répertoire (remplacer user par votre login):

cd ~
sudo chown -R user:user Desktop/

Utilisation de SwarmPlayer

Comme pour bittorent a besoin d’un fichier “.bittorrent”, SwarmPlayer utilise un fichier “.tstream”. Vous pouvez en deux exemples sur le site:

test de la vidéo à la demande

test de la vidéo live (depuis une caméra)

Une fois ces fichiers téléchargés sur votre disque, il suffit de lancer SwarmPlayer et d’ouvrir un des deux fichiers de test.

/usr/bin/swarmplayer

SwarmPlayer va alors commencer à télécharger la vidéo en P2P:

dés que possible (c’est à dire dès que les buffers sont assez remplis), la vidéo va s’afficher dans votre lecteur vidéo par défaut (VLC dans mon cas):

Comme pour le P2P, plus le nombre d’utilisateurs sera important, plus la qualité vidéo / rapidité de transfert pourra être élévée.

Il est possible, dans les options de définir un débit maximum à ne pas dépasser (histoire de ne pas saturer votre bande passante avec ce flux P2P).

Conclusion

Un nouveau logiciel open-source intéressant, à suivre dans les prochaine version. La version testé (v1.0.1-1) était relativement stable sur mon système et la qualité vidéo assez bonne.

L’enquête sur le format de pub 125×125 publiée sur votre dévoué blog il y a quelques jours est au menu de Paroles de blog, le “podcast” de Presse-Citron. C’est peut être l’occasion pour vous de découvrir cette nouvelle nouvelle façon de ce tenir informé sur l’actualité du Web.

CactiPlug est un plugin que j’ai développer pour lier facilement Cacti (outils de génération de graphe RRD) et Nagios (outils de supervision).

Dennis Yusupoff, un lecteur russe du blog a apporté quelques modifications pratiques:

• utilisation des hosts name en plus des adresses IP
• redirection vers une page centralisant l’ensemble des services supervisés

La nouvelle version est disponible ici, la procédure d’installation reste inchangée (consultable là).

Vive l’open-source…

Le format de publicité 125×125, bien que très répandu aux US, a du mal à ce développer sur le Web Francophone. Les blogs sont des pionniers dans l’utilisation de ce format et poussent petit à petit les régies en en proposer dans leurs offres.

Je vous propose dans ce billet une petit enquête que j’ai mené auprès des 100 blogs Francophones “hight-tech” (blog FR) issues du classement Wikio de Juin 2008.

Déroulement de l’enquête

Après une visite de chacun de ces blogs, j’ai envoyé par mail (si je trouvais une adresse ou un formulaire de contact) le questionnaire suivant:

1) Proposez-vous des espaces publicitaires 125×125 sur votre blog ?
si non:
2) Pour quelle raison ?
3) Envisagez-vous d’en proposer dans les prochains mois ?
si oui:
4) Combien d’espaces publicitaires 125×125 sont disponibles sur votre blog ?
5) Proposer-vous la location de ces espaces publicitaires de manière journalière, hebdomadaire, mensuel, annuel ?
6) Pour la location de ces espaces, passez-vous par une régie publicitaire ou bien en direct ?
7) Quel est le prix moyen mensuel pour la location d’un espace 125×125 ?
Proposez vous un prix dégressif pour un engagement sur une plus longue durée ?
9) Autorisez vous les formats de type (PNG, JPEG, GIF, GIF animé, Flash, Autres…)
10) Depuis combien de temps proposez vous le format 125×125 sur votre blog ?

Echantillon retenus

Sur les quelques 95 mails envoyés (moins les 5 blogs ou je n’ai pas trouvé d’adresse de contact…), j’ai reçu 29 réponses (merci à eux !). Les statistiques suivantes seront donc relative à cet échantillon.

Résultats de l’enquête

Nous allons commencer par la proportion des blogs FR proposant aux annonceurs des espaces publicitaires aux format 125×125.

Comme on peut s’y attendre, ce format n’est pas encore généralisé mais il se positionne souvent en bonne place dans le graphisme des blogs (majoritairement en haut de la sidebar). Il est utilisé en moyenne depuis 6 mois sur les blogs.

Le graphe suivant se focalise sur les blogs FR proposant de la publicité sur leur blogs (soit un peu moins de 60% des sites).

47% des blogueurs voulant monétiser leur site propose donc le format 125×125. Je trouve ce chiffre assez important vu la jeunesse de ce format.

Nous allons dans le graphe suivant nous pencher sur les raisons de la non utilisation de ce format.

Sans surprise, la principale raison invoqué est que le blogueur ne propose pas de publicité sur son site. La seconde raison est un choix graphique. En effet, plusieurs blogueurs trouve ce format trop petit ou pas adapté à leur thème actuel.

Pour ces mêmes blogs, à la question: “proposerez-vous ce format dans un futur proche ?”, les réponses sont les suivantes:

Plus de 35% des blogueurs pensent donc proposer le format 125×125 dans les prochains mois, ce qui démontre une montée en puissance de ce format.

Combien rapporte les publicités aux format 125×125

Nous allons maintenant nous pencher sur les aspects financiers des blogs proposant le format 125×125.

Tout d’abord, il est important de préciser que le principal avantage de ce format qui est la multiplication des publicité sur une même page est particulièrement bien exploité sur les blogs FR. En effet, nous arrivons à une moyenne de 5,6 espaces au format 125×125 proposés par blog (minimum: 2, maximum: 10).

Les abonnements se font majoritairement sur des périodes mensuelles mais beaucoup de blogueurs sont plutôt souples sur le sujet.

Au niveau des prix pratiqués (base mensuelle pour 1 espace 125×125), vous imaginez bien que les prix varient selon la notoriété des blogs. La moyenne est de 235 € (minimum: 30€, maximum: 500 €) par espace 125×125. En multipliant par le nombre d’espaces proposés on arrive à une moyenne de 1416 € (minimum: 60€, maximum: 4000 €) par blog.

Ces chiffres peuvent paraître importants, mais il faut noter deux choses. La première est qu’il existe un gros écart entre les sites professionnels ou semi-professionnel et le reste de la blogospheres. Ces derniers ont beaucoup de difficultés à trouver des sponsors. La seconde est que ces chiffres sont à pondérer par le fait qu’un blog arrive rarement à louer la totalité de ces espaces publicitaires.

Conclusion

Le format 125×125 arrive à point nommé pour développer la monétisation des blogs FR. En effet, ce format, bien qu’imparfait, est un des seul à pouvoir générer un revenu acceptable à un blogueurs par la multiplication de ces annonces sur une même page. Reste aux régies à faire un pas en avant et à proposer ce type de format.

Dans le domaines de la sécurité informatique, les sites Web sont les points les plus sensibles, car les plus exposés, aux attaques extérieures… Eric, comme beaucoup en a fait l’amère expérience avec son site SportsCafe.fr…

Bien qu’une protection efficace à 100% n’existe pas, quelques règles de bases sont toujours bonnes à vérifier. Pour les néophytes (et on l’est tous dans ce domaine très pointu), Unmaskparadises propose, en bêta, son service Website Security Check.

Ce dernier permet de vérifier de manière très simple (il suffit de saisir l’URL du site à tester) si votre serveur est vulnérable à certaines failles.

Le résultat:

Pour tester votre site: cliquer ici !

Bref, un bon service à bookmarker…

L’actualité open-source de la semaine…

L’image de la semaine

Linus n’aime pas OpenBSD et il le dit:

” Les personnes centrées sur la sécurité sont le genre de personnes que je ne supporte pas. Je pense que pour OpenBSD c’est un groupe de singes se masturbant dans le sens où ils accordent une telle importance à la sécurité qu’ils sont incapables d’admettre que rien d’autre ne compte pour eux “

Tout le monde en parle, sauf moi…

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

• Twitter libre, c’est par ici…
• Le noyau GNU/Linux 2.6.26 est là…
• Après les films libres, Blender se lance dans le jeu libre !
• VLC passe en version 0.8.6i (à quand la 0.9… ben pour bientôt…)
• OpenOffice 3.0 en bêta 2 sur Mac Intel

Autres choses ?

Dans une infrastructure réseau, le firewall est souvent le point central par lequel l’ensemble des flux transite. C’est donc un SPOF (”single point of failure” ou “point individuel de défaillance”) de votre système d’information. En effet, en cas de problème sur ce noeud, l’ensemble de votre réseau devient in-opérationnel (ce qui est impensable pour un administrateur réseau;)).

Ce billet fait suite à un autre: Installation d’un Firewall sous FreeBSD. Nous allons donc voir comment redonder notre cher Firewall en utilisant les protocoles CARP (”Common address redundancy protocol”) et PFSYNC (pour le synchronisation des règles PF). Pour cela, nous allons nous baser sur le réseau suivant afin d’illustrer notre article:

Comme on peut le voir, il faut donc deux machines pour effectuer cette redondance. La première (firewall-1) est celle utilisée par défaut. La seconde (firewall-2) prendra le relais en cas de problème sur la première. Il faut bien sûr mettre en place un système automatique de synchronisation des configurations entre les deux serveurs (sujet non abordé dans ce billet).

CARP ? c’est quoi ?

C’est un protocole sécurisé et libre permettant la redondance d’adresse IP sur un réseau. Il permet de partager une adresse IP entre plusieurs machines. Dans notre cas, nous allons mettre en place ce protocole entre les deux serveurs Firewall. Ils partageront ainsi une liste d’adresses IP (une par interface physique).

Pour les GNU/Linuxiens, une implémentation de CARP existe: UCARP. Dans mon cas je me focaliserai sur l’implémentation pour FreeBSD, inclus dans le noyau depuis la version 5.3.

Et PFSYNC… ?

C’est bien beau d’utiliser CARP pour la redondance mais si une des deux machines tombent, il faut que l’autre est un connaissance des tables d’état du Firewall PF (régles de Firewall, NAT, PAT, connexions …). C’est là qu’entre en jeu PFSYNC qui permet une synchronisation dynamique de ces tables entre les deux machines.

Par défaut, les messages échangés par PFSYNC utilise un couche de transport multicast. Si vous mettez en place une architecture avec une redondance sur deux machine, je vous conseille de forcer le mode unicast en utilisant l’option syncpeer.

Installation de CARP sous FreeBSD

Il faut commencer par ajouter une ligne dans le fichier de configuration de votre noyau (/usr/src/sys/i386/conf/MONNOYAU):

…
device carp
…

Puis recompiler le noyau en suivant cette procédure.

Ensuite on active le module en modifiant le fichier /etc/sysctl.conf et en y ajoutant les deux lignes suivantes:

…
net.inet.carp.allow=1
net.inet.carp.preempt=1
…

La première option permet de charger le module CARP, la seconde permet de dire à CARP de mettre DOWN toutes les interfaces d’un serveur quand une d’elles est DOWN (basculement de la totalité du Firewall).

Vous pouvez activer ces options sans avoir à redémarrer le serveur en tapant les commandes suivantes:

sysctl net.inet.carp.allow=1
sysctl net.inet.carp.preempt=1

Configuration de CARP et de PFSYNC

Adresses IP de notre schéma réseau:

Firewall1 / (local) eth0: 192.168.0.1/24
Firewall1 / (wan) eth1: 192.168.254.1/24
Firewall1 / (lan) eth2: 192.168.1.1/24
Firewall1 / (dmz) eth3: 192.168.100.1/24

Firewall2 / (local) eth0: 192.168.0.2/24
Firewall2 / (wan) eth1: 192.168.254.2/24
Firewall2 / (lan) eth2: 192.168.1.2/24
Firewall2 / (dmz) eth3: 192.168.100.2/24

Adresse IP partagée CARP (wan) carp1: 192.168.254.254/24
Adresse IP partagée CARP (lan) carp2: 192.168.1.254/24
Adresse IP partagée CARP (dmz) carp3: 192.168.100.254/24

Votre Firewall redondé sera donc connu de votre réseau par les adresses 192.168.254.254 sur votre réseau WAN, 192.168.1.254 sur votre réseau LAN et 192.168.100.254 sur votre réseau DMZ.

La première chose à faire pour configurer CARP est de créer, sur chacun des serveurs (firewall-1 et firewall-2) une interface virtuelle par réseau:

ifconfig carp1 create
ifconfig carp2 create
ifconfig carp3 create

Puis on modifie le fichier /etc/rc.conf en fonction de la machine. C’est là que l’on configure PFSYNC qui se présente sous la forme d’une interface virtuelle attaché à une interface physique. Je vous conseille, si possible de dédier une interface pour la synchronisation PFSYNC en mettant un câble croisé entre les deux machine (eth0 dans mon exemple).

Sur firewall-1:

# Interfaces physiques
ifconfig_eth0=”inet 192.168.0.1 netmask 255.255.255.0″
ifconfig_eth1=”inet 192.168.254.1 netmask 255.255.255.0″
ifconfig_eth2=”inet 192.168.1.1 netmask 255.255.255.0″
ifconfig_eth3=”inet 192.168.100.1 netmask 255.255.255.0″

# CARP
cloned_interfaces=”carp1 carp2 carp3″
ifconfig_carp1=”vhid 1 pass monmotdepasse 192.168.254.254 netmask 255.255.255.0″
ifconfig_carp2=”vhid 2 pass monmotdepasse 192.168.1.254 netmask 255.255.255.0″
ifconfig_carp3=”vhid 3 pass monmotdepasse 192.168.100.254 netmask 255.255.255.0″

# PFSYNC
pfsync_enable=”YES”
pfsync_syncdev=”eth0″
pfsync_syncpeer=”192.168.0.2″

et sur firewall-2:

# Interface physiques
ifconfig_eth0=”inet 192.168.0.2 netmask 255.255.255.0″
ifconfig_eth1=”inet 192.168.254.2 netmask 255.255.255.0″
ifconfig_eth2=”inet 192.168.1.2 netmask 255.255.255.0″
ifconfig_eth3=”inet 192.168.100.2 netmask 255.255.255.0″

# CARP
cloned_interfaces=”carp1 carp2 carp3″
ifconfig_carp1=”vhid 1 advskew 100 pass monmotdepasse 192.168.254.254 netmask 255.255.255.0″
ifconfig_carp2=”vhid 2 advskew 100 pass monmotdepasse 192.168.1.254 netmask 255.255.255.0″
ifconfig_carp3=”vhid 3 advskew 100 pass monmotdepasse 192.168.100.254 netmask 255.255.255.0″

# PFSYNC
pfsync_enable=”YES”
pfsync_syncdev=”eth0″
pfsync_syncpeer=”192.168.0.1″

Par défaut, l’intervalle entre deux annonces CARP (message multicast avec protocole IP/112) est d’une seconde. Il est possible de changer cette valeur en jouant sur les paramètres advbase et advskew de la commande ifconfig.

Dans la configuration donnée en exemple ci-dessus, les valeurs advbase sont laissées par défaut (1 seconde) et advskew mis à 100 pour le second serveur (0, par défaut sur le premier). Ainsi, firewall1 aura de plus grande chance d’être choisi comme serveur maître en cas de bon fonctionnement des deux serveurs.

Une dernière chose à faire est d’autoriser le protocole CARP entre les deux firewall avec une règles du type:

pass quick on { eth0 } proto pfsync keep state (no-sync)
pass on { eth0 } proto carp keep state

Comment tester le couple CARP/PFSYNC

Le plus simple est de débrancher un câble réseau (ou l’alimentation ;)) du firewall-1. Le trafic devrait basuler dans la seconde vers le deuxième firewall.

Une autre solution, qui peut être pratique lors de la maintenance d’un serveur est de forcer le basculement de manière soft. Il suffit pour cela de saisir sur firewall-1 la commande suivante:

ifconfig carp1 down

Nous venons donc de voir une solution “simple” pour faire de la redondance de Firewall. Cette technique est également applicable sur d’autres serveurs critiques (serveur Web par exemple…).

Quelques ressources utilisées pour rédiger cet article:

• http://www.openbsd.org/faq/pf/filter.html
• http://www.openbsd.org/faq/pf/fr/carp.html
• http://www.countersiege.com/doc/pfsync-carp/

Derrière ce titre très geek se cache en fait un article sur un petit utilisatire bien pratique que je viens de découvrir: Wput.

Wput est à l’upload ce que Wget est au download.

Il permet d’uploader un/plusieurs fichiers depuis une machine vers un serveur FTP.

Installation de Wput

La plupart des distribution Linux incluent ce logiciel dans leur gestionnaire de packages. Par exemple pour l’installer sous Ubuntu, il suffit de taper la commande suivante:

sudo apt-get install wput

Si ce ,n’est pas le cas, vous pouvez toujours le comiler depuis les sources en suivante la procédure suivante:

cd /usr/src
wget http://mesh.dl.sourceforge.net/sourceforge/wput/wput-0.6.1.tgz
tar zxvf wput-0.6.1.tgz
cd wput-0.6.1
./configure
make
sudo make install

Utilisation de Wput

L’utilisation standard est la suivante:

wput fichier.tgz ftp://login:password@serveurftp.com/upload/

Tout comme Wget, de nombreuses options sont disponibles (voir le man pour une liste complète):

• -b: pour passer en background le processus
• -l <RATE>: limite la bande passante utilisée (ex: -l 1M : limite à 1 Mbps)
• -Y <PROXY>: utilise un proxy (HTTP ou SOCKS)
• …

Et voili, bon week-end (3 jours youpi) à tous !

Voici un petit billet de plus sur Nagios. Nous aborderons le sujet de la supervision à distance de la mémoire vive (RAM) de nos serveurs.

Nous allons pour cela utiliser deux plugins, le premier est NRPE (il permet de lancer des commandes à distance sur d’autres machines), le second est un script permettant d’obtenir un état de la mémoire vive à un instant “t”.

Nous utiliserons donc le schéma suivant:

Installation de NRPE

Ce premier plugin doit être installé sur le serveur Nagios et sur toutes les machines à superviser.

Pour une procédure d’installation sous GNU/Linux, lire ce billet. Si vous voulez surveiller des machines FreeBSD, lire celui là.

A ce stade vous devez donc avoir un plugin NRPE opérationnel entre votre serveur Nagios et les machines à surveiller.

Installation du plugin de supervision de la mémoire

Il existe un grand nombre de méthodes pour obtenir la mémoire libre sur une machine. Personnellement j’utilise les deux scripts suivants selon que je sois:

• sous Linux: check_memory
• ou sous FreeBSD: check_mem

Mais, si le coeur vous en dit, vous pouvez écrire vous-même le plugin le plus adapté à votre système (Windows, Unix divers et varié…).

Une fois connecté sur votre machine à superviser, il faut mettre le plugin dans le répertoire /usr/local/libexec/nagios/ et lui donner les droits en lecture et exécution:

cp ./check_memory.pl /usr/local/libexec/nagios/
chmod 555 /usr/local/libexec/nagios/check_memory.pl

Vous pouvez tester localement le plugin grâce la commande suivante:

/usr/local/libexec/nagios/check_memory.pl -f -w 90 -c 50
Memory WARNING - 87.5% (1879588864 kB) free |pct=87.5

Configuration de NRPE pour prendre en compte le script check_memory

Toujours sur la machine cible, il faut éditer le fichier de configuration de NRPE pour y ajouter la définition du plugin check_memory:

vi /usr/local/etc/nrpe.cfg

…
command[check_mem]=/usr/local/libexec/nagios/check_memory.pl -f -w 30 -c 15
…

Dans la configuration ci-dessus, on demande à check_memory de déclencher une alerte (warning) si la mémoire passe en dessous des 30% et une erreur (critical) si elle descend en dessous des 15%. Avous d’adpater ces valeurs selon vos besoins.

Pour que NRPE prenne en compte la nouvelle configuration il faut relancer le daemon:

Sous Linux:

service nrpe2 restart

ou

/etc/init.d/nrpe2 restart

Sous FreeBSD:

/usr/local/etc/rc.d/nrpe2 restart

Configuration du serveur Nagios

Il ne reste plus qu’à modifier la configuration du serveur Nagios pour ajouter le service à superviser, voici un exemple:

# Mon serveur
define host{
use        generic-host
host_name    monserveur
alias        Mon beau serveur
address        192.168.0.200
}
define service{
use                     generic-service
host_name               monserveur
service_description     Memoire vive
check_command           check_nrpe!check_mem
}

Et voila le résultat: