HappyNewYear4all & retour sur les récentes modifications

Logo Web4all

Bonjour à toutes et à tous. Quoi de mieux pour commencer cette nouvelle année que le traditionnel « bonne année et meilleurs voeux« . Rien d’original certes, il y a sûrement bien mieux. Nous vous souhaitons sincèrement nos meilleurs voeux, en espérant que vos sites internet se développent autant que vous le voudrez (et que vous vous en donnerez les moyens). Nous ferons tout pour vous accompagner dans cette aventure.

L’année 2012 chez Web4all aussi se termine, beaucoup de projets auront vu le jour en cette année, certains auront mis du temps à être mis en production, certains sont visibles pour vous, d’autres moins… Nous allons donc revenir sur la dernière modification d’architecture qui a eu lieu le 25 et 26 décembre et qui a fortement impacté les sites de certains d’entres vous.

Si l’on devait résumer en une phrase cette modification ce serait compliqué tant les modifications sont conséquentes, mais les principales sont : Apache Worker & SuExec avec mise à jour du manager permettant à l’utilisateur de choisir sa version de PHP sans oublier l’apport du SSH ! Nous avons pour habitude de ne jamais faire de modification trop massive pour éviter en cas de problème de ne pouvoir isoler l’origine de ces derniers. Mais cette fois ci les modifications étaient dépendantes les unes des autres, nous obligeant à les mettre en production toutes en même temps.

Je vais essayer d’être le plus clair possible, certains passages seront un peu technique mais sans trop, je vous le promet 😉

Sommaire :

Cette fois ci je ne vous donnerais pas les temps passés sur chaque tâches, cela se compte en milliers d’heures

Il faut savoir que ce projet a débuté en 2009 (oui, vous avez bien lu, en 2009 !). Seulement, la croissance de Web4all nous obligeant en permanence à revoir notre copie, à refaire des essais, à laisser un peu de côté le projet pour se consacrer à d’autres…

Ce qui a changé et pourquoi


Les raisons sont nombreuses. La plus importante : la sécurité. Vient ensuite l’amélioration des performances ou encore l’apport possible de nouvelles fonctionnalités comme le SSH. Je vais donc vous expliquer un peu ce qui change par rapport à avant en prenant en exemple un hébergement.

Un hébergement avant la modification :

Avant la modification, cet hébergement ressemblait à cela :

Web4all Ancienne arborescence

L’hébergement se nomme w4a100010, cela n’a pas changé. Pour les clients les plus anciens, l’hébergement porte parfois comme nom celui d’un nom de domaine. Ensuite dans ce répertoire il y avait les données de vos sites. Un répertoire par domaine (en général, cela diffère d’un hébergement à un autre, ces valeurs étant personnalisables). Les fichiers appartenaient tous à l’utilisateur nommé www-data. Il s’agit sur le système de l’utilisateur dédié au serveur Web Apache qui publie vos sites.

Lorsqu’une personne naviguait sur votre site, le contenu statique (.html .css .js .gif .png…..) était servit par le serveur web Apache. Et lorsqu’il s’agissait d’un fichier .php alors Apache servait également le fichier grâce à « libapache2-mod-php5 » qui est le module lui permettant de traiter du PHP5.

Ainsi nous avions donc un serveur Web (enfin, plusieurs serveurs) qui servaient avec un même programme, sous un même utilisateur, pour tous les sites, tout le contenu quel qu’il soit.

Pour finir, ce serveur était configuré avec ce que nous appelons le « mod Prefork« . Le serveur lorsqu’il démarre créé un processus, le processus parent. Puis ensuite à chaque demande il va créer des threads enfants.

Voila une image que j’ai trouvé sur un site (non les serveurs ne sont pas en MacOSx mais en Linux, mais l’image étant assez parlante j’ai préféré prendre celle là que refaire quelque chose). Comme vous pouvez le voir nous avons bien le processus parent et les threads enfants :

Web4all Apache Prefork

Alors si l’on commençait par là… Notre premier soucis c’est celui là : Apache fait tout, il en fait trop. Alors nous allons faire différemment  nous allons faire travailler Apache sur le contenu pour lequel il a été conçu et pas plus. Le reste nous allons l’externaliser.

De plus, vu que Apache fait tout, avec un seul et même utilisateur : www-data, la sécurité était loin d’être parfaite. En effet, bien que nous ayons mis des protections sur la couche PHP avec OpenbaseDir et quelques modifications ou scripts « faits maison« , il était possible pour un utilisateur ayant un minimum de compétence dans le domaine, d’utiliser certaines failles pour hacker la plate forme comme cela s’est vu à quelques reprises depuis 2007.

Tout commence donc par l’utilisation de Apache, non plus en mode Prefork mais désormais en mode Worker ! Un processus parent au démarrage de l’application puis des processus enfants qui eux mêmes vont lancer des threads :

Web4all Apache Worker

Tout à l’heure nous disions :

« Lorsqu’une personne naviguait sur votre site, le contenu statique (.html .css .js .gif .png…..) était servit par le serveur web Apache. Et lorsqu’il s’agissait d’un fichier .php alors Apache servait également le fichier grâce à « libapache2-mod-php5″ qui est le module lui permettant de traiter du PHP5. »

Désormais, lorsqu’une personne navigue sur votre site, le contenu statique (.html .css .js .gif .png…..) est servit par le serveur web Apache. C’est tout. Alors que se passe t-il si le fichier est un fichier .php ? Et bien c’est très simple, Apache va envoyer la requête à PHP qui n’est plus un module de Apache, il est indépendant. Ceci grâce à Fast-CGI. Ainsi le contenu PHP de votre site est envoyé à l’application PHP qui va la traiter avec un utilisateur dédié à cela. Non plus www-data mais un utilisateur PHP dédié à cela et différent pour chaque hébergement ! Ainsi en cas de faille de sécurité sur un hébergement, l’utilisateur étant différent des autres hébergements, il ne pourra impacter les autres utilisateurs.

Cela nous oblige donc à créer un utilisateur sur chaque serveur Web pour chaque hébergement. Nous avons alors poussé l’idée plus loin, et nous avons créé au sein de chaque hébergement une arborescence système. Ainsi vous avez au sein de votre hébergement un ensemble de répertoire un peu comme si vous étiez seul sur le serveur. Cela va nous permettre par la suite de vous proposer certaines fonctionnalités telle que l’accès SSH.

Un hébergement après la modification :

Désormais un hébergement ressemble à cela :

Web4all Nouvelle arborescence

 

Oui, je vous l’accorde cela change beaucoup, alors ne vous inquiétez pas, nous allons détailler tout cela.

  • backups : il s’agit d’une nouveauté encore non officielle. Dans ce répertoire vous trouverez des liens vers les snapshots de votre hébergement. Il s’agit de clichés instantanés de votre hébergement tel qu’il était à certains moments. J’y reviendrais par la suite.
  • bin, dev, etc, lib, lib64, tmp, usr : il s’agit de répertoires systèmes utilisés par… le système. Vous ne pouvez pas écrire dedans, ils sont réservés à Web4all et nous permettrons certaines évolutions (encore une fois : comme le SSH)
  • var : c’est votre répertoire, celui dans lequel vos données vont se trouver. Ce dernier va contenir différents sous répertoires :
    • awstats : il contient les scripts pour les statistiques de vos sites (le fichier perl de génération et visualisation des statistiques ainsi que le fichier htpasswd pour protéger l’accès aux données). Comme vous le savez, Web4all, chaque nuit, génère les statistiques de visites de vos sites et vous permet d’y accéder via http://votresite.tld/stats Vous pouvez depuis le manager créer des comptes utilisateurs statistiques afin de donner un accès à des tiers. Le gros avantage de Awstats comparé à un logiciel comme Google Analytics ou encore Piwik, c’est qu’il voit ce que les autres ne voient pas. Si une page n’existe pas, cela va générer une erreur, ni Analytics, ni Piwik ou autre système de statistiques ne verront cette demande en erreur alors que Awstats lui travaille avec les logs de Apache, il sera donc en mesure de vous donner la liste des éléments appelés et qui ont retournés une erreur à vos visiteurs.
    • log : il contient les logs de visites de vos sites dans un sous répertoire apache2 (attention, sur la nouvelle version du manager vous devez demander à ce que la copie des logs soit effectué depuis la gestion de votre hébergement. Ceci n’est plus définit par défaut). Il contient également un autre sous répertoire, nommé awstats qui lui contient les données des statistiques dont nous venons de parler juste avant.
    • www : nous y voila, votre répertoire, le vrai, celui dans lequel se trouvent vos sites. Pour résumer, tout ce qui se trouvait avant dans votre hébergement a été déplacé ici !

Une dernière modification que vous aurez peut-être remarqué, l’utilisateur propriétaire des données n’est plus www-data, il s’agit désormais de w4a100010 qui a pour uid 100010 (dans cet exemple).

Comme dit plus haut, les données PHP sont désormais exécutées par PHP avec un utilisateur dédié par hébergement, cela implique donc que les données de chaque hébergement appartiennent à un utilisateur définit.

Cela est très bien mais impose certaines contraintes (positives !) en termes de sécurité. L’utilisateur PHP w4a100010 doit pouvoir lire les fichiers de votre site. Cela ne pose pas de soucis, elles lui appartiennent (il est le propriétaire de ces fichiers comme nous venons de le voir). En revanche, les autres fichiers (.html .css .js .gif .png…..) eux seront lus par le serveur Apache qui lui s’exécute toujours en www-data, il faut donc que ces fichiers lui soit accessible ! Vous devez donc sur ces fichiers avoir un CHMOD qui permette une lecture à un utilisateur autre c’est à dire au minimum un 4 sur le dernier chiffre.

Par exemple un fichier en lecture uniquement pour PHP : 0600 alors qu’un fichier lisible aussi pour apache devra avoir 0604 au minimum. L’avantage c’est que si vous indiquez par exemple 0400 sur le fichier de configuration de votre Joomla ou WordPress, il ne sera lisible que par votre site et par aucun autre ! Indispensable lorsque l’on sait que ce fichier contient vos identifiants d’accès à votre base de données !

Nous avons réalisé un topic sur nos forums qui explique tout cela : http://forums.web4all.fr/topic/3727-bien-choisir-les-permissions-sur-vos-fichiers/

Afin de ne pas impacter vos connexions FTP et notamment pour les personnes qui automatisent la récupération de données, nous avons déplacé les données de / vers var/www dans chaque hébergement et avons donc modifié les utilisateurs FTP afin qu’ils soient définit comme avant mais avec var/www en plus dans leurs chemins. Nous y reviendrons plus tard dans la partie « L’impact : attendu et inattendu » car cela a eu quelques conséquences sur les connexions au serveur de sauvegardes.

Ce qu’il faut donc retenir c’est que désormais, un hébergement contient une arborescence complète sur laquelle vous n’avez pas totalement la main. Une partie vous est réservée et appartient à un utilisateur dédié à votre hébergement. Ceci améliore donc considérablement la sécurité. Et grâce à la nouvelle architecture Apache / PHP, les performance s’en trouvent améliorées. Mais n’oubliez pas, vous devez gérer finement les permissions sur vos fichiers !

 

La mise en production


Lors de la mise en production, nous avons eu plusieurs éléments à modifier. Comme nous venons de le voir nous avons modifié la partie Apache et PHP mais pas uniquement. Je vais donc rapidement vous dire ce qui a été fait.

Manager :

Mise en production de la nouvelle version 1.5 de IWAL (il s’agit du nom du manager, entièrement développé par nos soins). Pour cette mise en place, nous avons mis en place une nouvelle plate forme afin de pouvoir travailler en parallèle de la production. L’ancienne version était sur un serveur Web et utilisait un petit serveur MySQL.

Voici donc ce qui a changé :

  • Mise en place d’un nouveau serveur MySQL à Roubaix avec réplication temps réel sur un autre serveur à Paris. Sauvegardes des bases de données toutes les heures à Paris.
  • Mise en place de deux serveurs avec répartition de charge pour la publication du manager afin d’assurer une haute disponibilité même en cas de maintenance.
  • Mise en place d’un serveur « CLI » (Command Line Interface), ce serveur assure le pilotage de l’infrastructure : système de fichiers, serveurs Web Apache, gestion des utilisateurs PHP / SSH, mises à jour des données et quotas, système de relance en cas d’impayés / échéance… traitement automatisé des paiements CB / Paypal… et bien d’autres tâches.

Cette nouvelle version du manager arbore un nouveau design. Esthétiquement différent mais également plus large ! Ce design va encore être un peu modifié suite aux remontées de certains utilisateurs. Nous avons quelques soucis d’affichage sur Internet Explorer et iPad, nous travaillons à la correction de cela. Mais déjà, nous avons uniformisés le design, les boutons d’actions, les « boites » d’informations à destination des utilisateurs… Nous avons essayé de le rendre plus cohérent. Nous espérons que cela est vraiment le cas.

Notez que vous retrouverez ce design prochainement sur le site internet de Web4all qui a prit un peu de retard 🙁 Un grand remerciement à Jean-Baptiste DEBAUCHe de chez Welovemedias pour ce design.

Web4all Accueil Manager

 

Allez je vous fais faire un petit tour rapide, nous allons nous contenter de la partie hébergement qui est celle qui a le plus changé 🙂

 

Web4all Manager Hébergement L’accueil de l’hébergement a subit quelques modifications. Pas forcément très visible… Les boutons d’actions ont été uniformisés, la synthèse de gestion des délégations se voit légèrement plus aéré et les bargraphs affichant l’utilisation des quotas ne sont plus gérés avec des images mais en CSS (quelques soucis sur Internet Explorer pour ce dernier point).
La partie Fichiers & accès se voit intégralement refaite : une synthèse est affichée afin de vous donner toutes les informations dont vous pouvez avoir besoin. La gestion des utilisateurs SSH est enfin arrivée et le tout est cohérent avec la charte graphique dans le reste du manager. Web4all Manager Hébergement
Web4all Manager Hébergement La gestion des domaines est aussi bien retouchée ! Comme dans d’autres parties du manager, nous avons mis en place des tableaux utilisant du Javascript permettant une présentation plus jolie mais surtout plus pratique (notez que les couleurs des lignes doivent être modifiées). Un champ de recherche vous permet en temps réel d’effectuer une recherche sur n’importe quel élément du tableau. De plus les en-têtes des colonnes sont cliquables afin de pouvoir modifier l’ordre d’affichage des données. Il est désormais possible d’afficher l’intégralité des données sur une seule et même page 🙂 Exit donc le bug au delà de 100 éléments que certains d’entre vous nous avaient remonté !
La visualisation d’un domaine… voilà sûrement la partie qui a le plus changé. En effet elle a été refaite de zéro (et doit encore se voir greffer quelques modifications notamment graphique). Outre l’harmonisation avec la charte graphique, cette partie se voit désormais découpé de manière structurée en plusieurs parties : la publication web Apache, la partie DNS et la partie Mail Zimbra. Concernant la partie web Apache, on y retrouve désormais la gestion de la configuration de Apache, des répertoires utilisés mais aussi et surtout, la nouveauté tant attendu depuis très longtemps, la possibilité de sélectionner la version de PHP parmi les versions 5.2, 5.3 et 5.4 ! Web4all Manager Hébergement
Web4all Manager Hébergement Comme pour la partie Fichiers & accès, la partie Zimbra se voit remise au goût du jour et surtout, se voit apporter des explications sur la page d’accueil. Nous recevions beaucoup de questions relative à Zimbra, nous avons donc essayé de synthétiser cela 🙂
La vue qui permet de visualiser les comptes emails Zimbra créé sur l’hébergement est modifié de la même manière que la gestion des domaines, Bis : nous avons mis en place des tableaux utilisant du Javascript permettant une présentation plus jolie mais surtout plus pratique (notez que les couleurs des lignes doivent être modifiées). Un champ de recherche vous permet en temps réel d’effectuer une recherche sur n’importe quel élément du tableau. De plus les en-têtes des colonnes sont cliquables afin de pouvoir modifier l’ordre d’affichage des données. Web4all Manager Hébergement
Web4all Manager Hébergement Pour finir, de très légères modifications sur la partie Awstats. Nous avons là aussi ajouté des informations afin de vous donner le plus d’infos possible. Nous y avons même indiqué quelques références en la matière comme Google Analytics, Piwik ou encore Open Web Analytics si vous désirez compléter ce que Web4all met à votre disposition.

Sachez également que de nombreux bugs ont été corrigés, la partie MySQL par exemple sur la gestion des utilisateurs et des mots de passe ou encore la mise à jour des quotas Zimbra et MySQL.

D’autres modifications doivent être effectuées dans les prochaines semaines 🙂

Revenons en à notre mise en production. Comme nous venons de le voir le manager a subit de lourdes modifications. Les scripts d’installation / mise à jour auront pris quelques minutes à passer les milliers de requêtes SQL modifiant le schéma de la base de données ainsi que  les données…

La partie Système de fichiers

Je ne vais pas m’attarder sur cette partie, nous avons vu plus haut que l’arborescence au sein d’un hébergement avait complètement été modifiée. Il nous aura ainsi fallu procéder de la sorte :

  • création de var/www dans chaque hébergement
  • déplacement de toutes les données de chaque hébergement dans le répertoire var/www
  • modification du propriétaire de tous les fichiers dans var/www pour qu’ils appartiennent à l’utilisateur w4axxxxxx correspondant à l’hébergement
  • modification des CHMOD de tous les fichiers afin de garantir que les fichiers soient correctement lisibles par Apache et PHP comme expliqué plus haut.

Cette partie là, j’y reviendrais dans la partie « L’impact : attendu et inattendu » a causé quelques problèmes 🙁

La partie Publication des données

Nous avions jusqu’alors 7 serveurs Web qui servaient les données Apache et PHP 5.2 et un serveur qui servait du Apache / PHP 5.3.

Mais ça, c’était avant… 🙂

Désormais nous avons mis en place :

  • 11 serveurs web qui publient Apache et PHP 5.x (toutes les versions).
  • 2 serveurs web qui publient le contenu CGI-BIN et Awstats car la sécurité est géré différemment dessus. Ce sont nos répartiteurs de charge qui routent différemment les requêtes sur les serveurs.

Le soucis, c’est que durant la migration dès qu’un hébergement se voyait modifié par notre script qui migrait les données comme expliqué au dessus dans « La partie Système de fichiers », les sites de cet hébergement ne fonctionnait plus du tout. Nous avons donc mis en place plusieurs script afin de permettre une interruption maximale de 1 minute par hébergement. Là aussi pour certains cela aura duré plus longtemps que cela, et là aussi j’y reviendrais après.

Nous avions donc réalisé entre autre un script qui dès que l’hébergement était modifié au niveau du système de fichiers, routait le site vers une plate forme web différente. Ainsi nous avons dû laisser en parallèle les 7 + 13 serveurs Web et cela donnait :

  • Tout le monde par défaut est routé sur l’ancienne architecture
  • Si l’hébergement est modifié, envoie d’une instruction aux répartiteurs de charges : les sites x, y, z… de cet hébergement doivent désormais être routés sur la nouvelle plate forme
  • Une fois tout le monde modifié, inversion du fonctionnement, la nouvelle plate forme devient celle par défaut.
  • Retrait de l’ancienne plate forme.

La partie Statistiques

Nous en avons profité pour mettre à jour Awstats. Il y aura eu une coupure de deux jours mais nous avons rejoué les scripts afin que vous ne perdiez pas les données de ces deux journées. Peu de modifications sur cette partie de votre côté. Amélioration considérable de notre côté sur la gestion des logs Apache et des statistiques.

La partie sauvegarde

Nous progressons vers la nouvelle plate forme de sauvegarde… le chemin à parcourir se réduit et nous vous en donnons un avant goût ! 🙂 Ce n’est pas inclut officiellement dans les offres, et tout le monde ne conservera probablement pas cela dans son offre (différence entre les offres haute sécurité et non HS).

Désormais à la racine de votre hébergement, vous trouverez un répertoire « backups ». Ce dernier vous fournit 4 liens vers des clichés instantanés (Snapshots) de votre hébergement :

Web4all Backups Snapshots

 

  • snap-hourly-1-latest : le dernier snapshot horaire qui a été effectué. Toutes les heures.
  • snap-daily-1-latest : le dernier snapshot journalier qui a été effectué. Tous les jours à 05H00 du matin.
  • snap-weekly-1-latest :  le dernier snapshot hebdomadaire qui a été effectué. Tous les dimanches à 07H00 du matin.
  • snap-monthly-1-latest : le dernier snapshot mensuel qui a été effectué. Tous les premiers du mois à 08H00 du matin.

Ces données sont en lecture seule. Pour y accéder votre utilisateur FTP doit avoir accès à l’ensemble de votre hébergement. Il ne doit donc pas avoir de repertoire de restriction définit sur le manager.

 

L’impact : attendu et inattendu

Il y avait certaines choses que nous avions prévues, et nous avions donc fait en sorte de ne pas avoir de soucis, comme expliqué plus haut à l’aide de script qui ont modifiés les données, les ont déplacés, ont agît sur les répartiteurs de charges pour avoir une période d’indisponibilité la plus courte possible pour chaque hébergement.

Et pourtant, comme vous l’avez peut-être constaté sur votre site, nous avons eu de gros soucis sur certains sites internet. En effet l’utilisation un peu surprenante de la part de certains de leur hébergement nous a posé quelques soucis.

Les directives Apaches

Par exemple le fait d’utiliser des fichiers .html ou .css contenant du PHP. Des choses courantes que malheureusement nous n’avions pas prises en compte 🙁 Vous faisiez cela car le serveur était le même pour Apache et PHP. Désormais il faudra indiquer au serveur de gérer cela :

AddHandler application/x-httpd-php .html

De même sur les FollowSymLinks qui nécessitent désormais un + obligatoirement au risque de générer une erreur 50x :

Options +FollowSymLinks

Les permissions sur les fichiers

Comme expliqué en début d’article, les permissions sur les fichiers sont désormais très importantes (voir également ce topic sur la gestion des permissions) . Ainsi nous avions passé un script pour modifier cela. Seulement nous avons rencontrés un petit soucis. PHP générait les fichiers avec un CHMOD en 0600 ce qui fait que lorsque Joomla, WordPress ou autre générait des fichiers de cache, Apache n’avait pas le droit de lire ces fichiers. Et en général vous n’aviez plus de Javascript ou de CSS sur votre site 🙁

Nous avons rapidement avec l’aide de certains d’entre vous isolé le problème et recompilé SuExec avec un usmak 0022 afin de ne plus générer les fichiers PHP en 0600 mais en 0644.

Les .htaccess

Certains d’entre vous ont eu des soucis de redirections liés à un bug de Apache lorsqu’il est utilisé avec Fast-CGI. Nous avons trouvé grâce à l’aide de certains d’entre vous comment résoudre cela. Ainsi il faut ajouter dans certains cas un ? après le index.php Dans cet exemple, si nous retirons le ? après index.php cela ne fonctionnera pas alors que cela fonctionnait très bien auparavant 🙁

RewriteEngine on 
RewriteRule ^fr/(.*) ./index.php?/fr/$1
RewriteRule ^en/(.*) ./index.php?/en/$1

D’autres utilisateurs ont eu des soucis à cause des .htaccess qui contenaient des directives php_value et php_flag. Avant, cela ne servait théoriquement à rien car la plupart des directives n’étaient alors pas prises en compte. Le soucis, c’est que comme expliqué plus haut, PHP n’est désormais plus un module de Apache. Il est totalement indépendant. Ainsi, Apache ne sait pas interpréter ces directives et provoque donc une erreur 50x. Nous avons alors dans l’urgence passé des scripts pour commenter ces directives afin de ne plus générer ces erreurs.

Nous avons réunit ces modifications et informations à connaitre sur nos forums : http://forums.web4all.fr/topic/8468-les-erreurs-possible-sur-les-sites/

Le répertoire de base / point de montage de votre site

Nous avons modifié les paths des hébergements. Au lieu d’avoir du /var/www/virtual et /var/www/sites avec les hébergements dedans, nous sommes passés sur /datas/vol1 et /datas/vol2

Nous avons alors mis en place des liens afin que les anciens chemins restent valides. Ce que nous n’avions pas prévu c’est que certains CMS refusent de fonctionner si le DocumentRoot n’est pas celui définit dans leur configuration. Il aura donc fallu modifier pour certains d’entre vous les configurations de vos CMS.

Les sauvegardes

Comme vous avez pu le constater, l’accès aux sauvegardes a été impossible durant près de 5 jours. En effet la modification des arborescence a posé des soucis sur les accès FTP nous obligeant à réaliser pas mal de modifications sur cette partie. Etant assez débordé par tous les problèmes liés à la migration, nous n’avons pu gérer cela rapidement 🙁

De plus la modification de l’arborescence dans les hébergements fait que les backups ne sont plus accessible pour tous les utilisateurs FTPPour y accéder votre utilisateur FTP doit avoir accès à l’ensemble de votre hébergement. Il ne doit donc pas avoir de repertoire de restriction définit sur le manager.

Les leçons à en tirer pour notre équipe

Malgré plus d’un an et demi de tests nous nous sommes retrouvés confrontés à des problèmes que nous n’avions pas constaté durant nos tests. De plus il y a des choses que nous n’avions pas correctement testés, avec du recul on s’en aperçoit. Les fautes qui suivent sont imputables à l’équipe de Web4all mais avant tout à moi. En tant que président et dirigeant en grande partie ce projet, j’aurais dû être bien plus perfectionniste. Je regrette terriblement la manière dont c’est déroulé cette mise en place et vous assure que nous allons en tirer les leçons pour les travaux à venir. Je vous présente donc toutes mes excuses 🙁

Le seul point positif, notre plus grande crainte était que l’architecture s’écroule en terme de ressources vu que nous avions changé beaucoup de paramétrage, satisfaction : ce n’est pas le cas, nous avons même gagné en performance ! 🙂

Des tests pas assez poussés

Nous avons réalisés de très nombreux tests, passés des centaines d’heures à faire et refaire les mêmes essais. Malheureusement nous n’avions pas les moyens financiers de créer la parfaite réplique de l’architecture de production. Cela implique que nous avons dû cibler nos tests et nous sommes donc passés à côté de nombreux points comme ceux que je viens d’évoquer ci-dessus. Nous aurions dû vous demander de participer à ces essais afin de couvrir bien plus de cas de figures.

Un manque de communication

Nous avons commencé à communiquer en 2009 sur la façon dont il fallait gérer les permissions puis en septembre 2011 sur la migration prévue. Autant dire que cela ne servait à rien. Beaucoup trop de temps s’est écoulé entre les messages sur les forums et sur l’interface de Travaux. Au final plus personne n’y pensait.

Vu que nos tests étaient très confortant et nous laissaient penser que nous n’aurions pas tout ces problèmes, nous n’avons pas jugé utile de vous prévenir. Il s’agit là d’une énorme faute et là encore je vous prie de nous en excuser 🙁

Une fois le tout lancé, nous avons été submergés par les demandes d’aide, plus de 150 tickets et plusieurs messages sur les forums. Nous n’avions alors plus le temps de faire une communication comme celle-ci 🙁

Le tout à la mauvaise période

L’équipe de Web4all a été très absente durant cette migration à l’exception de deux ou trois membres dans les meilleurs moments. Si cela est regrettable il faut surtout voir que j’aurais dû là aussi m’assurer que cette migration serait réalisée à un moment où la disponibilité de chacun aurait été de la partie 🙁

 

Voilà, je pense avoir fais le tour. Une migration qui apporte beaucoup d’améliorations sur la sécurité, les performances, la stabilité et les services inclus dans les hébergements mais qui pour une fois aura mal été gérée. Nous nous en excusons encore une fois et vous promettons que l’année 2013 ne sera que meilleure ! 🙂

Cordialement, 

Aurélien PONCINI

Président de l’association Web4all.

aurelien.poncini

Conseil d'Administration

24 réponses à “HappyNewYear4all & retour sur les récentes modifications

  1. Bonjour,

    Sachant le boulot que c’est de faire cette migration, je vous tire mon chapeau.
    Même dans les grosses boites il y a des « ratés », il est difficile de parer à toute éventualité, surtout sur du mutualisé.
    Bravo à tous et biensur, bonne année 2013.

    Cordialement,
    Mickelebof

    1. Bonjour Sylvain
      merci pour ton commentaire.

      Et puis, tu n’y es pas pour rien dans ce chantier, tu y avais bien contribué à l’époque 🙂

      ++

  2. Aurélien,
    Un grand merci pour cet énorme et bienvenu travail d’explication.
    Et un grand merci pour l’énorme travail en général que vous avez fourni ces derniers temps pour faire évoluer Web4All.
    Je n’ai eu pour ma part que quelques petits soucis sur des règles de réécriture devenues inopérantes dans un htaccess.
    Même si je me doute que certains des utilisateurs ont du faire face à des problèmes autrement plus conséquents, j’ai la conviction qu’ils se joindront à moi pour vous adresser des félicitations méritées.
    Je vous souhaite à vous et à toute l’équipe de Web4All une excellente année 2013.
    Laurent.

  3. Bonjour à toutes et à tous,

    Merci Aurélien pour ces voeux, ces explications et ces excuses.

    Pour ma part, les excuses sont inutiles : même si la migration ne s’est pas déroulée sans couacs, ceux que j’ai rencontrés ont été réglés (par toi) en quelques minutes. Comme d’hab serais-je tenté de dire.

    Et puis toutes ces améliorations vont dans le bon sens, donc on ne peut qu’être satisfaits. L’important ait que l’on n’ait rien perdu au passage et que l’indispo n’ait pas été trop longue. Peut-être que certains qui ont été plus touchés que d’autres seront moins conciliants. Après tout, mon site n’est pas mon gagne-pain, ça l’est pour d’autres.

    Enfin bon, voilà… meilleurs voeux à toute l’équipe, aux membres de l’association et aux autres clients.

    Juste une petite chose : tu évoques la nouvelle architecture avec notamment les dossiers var, www, awstats, log… je ne vois rien de tout cela sur mon hébergement. Uniquement mes domaines et mes sous-domaines (que j’ai tous réorganisés sur le modèle cgi-bin/errors/htdocs, au passage). Je n’ai donc plus accès aux logs comme c’était le cas avant (j’ai pourtant coché la case « Copier les logs Apache dans mon hébergement », même si cela n’apparaît pas).

    Mais peut-être que tout ce qui est évoqué n’est pas encore opérationnel ou finalisé ?

    Allez zou, encore merci pour ces explications et bonne fin de week-end.

    Cordialement,

    damien/dipisoft.

    1. Bonjour. Merci pour ce message 🙂 🙂

      Il faut que l’utilisateur FTP ait bien accès à tout l’hébergement. Pas de restriction type var/www 😉

  4. Bonjour et bonne année 2013 à WEB4ALL,

    Merci pour cette rénovation.
    Comme déjà dit, on a vu des migrations plus ratées que celle-là.
    J’aime bien la couleur des lignes des présentations java, on la garde ?

    Merci encore.

    François

  5. Globalement, l’apport en terme de fonctionnalités devraient être bien améliorées. Par contre, il y a eu effectivement un problème de communication, et en ce qui me concerne, il s’agit des directives php_value et php_flag. Désactiver les directives apache était une bonne idée à priori et pour la plupart, les sites ont été réouvert, par contre cela entraîne des réactions de la part des applications inatendues dans la mesure où elles tenaient comme acquis l’application de ces directives. Par exemple, j’ai une application qui prend en entrée du code html. Ce code html est parsé par DOMDocument puis enregistré en base. Autant vous dire que la désactivation de php_value magic_quotes a créé des codes html complétement mutilés en base. De plus, l’application fonctionnait mal sur la plupart des codes html puisque certaines opérations (comme trouvé le head d’un html) échouaient.

    Je n’ai pas souvenir d’avoir reçu un email nous prévenant que vous aviez commenté nos .htaccess – si les directives y sont, il y a une raison ! 😉

    Bon travail de votre part, le choix de la version de php est attendue depuis longtemps et va redonner à web4all son blason d’hébergeur de grande qualité. Je ne sais toujours pas ce qui vous motive autant 😉

    Bravo 🙂

    1. Bonjour,
      merci pour ce commentaire.

      Les directives php_flag non commentées empêchait tout l’hébergement de fonctionner. Nous avons pris la décision de commenter pour tous. Certains auraient préféré qu’on ne modifie pas cela effectivement mais nous devions prendre la décision dans l’urgence 🙁

  6. Merci pour toutes ces nouveautés (dont le très attendu php-switch par domaine/sous-domaine) et félicitations pour tout ce travail !

    Vivement la connexion SSH ! (une idée de la disponibilité ? relatif au nouveaux packs ?)!

    Encore merci et bonne année à tous !

    Davy

  7. Le coup classique … Dans un monde d’hypercommunication, on « oublie » de communiquer … lol

    Une période d’indisponibilité raisonnable sur une migration aussi lourde, c’est tout a fait normale … Pour être plus clair, les excuses sont très appréciées mais inutiles … Pour l’amateur que je suis, le plus important est que l’équipe me « dépanne » lorsqu’un problème se présente. Cela a toujours était le cas via les tickets ou le forum … et le plus important, avec rapidité, patience et sympathie …

    Meilleurs voeux à toutes l’équipes et encore merci pour l’énorme boulot que vous fournissez.

    1. merci.meme si ces news date de 2009 et ne sont rentre en vigueur le 6 de ce mois, ce n est pas grave. web4all as le meme point commun que beaucoup de projets libres, c’est a dire ne pas agir dans l’urgence et faire les choses bien. si cela as pris autant de temps,c est que cela devait prendre ce temps.
      Ces nouveautes associees a la qualite de service que vous avez, fait que je n ais aucune envie de changer. merci et continuez,c est tout ce que vous demandes. et je crois ne pas etre le seul a etre dans ce cas…..

  8. Un beau billet pédago!
    Par expérience dans le domaine de l’hébergement il y a toujours des cas non prévus, car les utilisateurs utilisent parfois des CMS/sites assez exotiques!

    De mon côté sur le FTP je n’ai pas de répertoire var/www qui apparaît ? l’arbo n’a pas changé visiblement.

    J’ai toujours /monsite.fr/subdomains/www/html/racine_du_site

  9. Bravo et merci pour ces explications. Je n’ai bien sûr pas tout compris…
    Comme chaque année, je vous renouvelle mon entière confiance même si elle est un peu biaisée du fait de mon investissement durant quelques temps au sein de l’association 😉
    Ca fait drôlement plaisir de voir une association qui fonctionne et qui perdure dans le temps comme web4all.
    Pensez à vous reposer (hein Aurélien) et je vous souhaite à tous une bonne année. Encore merci pour votre investissement sans faille.

Répondre à Mickelebof Annuler la réponse.

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *