Pour cette édition 2010, il y a 2 thématiques transversales : le développement durable et l’accessibilité.

Les thèmes des RMLL

Les logiciels libres sont un vaste domaine, couvrant de multiples aspects de notre vie ordinaire … et de l’informatique. C’est pourquoi ce cycle est composé de thèmes, regroupés sur 2 jours chacun :

• Technique
• Loisirs, Culture, Arts, libre diffusion
• Économie sociale et solidaire – Développement durable
• Accessibilité et handicap
• Sciences, Éducation, Éducation populaire
• Entreprises et Logiciel Libre
• Collectivités, administrations, politiques publiques

Chacune de ces thématiques comporte ensuite des sessions. Ces sessions agissent comme des sous-thèmes, afin d’affiner et guider le visiteur au sein de la centaine de conférences réparties sur 5 jours.

La session Internet

Nicolas et moi-même nous occupons de la session Internet, sous-thème de « Technique ». Le programme 2009 est à disposition si cela peut vous donner des idées.
Allez, quelques pistes :

• Firefox
• WordPress
• eZ Publish
• Drupal
• Apache, Nginx, Lighttpd & cie
• Zend Framework, Symfony, CodeIgniter
• Jabber/XMPP/PubSubHubbub
• OpenStreetMap
• Licences − CreativeCommons etc.

Soyez créatifs, proposez des sujets

Internet != Web

À titre de précision : si le Web fait partie de l’Internet ; l’Internet est bien plus que le Web. Cela concerne aussi bien IRC, le transport de mails, les protocoles de transport que l’infrastructure permettant à ce nuage d’exister.

Donc n’hésitez pas à avoir une vision large et de ne pas vous restreindre qu’au Web − aussi bien soit-il.

Pour en savoir plus

Le site Web de l’édition 2010 des RMLL est en ligne à l’adresse permanente http://2010.rmll.info. On y trouve, entre autre, d’autres informations sur l’appel à  conférences.
Vous avez jusqu’au début du mois de mars pour y songer.

Si vous avez « juste » peur d’être timide, établissez au moins le contact pour obtenir des informations.
Nous sommes également passés par là donc on pourra vraisemblablement vous assister.

Un email vers internet@listes2010.rmll.info fera l’affaire. On vous guidera le reste du processus.

J’ai déjà expliqué comment modifier l’emplacement des données d’un serveur MySQL mais cette fois-ci on va aller encore plus loin :

• on ne va pas toucher aux fichiers de configuration par défaut
• on va pouvoir conserver toute notre configuration sur une partition séparée
• on va être tranquille pour les éventuelles futures réinstallations

C’est pas très compliqué à mettre en œuvre et au final, tout le monde y gagne !

Organisation du répertoire /home

Le titre de l’article le suggère bien, cet article se consacre à la configuration des serveurs et programmes suivants :

• Apache 2
• PHP 5
• MySQL 5
• AppArmor (installé et activé par défaut depuis Ubuntu 8.04)

Pour des raisons évidentes de facilité, j’ai donc créé un répertoire qui rassemble toutes mes configurations spécifiques. En voici son arborescence :

• ~/config
  • /apache2
    • sites-available
      • 000-default-custom
      • local.monprojet.com
      • etc.
  • /apparmor
    • usr.sbin.mysqld-custom
  • /mysql
    • my-custom.cnf
  • /php5
    • php-custom.ini

Nous écrirons dans ces fichiers uniquement les points de configuration que l’on souhaite adapter. C’est plus simple à maintenir. Qui plus est, si les fichiers de configuration sont mis à jour par leur serveur respectif, nos fichiers resteront à l’abri.

Un des moto de Debian c’est la configuration à base de fichiers. Vous trouverez régulièrement des répertoires ayant un nom suivant le motif application.d. Donc plutôt que d’avoir 1 seul fichier de configuration, on a 1 fichier initial plus des configurations additionnelles dans ces fameux répertoires « .d ».

Configuration d’Apache

Pour Apache la démarche est la suivante :

1. créer les Virtual Host dans son répertoire personnel
2. lier les fichiers dans sites-available
3. activer les sites à l’aide de la commande a2ensite
4. recharger Apache

La seule étape par rapport à d’habitude c’est qu’on ne crée par les Virtual Host directement dans /etc/apache2/sites-available et qu’on les lie depuis notre répertoire personnel.
Admettons que je souhaite créer un Virtual Host pour une instance locale de mon blog. Je vais procéder ainsi :

1. gedit ~/conf/apache2/sites-available/local.case.oncle-tom.net
   J’y ai placé une configuration somme toute minimaliste :

   <VirtualHost *:80>
   ServerName local.case.oncle-tom.net
   DocumentRoot /home/oncletom/workspace/case.oncle-tom.net
   ErrorLog /var/log/apache2/error.case.oncle-tom.net.log
   LogLevel warn
   CustomLog /var/log/apache2/access.case.oncle-tom.net.log combined
   ServerSignature On
   </VirtualHost>

2. sudo ln -s ~/conf/apache2/sites-available/local.case.oncle-tom.net /etc/apache2/sites-available/local.case.oncle-tom.net
3. sudo a2ensite local.case.oncle-tom.net
4. sudo service apache2 reload

On se fendra de l’ajout d’un hôte local dans le fichiers hosts pour coller au plus près à l’instance de production. Toutefois je ne connais pas d’autre moyen que de modifier le fichier d’origine :-/ Si vous avez une solution je suis preneur.

Configuration de MySQL

Pour MySQL c’est un peu plus compliqué car on va également en profiter pour déplacer l’emplacement par défaut des données. Pourquoi ? Pour les placer sur une partition qui ne craindra pas les formattages et les réinstallation système.
Si vous aviez déjà suivi ma procédure de déplacement des données MySQL : oubliez là. Celle-ci est largement plus aboutie.

Avant de se jeter à corps perdu dans les manipulations, voici la démarche entreprise :

1. créer le fichier de configuration MySQL
2. créer le répertoire qui accueillera les données MySQL
3. lier la base mysql d’origine
4. modifier la configuration d’AppArmor
5. recharger la configuration des serveurs AppArmor et MySQL

C’est déjà un peu plus long mais là encore, il n’y a pas grand chose à faire en fin de compte :

1. gedit ~/conf/mysql/my-custom.cnf
   On y indique le nouvel emplacement de ses données MySQL :

   [mysqld]
   datadir            = /home/oncletom/Apps/mysql

2. mkdir /home/oncletom/Apps/mysql
   sudo chown mysql:mysql /home/oncletom/Apps/mysql
3. ln -s /var/lib/mysql/mysql /home/oncletom/Apps/mysql/mysql
4. sudo gedit /etc/apparmor.d/usr.bin.mysql
   J’y ai remplacé

   /var/lib/mysql/ r,
   /var/lib/mysql/** rwk,

   par l’ancien chemin + le nouvel emplacement des données MySQL

   /var/lib/mysql/ r,
   /var/lib/mysql/** rwk,
   /home/oncletom/Apps/mysql/ r,
   /home/oncletom/Apps/mysql/** rwk,

5. sudo service apparmor reload && sudo service mysql reload

Si vous avez bien suivi toutes mes explications, vous vous demanderez pourquoi j’ai modifié le profil existant de MySQL dans AppArmor au lieu de lier un nouveau profil ?
Je me suis rendu compte qu’au démarrage de l’OS, AppArmor ne chargeait pas le profil personnalisé et bloquait le démarrage de MySQL. J’ai créé un sujet sur Ubuntu Forums après une lecture de la documentation AppArmor mais pas de nouvelles. Là aussi je suis preneur car en relançant les serveurs à la main, tout fonctionne.

Ensuite à vous de repeupler vos bases de données à partir d’un dump. Si vous procédez à un déplacement des répertoires, n’oubliez pas de tout préserver : propriétaire et permissions ! Ça se passe avec l’option -a de cp par exemple.

Configuration de PHP

Fort heureusement pour PHP c’est plus simple puisqu’il n’y a qu’un seul petit lien symbolique à faire.
À noter que la configuration modifiée sera répercutée sur toutes les configurations de PHP, que ça soit pour Apache, en CLI ou CGI.

1. gedit ~/conf/php/my-custom.ini
   J’ai ai mis par exemple :

   memory_limit = 64M

2. sudo ln -s ~/conf/php/my-custom.ini /etc/php5/conf.d/my-custom.ini

Et voilà c’est tout pour PHP. Il faut bien entendu recharger votre serveur Web (Apache ou Lighttpd par exemple) pour qu’ils prennent en compte la modification.

Conclusion

J’ai déjà appliqué cette méthode par 2 fois et que dire si ce n’est que tout va plus vite ainsi !
Vos fichiers de configuration restent accessibles depuis votre gestionnaire de fichiers (pas besoin de passer en sudo pour sauvegarder les changements). Ils sont préservés de toute réinstallation impromptue.

Vous ne touchez que de manière minimaliste aux fichiers de configuration d’origine :

• /etc/hosts pour ajouter un nom d’hôte (utile seulement si vous ne souhaitez pas utiliser localhost)
• /etc/apparmor.d/usr.bin.mysql pour la raison évoquée plus haut … sinon on s’en serait passé

J’ai cherché à faire pareil avec phpmyadmin mais il ne semble pas y avoir de mécanisme de ce type. Dommage.

J’imagine qu’il doit y avoir des moyens similaires avec d’autres serveurs et d’autres langages. Vous procédez à un reparamétrage systématique ou bien vous utilisez une technique de ce genre ?

High Performance Web Site, sous-titré Essential Knowledge for Frontend Engineers, est ce genre de livre à lire au moins une fois à défaut de le posséder. Il résume en à peu près 120 pages 14 points d’optimisation d’un site Web.

C’est d’autant plus intéressant que l’approche se base sur les mécanismes et non sur de l’optimisation de code. Ainsi dans la plupart des cas, vous n’aurez « que » du paramétrage serveur à faire.

Ce livre fait étrangement penser aux conseils de haute performance prodigués par le Yahoo! Developer Network et repris par l’extension Firefox pour Firebug, j’ai nommé YSlow.
C’est normal : ce livre est écrit par un ingénieur de Yahoo!, probablement un de ceux qui ont participé à la rédaction du guide de performances.

Pourquoi acheter High Performance Web Sites ?

On serait tenté de ne pas acheter le livre puisqu’une bonne partie de ses conseils sont repris sur le guide de haute performance cité plus haut.

Sachez toutefois que cet ouvrage va plus loin dans le détail, prend bien le temps de présenter ses tests de performance pour illustrer et de justifier l’application de leurs méthodes. La plupart des relevés de mesure sont effectués sur une dizaine de sites allant de Google à Amazon.

J’achèterais ce livre si j’étais :

• un administrateur système chargé d’héberger 1 ou plusieurs sites Web
• un technicien/webmaster en charge d’un site à plus ou moins fort trafic
• un développeur Web soucieux des performances de ses productions
• toute personne avare en kilo-octets superflus
• toute personne voulant accélérer les temps de réponse de son ou ses sites Web

Les 14 points d’optimisation

High Performance Web Sites axe son discours sur 14 points :

1. Limiter le nombre de requêtes HTTP
2. Utiliser un Content Delivery Network (CDN)
3. Utiliser une entête Expires
4. Compresser les composants avec Gzip ou Deflate
5. Placer les feuilles de style en début de page
6. Placer les scripts JavaScript en bas de page
7. Éviter les expressions CSS (Internet Explorer)
8. Placer les scripts JavaScript et les feuilles de style dans des fichiers externes
9. Réduire le nombre d’appels à des DNS différents
10. Minifier le JavaScript et les CSS
11. Éviter les redirections
12. Supprimer les doublons de scripts
13. Configurer ETags
14. Permettre la mise en cache des appels Ajax

Il prend cependant le soin de bien expliquer les mécanismes d’HTTP et les intérêts à améliorer les performances frontend.

Le livre termine sur un comparatif des 14 points sur 10 sites, notation YSLow comprise, dont Amazon, Google, CNN, eBay, Wikipédia et Yahoo!.

La mise en pratique

J’étais déjà sensibilité à presque tous les points pour avoir lu ces fameuses 14 règles en utilisant l’extension YSlow et Firebug. Cependant après la lecture du livre j’ai eu davantage de clés et des exemples probants pour me convaincre de les mettre en œuvre.

On peut appliquer la majorité des points et les points pertinents en 1 heure. En effet, tout site ne peut se permettre d’utiliser un CDN pour accélérer les temps de réponse autour du globe.

Personnellement j’ai mis en place une compression Gzip directement au niveau d’Apache au lieu d’utiliser une compression effectuée en PHP (avec Gzip aussi). J’ai couplé cet effort avec la minification JavaScript et la désactivation des ETags.

J’avais déjà au préalable externalisés mes CSS et JavaScript, placé au bon endroit (mais seulement les appels externes au DNS principal en bas de page) et sans doublon.

C’est bête à dire mais le résultat s’est vraiment senti avec des chargements de page incroyablement plus rapides. YSlow est effectivement un compagnon idéal pour la mise en application de ces éléments avec son analyse des performances et des composants.

Conclusion

J’ai dévoré High Performance Web Sites grâce à sa simplicité de rédaction, les nombreux exemples et surtout, les explications enrichissantes. Elles sont mises en application sur Yahoo! et certes, même si on peut se dire qu’on n’a pas de site de leur envergure, leurs conseils sont toujours bons à prendre.

High Performance Web Sites est un concentré de bonnes pratiques, simples à mettre en œuvre. Pourquoi s’en priver ?

Ces optimisations ne sont évidemment pas les seules à mettre en place pour que tout fonctionne bien : il faut aussi produire du code HTML propre, du JavaScript optimisé, du code application qui ne soit pas redondant.

C’est un bon début et des pratiques à généraliser.

S’il me paraissait logique de créer chaque dépôt manuellement dans Subversion, ça l’était en revanche beaucoup moins pour le serveur Web Apache. Je souhaite en effet disposer d’un accès HTTP, pour tester les différents protocoles SVN entre autre. Flemme oblige, je n’avais vraiment pas envie de configurer également des alias et configurations de répertoires pour chaque dépôt.

Une fois de plus, la flemme a vaincu.

Après avoir lu des billets intéressants sur l’installation de Subversion sur Ubuntu ainsi que l’installation de Subversion sur Ubuntu ou Debian, je devais me rendre à l’évidence : pour chaque dépôt créé, il faut également modifier (à la main) le fichier de configuration d’Apache.

Directive DirectoryMatch

J’ai tenté de contourner le problème en utilisant la directive DirectoryMatch d’Apache mais impossible de récupérer le résultat du masque.
Si vous comptiez faire ceci, oubliez de suite, ce n’est pas possible :

<directorymatch "/chemin/vers/racine/svn/([a-z0-9-]*)>
 DAV svn
 SVNPath /chemin/vers/racine/svn/$1
 ...
</directorymatch>

En effet, DIrectoryMatch ne fait que vérifier l’existence d’un chemin par rapport à un masque ; il n’en récupère pas le contenu pour une exploitation ultérieure. C’est bien dommage.

Solution : SVNParentPath

Heureusement tout a été prévu (mais rarement mentionné). Au lieu d’utiliser SVNPath pour renseigner le chemin d’un seul dépôt, il vaut mieux utiliser SVNParentPath qui, lui, spécifie la racine des dépôts Subversion. En gros, tous les répertoires enfants à SVNParentPath sont considérés comme étant des dépôts (référentiels) indépendants.

Exactement ce qu’il me fallait.

Au final, après avoir cherché à configurer Subversion pour Windows, voici ce que j’ai rajouté dans ma config Apache :

<Location /svn>
  DAV svn
  # any /svn/foo URL will map to a repository D:/svn/foo
  SVNParentPath D:/svn
  #AuthType Basic
  #AuthName "Subversion repository"
  #AuthUserFile d:/svn/.htaccess
  #Require valid-user
</Location>

Je ferai très probablement d’autres billets sur Subversion. Depuis le temps que je voulais m’y mettre, apprendre ses rouages et sa rigueur ne sont pas forcément faciles.

Pour mesurer l’utilisation des flux RSS d’Emu Nova, j’ai décidé d’utiliser Feedburner dans sa version gratuite. Je l’utilise déjà pour ce blog et j’en suis très satisfait, que ce soit pour les données fournies, les personnalisations possibles ou encore la qualité du service.

La problématique du jour : comment utiliser Feedburner sur des flux RSS déjà existants ? Le changement doit être transparent pour les utilisateurs.

Créer son flux Feedburner

Avant de faire quoi que ce soit, il convient de créer son flux Feedburner à partir d’un flux déjà existant (qu’on souhaite rediriger tant qu’à faire). L’étape la plus simple.

Modifier les liens vers les flux

Une fois le flux créé, pensez à mettre à jour tous vos liens pointant vers ce fichier (balises <link />, liens hypertextes, boutons personnalisés etc.). Ceci a pour but d’unifier toute les adresses et éviter qu’il y aient plusieurs adresses visibles pour accéder à la même information.

Rediriger les flux existants

Arrivé à ce stade, il faut bien comprendre que nous avons 2 cas de figure :

• les anciens abonnés : ceux qui ont souscrit au flux avant que la modification précédente n’ait eu lieu. Le changement doit être transparent pour eux et ils ne doivent pas avoir à modifier la configuration de leurs agrégateurs actuels
• les nouveaux abonnés

L’intérêt est d’auditer tous les abonnés et donc pas seulement les nouveaux. C’est là que la redirection s’avère indispensable.
On est bien d’accord qu’il faudrait créer une redirection renvoyant l’ancienne adresse du flux vers la nouvelle adresse (celle fournie par Feedburner).

Le plus simple consiste à créer un fichier .htaccess (ou d’éditer directement les directives de votre serveur virtuel) dans le même répertoire que celui du fichier XML. Il contiendrait ce code :

RewriteEngine on
RewriteRule ^votreFlux\.xml$ http://feeds.feedburner.com/votreFluxFeedburner [R=301,L]

On teste, ça marche. Un peu trop bien puisqu’en suivant ce principe, quiconque appelle la véritable URL de votre flux sera redirigé vers le flux Feedburner. Si en soi ça ne pose pas problème majeur, ça l’est pourtant pour le robot d’indexation Feedburner qui, lui, a besoin d’accéder au véritable flux pour en extraire les informations.

Feedburner ayant bien fait les choses, leur robot d’indexation se signale en envoyant une entête User Agent FeedBurner/1.0 (http://www.FeedBurner.com). Ca tombe bien, il existe un filtre RewriteCond dans le module mod_rewrite. Ce dernier va nous servir à exclure le robot Feedburner de notre redirection précédente.

Juste au-dessus de notre RewriteRule, il suffit d’insérer la ligne suivante :

RewriteCond %{HTTP_USER_AGENT} !FeedBurner

L’utilisation de cette condition est d’ailleurs la seule raison pour laquelle une règle de réécriture a été employée en lieu et place d’un RedirectPermanent.
Attention cependant, le RewriteCond est à spécifier à chaque règle de réécriture. La documentation est assez explicite à ce sujet : la condition n’est effective que pour une seule règle de réécriture.

Le résultat final

Et plutôt qu’un long discours, voici le résultat final obtenu pour Emu Nova. Les fichiers RSS étaient placés dans le répertoire go/rss/. J’y ai donc placé un fichier .htaccess contenant le code suivant :

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} !FeedBurner
RewriteRule ^news\.xml$ http://feeds.feedburner.com/emunovaNews [R=301,L]
RewriteCond %{HTTP_USER_AGENT} !FeedBurner
RewriteRule ^veda\.xml$ http://feeds.feedburner.com/emunovaVedaTests [R=301,L]
RewriteCond %{HTTP_USER_AGENT} !FeedBurner
RewriteRule ^veda_commentaires\.xml$ http://feeds.feedburner.com/emunovaVedaCommentaires [R=301,L]

Pas difficile et tellement pratique