Le principe de ce site est le suivant. Les utilisateurs proposes des news dans le domaine des logiciels libres. Les news sont validés par une équipe avant publication assurant ainsi une sélection aux petits oignons…
Même si Philippe est plus connu pour ces billets fleuves et philosophique sur le monde des logiciels libres, il est en plus une très bonne source d’informations pour la combo « Cloud + Open-source ». Un must have dans votre agrégateur RSS.
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.
coté Web 2.0, un compte Twitter (@nicolargo) avec 780 abonnés et une page Facebook (on peut remarquer un report des abonnements RSS vers Twitter)
Pour revenir sur le hack du site qui est arrivé en pleine vacance d’août, il a causé une interruption de service de plus de 2 semaines. L’impact en terme de référencement du site dans Google et donc de trafic n’est pas négligeable…
Le point positif est que cette claque m’a permis de repartir sur une base saine (nouveau serveur, nouvelle procédure d’installation, backup…) et donc d’une nouvelle section du l’hébergement sur le site 🙂
Cette année 2011 risque d’être un peu moins active sur ce blog de part mes activités professionnelles. Mais j’ai quelques petits billets dans la tête (suite des billets sur la sécurisation des blogs WordPress, découverte de Shinken, article sur la virtualisation des serveurs…).
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 !
Le 24 décembre n’a jamais été une journée particulièrement productive. Alors au lieu de faire semblant de faire des choses vachement importante, pourquoi ne pas vous occuper un peu de l’objet que vous regardez plus que votre femme (ou que votre homme): je parle bien sûr de votre écran !
Voici donc une sélection de site proposant des fonds d’écran qui changeront un peu votre quotidien.
Une fois par an, Dektopography propose une sélection d’image mélange de nature et de numérique. La version 2010 vient de sortir. En un mot: Superbe ! Si vous découvrez ce site, je vous conseille de regarder les sélections des autres années.
Qui ne connait pas ce site ou les artistes numériques exposent leurs oeuvres ? Personnes depuis que le site c’est fait hacker la liste de ses comptes utilisateurs 🙂
Un concept assez sympa qui propose de mettre en avant un wallpaper. On peut ensuite parcourir la base de donnée de manière plus ou moins ciblé. Des images de qualitées.
Mon chouchou. Un moteur de recherche au top. Une sélection d’images de qualités. Des filtres permettant de trouver rapidement ce que l’on cherche (même un section NSFW :)).
Et voilà de quoi faire une petite sélection pour 2011.
Vous avez deux liaisons Internet (par exemple chez deux FAI), un routeur basée sur BSD (c’est une bonne idée), alors ce billet va vous permettre de faire du partage de charge entre ces deux liaisons.