Catégorie : Reseau

Catégories
Open-source Planet-libre Reseau Systeme Web

Protéger son serveur en utilisant Fail2Ban

Comme toutes les machines exposées au réseau Internet, mon serveur Web est continuellement la cible de tentatives d’attaques basiques de type brute force et DOS. J’avais déjà abordé le sujet sous la forme de billets tel que « Sécuriser son blog WordPress » ou « Détection des attaques DOS/DDOS avec Nagios« . Nous allons aujourd’hui parler d’une solution de protection active se déclenchant automatiquement lors d’une de ces attaques: Fail2Ban.

Comment marche Fail2Ban ?

Développé en langage Python, Fail2Ban est un logiciel libre permettant d’analyser des fichiers de logs et de déclencher des actions si certaines choses suspectes sont détectées. La grande force de Fail2Ban est sa grande modularité que cela soit au niveau des mécanismes de détections basées sur les expressions régulières ou sur les actions à mener qui peuvent aller de l’expédition d’un mail à la mise en place de règles de Firewall.

Fail2Ban se base sur un système de prisons (jails) que l’on peut définir, activer ou désactiver dans un simple fichier de configuration (/etc/fail2ban/jail.conf).

Une prison (jail) est composée, entre autres, des éléments suivants:

  • Nom du fichier de log à analyser.
  • Filtre à appliquer sur ce fichier de log (la liste des filtres disponibles se trouve dans le répertoire /etc/fail2ban/filter.d). Il est bien sûr possible de créer ses propres filtres.
  • Paramètres permettant de définir si une action doit être déclenchée quand le filtre correspond (« match »): Nombre de « matchs » (maxretry), intervalle de temps correspondant (findtime)…
  • Action à mener si nécessaire. La liste des actions se trouve dans le répertoire /etc/fail2ban/action.d. Il est également possible de créer ses propres actions.

Installation de Fail2Ban

On commence par installer Fail2Ban sur son système. Il se trouve dans la grande majorité des distributions GNU/Linux et BSD. par exemple pour l’installer sur une machine Debian 6, il suffit de saisir la commande suivante (en root ou bien précédée d’un sudo):

apt-get install fail2ban

Protection contre les attaques « brute force » SSH

Un exemple étant toujours plus parlant, nous allons configurer notre Fail2Ban pour bloquer automatiquement les adresses IP des machines essayant des attaques de type « brute force » sur notre port SSH (cette attaque est à la portée de n’importe quel « neuneu ». On trouve de très bon tutoriaux sur le sujet sur le net).

Si une machine cliente échoue 3 fois de suite lors de la saisie du couple login/password sur le serveur SSH alors on bloque l’accès au port TCP/SSH pendant 15 minutes. On analyse pour cela le fichier de log /var/log/auth.log en lui appliquant le filtre /etc/fail2ban/filter.d/sshd.conf puis, si nécessaire, l’action /etc/fail2ban/action.d/iptables.conf. La définition de cette prison (jail) est à faire dans le fichier /etc/fail2ban/jail.conf:

# SSH
# 3 retry ? > Ban for 15 minutes

[ssh]
enabled = true
port = ssh
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
logpath = /var/log/auth.log
maxretry = 3
bantime = 900

Un fois le filtre activé en relançant Fail2Ban avec la commande (en root):

service fail2ban restart

On peut rapidement voir son efficacité en regardant le fichier de log (par défaut sous /var/log/fail2ban.log):

Protection contre les attaques DOS (HTTP/GET)

Dans ce deuxième exemple nous allons voir comment lutter efficacement contre les attaques de type DOS ciblant vos serveurs Web. Ces attaques se caractérisent par un nombre inhabituel de requêtes HTTP venant d’un même client (du moins d’une même adresse IP source).

Le plus difficile est de trouver les bons paramètres correspondants à un comportement « inhabituel ». Dans l’exemple suivant, je considère comme « inhabituel » le fait qu’un client effectue plus de 360 requêtes en 2 minutes (soit une moyenne de supérieurement à 3 req/sec) sur mon serveur Web. Dans ce cas, je bloque l’accès au port HTTP pendant une durée de 10 minutes.

La prison (jail) correspondante est la suivante (à ajouter dans votre fichier /etc/fail2ban/jail.conf):

# Protect against DOS attack
# 360 requests in 2 min > Ban for 10 minutes

[http-get-dos]
enabled = true
port = http,https
filter = http-get-dos
logpath = /var/log/varnish/varnishncsa.log
maxretry = 360
findtime = 120
action = iptables[name=HTTP, port=http, protocol=tcp]
mail-whois-lines[name=%(__name__)s, dest=%(destemail)s, logpath=%(logpath)s]
bantime = 600

En regardant de plus près cette prison, on remarque qu’elle utilise en entrée le fichier de log au format NCSA généré par le système de cache Varnish que j’utilise en frontal sur mes serveurs Web (/var/log/varnish/varnishncsa.log). Il est bien sûr possible d’utiliser directement le log de votre serveur Apache ou Nginx. Le filtre http-get-dos n’est pas fourni par défaut. Il faut donc éditer le fichier /etc/fail2ban/filter.d/http-get-dos.conf avec le contenu suivant:

# Fail2Ban configuration file

#

# Author: http://www.go2linux.org

#

[Definition]

# Option: failregex

# Note: This regex will match any GET entry in your logs, so basically all valid and not valid entries are a match.

# You should set up in the jail.conf file, the maxretry and findtime carefully in order to avoid false positives.

failregex = ^<HOST>.*\"GET

# Option: ignoreregex

# Notes.: regex to ignore. If this regex matches, the line is ignored.

# Values: TEXT

#

ignoreregex =

Enfin, en cas de « match », on applique deux actions:

  1. blocage du port HTTP avec l’action iptables définie dans /etc/fail2ban/action.d/iptables.conf
  2. envoie d’un mail signalant le blocage avec l’action mail-whois-lines. L’adresse du mail est défini dans la variable destemail à modifier dans le fichier jail.conf.

Un fois le filtre activé:

service fail2ban restart

On peut regarder le fichier de log (/var/log/fail2ban.log)…:

$ tail -f /var/log/fail2ban.log

2012-02-22 11:36:59,134 fail2ban.actions: WARNING [http-get-dos] Ban 107.---.---.---

… et/ou attendre la réception des mails:

Conclusion

Ce billet est une simple introduction à l’utilisation de Fail2Ban qui peut être configuré de manière beaucoup plus personnalisé et en fonction de vous besoins. Si vous avez d’autres exemples d’utilisation, les commentaires ci-dessous sont fait pour cela !

Catégories
Open-source Planet-libre Reseau Web

OwnCloud 3 sur un serveur Debian / Nginx

Par ces temps de dématérialisation des espaces de stockages, les services en ligne comme Dropbox et SpiderOak focalisent à la fois des commentaires admiratifs (facilité d’utilisation, fiabilité) et réticents (protection de la vie privée, pérennité du service à moyen et long terme, prix). Du bon coté de la force, les alternatives libres et auto-hébergées commencent à pointer le bout de leurs nez. Une de ces solutions a eut droit à son petit buzz ces dernières semaines: OwnCloud.

J’apporte donc ma petite pierre à l’édifice en vous proposant une installation et une configuration de OwnClound version 3 sur un serveur Debian Squeeze sous NGinx.

Présentation de OwnCloud

OwnClound (en version 3 au moment de l’écriture de ce billet) se présente sous la forme d’un serveur à héberger sur une machine GNU/Linux.

Une fois installé, ce dernier propose les services suivants:

  • partage d’espaces disques via le protocole WebDav (support GNU/Linux, BSD, Mac OS X, Windows)
  • partage de fichiers en HTTP (fonction « sharing »)
  • édition de fichier en ligne
  • accès à votre musicale
  • accès à vos photos
  • synchronisation de vos contacts en utilisant le protocole CardDav
  • synchronisation de votre agenda en utilisant le protocole CalDav
  • client disponible sous IOS et Android
  • extensibilité de votre cloud avec des applications…

Installation de OwnClound

Installation de LESP

La plupart des articles sur OwnCloud se base sur une couche LAMP (Linux Apache MySQL PHP). Je vous propose d’utiliser une base LESP (LESP = Linux + Engine X aka NGinx + SqLite + PHP). Les étapes de ce premier chapitre sont à effectuer seulement si les logiciels concernés ne sont pas déjà installés. On commence par installer le couple NGinx / PHP-FPM en utilisant par exemple mon script d’auto install:

[cc]

mkdir ~/installowncloud

cd ~/installowncloud

wget https://raw.github.com/nicolargo/debianpostinstall/master/nginxautoinstall.sh

chmod a+x nginxautoinstall.sh

sudo ./nginxautoinstall.sh

[/cc]

Note: la chose importante est de compiler NGinx avec le support Webdav (–with-http_dav_module).

Configuration de LESP pour OwnCloud

Par défaut, PHP n’autorise pas l’upload de fichier de plus de 2 Mo. Il faut donc changer cette configuration en éditant le fichier /etc/php5/fpm/php.ini pour augmenter cette limite à 1000 Mo (ou plus, c’est à adapter à vos besoins).

[cc]

post_max_size = 1000M

upload_max_filesize = 1000M

[/cc]

On configure NGinx pour qu’il gère le site cloud.comaine.com pointant vers le répertoire /var/www/owncloud (là encore, la configuration est à adapter à votre infrastructure) en éditant le fichier /etc/nginx/sites-enabled/owncloud (à adapter à votre besoins/configuration):

[cc]

server {

listen 80;

server_name cloud.mondomaine.com;

root /var/www/owncloud;

client_max_body_size 1000M;

index index.php;

dav_methods PUT DELETE MKCOL COPY MOVE;

create_full_put_path on;

dav_access user:rw group:rw all:r;

try_files $uri $uri/ @webdav;

location @webdav {

fastcgi_split_path_info ^(.+\.php)(/.+)$;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

include fastcgi_params;

fastcgi_pass 127.0.0.1:9000;

}

# PHP scripts -> PHP-FPM server listening on 127.0.0.1:9000

location ~ \.php$ {

try_files $uri =404;

fastcgi_pass 127.0.0.1:9000;

fastcgi_index index.php;

include fastcgi_params;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

}

# Stuffs

location = /favicon.ico {

access_log off;

return 204;

}

# Protect hidden file to read/write access

location ~ /\. {

deny all;

}

}

[/cc]

On relance NGinx:

[cc]

sudo /etc/init.d/nginx reload

[/cc]

Il est possible d’utiliser le protocole sécurisé HTTPS en lieu et place de HTTP pour les communications entre le navigateur Web et votre serveur OwnCloud. La configuration est donnée en exemple sur cette page.

Installation des dépendances

OwnCloud utilise des librairies pour fonctionner correctement. Sous Debian (et Ubuntu), l’installation de dépendances se fait de la manière suivante:

[cc]

sudo apt-get install php5-sqlite php5-json mp3info curl libcurl3 libcurl3-dev php5-curl zip git

[/cc]

Installation de OwnClound depuis son dépôt GIT

OwnClound étant un projet encore « jeune », les évolutions sont fréquentes et je vous conseille l’installation depuis le HEAD des « sources » Git.

[cc]

cd ~/installowncloud

git clone git://gitorious.org/owncloud/owncloud.git

sudo mv owncloud /var/www/

sudo chown -R www-data:www-data /var/www/owncloud

sudo /etc/init.d/php5-fpm restart

[/cc]

Il ne reste plus qu’à finaliser l’installation en pointant un navigateur Web sur l’adresse de votre serveur:

http://cloud.votredomaine.com/

Et oh joie oh espoir:

Mettre à jour OwnCloud

Pour mettre à jour OwnCloud:

[cc]

cd /var/www/owncloud

sudo git pull

sudo chown -R www-data:www-data /var/www/owncloud

[/cc]

Utilisation de OwnCloud

Utilisation de l’interface Web

L’interface Web est légère et bien pensée. Elle présente vos fichiers sous la forme d’une arborescence classique (répertoire/ficher) ou bien avec des filtre pour n’afficher que vos fichiers musicaux (onglet Musique) ou photos (onglet Galerie si vous avez installé l’application). OwnCloud permet bien sûr de jouer vos musiques à distance (fonction streaming). Utilisant le service Spotify, je n’utilise pas trop cette fonction. La visualisation des images est un plus mais ne remplace pas un service dédié (comme on peut le trouver sur Internet).

Bref vous l’aurez compris, je n’ai pas vraiment accroché sur les applications tierces (musiques, photos, contact, agenda…), j’ai mes habitudes avec des services « Web » et il est dur d’en changer. Par contre, la fonction principale de OwnCloud (la mise à disposition d’un espace de stockage dans un nuage) est une alternative possible à Dropbox ou SpiderOak. Il faut toutefois relativiser cette comparaison. En effet, la population des personnes intéressées par OwnCloud et disposant d’une machine allumée et connectée en permanence sur Internet se limite au petit monde des GL (Geeks Libristes).

Nous allons voir maintenant comment accéder à son espace de stockage OwnCloud en utilisant autre chose que l’interface Web.

Accès direct depuis le serveur

Par défaut, vos fichiers sont stockés sur le serveur dans le répertoire /var/www/owncloud/data/user/files. Il est donc tout à fait possible d’accéder directement à cette arborescence depuis le serveur ou un accès distant comme SSH. Il faut par contre veiller à ce que les fichiers / sous-répertoires appartiennent à l’utilisateur www-data:www-data afin que l’on puisse les gérer avec les autres moyens d’accès (interface Web, Webdav…). Attention toutefois, dans sa version actuelle, OwnCloud ne gère pas les liens symboliques.

WebDav depuis Linux

Le plus simple est de faire le montage WebDav depuis votre navigateur de fichier. Sous Gnome le menu « Se connecter à un serveur » (Connect to a server) permet d’afficher la fenêtre suivante:

Il suffira ensuite de créer un bookmark vers le point de montage WebDav ainsi obtenu en le renommant OwnCloud. Un simple click vers ce bookmark vous donnera l’accès à vos données dans votre nuage.

Il est bien sûr possible de faire la manipulation en ligne de commande (après l’installation de davfs2):

[cc]

mount -t davfs http://cloud.mondomaine.com/files/webdav.php /home/user/owncloud

[/cc]

Update (27/02/2012): Afin de simplifier le lien entre vos répertoires locaux et ceux disponibles dans votre Cloud, il est également possible d’utiliser le couple Mirall/CSync qui comblent le gap des fonctions proposées par Dropbox avec un client desktop bien pensé.

WebDav sous Windows

Sous Windows 7, la manipulation est un peu plus complexe, il faut en effet modifier une clé de registre à partir du logiciel « regedit »:

HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Services > WebClient > Parameters > BasicAuthLevel = 2

On peut ensuite passer par l’outil système de connexion de lecteur réseau:

Conclusion

Bien que réservé aux heureux possesseurs d’un serveur connecté en permanence à Internet, OwnCloud est un projet intéressant. Il centralise en un seul point les services utiles à la vie numérique de tous les jours: fichiers, images, photos, contact, agenda. Il lui manque encore quelques fonctions qui seront sûrement apportées par le système de plugins. Je pense notamment à: possibilité de jouer en streaming les vidéos stockées dans notre « cloud », accès par un protocole plus optimisé que WebDav (par exemple SSH), connexion vers les réseaux sociaux pour facilité le partage…

Le modèle économique de la société qui se cache derrière ce projet est de conserver le coeur du système (le serveur OwnCloud) sous licence libre (actuellement AGPL version 3) et de proposer une offre commerciale pour héberger vos données sur leurs infrastructures (cette offre sera disponible mi mars 2012).

Alors près à « switcher » vos données vers votre propres cloud ? Personnellement, j’attend encore un peu.

Quelques liens consultés lors de la rédaction de ce billet:

 

Catégories
Open-source Planet-libre Reseau Systeme

Installation et configuration de Munin, le maître des graphes

Munin est un logiciel de supervision permettant de centraliser la gestion des graphes de données RRDTools. Il permet en quelques commandes que nous allons détailler dans ce billet de générer des graphes complexes pour surveiller vous machines et les processus qui tournent dessus.

Voici un exemple de graphe sur les statistiques remontées par un serveur utilisant Varnish:

Introduction

Munin est proposé sous la forme de deux packages complémentaires: munin et munin-node.

Le premier (munin) est à installer sur votre serveur de supervision (appelé maître). Son objectif principal est de récupérer les données venant des machines à surveiller puis de générer des graphes qui seront présentés aux utilisateurs via une interface Web.

Le second  (munin-node) est à installer sur toutes les machines à superviser (appelées noeuds). Son objectif est de collecter les informations systèmes en utilisant des plugins (présent dans le package munin-node et dans munin-plugins-extra).

La communication entre le serveur maître et les machines noeuds utilise, par défaut le protocole TCP/4949 (initialisation de la connexion TCP de la part du serveur maître).

Installation de Munin

Pour la suite de ce billet (et sauf mention spécifique), je partirai sur le principe ou vous utilisez des machines sous Debian/Ubuntu.

Installation de Munin sur le serveur maître

Le serveur maître doit disposer d’un serveur Web (voir ce billet pour installer simplement NGinx sur votre système) configuré avec le répertoire root par défaut: /var/www.

Comme Munin est présent dans les dépôts officiels, il suffit de saisir la commande suivant qui va installer le package maître ainsi que le package esclave histoire de pouvoir superviser son serveur de supervision…:

sudo apt-get install munin munin-node munin-plugins-extra

sudo ln -s /var/cache/munin/www /var/www/munin

sudo /etc/init.d/munin-node restart

En faisant pointer un navigateur Web vers l’URL:

http://votreserveurdesupervision/munin

Vous devriez voir s’afficher les statistiques de votre serveur. Il faut attendre quelques minutes avant de voir les premiers graphes, le temps que les bases de données soient renseignées.

Installation de Munin sur les machines noeuds

Installation des noeuds sous GNU/Linux

Là encore c’est assez simple:

sudo apt-get install munin-node munin-plugins-extra

La configuration de Muni sur les machines noeuds est centralisée dans le fichier /etc/munin/munin-node.conf. Il faut éditer ce fichier pour y configurer l’adresse IP de votre serveur maître à la ligne suivante:

# A list of addresses that are allowed to connect. This must be a

# regular expression, since Net::Server does not understand CIDR-style

# network notation unless the perl module Net::CIDR is installed. You

# may repeat the allow line as many times as you'd like

allow ^192\.168\.1\.200$

Cette configuration (à adapter à votre besoin) va autoriser la machine maître d’adresse IP 192.168.1.200 à se connecter sur cette machine noeud pour y récupérer les données à superviser.

Il faut ensuite relancer le service Munin-node pour faire prendre en compte la nouvelle configuration:

sudo /etc/init.d/munin-node restart

Installation des noeuds sous Windows

Le projet Munin ne fourni pas de « node » pour WIndows, il faut donc se retourner du coté de la communauté pour trouver notre bonheur. En l’occurrence du coté du logiciel Munin-Node-Win32 disponible au téléchargement sur cette page.  Il suffit de lancer l’installer pour que l’installation et le lancement du processus en tache de fond soit effectué (procédure testé sous Windows 7).

Installation des noeuds sous MacOS

Si vous avez à surveiller des machines sous Mac OS X, il va falloir mettre un peu plus les mains dans le cambouis. En effet, il faut obligatoire passer par l’installation des gestionnaires de paquets Fink ou MacPorts. Je vous conseille la lecture du Wiki officiel.

Configuration des plugins sur les machines noeuds

Nous allons voir dans cette sections comment configurer ce que l’on souhaite superviser sur les machines noeuds. Munin utilise le fichier  /etc/munin/plugin-conf.d/munin-node (ainsi que tous les fichiers se trouvant dans le même répertoire) pour configurer les paramètres des plugins (bien souvent de simples script Perl).

Le répertoire /etc/munin/plugins/ contient la liste des plugins utilisables par la machine noeud et le répertoire /usr/share/munin/plugins/ l’ensemble des plugins. En y regardant de plus prêt, le répertoire  /etc/munin/plugins/ fait des liens symboliques vers le répertoire /usr/share/munin/plugins/.

Pour voir la liste des plugins disponibles sur le noeud, on peut utiliser:

# sudo munin-node-configure

Exemple de l’ajout des plugins NGinx (permettant de surveiller un serveur Web NGinx) sur un noeud:

Pour faire prendre en compte un nouveau plugin sur un noeud (node) il faut faire un lien symbolique entre le fichier en question dans ce répertoire et /etc/munin/plugins/. Par exemple pour accéder aux stats de mon serveur NGinx:

sudo ln -s /usr/share/munin/plugins/nginx_status /etc/munin/plugins/nginx_status

sudo ln -s /usr/share/munin/plugins/nginx_request /etc/munin/plugins/nginx_request

Il est quelquefois necessaire d’installer des dependances pour que le plugin fonctionne.

Pour voir les dépendances nécessaire il suffit de saisir la commande:

sudo munin-node-configure --suggest | grep nginx

nginx_request | yes | no [LWP::UserAgent not found]

nginx_status | yes | no [LWP::UserAgent not found]

Il faut donc installer la librairie perl contenant le module LWP qui est présente dans le package libwww-perl sur Debian/Ubuntu:

sudo apt-get install libwww-perl

Cela a l’air OK:

sudo munin-node-configure --suggest

nginx_request | yes | yes

nginx_status | yes | yes

On peut faire prendre en compte la configuration par Munin-node:

sudo /etc/init.d/munin-node restart

Configuration du maître pour prendre en compte les machines noeuds

Une fois toutes vos machines noeuds configurés (voir le chapitre précédant), il faut maintenant modifier la configuration du serveur maître pour les prendre en compte. Là encore, fidèle à la philosophie Unix, la configuration est centralisé dans le fichier /etc/munin/munin.conf.

En plus des répertoires systèmes en début de fichier:

# The next three variables specifies where the location of the RRD

# databases, the HTML output, logs and the lock/pid files. They all

# must be writable by the user running munin-cron. They are all

# defaulted to the values you see here.

#

dbdir /var/lib/munin

htmldir /var/cache/munin/www/

logdir /var/log/munin

rundir /var/run/munin

Il faut configurer la liste des noeuds de la manière suivante:

# A simple host tree for mondomaine.com

[maitre.mondomaine.com]

address 127.0.0.1

[noeud1.mondomaine.com]

address noeud1.mondomaine.com

[noeud2.mondomaine.com]

address noeud2.mondomaine

Reste à relancer le serveur Munin pour prendre en compte la configuration:

su - munin --shell=/bin/bash

/usr/share/munin/munin-update

exit

En faisant pointer un navigateur Web vers l’URL:

http://votreserveurdesupervision/munin

Puis par exemple les graphes sur l’occupation mémoire:

Pour voir une démonstration en ligne des capacités de Munin, vous pouvez consulter ce serveur maître qui est en accès libre.

Plus de plugins ?

Un des gros avantage de Munin est le fait de pouvoir simplement écrire de nouveaux plugins en utilisant votre langage favori (nous reviendrons bientôt sur ce sujet dans un prochain billet).  Pas mal d’exemples sont proposés  dans le dépôt GitHub suivant (vous devriez trouver votre bonheur).
Catégories
Open-source Planet-libre Reseau Systeme

Debian et les mails depuis la ligne de commande

Suite à l’installation d’un serveur Kimsufi 16G sous Debian 6.0 puis configuré avec mon script de post installation spécial serveur, j’ai attendu en vain la réception des premiers apports de Fail2ban qui devaient être envoyés par mail.

Une petit visite des fichiers de logs me montre rapidement d’ou vient le problème:

… Can’t exec /usr/lib/sendmail: No such file or directory…

Par défaut, il n’y a donc pas de brique système permettant d’envoyer des mails.

Installation de Postfix

Pour résoudre cela, j’ai donc exécuté la commande suivante qui va installer le serveur de messagerie Postfix:

[cc lang= »bash »]

sudo apt-get install postfix

[/cc]

Puis configuré Postfix de la manière suivante:

Puis:

Configure le Firewall

Cette section est optionnelle et ne concerne que les serveurs qui embarque un Firewall système (Iptables).

Si vous avez un Firewall sur votre serveur (j’utilise ce script que je place dans /etc/init.d/), il faut autoriser les flux sortant sur le port SMTP (TCP/25) sous risque d’avoir le message suivant dans votre fichier syslog:

Dec 11 08:46:00 ks387949 kernel: IN= OUT=eth0 SRC=176.31.252.29 DST=217.70.184.162 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=30778 DF PROTO=TCP SPT=59718 DPT=25 WINDOW=14600 RES=0x00 SYN URGP=0

Pour cela, il faut éditer le script puis ajouter le port 25 dans la variable REMOTE_TCP_SERVICES:

REMOTE_TCP_SERVICES= »22 25 80 443″

Et enfin relancer le script:

[cc lang= »bash »]

sudo /etc/init.d/firewall.sh restart

[/cc]

On teste

Le plus simple est d’utiliser la ligne de commande et la commande mail:

[cc lang= »bash »]

$ mail contact@nicolargo.com

Subject: Test

Test de 09:27

.

[/cc]

Quelques secondes plus tard, vous devriez recevoir le mail:

A vous les rapports Fail2ban…

Catégories
Developpement Open-source Planet-libre Reseau Systeme

Glances: vos stats systèmes en un clin d’oeil

Il y a quelques jours, je vous avais parlé de Saidar, un logiciel permettant de regrouper dans un terminal|console un certain nombre de statistiques sur votre machine. Après quelques heures d’utilisations, j’ai identifié des choses qui ne me convenait pas:

  • pas d’affichage de la mémoire réellement disponible (comme on peut le trouver sur la deuxième ligne de la commande free -m)
  • pas de détail au niveau des processus
  • affichage des débits réseaux en octets/sec alors que j’utilise toujours les bits/sec
  • pas d’information sur l’espace disque disponible

Comme je ne trouvais pas la « killer application » dans ce domaine (même si il existe de très bon outils comme top), j’ai décidé de repartir d’une feuille blanche et de développer le logiciel Glances (licence LGPL) dont je vais vous présenter les grandes lignes dans ce billet.

Glances screenshot

Objectifs

Ils sont multiples:

  • prises en compte de mes griefs sur Saidar
  • accès à la fois depuis un environnement graphique (terminal) qu’à distance (console)
  • mise en avant des statistiques importantes à la compréhension d’un éventuel problème
  • affichage des processus triés de manière intelligente et automatique
  • développement en langage Python (je connais assez bien, c’est portable et facile à maintenir)

Installation

Après avoir téléchargé la dernière version stable disponible , il suffit de saisir les commandes suivantes:

[cc lang= »bash »]

tar zxvf glances-version.tar.gz

cd glances-version

./configure

make

sudo make install

[/cc]

Notes: remplacer « version » par le numéro de version que vous avez téléchargé…

Glances a besoin de la librairie python-statgrab version 0.5 (ou supérieure) pour fonctionner correctement. Sous Ubuntu, il suffit de lancer la commande:

[cc lang= »bash »]

sudo apt-get install python-statgrab

[/cc]

Sous Debian Squeeze, seule la version 0.4 de python-statgrab est disponible dans les dépôts. Il faut donc installer la version 0.5:

[cc lang= »bash »]

sudo apt-get install libstatgrab-dev

wget http://ftp.uk.i-scream.org/sites/ftp.i-scream.org/pub/i-scream/pystatgrab/pystatgrab-0.5.tar.gz

tar zxvf pystatgrab-0.5.tar.gz

cd pystatgrab-0.5/

./setup.py build

sudo ./setup.py install

[/cc]

Utilisation

On lance le logiciel avec la commande:

[cc lang= »bash »]

glances.py

[/cc]

Par défaut, le rafraîchissement des données se fait toutes les secondes. Il est possible de l’augmenter avec l’option -t. Par exemple pour avoir un taux de rafraîchissement de 5 secondes:

[cc lang= »bash »]

glances.py -t 5

[/cc]

Une fois lancé, les touches suivantes sont actives:

  • ‘a’: passer le tri des processus en automatique (c’est le mode par défaut). Glances utilisera par défaut un tri décroissant sur l’utilisation CPU. Si une alerte sur la mémoire globale apparaît (mémoire occupé > 70%), le tri se fera alors par occupation mémoire.
  • ‘c’: forcer le tri des processus en fonction de leurs utilisations de la CPU.
  • ‘m’: forcer le tri des processus en fonction de leurs occupations mémoire.
  • ‘q’: quitter le programme (on peut également utiliser CTRL-C).

Si votre terminal|console est compatible avec un affichage couleur, alors les statistiques importantes (à mes yeux…) sont mises en avant de la manière suivante:

  • VERT: le compteur est < 50%
  • BLEU: le compteur est > 50% et < 70%
  • VIOLET: le compteur est > 70% et < 90%
  • ROUGE: le compteur est > 90%

Limitations

L’API python-statgrab comporte actuellement un bug pour la récupération des statistiques sur les espaces disques. Dès que ce dernier sera corrigé, je pense inclure ces statistiques dans l’espace libre en bas à gauche de la fenêtre de Glances.

Un problème ?

Si vous rencontrez un problème lors de l’installation ou de l’utilisation de Glances:

  1. Vérifié que le problème n’est pas référencé
  2. Saisir le nouveau bug dans le tracker GitHub

Lors de la saisie du bug merci de fournir les informations suivantes:

  • Système d’exploitation (nom, version)
  • version de Python (python -v)
  • version de la librairie statgrab (apt-cache show statgrab)
  • version de la librairie python-statgrab (apt-cache show python-statgrab)

Contribuer ?

Le logiciel est distribué sous licence libre LGPL. Il est disponible dans le GitHub suivant: https://github.com/nicolargo/glances

Si vous trouvé ce logiciel intéressant et que vous souhaitez vous impliquer, j’ai besoin de vous sur les sujet suivants:

  • packaging de Glances pour Debian, Ubuntu (PPA), Fedora, Redhat, Free|Open|NetBSD…
  • amélioration/optimisation du code (lire le billet contribuer à un projet hébérgé sur GitHub)
  • inclure la vérification de la présence de la librairie python-statgrab lors du .configure (j’ai un bug dans le configure.ac)
  • ‘Man’ page
  • Afficher une fenêtre d’aide avec les touches disponibles quand on clique sur F1
  • Corriger le bug de python-statgrab afin que l’on puisse inclure les statistiques sur les systèmes de fichiers
  • …

J’attends vos retours. 🙂

Catégories
Open-source Planet-libre Reseau

Installation d’un serveur de temps sur votre réseau

Dans un système d’information moderne, la synchronisation des machines sur une horloge commune est un pré-requis pour de nombreuses actions comme l’analyse des logs ou la supervision système et réseau. Si vos machines sont directement connectés à Internet alors il n’y a pas de problème car les distributions GNU/Linux, Windows et Mac OS X embarquent des mécanisme pour se mettre automatiquement à l’heure en se synchronisant sur des serveurs publics (par exemple 0.debian.pool.ntp.org sur une Debian Squeeze). Si ce n’est pas le cas et que vos machines sont isolées et/ou bien filtrées lors de leurs accès à Internet, il peut être intéressant d’installer un serveur de temps local sur une de vos machine.

Nous allons donc dans ce billet installer un serveur de temps NTP sur une machine sous Debian 6 (Squeeze).

Le protocole NTP

J’invoque le bon génie Wikipédia: « Le Protocole d’Heure Réseau (Network Time Protocol ou NTP) est un protocole qui permet de synchroniser, via un réseau informatique, l’horloge locale d’ordinateurs sur une référence d’heure. »

La référence en question sera donc, dans notre cas, la machine ou nous allons installer puis configurer notre serveur NTP.

Le protocole NTP utilise le port UDP/123 pour effectuer les requêtes sur le réseau. Notre serveur sera donc en écoute sur le port UDP 123 (si vous avez un Firewall, il faudra bien entendu le configurer pour autoriser les requêtes sur ce port).

Installation du serveur NTP

On commence par installer les paquets nécessaires dans une console root:

[cc lang= »bash »]

apt-get install ntp ntpdate

[/cc]

La première chose à faire est de mettre le serveur à la bonne heure (quitte à avoir une référence, autant qu’elle soit juste…).

Pour cela deux solutions:

  • si votre machine à accès à Internet, utiliser la commande « ntpdate-debian » qui va synchroniser votre machine sur les serveur NTP Debian.
  • si votre machine n’a pas accès à Internet, alors téléphoner à l’horloge parlante (numéro payant: 3699) puis configurer l’heure système avec la commande « date ». Par exemple « date -s 16:56:23 ».

On édite ensuite le fichier /etc/ntp.conf:

[cc lang= »bash »]

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift

# Enable this if you want statistics to be logged.

#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

# You do need to talk to an NTP server or two (or three).

#server ntp.your-provider.example

# 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

# pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server will

# pick a different set every time it starts up. Please consider joining the

# pool: <http://www.pool.ntp.org/join.html>

# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for

# details. The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>

# might also be helpful.

#

# Note that « restrict » applies to both servers and clients, so a configuration

# that might be intended to block requests from certain clients could also end

# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don’t allow configuration.

restrict -4 default kod notrap nomodify nopeer noquery

restrict -6 default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.

restrict 127.0.0.1

restrict ::1

# Clients from this (example!) subnet have unlimited access, but only if

# cryptographically authenticated.

#restrict 192.168.123.0 mask 255.255.255.0 notrust

# My server is a public server

restrict 0.0.0.0 mask 0.0.0.0

# If you want to provide time to your local subnet, change the next line.

# (Again, the address is an example only.)

broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the

# next lines. Please do this only if you trust everybody on the network!

#disable auth

#broadcastclient

[/cc]

Les informations intéressantes sont les suivantes:

server 0.fr.pool.ntp.org

server 1.fr.pool.ntp.org

server 2.fr.pool.ntp.org

server 3.fr.pool.ntp.org

Permet de configurer les serveurs maîtres sur lesquels votre machine va essayer de se synchroniser pour rester à l’heure. Il faut bien sûr que votre machine est accès à Internet sur le port UDP/123.

restrict 0.0.0.0 mask 0.0.0.0

On rends notre serveur public, toutes les machines ayant un accès réseau (encore une fois sur le port UDP/123) pourront se synchroniser à partir de votre serveur. Il est bien sûr possible de limiter ce droit aux seules machines de vos réseaux.

broadcast 192.168.0.255

(optionnel) Diffuse le temps sur l’adresse de broadcast de votre réseau (par exemple 192.168.0.0/24).

On relance ensuite le serveur pour que la configuration soit prise en compte:

[cc lang= »bash »]

# /etc/init.d/ntp restart

Stopping NTP server: ntpd.

Starting NTP server: ntpd.

[/cc]

Synchroniser vos machines avec votre serveur NTP

La configuration des clients est relativement simple car souvent inclus dans les « wizards » d’installations. Il suffit de préciser l’adresse IP ou le nom de votre machine hébergeant le serveur NTP comme serveur de temps.

Sur un client Debian 6 existant, il faut installer le package suivant (en root):

[cc lang= »bash »]

apt-get install ntpdate

[/cc]

Puis lancer la commande suivante (si votre serveur de temps est hébergé sur la machine 192.168.0.100):

[cc lang= »bash »]

ntpdate -dv 192.168.0.100

[/cc]

Conclusion

Le protocole NTP étant normalisé, il est bien sur possible de synchroniser toutes vos machines (Linux, BSD, Windows, OS X…) sur votre nouveau serveur de temps.

Catégories
Reseau

Cisco et le routage inter VLAN

Nous allons dans ce billet mettre en place une architecture réseau basée sur des équipements Cisco (un routeur 1841 et un switch 2960). Deux réseaux LAN différents (un pour les chefs, un autre pour le peuple) seront disponibles sur le même switch (en utilisant les fonctions VLAN). Le routage (et éventuellement le filtrage) entre ces deux réseaux LAN se fera par le routeur.

Voici un schéma simplifié:

Dans la suite du billet nous utiliserons le plan d’adressage IP suivant:

  • Réseau des chefs: 192.168.1.0/24
  • Réseau du peuple: 192.168.2.0/24

Configuration du switch Ethernet (Cisco Catalyst 2960)

L’idée générale est d’associer chaque port à un des deux réseaux virtuel. Par exemple on voudra brancher le PC du chef sur le port n°1, celui de sa secrétaire sur le port n°2.

Nous allons donc dans un premier temps définir deux réseaux LAN virtuel (VLAN):

  • Réseau des chefs: VLAN id n°1
  • Réseau du peuple: VLAN id n°2

Puis associer les ports Ethernet physique à ces VLANs:

  • VLAN id n°1:  Port n°1
  • VLAN id n°2:  Port n°2

La configuration IOS est donc la suivante:

vlan 1

name CHEFS

!

vlan 2

name PEUPLE

!

interface GigabitEthernet1/0/1

description Reseau des chefs

switchport access vlan 1

switchport mode access

switchport nonegotiate

!

interface GigabitEthernet1/0/2

description Reseau du peuple

switchport access vlan 2

switchport mode access

switchport nonegotiate

Il faut ensuite configurer l’interface Ethernet (arbitrairement le port n°24) qui fera le lien vers le routeur. La caractéristique de cette interface est qu’elle doit appartenir à tout les VLANs.

  • VLAN id n°1:  Port n°1 et n°24
  • VLAN id n°2:  Port n°2 et n°24

Pour cela nous utilisons la configuration suivante:

interface GigabitEthernet1/0/24

description Trunk de tous les VLAN vers le routeur

switchport mode trunk

Il ne reste plus qu’a faire les branchements:

  • Le PC du chef (en 192.168.1.100/24) sur le port n°1
  • Le PC de la secrétaire (en 192.168.2.100/24) sur le port n°2
  • Le routeur sur le port n°24

Configuration du routeur IP (Cisco 1841)

Le routeur Cisco 1841 est un routeur LAN/LAN. Nous allons utiliser l’interface FastEthernet0/1 pour effectuer le routage inter VLAN. L’autre interface (la FastEthernet0/0) pourra, par exemple être connecté directement à la box/routeur Internet).

On commence donc par activer l’interface FastEthernet0/1 (elle doit être shutdown par défaut):

interface FastEthernet0/1

description LAN-VLANS

no ip address

duplex auto

speed auto

Ensuite on génère les interfaces virtuelles correspondantes à chacun des VLANs. Les interfaces virtuelles auront comme adresse IP:

  • 192.168.1.254 pour le VLAN 1
  • 192.168.2.254 pour le VLAN 2
interface FastEthernet0/1.1

description VLAN des chefs

encapsulation dot1Q 1

ip address 192.168.1.254 255.255.255.0

!

interface FastEthernet0/1.2

description VLAN du peuple

encapsulation dot1Q 2

ip address 192.168.2.254 255.255.255.0

Une fois la configuration en place, vous devriez sans problème pouvoir « pinguer » les machines entre elles (il n’y a pas de filtrage par défaut).

Catégories
Open-source Planet-libre Reseau

Installer un serveur TFTP pour vos Cisco

Un rapide billet pour rappeler les étapes nécessaires à la mise en place d’un serveur TFTP sur un système GNU/Linux (Debian Squeeze) afin de sauvegarder les configurations de vos routeurs Cisco.

Installation du serveur TFTPD

On utilise le paquet tftpd qui se trouve dans les dépôts Debian (commande à saisir dans un terminal root ou en utilisant la commande sudo):

apt-get install tftpd

On doit ensuite créer le répertoire ou seront stockés les fichiers des configurations Cisco (/srv/tftp dans mon cas).

mkdir /srv/tftp
chmod -R 777 /srv/tftp
chown -R nobody /srv/tftp

Si vous choisissez un autre répertoire que /srv/tftp, il faut:

  1. éditer le fichier de configuration /etc/inetd.conf et changer le répertoire de la ligne commençant par tftp
  2. Redémarrer le serveur TFTP avec la commande /etc/init.d/open-inetd restart

Création du fichier de configuration vide

TFTP est un protocole de communication de bas niveau. Il ne met pas en place de mécanisme d’authentification. La création du fichier de configuration vide doit donc se faire à partir du serveur (il est possible de changer ce comportement et ainsi de permettre au client, c’est à dire au routeur Cisco, de créer lui même le fichier mais je ne le conseille pas pour des questions de sécurité).

On va donc créer un fichier vide nommé cisco-rtr-01-confg:

touch /srv/tftp/cisco-rtr-01-confg
chmod -R 777 /srv/tftp
chown -R nobody /srv/tftp

Sauvegarde de la configuration depuis le routeur Cisco

On en vient enfin au vif du sujet: c’est à dire la sauvegarde de la configuration (IOS running) de notre Cisco sur le serveur TFTP.

# copy run tftp:
Address or name of remote host []? 192.168.0.100
Destination filename [yourname-confg]? cisco-rtr-01-confg
!!
1292 bytes copied in 0.380 secs (3400 bytes/sec)

Il faut bien sûr remplacer l’adresse 192.168.0.100 par l’adresse IP (ou le nom) de votre machine Debian ou vous avez installés TFTP.

Catégories
Gstreamer Hardware Open-source Reseau Systeme

Supervision SMART de vos disques via Nagios

Disque dur

Disque durSuperviser l’espace disque des serveurs est une bonne chose… encore faut il que les données soient stockées sur des disques en bonne santé. Le but de ce billet est de mettre en place via Nagios/Shinken une supervision de l’état SMART renvoyé par l’outil Smartmontool.

Sur le serveur à superviser

Les pré-requis

La commande smartctl sera exécutée avec sudo, il faut donc l’installer si ce n’est pas déjà fait sur votre système:

[cce lang=bash »]

apt-get update

apt-get install sudo

[/cce]

Il fait aussi installer l’outil de vérification SMART : SmartMonTools.

[cce lang=bash »]

apt-get install smartmontools

[/cce]

Superviser quels disques ?

Pour savoir quels disques superviser, on peut utiliser la commande suivante (en root):

[cce lang=bash »]

fdisk -l

[/cce]

Exemple : sur un RAID1, on trouvera souvent /dev/sda et /dev/sdb. On prendra ce cas pour illustrer le reste de notre procédure.

Récupération et installation du plugin

Téléchargement du script :

[cce lang=bash »]

cd /etc/snmp/

wget https://raw.github.com/nicolargo/nagiosautoinstall/master/check_smart.pl

[/cce]

On donne les droits d’exécution :

[cce lang=bash »]

chmod 755 /etc/snmp/check_smart.pl

[/cce]

Modification de la configuration de SNMP

Pour prendre en compte Smart, il faut modifier la configuration de votre serveur SNMP (suivre cette procédure pour installer le serveur SNMPd sur votre machine) en éditant le fichier snmpd.conf et en y ajoutant les lignes suivantes :

[cce lang=bash »]

vi /etc/snmp/snmpd.conf

exec SmartSDA /etc/snmp/check_smart.pl -t -d /dev/sda

exec SmartSDB /etc/snmp/check_smart.pl -t -d /dev/sdb

[/cce]

Note : L’ordre des lignes est important !

La première ligne « exec » aura l’OID « .1.3.6.1.4.1.2021.8.1.101.1 », la seconde ligne l’OID « .1.3.6.1.4.1.2021.8.1.101.2 », etc…

Si vous utilisez déjà des commande exec dans le fichier snmpd.conf, les OID ne correspondront pas forcément avec ceux de cette procédure.

Redémarrage du service SNMP

[cce lang=bash »]

/etc/init.d/snmpd restart

[/cce]

Modification des sudoers

Il faut autoriser l’utilisateur snmp à exécuter la commande « /usr/sbin/smartctl ».

Pour faire cela, il est nécessaire de modifier le fichier /etc/sudoers via la commande visudo et d’ajouter :

[cce lang=bash »]

snmp ALL= NOPASSWD:/usr/sbin/smartctl

[/cce]

Vérification du plugin

Pour voir si les résultats des checks sont bien rentrés dans la MIB SNMP du serveur, on teste avec cette commande :

[cce lang=bash »]

snmpwalk -c public -v 1 [IP du serveur à superviser] .1.3.6.1.4.1.2021.8.1

[/cce]

On devrait avoir quelque chose du genre :

UCD-SNMP-MIB::extIndex.1 = INTEGER: 1

UCD-SNMP-MIB::extIndex.2 = INTEGER: 2

UCD-SNMP-MIB::extNames.1 = STRING: SmartSDA

UCD-SNMP-MIB::extNames.2 = STRING: SmartSDB

UCD-SNMP-MIB::extCommand.1 = STRING: /etc/snmp/check_smart.pl

UCD-SNMP-MIB::extCommand.2 = STRING: /etc/snmp/check_smart.pl

UCD-SNMP-MIB::extResult.1 = INTEGER: 0

UCD-SNMP-MIB::extResult.2 = INTEGER: 0

UCD-SNMP-MIB::extOutput.1 = STRING: SMART overall-health self-assessment test result: PASSED

UCD-SNMP-MIB::extOutput.2 = STRING: SMART overall-health self-assessment test result: PASSED

UCD-SNMP-MIB::extErrFix.1 = INTEGER: noError(0)

UCD-SNMP-MIB::extErrFix.2 = INTEGER: noError(0)

UCD-SNMP-MIB::extErrFixCmd.1 = STRING:

UCD-SNMP-MIB::extErrFixCmd.2 = STRING:

L’état SMART du disque sda est remonté sur l’OID : .1.3.6.1.4.1.2021.8.1.101.1

L’état SMART du disque sdb est remonté sur l’OID : .1.3.6.1.4.1.2021.8.1.101.2

Sur le serveur Nagios

Création de la commande

On défini une nouvelle commande en ajoutant les lignes suivantes dans le fichier commands.cfg:

[cce lang=bash »]

define command{

command_name check_smart

command_line $USER1$/check_snmp -H $HOSTADDRESS$ -C public -o $ARG1$ -r $ARG2$

;command_example !.1.3.6.1.4.1.2021.8.1.101.1!PASSED

}

[/cce]

Syntaxe de la commande :

• -H Hostaddress : IP ou nom DNS de la machine à superviser

• -C public : Communauté SNMP (on peut la mettre en variable si on veut)

• -o $ARG1$ : OID SNMP à intérroger

• -r $ARG2$ : Comparaison avec une chaine de caratère, ici « PASSED » (attention de respecter la casse). Si dans le retour du check, on ne trouve pas la chaine de caractère « PASSED », le service va passer en « Critical ».

Exemple de service

On défini ensuite le service:

[cce lang=bash »]

define host{

use generic-host

host_name monserveur

alias Serveur_Zimbra

address 192.168.0.100

}

define service{

use generic-service

host_name monserveur

service_description SMART_sda

check_command check_smart!.1.3.6.1.4.1.2021.8.1.101.1!PASSED

}

[/cce]

Il ne reste plus qu’à redémarrer votre service Nagios ou Shinken pour prendre en compte la configuration:

[cce lang=bash »]

sudo /etc/init.d/nagios restart

[/cce]

Catégories
Developpement Open-source Planet-libre Reseau Systeme Web

VnStat.js, un node pour VnStat

Mes derniers billets traitaient de VnStat (le logiciel pour surveiller les débits de vos interfaces Ethernet) et de Node.js (le framework permettant de créer facilement des applications réseaux coté serveur). C’est donc dans ma logique toute cartésienne, que j’ai développé un javascript permettant de disposer d’une interface Web pour consulter ces statistiques de débits sans avoir à installer un serveur Web et son plugin PHP (comme c’est le cas avec le VnStat PHP frontend).

Ce script, disponible sous licence GPL v3, s’appelle VnStat.js est disponible dans mon GitHub à l’adresse suivante:


https://github.com/nicolargo/vnstat.js

Installation

Pour fonctionner correctement, VnStat.js nécessite:

  • une installation de VnStat fonctionnelle. Je vous conseille la lecture de ce billet pour effectuer une installation « from-scratch » sur une machine tournant sous Debian / Ubuntu.
  • que le framework Node.js soit installé sur cette même machine. Le script a été validé avec la dernière version stable de Node.js (0.4.12).

On commence par récupérer la dernière version de VnStat.js depuis le dépôt Git:

[cce lag= »bash »]

cd ~

git clone git://github.com/nicolargo/vnstat.js.git

cd vnstat.js

[/cce]

Pour les personnes utilisant NPM (le package manager de Node.js), vous pouvez l’utiliser pour installer VnStat.js. Suivre les instructions de cette page.

Lancement de VnStat.js

Pour lancer le noeud VnStat.js, il suffit de saisir les commandes suivantes:

[cce lag= »bash »]

cd ~/vnstat.js

node ./vnstat.js

[/cce]

Le « node » va se mettre en écoute sur le port TCP 1337 de votre serveur (il faut donc ajouter une règle pour autoriser les requêtes entrantes vers ce port si vous avez un firewall).

A l’ouverture de l’URL http://adressedevotremachine:1337/ dans un navigateur compatible HTML5, la page principale suivante va s’afficher:

Elle affiche le résumé des statistiques de VnStat ainsi que le top 10 des journées. Le menu du haut permet de naviguer vers des statistiques plus ciblés.

Par heures (avec à la fois la vue graphique et textuelle):

Et ainsi de suite pour les jours, semaines (à noter qu’il n’y a pas de graphe spécifique par semaine généré par vnstati) et enfin par mois.

Configuration de VnStat.js

Le design de VnStat.js peut bien entendu être adapté à vos besoins en éditant le fichier css/style.css (CSS3). Si vous avez besoin de changer le port TCP d’écoute du node, il y a une variable pour cela dans le fichier lib/server.js.

C’est mon premier développement avec le framework Node.js, il y a sûrement des améliorations à faire mais la structure reste assez didacticiel pour servir de base pour d’autre développement du même type.

Lancement automatique de VnStat.js au démarrage de votre machine

 Comme vous avez pu le remarquer, le node VnStat.js est lancé à la main dans ce billet. Si vous souhaitez mettre en production ce script et le lancer automatiquement au démarrage de votre machine, je vous conseille la lecture du billet de Vincent sur son blog qui regorge d’information sur ce superbe framework qu’est Node.js.