En début de semaine, j’ai été emmenée à donner un cours d’introduction aux technologies de Cloud Computing à l’école supérieure des ingénieurs de Luminy (ESIL à Marseille). Le sujet étant vaste pour les trois petites heures imparties, j’ai préféré axer mon cours sur certains aspects (notamment les architectures IAAS et l’utilisation de technologies ouvertes et libres).
Pour ceux que cela intéresse, voici (sous licence « CC By:« ):
Oui je sais c’est un pompage en règle du billet de Cyrille Borne. Mais bon il faut dire que par les temps qui courent c’est une rudement bonne idée que de disposer de son propre serveur Jabber.
Nous allons donc détailler les étapes d’installation et de configuration d’un serveur Prosody dans sa dernière version (0.7) avec un chiffrement SSL entre les clients et le serveur.
Pourquoi Prosody et pas Jabber ? Tout simplement car il est bien plus simple et léger à installer (un peu trop usine à gaz). Et puis le titre du billet aurait été moins vendeur: « Un serveur Jabber en 3h45 chronos… ».
Installation de Prosody
L’installation de Prosody se fait en utilisant les commandes suivantes:
echo « deb http://packages.prosody.im/debian stable main » | sudo tee -a /etc/apt/sources.list
PS: la librairie LibLua est utilisé pour le chiffrement SSL. Le fichier liblua5.1-sec0_0.3.2-2prosody1_amd64.deb doit être utilisé pour les machines sous AMD 64 bits.
On relance Prosody pour prendre en compte la configuration:
sudo /etc/init.d/prosody restart
Si vous avez un Firewall sur votre serveur (ce qui est une bonne idée), il faut penser à ouvrir les ports TCP de Jabber en ajoutant les lignes suivantes dans votre script de configuration iptable (/etc/init.d/iptables.sh dans mon cas):
Il n’y a pas si longtemps le dock était le parent pauvre des distributions GNU/Linux. Avec l’apparition de projets comme Docky, Cairo ou AWN, cette tendance s’inverse à vitesse grand V ! Partisant de Docky depuis quelques mois, je vais donner une nouvelle chance à AWN qui, dans ses dernières versions, apportent des fonctionnalités intéressantes.
PS: Si vous avez un autre dock (par exemple Docky), il faudra le désinstaller histoire de ne pas se retrouver avec deux docks (mais il est possible de concerver les deux en // durant la phase de test).
sudo aptitude remove docky
Lancement de AWN
A partir du menu Applications > Accessoires > Avant Window Navigator
Configuration de AWN
Voilà ce que donne mon dock (après la configuration à faire ci-dessous):
Pour accèder au menu de configuration, il faut cliquer sur le bouton de gauche du dock puis sur le bouton configuration.
Vous pouvez directement importer une configuration existante (par exemple si vous avez plusieurs PC) en allant dans le menu Thème puis en cliquant sur le bouton Importer. Vous pouvez télécharger mon thème en cliquant ici ou bien suivre pas à pas les étapes suivantes:
—
—
—
—
Sauvegarder votre configuration AWN
Pour éviter d’avoir à refaire la configuration à chaque installation (ou re-installation de machine), il est possible d’archiver la configuration d’AWN dans un fichier .tgz. Pour cela, il faut se rendre dans le menu Thèmes > Personnaliser puis cliquer sur le bouton exporter le thème.
Je n’avais pas testé AWN depuis un bon moment, j’utilisais Docky comme gestionnaire de dock. Je dois dire que de nombreux progrès ont été fait. La configuration est vraiment simple, intuitive et l’utilisation agréable. Je n’ai eu aucun plantage même avec l’utilisation de la version de développement.
C’est donc décidé pour ma part, je migre vers AWN 🙂
NGinx est une des alternative au serveur Web Apache (il est actuellement utilisé par plus de 6% des serveurs Web). Il se targue d’être plus rapide, plus léger et facile à configurer.
Nous allons vérifier tout cela dans ce billet en détaillant une installation de NGinx 0.8.54 (Stable) sur une machine GNU/Linux (Ubuntu Desktop 10.10) avec en bonus le support FastCGI de PHP et de Perl !
Installation de NGinx
On commence par ajouter le dépôt officiel pour la version stable:
sudo add-apt-repository ppa:nginx/stable
sudo aptitude update
Puis on installe la bête (facile non ?):
sudo aptitude install nginx
Remarque: si un serveur Web (Apache ou autre) tourne déjà sur votre machine, l’installation de NGinx se passera normalement, par contre il n’arrivera pas à se lancer car le port HTTP par défaut (TCP/80) sera déjà occupé. La solution la plus propre est de configurer NGinx pour qu’il écoute sur un autre port (TCP/81 par exemple) puis faire vos tests en forcant l’utilisation de ce port dans votre navigateur Internet (en ajoutant :81 aux URL). Une fois Nginx validé, il suffira de supprimer l’autre serveur Web de votre machine, puis de reconfigurer Nginx sur le port par défaut (TCP/80).
Premier contact avec NGinx
Un script de démarrage nommé nginx a été installé dans le répertoire /etc/init.d. On peut voir la liste des commandes accepté par ce script en saisissant la ligne de commande suivante:
On ouvre un navigateur sur la même machine puis on entre l’UTL suivante: http://localhost/
La page suivante devrait s’afficher:
On peut ensuite arrêter le serveur:
sudo service nginx stop
Stopping nginx: nginx.
Puis passer à l’étape suivante…
Configuration du serveur NGinx
Les fichiers de configuration se trouvent dans le répertoire /etc/nginx. Les habitués d’Apache ne seront pas trop perturbés par la structure de l’arborescence de ce répertoire:
conf.d/: un répertoire contenant des fichiers de configuration additionnels
sites-available/: répertoire contenant la liste des fichier de configuration des sites disponibles
sites-enabled/: répertoire contenant la liste des fichiers de configuration des sites actifs (liens symboliques vers le répertoire site-availables)
On commence par jeter un coups d’oeil au fichier nginx.conf…. Quel bonheur par rapport à celui d’Apache :).
On passe ensuite au fichier du site par défaut /etc/nginx/sites-available/default (que l’on a activé tout à l’heure par la commande ‘sudo service nginx configtest’):
server {
listen 80
root /usr/share/nginx/www;
index index.html index.htm;
server_name localhost;
location / {
try_files $uri $uri/ /index.html;
}
location /doc {
root /usr/share;
autoindex on;
allow 127.0.0.1;
deny all;
}
location /images {
root /usr/share;
autoindex off;
}
}
On peut donc voir que l’on a un site qui écoute sur le port TCP/80 (listen 80) et sert les pages se trouvant dans le répertoire /usr/share/nginx/www (root /usr/share/nginx/www) à partir de l’URL http://localhost/ (server_name localhost).
Nous allons nous baser sur cet exemple pour construire un nouveau fichier de configuration propre à nos besoins.
On commence par créer l’arborescence qui va héberger nos pages (par exemple /home/labo/www). Si le répertoire n’existe pas il faut le créer et lui donner les bons droits:
mkdir /home/labo/www
Enfin on édite une page de test:
# vi /home/labo/www/index.html
<html><body>Ma page</body></html>
Ensuite on passe à la création du fichier de configuration du site.
sudo vi /etc/nginx/sites-available/monsite
Avec le contenu suivant (à adapter à votre configuration):
# Mon site a moi
server {
listen 80;
root /home/labo/www;
index index.html index.htm;
server_name localhost;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to index.html
try_files $uri $uri/ /index.html;
}
}
On supprime le site par defaut et on active le notre:
cd /etc/nginx/sites-enabled
sudo rm default
sudo ln -s ../sites-available/monsite
On redémarre le serveur Nginx:
sudo service nginx restart
Restarting nginx: nginx.
Puis on teste la page: http://localhost/
Pour rendre le site « visible depuis l’extérieur », il faut changer la ligne:
server_name localhost;
Puis la remplacer par:
server_name www.mondomaine.com;
Il faut bien sur que le nom www.mondomaine.com pointe sur l’adresse IP de votre serveur Nginx…
Test des performances
Pour voir ce qu’il a dans le ventre, j’ai installé en Nginx et Apache sur ma machine. Nginx écoutant sur le port TCP/81 et Apache sur le port TCP/80.
J’ai ensuite utilisé le logiciel httperf (disponible dans les dépôts Ubuntu) pour simuler des requêtes sur le serveur.
On a donc un gain d’environ 30% en terme de requêtes supportées par le serveur.
Request rate / Request number
Support du PHP
De nos jours, un serveur Web sans support PHP c’est un peu comme un Ferrari avec des roues de 13 pouces. Dans l’optique d’avoir un serveur performant nous allons donc utiliser le module externe PHP FPM (PHP FastCGI) qui s’occupera de l’exécution des scripts PHP dans un processus indépendant de NGinx (merci à cet article qui m’a bien aidé).
Par défaut, le processus PHP-FPM va se mettre en écoute sur le port TCP/9000 et écouté les requêtes venant seulement de la machine locale (localhost).
Il ne reste plus qu’à modifier le fichier de configuration de votre site pour prendre en compte le langage PHP (fichier /etc/nginx/sites-available/monsite):
# Mon site a moi
server {
listen 80;
server_name localhost;
root /home/labo/www;
location / {
index index.php index.html;
}
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
include /etc/nginx/fastcgi_params;
fastcgi_index index.php;
}
}
Attention de bien avoir configurer la variable root (« root /home/labo/www » dans mon exemple), sinon vous risquez de tomber sur une erreur 404 lors du passage du script PHP vers le process PHP-FPM.
On relance ensuite Nginx:
sudo service nginx restart
Restarting nginx: nginx.
Pour tester que le PHP fonctionne bien, le plus simple est de créer un fichier info.php (à mettre à la racine du site /home/labo/www/) contenant:
<?php
phpinfo();
?>
Puis de pointer votre navigateur Web vers l’URL: http://localhost/info.php
La page suivante devrait s’afficher:
Support de Perl
Tout comme PHP, nous allons utiliser FastCGI pour exécuter les scripts Perl depuis notre serveur NGinx. Le principe est le même. Un processus (fastcgi-wrapper.pl) va se mettre en écoute sur le port TCP/8999 puis attendre les demandes d’exécution envoyées par NGinx.
Contrairement à PHP, il n’existe pas (encore) de package Ubuntu permettant d’automatiser l’installation de ce processus. Il faut donc mettre un peu les mains dans le cambouis (merci à ce blog) !
On commence par installer le module Perl FCGI sur lequel le processus fastcgi-wrapper.pl va se baser:
sudo perl -MCPAN -e ‘install FCGI’
On installe le processus fastcgi-wrapper.pl qui va s’occuper de l’exécution des scripts Perl:
La plupart des tutos que j’ai trouvé sur le Net utilise ensuite un script init.d pas très beau à voir (http://lindev.fr/public/nginx/perl-fastcgi). En effet, pour arrêter le processus on a droit à un beau killall -9 perl ! Autant dire que si vous avez d’autres processus Perl en tache de fond de votre serveur cela risque de poser quelques problèmes :). J’ai donc écrit un nouveau script basée sur celui du wrapper PHP.
On automatise le lancement de ce script au démarrage du serveur:
C’est le début de l’année et le moment des bilans concernant les statistiques de votre blog. Voici donc un petit billet sur quelques hacks MySQL permettant d’obtenir des statistiques à diffuser vers vos lecteurs ou à garder au chaud !
Avant tout il faut disposer d’un accès à votre base de donnée MySQL (soit via une interface de type phpMySQL, soit directement via une ligne de commande mysql). Pour avoir vos paramètres de connexion à votre BD WordPress il suffit de regarder le fichier wp-config.php à la racine de votre répertoire Web.
Voici l’architecture des tables de votre BD WordPress. Je ne suis plus trop un expert en requêtes MySQL (les cours datent de plus de 10 ans maintenant ;)) alors si vous voyez des améliorations dans les requêtes ci-dessous je suis preneur de commentaires.
Nombre de billets publiés en 2010
Cette première requête donne le nombre de billets publiés (status= »publish ») sur l’année 2010 (c’est à dire entre le 1er janvier et le 31 décembre 2010).
mysql> SELECT COUNT(*) FROM wp_posts WHERE post_status= »publish » AND post_date BETWEEN ‘2010-01-01’ AND ‘2010-12-31’;
+———-+
| COUNT(*) |
+———-+
| 161 |
+———-+
1 row in set (0.00 sec)
Nombre de commentaires pour les billets publiés en 2010
Une requête un peu plus complexe qui somme (SUM) le nombre de commentaires pour les billets 2010.
mysql> SELECT SUM(comment_count) FROM wp_posts WHERE post_status= »publish » AND post_date BETWEEN ‘2010-01-01’ AND ‘2010-12-31’ GROUP BY post_status;
+——————–+
| SUM(comment_count) |
+——————–+
| 1314 |
+——————–+
1 row in set (0.01 sec)
Liste des 10 billets les plus commentés publiés en 2010
On continu pas le classement (TOP 10) des nouveaux billets les plus commentés.
mysql> SELECT post_title,comment_count FROM wp_posts WHERE post_status= »publish » AND post_date BETWEEN ‘2010-01-01’ AND ‘2010-12-31’ ORDER BY comment_count DESC LIMIT 0,10;
+——————————————————————-+—————+
| post_title | comment_count |
+——————————————————————-+—————+
| Configurer VPNTunnel sous Ubuntu | 58 |
| Installation et test de Flumotion 0.8 | 46 |
| Script d’installation automatique de Nagios | 42 |
| Spideroak, un sérieux concurrent à Dropbox | 40 |
| Utiliser Nmap pour générer vos fichiers de configuration Nagios | 38 |
| Installation d’un serveur OpenVPN sous Debian/Ubuntu | 36 |
| 12 étapes pour optimiser les performances de son blog WordPress | 35 |
| Le blog de Nicolargo a son application IOS | 35 |
| Tu fais quoi après l’installation de Firefox ? | 26 |
| MyScreenCast, comment faire du screencast avec GStreamer | 26 |
+——————————————————————-+—————+
10 rows in set (0.01 sec)
Top 10 des lecteurs ayant le plus posté de commentaires sur le blog en 2010
Enfin une requête un peu plus complexe qui donne le classement des plus gros « commentateurs » sur le blog.
mysql> SELECT comment_author,COUNT(comment_count) AS F01 FROM wp_comments,wp_posts WHERE comment_approved=1 AND comment_post_ID=ID AND comment_date BETWEEN ‘2010-01-01’ AND ‘2010-12-31’ GROUP BY comment_author ORDER BY F01 DESC LIMIT 0,10;+—————-+—–+
| comment_author | F01 |
+—————-+—–+
| NicoLargo | 315 |
| Albert | 22 |
| Pierre-Yves | 18 |
| ninja21a | 18 |
| Mr Xhark | 15 |
| Sylvain | 14 |
| Christophe | 12 |
| floppy84 | 12 |
| Nico | 11 |
| Guillaume | 10 |
+—————-+—–+
10 rows in set (0.07 sec)
Si vous avez d’autres requêtes MySQL dans votre besace et bien faites tourner !
Dans ce deuxième billet, nous allons aborder la pierre angulaire de la sécurisation de votre site/blog: la sécurisation du couple infernal Apache/PHP.
Bien qu’il existe d’autres serveurs Web (par exemple le très rapide NGinx ou le très simple Cherokee), Apache reste, à ce jour, le plus répandu. Un des reproche que l’on peut lui faire est sa lourdeur de configuration. Cette lourdeur et l’utilisation de fonctions pas forcement utiles à votre site peut rapidement entraîner des failles de sécurité. Nous allons donc détailler la sécurisation du serveur Web ainsi que celle du moteur de langage PHP qui est utilisé par WordPress.
Je vous rappelle que cet article est découpé en plusieurs billets (vous êtes en train de lire le #2):
Cette série de billets a été co-écrite avec Jérémie Marguerie étudiant à EPITA (merci à lui !).
Serveur Web Apache
Sécuriser l’installation par défaut d’Apache2
Apache est développé en tenant compte de la sécurité mais dévoile, dans le header HTTP, son identité (son nom et son numéro de version) à chaque client qui se connecte. Ne pas divulguer ces informations permet d’éviter aux scripts kiddies de connaitre directement les failles connues pour la version d’Apache utilisée et peut compliquer le travail des crackers.
Pour cacher ces informations aux clients HTTP, il suffit d’éditer le fichier /etc/apache2/conf.d/security et d’y ajouter/modifier les variables suivantes:
ServerTokens Prod
ServerSignature Off
TraceEnable On
Module de securité IDS pour Apache
Il existe dans Apache un module optionnel nommé ModSecurity2 qui permet de détecter et de protéger son serveur contre des attaques touchant vos applications Web (notamment les « SQL injections », « cross-site scripting », « path traversal attacks »…).
On commence par l’installation de mod-secure:
sudo aptitude install libapache2-mod-security2
Par défaut, aucune règle n’est appliquée. Il faut donc partir du fichier de configuration qui est donné en exemple:
# Serial audit log
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus ^5
SecAuditLogParts ABIFHZ
SecAuditLogType Serial
SecAuditLog /var/log/apache2/modsec_audit.log
# Maximum request body size we will
# accept for buffering
#SecRequestBodyLimit 131072
SecRequestBodyLimit 8192000
# Store up to 128 KB in memory
SecRequestBodyInMemoryLimit 131072
# Buffer response bodies of up to
# 512 KB in length
SecResponseBodyLimit 524288
# Verify that we’ve correctly processed the request body.
# As a rule of thumb, when failing to process a request body
# you should reject the request (when deployed in blocking mode)
# or log a high-severity alert (when deployed in detection-only mode).
SecRule REQBODY_PROCESSOR_ERROR « !@eq 0 » \
« phase:2,t:none,log,deny,msg:’Failed to parse request body.’,severity:2 »
# By default be strict with what we accept in the multipart/form-data
# request body. If the rule below proves to be too strict for your
# environment consider changing it to detection-only. You are encouraged
# _not_ to remove it altogether.
SecRule MULTIPART_STRICT_ERROR « !@eq 0 » \
« phase:2,t:none,log,deny,msg:’Multipart request body \
failed strict validation: \
PE %{REQBODY_PROCESSOR_ERROR}, \
BQ %{MULTIPART_BOUNDARY_QUOTED}, \
BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
DB %{MULTIPART_DATA_BEFORE}, \
DA %{MULTIPART_DATA_AFTER}, \
HF %{MULTIPART_HEADER_FOLDING}, \
LF %{MULTIPART_LF_LINE}, \
SM %{MULTIPART_SEMICOLON_MISSING}, \
IQ %{MULTIPART_INVALID_QUOTING}' »
# Did we see anything that might be a boundary?
SecRule MULTIPART_UNMATCHED_BOUNDARY « !@eq 0 » \
« phase:2,t:none,log,deny,msg:’Multipart parser detected a possible unmatched boundary.' »
On relance ensuite Apache pour prendre en compte le plugin:
sudo /etc/init.d/apache2 restart
Ce module contient un ensemble d’expressions rationnelles dont l’objectif est de bloquer les requêtes jugées dangereuses. Il bloquera une partie des tentatives de piratage. C’est tout de même une barrière de protection faillible mais qui peut empêcher l’exploitation de certaines failles. Dans tout les cas, cela n’empêche pas le développeur de coder correctement, en prenant en compte la sécurité au moment du développement des sites.
Module anti DOS
Nous allons installer le module Apache mod_evasive qui permet d’atténuer les attaques DOS faite en utilisant le protocole HTTP en bloquant les adresses IP des clients trop gourmand, c’est à dire ceux qui demandent trop rapidement des pages webs.
Contrairement à ce que l’on peut lire sur certains sites, ce module ne protège pas des DDOS, seulement des DOS (lire ici une explication des attaques DOS et DDOS). Autrement dit, il bloque les reqêtes venant d’une adresse IP (DOS).
Si un très grand nombre d’IPs font une seule requête : votre serveur sera saturé et le mod_evasive n’aura pas servi (DDOS). Bloquer les DDOS est très difficile car les requêtes sont difficilement reconnaissables des requêtes autorisées.
On commence par installer le module:
sudo aptitude install libapache2-mod-evasive
On édite le fichier /etc/apache2/conf.d/mod-evasive:
C’est la configuration par défaut qui va bloquer pendant 10 secondes (DOSBlockingPeriod) les requêtes HTTP venant de l’adresse IP source si une des assertions suivantes est vérifiée:
il y a plus de 2 requêtes (DOSPageCount) sur la même page dans un intervalle de 1 seconde (DOSPageInterval)
il y a plus de 50 requêtes (DOSSiteCount) sur l’ensemble du site dans un intervalle de 1 seconde (DOSSiteInterval)
On relance ensuite Apache pour prendre en compte le plugin:
sudo /etc/init.d/apache2 restart
Sécurisation du moteur PHP
PHP est un langage interprété, largement utilisé pour générer dynamiquement des pages HTML. C’est le langage utilisé par le moteur de CMS WordPress. La génération des pages de votre blog se faisant directement sur votre serveur, il est important de protéger l’environnement d’exécution des scripts PHP.
Il est donc conseillé d’utiliser suphp. Il est relativement facile à installer et permet d’exécuter vos scripts PHP sous un utilisateur autre que www-data et donc protéger votre système.
Cela permet aussi de servir plusieurs sites internet sur un même serveur. Si un pirate atteint un site, il ne pourra pas toucher aux autres.
Ce module fournit aussi la possibilité de disposer d’un fichier PHP.ini par site web, et offre donc plus de flexibilité que l’installation standard de PHP.
La sécurité a néanmoins un coup: la performance. Attendez vous à des pertes de performances sur vos applications. Dans le cas d’une application codée correctement et d’un serveur non surchargé, cette perte devrait cependant être minime.
Il est également possible de désactiver certaines fonctions sensible de PHP (system, exec…) en éditant le fichier php.ini (voir exemple dans l’étape n°3 de ce billet).
Pour installer suPhp sur votre serveur je vous conseille la lecture de cet article. (si vous voulez/devez faire cohabiter deux versions de PHP, par exemple la 4 et la 5, vous pouvez également consulter ce billet).
Conclusion (temporaire)
On dispose donc maintenant d’un système et d’un serveur Web sécurisé. Il ne reste plus qu’à attendre la suite de cette série de billets pour s’attaquer à la sécurisation du moteur de blogging WordPress.
Installer de la combo magique (Equinox + Faenza + Nautilus Elementary)
Je n’ai pas trouvé mieux à mon goût pour le moment. Equinox est clair, les icônes Faenza sont lisibles et facile à reconnaître et Elementary apporte une certaine légèreté à Nautilus.:
Pour coller un peu plus avec le fond d’écran, j’ai choisi le thème Glass d’Equinox en allant dans le menu “Système > Préférences > Apparences > Thème > Equinox Glass“.
Installation de Docky
Ce dock « à la MacOS X » est disponible dans les dépôt standard, pour l’installer en ligne de commande:
sudo aptitude install docky
Pour le paramétrage, j’utilise:
Voilà ce que j’ai dedant au moment de l’écriture de ce billet:
Paramétrage de mon tableau de bord
J’utilise l’application NetSpeed pour voir en temps réel les débits sur mon interface réseau. Il faut l’installer avec la ligne de commande suivante:
sudo aptitude install netspeed
Ensuite je configure de la manière suivante:
Et vous cela donne quoi vos desktops en ce moment, à vos screenshots !
Pour moi, la vraie révolution Internet de ces dernières années est l’apparition de blogs ayant petit à petit pris le relais des sites institutionnels pour diffuser de l’information. Souvent tenu à bout de bras par des particuliers, ils ne disposent pas d’une infrastructure informatique professionnelle.
Ainsi en cas de problème technique, l’administrateur est souvent prévenu par ses lecteurs…
Nous allons donc voir dans ce billet comment utiliser le logiciel libre de supervision Nagios pour surveiller automatiquement son blog.
Voilà ce que donnera le résultat dans l’interface Web de Nagios:
Contexte
Afin d’illustrer ce billet, nous allons partir sur l’hypothèse ou vous disposer d’un blog hébergé sur un serveur dédié ou virtuel sous Ubuntu Server 10.04 avec un accès SSH et un compte utilisateur avec les droits d’administration (sudo>r00t).
Aller on se connecte en SSH sur son serveur et on suit le guide.
Installation de Nagios
Nous allons utiliser le script d’installation automatique de Nagios (développé par votre serviteur).
On commence par le télécharger le script nagiosautoinstall-ubuntu.sh:
Ce billet a été rédigé par Jonathan Gaulupeau et à pour double objectif de mettre en avant Web4all, un hébergeur alternatif à but non lucratif et de montrer comment des outils open-source sont utilisés pour assurer une supervision professionnelle de ce type de réseau.
Web4All, qui sommes-nous ?
Web4All est une association à but non lucratif qui a pour but de fournir un hébergement mutualisé de qualité professionnelle au plus grand nombre. Nos offres, plus orientées vers l’utile que vers le tape-à-l’œil, sont parmi les moins chères du marché.
Notre gestion est totalement désintéressée. Tous les acteurs de Web4All sont des bénévoles animés par l’envie de rendre un service de qualité à plus de 2000 clients.
Nous sommes constamment à la recherche du meilleur rapport qualité / prix. Nous étudions pour cela aussi bien des solutions libres que propriétaires. Dans les faits, la quasi-totalité de nous outils est issue de la communauté open-source. Cependant, nos besoins étant parfois très spécifiques, nous développons également nos propres outils.
Pourquoi la supervision ?
Toute entité possédant un ou plusieurs serveurs (quels que soient les systèmes d’exploitation utilisés) se doit de contrôler en permanence leur état. D’autant plus lorsqu’il s’agit, comme nous, de serveurs dont dépend le maintien en conditions opérationnelles des services que nous proposons.
En réalité, ce n’est pas tout à fait le cas, notre infrastructure étant redondée afin de fournir des services à haut taux de disponibilité.
La supervision sous quelle forme, quels outils ?
Je n’ai parlé, jusqu’à présent, que de la supervision en temps réel. Celle qui nous remonte une alarme si un service ne respecte pas des paramètres que nous avons définis. Un technicien peut alors prendre en compte l’alarme, en chercher la cause et, de préférence, la régler. Si, malgré nos précautions, un service est impacté, le technicien en informe les clients par une interface dédiée.
Chez nous, cette supervision est assurée par Nagios.
Quelques services surveillés par Nagios sur un frontal Apache
Toutefois, un autre aspect est important dans la supervision : suivre l’évolution de divers indicateurs sur une période plus ou moins longue. En clair, nous avons besoin, par exemple, pour anticiper l’évolution de nos besoins en terme de stockage, de regarder l’évolution sur l’espace disque que nous avons eu par le passé. Ces indicateurs peuvent nous fournir des informations remontant à des mois, voire des années. Ils nous permettent également de prévoir les pics de charge que subira notre infrastructure. Très pratique pour savoir quand ne pas programmer des tâches d’archivage par exemple. Enfin, cela peut s’avérer très utile lorsqu’il s’agit de réaliser un état de santé général. Nous savons à quoi doivent ressembler nos graphiques, nous pouvons donc voir d’un coup d’œil si tout semble correct.
Cette partie est réalisée par un autre outil : Cacti.
Graphique de trafic réseau réalisé par Cacti
Tous ces indicateurs combinés nous permettent d’évaluer notre qualité, point très important pour la personne chargée de la QoS (Quality of Service). Ils nous permettent également de prévoir nos futurs achats et évolutions de l’infrastructure. Nous pouvons ainsi réaliser tous les tests nécessaires aux évolutions dans un environnement de pré-production, sans travailler dans l’urgence et la panique que pourrait constituer une dégradation de la qualité des services rendus aux clients.
Enfin, nous avons également une carte d’état en temps réel du réseau client de Web4All qui est accessible à tous les clients.
Cette carte se base sur les informations récupérées par Cacti.
Carte d’état en temps réel du réseau client de Web4All
Ce que nous supervisons
Tous ces tests sont réalisés dans Nagios ainsi que dans Cacti.
Les basiques
Les incontournables de la supervision que sont :
Le ping -> Un ping est réalisé sur le serveur, nous indiquant s’il est joignable ou non sur le réseau. C’est l’information la plus élémentaire dont nous avons besoin.
Le load average -> Le load est récupéré par SNMP. Il nous indique la charge système. Des seuils de criticité sont définis en fonction des habitudes de chaque serveur.
La mémoire -> Le taux de mémoire utilisée est récupéré par SNMP. Il nous permet de savoir si une application souffre d’une fuite mémoire par exemple.
L’espace disque -> Le taux d’espace libre sur les partitions des serveurs est récupéré par SNMP. Il nous permet d’être alertés avant qu’une partition ne soit pleine.
Le réseau
C’est le cœur de notre activité. Il fait donc l’objet de toutes les attentions.
Nous surveillons le taux de transfert de toutes les interfaces des serveurs. Nous pouvons alors être alertés en cas de pic anormal ainsi qu’étudier l’évolution de la charge réseau afin d’anticiper les besoins en terme de bande passante.
Les services
Chaque service est testé par Nagios grâce à des plug-ins.
Ces plugins sont soit récupérés sur la plateforme d’échange Nagios Exchange soit écrits spécifiquement pour Web4All.
Voici quelques exemples :
Serveur DNS -> Test de résolution de nom
Serveur Mail -> Test des protocoles POP, IMAP, SMTP, état de la queue des mails, etc.
Frontaux Apache -> Test des Apache Server Status
Load Balancers -> Vérification du nombre de serveurs dans le pool
Serveurs SQL -> Test de connexion à une base de données
Les aide-mémoires
Certains tests n’ont pour but que de nous rappeler de réaliser une action bien précise.
Par exemple, tous nos certificats SSL sont testés afin de nous remonter une alerte plusieurs semaines avant leur date d’expiration.
Conclusion
La supervision est un point essentiel chez Web4All. Elle nous permet d’avoir une meilleure réactivité grâce aux alertes remontées par Nagios, mais elle nous permet également de mieux préparer l’avenir grâce aux graphiques réalisés par Cacti.
Enfin, grâce à la supervision, nous pouvons également fournir à nos clients le taux de disponibilité réel de nos services.
A propos de l’auteur: Jonathan est expert sur le logiciel de conception mécanique CATIA V5, la « crise » du secteur automobile l’a poussé à s’orienter vers l’administration des systèmes Unix. Il est aujourd’hui Ingénieur Systèmes & Réseaux. Depuis 2009 il s’est engagé dans l’association Web4All ou il fait partie du Conseil d’Administration et ou il s’occupe de l’administration des serveurs ainsi que de leur supervision.
A propos de Web4All: Web4all est un hébergeur associatif qui propose des hébergements de site web à faible coût ainsi que la vente de nom de domaine et un service emails.
J’espère que comme moi cet article vous a intéressé. N’hésitez pas à poser des questions à Jonathan dans les commentaires de ce billet, je suis sur qu’il se fera un plaisir de vous répondre.
Dropbox vient de mettre à jour son client vers la version 1.0. Malheureusement, la procédure d’installation qui est donnée sur le site ne marchait pas pour moi (j’ai fait le test sous Ubuntu 10.10 et Fedora 14).
Voici donc un petit hack pour mettre à jour le client depuis une version 0.7.110 vers la 1.0.10:
1) Arrêter votre client Dropbox
2) Lancer les commandes suivantes dans un terminal: