En parallèle j’ai modifié les scripts d’installation et de mise à jour de Nagios pour qu’il prenne en compte cette nouvelle version.

Si vous avez suivi mon tutoriel d’installation de Nagios (ou que vous avez utilisé le script), il suffit de saisir les commande suivantes pour effectuer une mise à jour de votre serveur:

wget http://svn.nicolargo.com/nagiosautoinstall/trunk/nagiosautoupdate-ubuntu.sh

chmod a+x nagiosautoupdate-ubuntu.sh

sudo ./nagiosautoupdate-ubuntu.sh

Attention: cette méthode de mise à jour ne fonctionnera pas si vous avez installé Nagios à partir des dépôts officiels de votre distribution.

Et hop !

Après des échanges ping pong entre le support de Gandi et celui de Free, j’ai décidé de prendre les choses en main, du moins en ce qui concerne l’identification du problème.

Le comportement est le suivant: sur le réseau Free, certains lecteurs voient normalement le blog tandis que d’autre sont redirigé vers l’ancienne adresse du serveur (aujourd’hui un compte iWeb8 suspendu). J’arrive parfaitement à reproduire ce comportement depuis chez moi (et oui je suis chez Free ).

nicolargo@nicolargo-laptop:~$ dig +nocmd nicolargo.com any +multiline +noall +answer

nicolargo.com. 85644 IN SOA ns1.panelboxmanager.com. logs.logs.privatedns.com. (
2010072800 ; serial
86400 ; refresh (1 day)
7200 ; retry (2 hours)
3600000 ; expire (5 weeks 6 days 16 hours)
86400 ; minimum (1 day)
)
nicolargo.com. 13644 IN A 72.55.186.68
nicolargo.com. 85644 IN NS ns1.panelboxmanager.com.
nicolargo.com. 85644 IN NS ns2.panelboxmanager.com.
nicolargo.com. 13644 IN MX 0 nicolargo.com.

—

nicolargo@nicolargo-laptop:~$ dig +nocmd nicolargo.com any +multiline +noall +answer

nicolargo.com. 10080 IN MX 10 spool.mail.gandi.net.
nicolargo.com. 10080 IN MX 50 fb.mail.gandi.net.
nicolargo.com. 10080 IN A 217.70.184.38
nicolargo.com. 10080 IN SOA a.dns.gandi.net. hostmaster.gandi.net. (
1282917455 ; serial
10800 ; refresh (3 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
10800 ; minimum (3 hours)
)
nicolargo.com. 10080 IN NS a.dns.gandi.net.
nicolargo.com. 10080 IN NS b.dns.gandi.net.
nicolargo.com. 10080 IN NS c.dns.gandi.net.

Une fois la résolution de nom se fait normalement (c’est à dire avec les NS pointant chez Gandi: dns.gandi.net), une fois non (les DNS pointent encore sur panelboxmanager.com, les serveurs DNS de iWeb8).

En regardant de plus près la réponse on peut voir les deux lignes suivantes:

Réponse venant de iWeb8: “2010072800 ; serial”

Réponse venant de Gandi: “1282917455 ; serial”

Je commence alors à comprendre d’ou vient le problème: quand le domaine était géré par iWeb8, ces derniers utilisait une gestion standard des numéro de série au format ANNEE-MOIS-JOUR-ID (2010072800), ce qui n’est pas le cas de Gandi qui doit générer dynamiquement ce numéro avec un algorithme interne (1282917455). Dans mon grand malheur, le numéro de série Gandi de la zone DNS nicolargo.com est inférieur à celui chez iWeb8. Il est donc normal que les serveurs DNS ne soit pas mis à jour…

Un petit tour du coté d’un site de validation de zone DNS:

Je viens d’envoyer un mail au support Gandi pour qu’il me change le numéro de série SOA à une valeur > à  2010072800…

Sinon il ne me reste plus qu’a attendre l’expiration de la zone DNS, c’est à dire presque… 6 semaines !!! Heureusement que je ne vie pas de ce blog . Une autre solution serait de gérer moi même mon propre serveur DNS (c’est possible en mode expert sur les VPS Gandi), mais je n’ai pas vraiment le couple temps/envie de m’en occuper.

L’erreur que j’ai faite est de ne pas avoir modifier la zone DNS chez iWeb avant de clôturer mon compte… Cette aventure est quand même une bonne leçon à retenir pour les administrateurs de domaines DNS (par exemple pour ceux qui doivent installer un BIND): respecter les standards de numérotation des serials SOA !

Update (j+9): Comme le signale Pascal dans son commentaire le serial SOA n’est utile que pour la réplication des zones entre le serveur primaire et le/les serveurs secondaires. Ce sont les TTL des RR qui fixent le temps de rafraîchissement des caches DNS (hébergé chez les FAI). Manifestement les serveurs de caches DNS de Free ne tiennent pas compte de ces TTL (fixés à 48h pour le domaine nicolargo.com) ou sont tout simplement bugués…

Update (j+10): Je n’arrive malheureusement pas à avoir une réaction de la part du support de Free, il me dise que la mise à jour des caches se fait de manière automatique (je veux bien les croire sur ce point…) et qu’ils ne peuvent pas intervenir. Bref 10 jours après la migration, certain utilisateur ne peuvent toujours pas accéder au blog. Si quelqu’un connait un administrateur réseau chez Free je suis preneur !!!!

Actuellement en développement (version 0.5.7 au moment de l’écriture de cet article), Xplico se base sur une architecture ouverte permettant d’ajouter assez simplement des modules de décodage (manipulators) et de visualisation (vizualization) de protocoles.

Nous allons maintenant voir comment installer, configurer et utiliser XPlico sur une système d’exploitation Debian like (Debian / Ubuntu…).

Installation

Update: je viens d’ajouter Xplico dans mon PPA…

On récupère la dernière version du package .deb sur le site officiel puis on installe le .deb avec lke gestionnaire de paquet Ubuntu.

Si votre système dispose d’un serveur APACHE, PHP5 et du module PHP5-SQLITE, vous n’avez rien d’autre à faire dans ce chapitre installation.

Sinon, il faut saisir les commande suivantes:

sudo install  apache2 mysql-server php5 php5-sqlite

sudo a2enmod rewrite

sudo cp /opt/xplico/cfg/apache_xi /etc/apache2/sites-enabled/xplico

sudo apache2ctl restart

Configuration

L’interface Web va vous permettre d’uploader vos fichiers de capture. De base, PHP limite la taille maximale des fichiers “uploadables” à 8 Mo. Pour augmenter cette limite, il faut éditer le fichier /etc/php5/apache2/php.ini:

post_max_size = 100M

upload_max_filesize = 100M

Puis relancer Apache pour prendre en compte la modification:

sudo apache2ctl restart

Utilisation

On commence par lancer un navigateur Web et pointer vers l’adresse suivante: http://localhost:9876/

Le compte par défaut est le suivant:

Login: xplico
Ppassword: xplico

On clique ensuite sur “New Case” pour créer un nouveau projet.

Puis une nouvelle session (correspondant à une capture):

On associe alors la session à notre fichier .pcap préhalablement généré avec Wireshark (vous pouvez récupérer un exemple de capture à l’adresse suivante).

Le chargement du fichier capture et son analyse peuvent prendre quelques secondes…

On a enfin le résultat qui s’affiche:

On peut par exemple visualiser l’adresse (URL) des sites Web visités:

Et entrer dans le détail des images téléchargées:

On peut également voir:

• la liste des requêtes DNS
• la liste des mails envoyés et leur contenus (si votre serveur Webmail n’est pas HTTPS…)
• la liste des appels SIP avec les numéros de téléphones
• la liste des fichiers téléchargés en HTTP, FTP, TFTP (que l’on peut récupérer)
• l’historique des chats (MMS, NNTP, Facebook)
• l’historique des sessions Telnet
• une matrice des autres protocoles (non décodés)

Une bonne raison d’utiliser des protocoles chiffrés

Big brother, à vous Paris…

Configuration du routeur A

crypto isakmp policy 1
 authnetification pre-share
 lifetime 86400

crypto isakmp key AZERTYUIOPQSDFGHJKLMWXCVBNAZERTY address 80.80.80.2

crypto ipsec transform-set MATS esp-aes 256 esp-sha-hmac

crypto map MAMAP 10 ipsec-isakmp
 set peer 80.80.80.2
 set transform-set  MATS
 match address IPSEC-TUN

ip access-list extended IPSEC-TUN
 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

interface FastEthernet 0/1
 crypto map MAMAP

Configuration du routeur B

crypto isakmp policy 1
 authnetification pre-share
 lifetime 86400

crypto isakmp key AZERTYUIOPQSDFGHJKLMWXCVBNAZERTY address 80.80.80.1

crypto ipsec transform-set MATS esp-aes 256 esp-sha-hmac

crypto map MAMAP 10 ipsec-isakmp
 set peer 80.80.80.1
 set transform-set  MATS
 match address IPSEC-TUN

ip access-list extended IPSEC-TUN
 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

interface FastEthernet 0/1
 crypto map MAMAP

Installation de NTTcp

Il faut installer le logiciel sur les deux machines (ou plus) entre lesquelles vous voulez tester votre réseau TCP/IP.

Sous Ubuntu:

sudo aptitude install nttcp

Utilisation de NTTcp

Sur la machine A ayant comme adresse IP 192.168.0.100 (d’un coté du réseau):

nttcp -i -v

Sur la machine B (de l’autre coté du réseau à tester):

nttcp -t -T 192.168.0.100

Par défaut, NTtcp va transférer 2048 “buffers” de 4 Kilo octets (4KB), soit un total de 8 Mo de B vers A.

Le résultat devrait ressembler à:

     Bytes  Real s   CPU s Real-MBit/s  CPU-MBit/s   Calls  Real-C/s   CPU-C/s
l  8388608    0.71    0.02     93.8840   3355.2754    2048   2865.11  102394.9
1  8388608    0.72    0.06     92.7279   1198.3084    5209   7197.55   93012.9

Les options disponibles

Pour inverser et effectuer un test de débit de A vers B, il faut utiliser l’option -r au lieu de l’option -t.

On peut notamment noter l’option -u pour forcer l’utilisation du protocole UDP en lieu et place de TCP.

Un petit coup de man:

Usage: nttcp [local options] host [remote options]
local/remote options are:
-t	transmit data (default for local side)
-r	receive data
-l#	length of bufs written to network (default 4k)
-m	use IP/multicasting for transmit (enforces -t -u)
-n#	number of source bufs written to network (default 2048)
-u	use UDP instead of TCP
-g#us	gap in micro seconds between UDP packets (default 0s)
-d	set SO_DEBUG in sockopt
-D	don't buffer TCP writes (sets TCP_NODELAY socket option)
-w#	set the send buffer space to #kilobytes, which is
dependent on the system - default is 16k
-T	print title line (default no)
-f	give own format of what and how to print
-c	compares each received buffer with expected value
-s	force stream pattern for UDP transmission
-S	give another initialisation for pattern generator
-p#   specify another service port
-i	behave as if started via inetd
-R#	calculate the getpid()/s rate from # getpid() calls
-v	more verbose output
-V	print version number and exit
-?    print this help
-N	remote number (internal use only)
default format is: %9b%8.2rt%8.2ct%12.4rbr%12.4cbr%8c%10.2rcr%10.1ccr

Principe

En effet, le client SpiderOAK peut être lancé en ligne de commande (vous pouvez voir la liste des options disponibles en lancant /usr/bin/SpiderOak –help). Malheureusement, il n’est, à l’heure actuelle, pas possible de configurer le client par cette méthode. Nous allons donc:

• installer le client SpiderOAK sur le serveur
• en utilisant les fonctions x-forwarding de SSH, lancer le client à distance (l’interface s’affichera sur  votre machine locale) puis faire la configuration (c’est à dire choisir les répertoires à sauvegarder)
• automatiser le lancement du client en ligne de commande (via crontab)

Aller zou à vos claviers…

Installation du client SpiderOak sur le serveur

On commence par télécharger la dernière version du client (attention de choisir une version compatible avec votre serveur: AMD64 / i386…) sur sa machien locale (on doit obtenir un fichier nommé spideroak_9658_i386.deb ou quelque chose comme ça…).

On copie ensuite ce fichier vers le serveur:

scp spideroak_9658_i386.deb monlogin@monserveur.com

On se connecte en SSH sur le serveur:

ssh login@monbeauserveur.com

Puis on lance l’installation:

sudo dpkg -i spideroak_9658_i386.deb

Avant de fermer la session SSH, on installe xauth qui va nous permettre de lancer SSH en mode x-forwarding (exemple d’installation sur une distribution Ubuntu Serveur) ainsi que quelques librairies dépendantes:

sudo aptitude install xauth dbus libice6 libsm6 libxrender1

exit

Configuration du client à distance

On lance une nouvelle session SSH en activant le x-forwarding (option -X):

ssh -X login@monbeauserveur.com

Puis on lance le client SpiderOak:

/usr/bin/SpiderOak

Il ne reste plus qu’a choisir dans l’interface graphique les répertoires à sauvegarder (voir un screencast de démonstration ici).

Une fois le client configuré, vous pouvez fermer l’application.

Lancement du client sur le serveur

Pour lancer le client sans interface graphique, il suffit de saisir la commande suivante (dans votre session SSH):

/usr/bin/SpiderOak --headless &

Enfin pour automatiser le lancement du client au démarrage du serveur, il suffit d’ajouter une ligne à votre crontab:

# crontab -e

@reboot /usr/bin/SpiderOak --headless &

Si vous avez besoin de reconfigurer votre client (pour ajouter ou supprimer un répertoire à sauvegarder), il faut:

• se connecter au serveur en SSH avec l’option -X
• tuer le process SpiderOak existant
• lancer la commande: /usr/bin/SpiderOak
• Configurer puis quitter l’interface
• lancer la commande: /usr/bin/SpiderOak –headless &

Voili, plus d’excuses pour perde ses données

Source: Le blog de Marc Seeger

NPtcp (disponible dans le package Netpipe-TCP sous Ubuntu) est un petit utilitaire bien pratique, en ligne de commande, permettant de tester le débit maximal d’une liaison en fonction de la taille des paquets.

Installation de NPtcp

Il faut installer le logiciel sur les deux machines (ou plus) entre lesquelles vous voulez tester votre réseau TCP/IP.

Sous Ubuntu:

sudo aptitude install netpipe-tcp

Utilisation de NPtcp en mode TCP

Sur la machine A ayant comme adresse IP 192.168.0.100 (d’un coté du réseau):

NPtcp

Sur la machine B (de l’autre coté du réseau à tester):

NPtcp -h 192.168.0.100

Il est important de noter que NPTcp va faire un test bi-directionnel (c’est à dire que les flux seront envoyé simultanément de A vers B et de B vers A). Pour tester seulement de B vers A, on peut utiliser l’option -s (à ajouter sur les deux lignes de commande).

Le résultat devrait ressembler à:

Send and receive buffers are 16384 and 87380 bytes
(A bug in Linux doubles the requested buffer sizes)
Now starting the main loop
 0:       1 bytes    648 times -->      0.05 Mbps in     142.98 usec
 1:       2 bytes    699 times -->      0.11 Mbps in     144.26 usec
 2:       3 bytes    693 times -->      0.16 Mbps in     145.62 usec
 3:       4 bytes    457 times -->      0.21 Mbps in     145.54 usec
 4:       6 bytes    515 times -->      0.31 Mbps in     145.94 usec
 5:       8 bytes    342 times -->      0.42 Mbps in     144.11 usec
 6:      12 bytes    433 times -->      0.63 Mbps in     146.39 usec
 7:      13 bytes    284 times -->      0.67 Mbps in     147.55 usec
 8:      16 bytes    312 times -->      0.83 Mbps in     147.73 usec
 9:      19 bytes    380 times -->      0.98 Mbps in     148.04 usec
 10:      21 bytes    426 times -->      1.07 Mbps in     150.25 usec
...

Comment lire les résultats ?
On obtient donc un débit de 0.63 Mbps pour des tailles de paquets TCP de 12 octets, 1 Mbps pour 21 octets…

Et si l’on veut générer un beau graphe

Et oui, les chefs, les tableaux et les résultats en mode texte ils n’aiment pas ça… Donc pour assurer votre prochaine augmentation, nous allons, avec l’aide de gplot, compulser les chiffres générés par NPTcp dans un “beau” graphe…

On commence par ajouter l’option “-o fichier”:

Sur la machine B (de l’autre coté du réseau à tester):

NPtcp -h 192.168.0.100 -o nptcp.out

Puis on trace le graphe:

echo "reset; set terminal png; \
set logscale x;
set xlabel 'Taille des paquets (octets)'; \
set ylabel 'Debits (Mbps)'; \
plot 'nptcp.out' using 1:2 with linespoints;" | gnuplot > nptcp.png

Et on a le résultat suivant (sur une liaison LAN):

Quelques options en bonus…

Pour simuler un flux unidirectionnel de B vers A (streaming):

A# NPtcp -s
B# NPtcp -h 192.168.0.100 -s -o nptcp.out

Pour limiter le test a une taille maximale de paquet de 256 Ko:

NPtcp -h 192.168.0.100 -u 256000 -o nptcp.out

Pour fixer une taille minimale à 16 Ko:

NPtcp -h 192.168.0.100 -u 256000 -l 16000 -o nptcp.out

Conclusion

Un bon outil de plus à ajouter a son couteau suisse des applications open-source pour l’administration et le test de son réseau !

Ce manuel de référence, en Anglais, balaye toutes les fonctions de Zabbix en détaillant étape par étape l’installation, la configuration et l’utilisation.

Si vous voulez vous faire une idée par vous même, il est possible de télécharger gratuitement le deuxième chapitre au format PDF.

Je reviens rapidement vers vous dès que je trouve le temps de finir le livre !

PS: merci à Pack Publisher de m’avoir gracieusement fourni la version e-book de cet ouvrage.

Installation de SmokePing

Il est possible de repartir des sources en suivant cette procédure. Si vous êtes sous Ubuntu, SmokePing existe dans les dépôts et l’installation se résume à la ligne de commande suivante:

sudo aptitude install smokeping

Une fois installé, il faut configurer Apache (out tout autre serveur Web…) pour afficher les graphes générés par SmokePing (le logiciel se base sur un CGI).

cd /usr/share/smokeping/www

sudo cp apache2.conf /etc/apache2/sites-available/smokeping

sudo a2ensite smokeping

sudo /etc/init.d/apache2 reload

Vous pouvez vérifier l’installation en visitant l’URL suivante avec votre navigateur Web favori:

http://localhost//smokeping/smokeping.cgi

Configuration de SmokePing

On va maintenant passer à la phase de configuration de SmokePing pour votre réseau. Je vais ici me focaliser sur une supervision basée sur des “ping” (la probe FPing pour être précis), mais il faut noter qu’il existe un grand nombre d’extension permettant d’utiliser d’autres protocoles que ICMP (voir la liste des probes ici).

Le fichier de configuration principal se trouve à l’emplacement /etc/smokeping/config. En regardant le contenu de ce fichier, on voit que c’est juste une coque vide qui pointe vers d’autres fichiers de configurations qui se trouvent dans le répertoire /etc/smokeping/config.d. Pour aller directement à la configuration de notre réseau, il faut éditer le fichier /etc/smokeping/config.d/Targets:

*** Targets ***

probe = FPing

menu = Top
title = Network Latency Grapher
remark = Mon beau reseau a moi

+ monreseau
menu = monreseau
title = Mon reseau

++ firewall
host = firewall.mondomaine.com
++ routeur
host = routeur.monrouteur.com
++ internet
host = www.google.fr

Puis relancer SmokePing pour prendre en compte les informations:

sudo /etc/init.d/smokeping restart

Après quelques minutes, les graphes devraient commencer à se mettre à jour dans votre Interface Web (http://localhost/smokeping/smokeping.cgi):

On peut voir en vert la courbe représentant le délais réseau (environ 33ms pour faire un aller/retour vers le site www.google.fr). En gris, on peut visualiser la variation de ce délais (on a donc une estimation de la gigue).