Pourquoi un nouveau thème ?

Tout simplement parce que je commençais à me lasser du précédent. De plus comme Largo v1 était le premier thème WordPress que j’avais développé “from scratch” (merci encore aux tutos de Francis), il était assez difficile à administrer et à faire évoluer.

Une fois la décision de changement de thème prise, j’ai commencé à regarder ce qu’il existait sur le marché, que ce soit au niveau des thèmes gratuits et payants. Je n’ai malheureusement jamais trouvé un thème qui réponde totalement à mes besoins. N’ayant pas les moyens de le faire développer par des professionnels du Webdesign (peut être la prochaine version…), j’ai mis la main dans le clavier et la souris.

Petit tour du propriétaire

Le haut et le base du blog…

On retrouve en haut à gauche une liste de liens vers les pages statiques du blog qui évoluera selon… mes envies. Pour l’instant des liens vers:

• la home page
• la catégorie Open-source (le fond de commerce du blog;))
• la “famous” page Nagios & Co avec tous les billets sur la supervision système et réseau
• la “nouvelle” page GStreamer avec tous les billets sur ce framework multimedia
• la page Publicité pour les annonceurs (coucou)
• la page A propos
• la Contact

En haut à droite, on a la liste des liens pour s’abonner au blog (c’est à dire recevoir les nouveaux billets sans forcement venir tout les jours sur le blog). Plusieurs solutions: par mail, via Facebook, par Twitter et enfin par RSS.

En bas du blog, on a le pas très original footer:

La home page (index)

On retrouve sur la page principale la liste des derniers billets avec quelques informations:

Les billets

C’est le coeur du blog, vu que ces pages représentent 95% des visites… A gauche du billet, j’ai mis en place une sidebar avec quelques informations et liens utiles aux lecteurs pour approfondir le sujet.

Au bas du billet, un menu permet de partager ou lire plus d’articles sur le sujet:

Il suffit de cliquer sur le bandeau vert pour accéder aux différents sous menus…

Enfin les commentaires se trouve après tout celà:

Conclusion

Bien que j’ai testé en interne (et avec l’aide de Nicolas aka Ritchy) le thème, il doit sûrement y avoir quelques coquilles restantes. Je compte sur vous pour me les signaler. De plus si vous avez des questions ou des remarques sur ce nouveau thème je suis également preneur !

Ce blog est fait pour vous !

PS: suite au hack du blog et à mon changement d’hébergeur, il semble que certains utilisateurs du réseau Free utilisent des DNS pointant encore sur mon ancien serveur. J’ai envoyé un mail au support de Free en espérant que le problème soit vite résolu…

En contre partie, je viens de créer une “fan page” pour Le blog de Nicolargo.

Elle va reprendre les articles publiés sur le blog et les news de ma timeline twitter. Pour devenir “fan” du blog, il suffit de cliquer sur le bouton ‘J’aime’…

La page Facebook du Blog de Nicolargo se trouve à l’adresse suivante:

http://www.facebook.com/pages/Le-blog-de-Nicolargo/151534574873311

A bientôt sur Facebook ou ailleurs !

Nous allons donc voir dans ce billet comment installer, sécuriser et optimiser une blog WordPress sur une serveur privé virtuel !

Commencons par le commencement

Il faut d’abord choisir les performances initiales du serveur virtuel. J’ai utilisé le serveur que j’avais créé il y a quelques mois. C’est l’entrée de gamme, c’est à dire 1 part correspondant aux spécifications suivantes:

• 1/64^ème des capacités globales du serveur, soit environ 1 GHz
• 1/64^ème des 16 Go de mémoire du serveur, soit 256 Mo de RAM garantie avec un burst possible à 2 Go (+512 Mo de Swap)
• 1/64^ème des capacités réseau, soit 5 Mbits dédiés
• 1/64^ème du disque réservé au serveur, soit 5 Go de disque data (+3 Go pour le système)

Comme nous allons le voir plus tard cette configuration n’est pas adapté pour un blog avec un trafic relativement important (environ 1 00 000 pages vues par mois) . Je suis donc rapidement passé à la configuration suivante:

Nous disposons donc d’un accès SSH (root) sur le serveur,. Après une mise à jour du système d’ecploitation (Ubuntu Server 9.04) nous pouvons enfin commencer les choses sérieuses…

Installation du serveur Web Apache

On commence par installer le serveur:

sudo aptitude install apache2

Puis on active les modules qui vont nous permettre d’optimiser les performances de WordPress:

sudo a2enmod deflate

sudo a2enmod headers

sudo a2enmod rewrite

sudo a2enmod expires

Il est également possible d’adapter la configuration des processus Apache (nombre de process, nombre maximal de client par process..) en modifiant le fichier /etc/apache2/apache2.conf:

<IfModule mpm_prefork_module>

StartServers 5

MinSpareServers 5

MaxSpareServers 10

MaxClients 40

MaxRequestsPerChild 2000

</IfModule>

StartServers permet de configurer le nombre de processus Apache lancés au démarrage.

MinSpareServers et MaxSpareServers donnent respectivement le nombre minimum et maximum de processus Apache selon les besoins.

MaxClients permet de configurer le nombre de clients (au sens session TCP) pouvant se connecter simultanément à un processus Apache. Pour des sites dynamiques (comme WordPress) il est plutôt conseillé de ne pas avoir une valeur trop élevée afin d’éviter les swap mémoire sur disque.

Une solution proposée sur ce blog pour calculer la valeur MaxClients est la suivantes: Il faut d’abord regarder combien de mémoire prend un processus apache2 (par exemple avec la commande top), puis diviser la mémoire système disponible par cette valeur. Par exemple, pour un serveur disposant de 1 Go de RAM (1000 Mo) et dont chaque processus Apache occupe 25 Mo, on a le calcul suivant:

MaxClients = 1000 / 25 = 40

Enfin MaxRequestsPerChild permet de définir le nombre maximal de requête qu’un processus peut prendre en charge avant d’être tué. Il est conseillé de mettre une valeur différente de 0 (le processus n’est alors jamais tué) pour éviter qu’une processus ne consomme trop de mémoire si un problème arrive.

On passe ensuite aux directives KeepAlive qui permette de configurer finement le temps de vie des sessions TCP. Pour un site dynamique comportant un nombre important d’images et de JS (comme mon blog), les valeurs suivants sont un bon point de départ:

# KeepAlive: Whether or not to allow persistent connections

KeepAlive On

# MaxKeepAliveRequests: The maximum number of requests to allow

MaxKeepAliveRequests 200

# KeepAliveTimeout: Number of seconds to wait for the next request

KeepAliveTimeout 5

# Timeout: The number of seconds before receives and sends time out.

Timeout 50

Enfin on relance le serveur pour que la configuration soit prise en compte:

sudo /etc/init.d/apache2 restart

Installation de MySQL

On commence par installer le serveur MySQL:

sudo aptitude install mysql-server

Puis on créé une base de donnée et un compte utilisateur associé qui va servir pour WordPress:

mysql -u adminusername -p

mysql> CREATE DATABASE databasename;

Query OK, 1 row affected (0.00 sec)

mysql> GRANT ALL PRIVILEGES ON databasename.* TO “wordpressusername”@”hostname”

-> IDENTIFIED BY “password”;

Query OK, 0 rows affected (0.00 sec)

mysql> FLUSH PRIVILEGES;

Query OK, 0 rows affected (0.01 sec)

mysql> EXIT

On peut optimiser la base de donnée en éditant le fichier /etc/mysql/my.cnf:

query_cache_type = 1

query_cache_limit = 2M

query_cache_size = 32M

Ne pas oublier de relancer le serveur MySQL pour prendre en compte les modifications.

Installation de WordPress

Depuis le hack de mon blog, j’ai décidé de travailler directement avec la version SVN de WordPress afin de disposer au plus vite des patchs de sécurité. Une fois de le répertoire racine de votre site Web (/home/nicolargo/web/blog dans mon cas), il faut saisir la commande suivante:

svn co http://core.svn.wordpress.org/trunk/ .

On ajoute ensuite la ligne suivante dans le fichier .htaccess afin de rendre invisible les sous répertoires .svn:

RewriteRule ^(.*/)?\.svn/ – [F,L]

Puis on finalise l’installation en suivant la fameuse installation de WordPress en 5 minutes.

Il est ensuite conseillé de supprimer le fichier wp-admin/install.php (qui ne servira plus une fois l’installation faite):

rm wp-admin/install.php

Sécurisation de WordPress

Cette sécurisation passe par deux étapes. Une première est de protéger le blog à l’aide du fichier .htaccess. La seconde est d’installer des plugins de sécurité qui vont nous permettre de faire régulièrement des audits sur notre serveur.

Pour le fichier .htaccess, j’utilise la base suivante:

# MAIN

RewriteEngine On

ServerSignature Off

Options All -Indexes

Options +FollowSymLinks

# SVN protect

RewriteRule ^(.*/)?\.svn/ – [F,L]

# Secure .htaccess

<Files .htaccess>

Order Allow,Deny

Deny from all

</Files>

# Secure wp-config.php

<Files wp-config.php>

Order Deny,Allow

Deny from all

</Files>

# FILTER REQUEST

<IfModule mod_rewrite.c>

RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /index.php [L]

</IfModule>

# BEGIN Expire Header

<FilesMatch “\.(ico|jpg|jpeg|png|gif|js|css|swf)$”>

ExpiresDefault “access plus 2 hours”

</FilesMatch>

# BLACKLIST CANDIDATES

<Limit GET POST PUT>

Order Allow,Deny

Allow from all

Deny from 75.126.85.215 “# blacklist candidate 2008-01-02 = admin-ajax.php attack “

Deny from 128.111.48.138 “# blacklist candidate 2008-02-10 = cryptic character strings “

Deny from 87.248.163.54 “# blacklist candidate 2008-03-09 = block administrative attacks “

Deny from 84.122.143.99 “# blacklist candidate 2008-04-27 = block clam store loser “

Deny from 210.210.119.145 “# blacklist candidate 2008-05-31 = block _vpi.xml attacks “

Deny from 66.74.199.125 “# blacklist candidate 2008-10-19 = block mindless spider running “

Deny from 203.55.231.100 “# 1048 attacks in 60 minutes”

Deny from 24.19.202.10 “# 1629 attacks in 90 minutes”

</Limit>

# QUERY STRING EXPLOITS

<IfModule mod_rewrite.c>

RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]

RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]

RewriteCond %{QUERY_STRING} tag\= [NC,OR]

RewriteCond %{QUERY_STRING} ftp\: [NC,OR]

RewriteCond %{QUERY_STRING} http\: [NC,OR]

RewriteCond %{QUERY_STRING} https\: [NC,OR]

RewriteCond %{QUERY_STRING} mosConfig [NC,OR]

RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>|’|”|;|\?|\*).* [NC,OR]

RewriteCond %{QUERY_STRING} ^.*(%22|%27|%3C|%3E|%5C|%7B|%7C).* [NC,OR]

RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F|127\.0).* [NC,OR]

RewriteCond %{QUERY_STRING} ^.*(globals|encode|config|localhost|loopback).* [NC,OR]

RewriteCond %{QUERY_STRING} ^.*(request|select|insert|union|declare|drop).* [NC]

RewriteRule ^(.*)$ – [F,L]

</IfModule>

# CHARACTER STRINGS

<IfModule mod_alias.c>

# BASIC CHARACTERS

RedirectMatch 403 \,

RedirectMatch 403 \:

RedirectMatch 403 \;

RedirectMatch 403 \=

RedirectMatch 403 \@

RedirectMatch 403 \[

RedirectMatch 403 \]

RedirectMatch 403 \^

RedirectMatch 403 \`

RedirectMatch 403 \{

RedirectMatch 403 \}

RedirectMatch 403 \~

RedirectMatch 403 \”

RedirectMatch 403 \$

RedirectMatch 403 \<

RedirectMatch 403 \>

RedirectMatch 403 \|

RedirectMatch 403 \.\.

RedirectMatch 403 \/\/

RedirectMatch 403 \%0

RedirectMatch 403 \%A

RedirectMatch 403 \%B

RedirectMatch 403 \%C

RedirectMatch 403 \%D

RedirectMatch 403 \%E

RedirectMatch 403 \%F

RedirectMatch 403 \%22

RedirectMatch 403 \%27

RedirectMatch 403 \%28

RedirectMatch 403 \%29

RedirectMatch 403 \%3C

RedirectMatch 403 \%3E

RedirectMatch 403 \%3F

RedirectMatch 403 \%5B

RedirectMatch 403 \%5C

RedirectMatch 403 \%5D

RedirectMatch 403 \%7B

RedirectMatch 403 \%7C

RedirectMatch 403 \%7D

# COMMON PATTERNS

Redirectmatch 403 \_vpi

RedirectMatch 403 \.inc

Redirectmatch 403 xAou6

Redirectmatch 403 db\_name

Redirectmatch 403 select\(

Redirectmatch 403 convert\(

Redirectmatch 403 \/query\/

RedirectMatch 403 ImpEvData

Redirectmatch 403 \.XMLHTTP

Redirectmatch 403 proxydeny

RedirectMatch 403 function\.

Redirectmatch 403 remoteFile

Redirectmatch 403 servername

Redirectmatch 403 \&rptmode\=

Redirectmatch 403 sys\_cpanel

RedirectMatch 403 db\_connect

RedirectMatch 403 doeditconfig

RedirectMatch 403 check\_proxy

Redirectmatch 403 system\_user

Redirectmatch 403 \/\(null\)\/

Redirectmatch 403 clientrequest

Redirectmatch 403 option\_value

RedirectMatch 403 ref\.outcontrol

# SPECIFIC EXPLOITS

RedirectMatch 403 errors\.

RedirectMatch 403 config\.

RedirectMatch 403 include\.

RedirectMatch 403 display\.

RedirectMatch 403 register\.

Redirectmatch 403 password\.

RedirectMatch 403 maincore\.

RedirectMatch 403 authorize\.

Redirectmatch 403 macromates\.

RedirectMatch 403 head\_auth\.

RedirectMatch 403 submit\_links\.

RedirectMatch 403 change\_action\.

Redirectmatch 403 com\_facileforms\/

RedirectMatch 403 admin\_db\_utilities\.

RedirectMatch 403 admin\.webring\.docs\.

Redirectmatch 403 Table\/Latest\/index\.

</IfModule>

On passe ensuite à l’installation des plugins de sécurité suivants:

• Secure WordPress
• WP Security Scan

Le premier (Secure WordPress) permet d’effectuer simplement et automatiquement une liste d’actions essentielle à la sécurité de votre site:

Le second (WP Security Scan) effectue régulièrement un scan de l’arborescence de votre site et remonte dans l’interface d’administration de WordPress les fichiers modifiés.

Optimisation de WordPress

Pour l’optimisation des performance du blog, je me base sur l’indispensable plugin W3 Total Cache. Bien qu’il ne se limite pas qu’a cela, il permet de mettre facilement en place un système de cache ou les pages sont directement gérées en mémoire RAM plutôt qu’en lecture sur le disque dur. J’ai choisi de coupler W3 Total Cache avec Memcached (un cache mémoire sous licence libre).

L’installation de Memcached est des plus simple:

sudo aptitude install libcache-memcached-perl memcached

Si votre serveur est protégé par un Firewall (ce que je conseille évidemment…), il ne faut pas oublier d’ajouter la règle suivante:

iptables -A OUTPUT -p tcp –destination 127.0.0.1 –dport 11211 -j ACCEPT

La configuration de W3 Total Cache se fait via l’onglet Performance / General settings:

Une dernière optimisation consiste à installer le plugin WP-DBManager et de suivre régulièrement (tout les mois environ) les procédures d’optimisation (onglet Database).

Test et validation

Pour tester les performances de votre serveur, vous pouvez utiliser la commande suivante:

ab -t 30 -c 5 http://votreblog.com/

L’information intéressante se trouve sur la ligne:

Requests per second:    159.46 [#/sec] (mean)

Il est également important de surveiller les paramètres suivant: charge CPU, mémoire RAM disponible, accès disque et réseau. Gandi propose pour cela une interface d’administration Web avec un système de sonde permettant de remonter des alertes par mail ou même d’augmenter dynamiquement le nombre de part lors d’un pic de trafic.

Personnellement, je surveille mon serveur via Nagios mais cela sera le sujet d’un prochain billet…

• Compiler Ntop depuis les sources sous Ubuntu
• Des stickers Ubuntu pour votre PC portable !
• Tunnels TCP à travers proxy HTTP avec Corkscrew et Proxytunnel
• Le site pour trouver des brosses (brush) pour Gimp et Photoshop
• Tutorial d’introduction aux WebSockets
• Simplifiez vos sauvegardes avec Grsync
• Inclure des vidéos YouTube au format HTML5 dans son site/blog
• Un article très intéressant sur comment créer une communauté open-source
• Version 2.53 pour Blender, le 3D Studio libre
• La technologie d’encodage WebM pour “for dummy”
• Offrer votre temps avec un congés solidaire (Planète urgence)
• Ntop 4 est disponible
• Quelques très bonnes pipelines Gstreamer
• Djando, un Framework Python

Enfin de bénéficier d’un scrolling fluide (c’est à la mode avec les smarthphones) sur le navigateur Google Chrome ou Chromium de votre ordinateur personnel, je vous conseille fortement l’installation du plugin SmoothScrool.

Une fois installé, il suffit de se rendre dans les paramètres de configurations du plugins en cliquant sur l’icône Clès > Tools > Extensions.

Personnellement et après quelques tests sur mon portable, j’utilise les paramètres suivants:

Update: si vous trouvez le scroll trop lent, vous pouvez augmenter la valeur de “Stride size per scroll” in pixel à 50 ou plus.

Le plugin fonctionne parfaitement sur mon Chromium sous Ubuntu 10.04…

Encore un plugin indispensable de plus à ajouter à sa liste…

• Synchronisez vos favoris et onglets entre Firefox et iPhone

• Webdesign : 21 livres à télécharger gratuitement

• Formulaire en jQuery et CSS3

• Script création paquets sous Ubuntu

• OuRec une petite application pour enregistrer la sortie de votre carte son

• Beini Linux, une distro orientée sécurité Wifi

• 30 mini code jQuery pour vos sites

• Tuto redimensionnement liquide avec Gimp

Dans quelques jours, le Chrome Web Store va ouvrir ses portes. Ce site va permettre au utilisateur de Google Chrome ou de la version libre Chromium d’installer des applications Web dans leur navigateur. Quelques applications sont déjà disponible (Gmail, Calendar, Google Reader…), elle se présente sous la forme d’une icône en haut à gauche des onglets et permet l’accès direct aux sites. Des fonctions de notifications seront bientôt disponibles (par exemple pour vous avertir lors de l’arrivée d’un nouveau message).

Rien de neuf par rapport aux nombreux plugins (extensions) que l’on peut trouver la toile… oui et non. En effet, comme nous allons le voir dans ce billet il est très facile de créer une application à partir d’un site Web existant. On a ainsi un accès immédiat à ces sites.

Assez de blabla, nous allons voir comment transformer votre site/blog dans une belle application Webs que vous pourrez mettre à disposition de vos lecteurs !

Toutes les manipulations suivantes marchent aussi bien sous Google Chrome ou sur Chromium (la version libre !). Il faut juste avoir la dernière version (voir instruction ici pour Chromium sous GNU/Linux Ubuntu).

Activer la prise en charge des Web Apps

Avant de commencer, il faut activer la prise en charge des Web Apps dans votre navigateur (cette fonction est en développement et n’est donc pas active par défaut). Sous GNU/Linux, le plus simple est de modifier le lanceur Gnome (bouton droit sur l’icône puis Propriétés).

chromium-browser  --enable-apps --enable-extension-timeline-api %U

Il faut ensuite relancer votre navigateur.

Création de votre application

Les Google Chrome Webs Apps sont des fichiers au format (.crx). En fait un bête fichier ZIP contenant un répertoire au format nomapplication_app et les fichiers suivants:

• manifest.json: Le fichier principal d’écrivant votre application
• 128.png: Une icône de 128×128 pixels au format PNG représentant votre application
• 24.png: Une icône de 24×24 pixels au format PNG représentant votre application

On va donc commencer par créer l’arborescence suivante: ~/chromiumapps/nicolargo_app/

On copie ensuite les deux icônes dans le répertoire ~/chromiumapps/nicolargo_app/

Puis on édite le fichier ~/chromiumapps/nicolargo_app/manifest.json (permettant de créer une application à partir de mon blog):

{

"name": "Le blog de Nicolargo",

"version": "1",

"icons": {

"128": "128.png",

"24": "24.png"

},

"permissions": [ "notifications" ],

"app": {

"launch": {

"web_url": "http://blog.nicolargo.com/"

}

}

}

Rien de bien compliqué

Test de votre application

Pour tester l’application, on clique sur le bouton du navigateur puis on va dans le menu Tools > Extensions:

On clique ensuite sur le bouton “+ Developer mode”:

Puis sur “Load unpacked extension…”:

On sélectionne le répertoire ou se trouve l’application: ~/chromiumapps/nicolargo_app/, elle devrait se charger:

Il ne reste plus qu’a faire un CTRL-T (pour ouvrir un nouvel onglet et cliquer sur l’icône de l’application):

Si tout va bien, l’application devrait s’afficher en haut à gauche de votre navigateur !

Création du fichier .CTX

Maintenant que votre application fonctionne, il faut créer un package pour la distribuer à vos utilisateurs. Chromium (ou Google Chrome) permet d’automatiser cette création en cliquant sur le bouton “Pack extension” du menu “Extension > + Developer mode”. Il suffit de sélectionner le répertoire de votre application: ~/chromiumapps/nicolargo_app/. Le navigateur va automatiquement créer le package ~/chromiumapps/nicolargo_app.ctx (ainsi qu’une clé privée ~/chromiumapps/nicolargo_app.pem).

Il ne vous reste plus qu’a distribuer le fichier nicolargo_app.ctx à vos utilisateur. En attendant la disponibilité du Chrome Web Store la procédure à suivre pour installer le fichier .ctx sur votre navigateur est disponible ici.

Pour finir, si vous voulez tester la Web Application du Blog de Nicolargo !

• Support de l’iPhone iOS 4 dans Ubuntu

• Cet été, pour avoir de la lecture sur la plage: Linux Magazine HS special Python

• 5 touches de raccourcies lors du démarrage d’Ubuntu

• Comment construire un package Ubuntu pas à pas

• Une bonne liste de chose à faire après une installation d’Ubuntu (par OMG Ubuntu)

• Utiliser une webcam en ligne de commande sous Linux

• Redo – Le live CD des backups et récupérations de fichiers

• Créer une distribution Linux Debian avec Novo

• Bonita, un BPM (Business Process Management) libre

• Pleins de tutos sur HTML de la part de Google…

• Configurer un Linux Ubuntu avec Squid 3 en mode transparent

• Soundation Studio: un studio audio en ligne

• Liste des choses à prendre en compte pour comparer des codecs vidéos

• VLC 1.1.0 est là

• Introduction aux CDN…

• Optimiser son blog avec un système de cache
• MemCached, le système open-source de cache distribué
• Sauvegarder son Gmail grâce à Linux
• FFmpeg 0.6 HTML 5 Ready
• Plate-forme en ligne de collaboration pour projet open-source
• Un superbe thème pour lancer son projet !