Posts Tagged ‘LAMP’

Mise-à-jour WordPress et sécurisation basique

Thursday, August 13th, 2009

Une faille de sécurité sur le logiciel WordPress permet de réinitialiser le mot de passe d’un utilisateur connu (admin par exemple…). Cela consiste à faire une requête du type http://SERVERNAME/wp-login.php?action=rp&key[]= (soumettre une key[] vide permet apparemment de rendre inutile la vérification par mail). Il est donc conseillé de mettre à jour WordPress en version 2.8.4 (voici le patch pour passer de la version 2.8.3 à 2.8.4).

J’en profite pour rappeler quelques notions basiques pour sécuriser une installation d’un logiciel PHP, surtout quand il est très répandu : si possible, limiter les accès aux parties backoffice via Apache (restriction par adresses IP et/ou authentification HTTP), utiliser des identifiants originaux (pas forcément admin…), des mots de passes complexes, éviter les modules/plugins non fiables, suivre les notifications de mises-à-jour et les appliquer rapidement (cela implique de limiter les modifications intrusives empêchant des futures mises-à-jour, ou du moins les préparer sous forme de patch pour les ré-appliquer très rapidement), etc. Pour le premier point, voici un exemple de sécurisation de WordPress via Apache :

<LocationMatch "^/wordpress/wp-(admin|login)">
Deny from all
Allow from YOUR_IP
</LocationMatch>

Tags: , , ,
Posted in Evolix, french | 2 Comments »

Migration web-mutu de zidane vers hosting

Saturday, April 12th, 2008

Il n’est pas aisé de maintenir un serveur LAMP car les mises-à-jour majeures du système nécessitent un travail important de vérification (et correction) de toutes les applications web. Et cela s’avère carrément impossible dans le cadre d’un serveur LAMP mutualisé où l’on ne peut pas imposer à tous une migration à un instant défini. La seule alternative viable est de mettre en place un second serveur permettant aux webmasters d’avoir deux comptes en parallèle et ainsi de réaliser une migration en douceur.

C’est donc ce cas de figure qui se pose le serveur web-mutu zidane.evolix.net (Debian 3.1, Apache 2.0.54, PHP 4.3.10, MySQL 4.0.24) qui a désormais une espérance de vie très limitée. Tous les hébergés restants sont donc priés de migrer vers hosting.evolix.net (Debian 4.0, Apache 2.2.3, PHP 5.2.0, MySQL 5.0.32) où un compte leur a été créé. Voici un petit concentré des détails techniques sur lesquels il est nécessaire de se concentrer pour cette migration :

  • Migration PHP 4.3 vers PHP 5.2 : vous pouvez consulter les pages suivantes 4.x->5.0, 5.0->5.1 et 5.1->5.2 pour voir les évolutions (nouvelles fonctionnalités, incompatibilités, etc.).
  • Migration MySQL 4.0 vers 5.0 : vous pouvez consulter les pages suivantes : 4.0->4.1 et 4.1->5.0.
  • Charset ISO8859-1 VS UTF8 : il faut prendre garde aux problèmes d’encodage de caractères. Il est désormais conseillé d’utiliser du full-UTF8 (encodage des fichiers, stockage MySQL, content-type des pages HTML, etc.). Notez que MySQL5 offre la possibilité de stocker ses bases en UTF8, mais cela peut poser des problèmes avec certaines web-applications (des problèmes ont été constatés avec WordPress, Dotclear) et cela peut nécessiter de convertir votre base. Si les commandes “SET NAMES”, “SET CHARACTER”, etc. vous sont iconnues, reportez vous à la documention MYSQL sur l’internationalisation/localisation.
  • Pour la gestion des droits, le serveur web d’hosting.evolix.net tourne avec un groupe commun avec votre utilisateur. Vous devez donc vous assurer que vos fichiers sont en lecture pour le groupe pour qu’ils puissent être lus par le serveur web, et en écriture si le serveur web doit écrire dedans.
  • En ce qui concerne les modules PEAR, seuls des modules de base sont installés sur le nouveau serveur (Archive_Tar, Console_Getopt, Log, Net_Sieve). Sur demande, nous pourrons installer certains modules supplémentaires ou alors il faudra envisager une installation locale.
  • Au niveau DNS, vous avez la possibilité de forcer le pointage vers le nouveau serveur afin de vérifier que tout fonctionne correctement avant de réaliser la bascule réelle de votre site. Si vous souhaitez une bascule rapide en minimisant les délais de propagation DNS, vous pouvez réduire le TTL juste avant le changement effectif (mettez le à 1 heure par exemple, ce qui donnera un délai moyen de 15 minutes pour vos visiteurs).
  • Au niveau des statistiques Awstats, vos anciennes statistiques peuvent être récupérées. Il suffit de nous demander de les transférer quelques minutes avant le changement effectif de DNS.

N’hésitez pas à nous contacter par mail ou via le canal IRC #evolix sur Freenode.

Tags: , ,
Posted in Evolix, french | Comments Off on Migration web-mutu de zidane vers hosting