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.

Les résultats des sondages de janvier 2012

En janvier 2012 nous avons mis en place un portail de publication de sondages. Nous avions alors créé trois sondages différents pour recueillir vos avis. Ces sondages portaient sur différentes thématiques.

Il était prévu de publier ces résultats courant février / mars mais nous avons eu une charge de travail assez importante ces dernières semaines. Avec l’arrivée du Blog nous avions décidé qu’il serait plus intéressant d’utiliser ce dernier plutôt que de communiquer via les forums de l’association.

C’est que vous en avez entendu parler des sondages en cette année 2012… il serait peut être bénéfique de vous rappeler sur quoi portaient ceux de Web4all 🙂

Dans cet article, nous allons uniquement effectuer un bref rappel de ces sondages puis nous publierons les résultats en plusieurs articles en regroupant les questions par thématiques. Dans un soucis de clarté maximale vis à vis des clients -et des non clients- nous fournirons à chaque fois un document PDF contenant une extraction des données depuis l’application (nous avons utilisé LimeSurvey). Sachez toutefois que nous ne pouvons publier les données brutes, nous sommes en effet obligé de retirer les informations personnelles que certains ont mis dans les champs de types texte (nom, adresse mail…).

Modification des offres et augmentation tarifaire

Ce sondage consistait à recueillir les avis sur différentes évolutions que nous envisagions afin de nous permettre de mieux prioriser le lancement de nouvelles offres et options. Nous avions également soumis une augmentation tarifaire afin de voir comment cela serait perçu par l’ensemble des clients. Pour finir nous avions ajoutés quelques questions pour recueillir les avis au sujet de Web4all, tant sur le plan technique qu’au sujet du support (rapidité et qualité des réponses apportés) et du Manager (qui permet aux clients de gérer l’ensemble des services).

Les résultats de ce sondage seront publiés en trois articles :

  • Evolutions
  • Modifications des offres
  • Satisfaction client

Quelles sont vos attentes en matière de sauvegarde de données ?

Depuis le mois de novembre nous avons mis en place une architecture de tests pour le stockage de données et leurs sauvegardes. Au cours du premier trimestre 2012 nous avons pu mettre cette architecture en production. Le stockage des données à été totalement revu et la sauvegarde est désormais effectuée de deux manières différentes : l’ancien système pour des raisons de sécurité et le futur système le temps de valider intégralement la fiabilité des sauvegardes.

Aussi, nous avons voulu savoir quelles étaient les attentes des utilisateurs, clients Web4all ou non, en matière de sauvegarde : durée de rétention des données, la fréquence d’exécution des sauvegardes, le tarif considéré comme convenable… Nous avons ainsi pu en tenir compte pour nos futures offres et je peux vous dire que cela a considérablement modifié ce que nous avions prévu…

Les résultats de ce sondage seront publiés en un seul article.

Zimbra Network Edition, ce que vous aimeriez et à quel prix ?

Depuis 2008 nous avons remplacé le système de messagerie email classique par une plate forme Zimbra Open Source Edition. Cette dernière a considérablement évoluée en septembre 2011 pour offrir de meilleures performances et disponibilité sans oublier l’aspect évolutivité côté administration.

Très satisfait de la suite Zimbra nous avons mis en place en novembre 2011 une autre plate forme de messagerie, cette fois basée sur la version Network Edition de Zimbra. Nous avions eu l’occasion de testé cette suite pendant de nombreuses semaines au cours de l’année 2011 et nous avons donc décidé de franchir le pas. Les membres de l’équipe de Web4all utilisent la messagerie Network Edition apportant de nombreuses fonctionnalités en plus (synchronisation mobile, connecteur Outlook pour ceux qui l’utilisent, prévisualisation des pièces jointes en HTML via une conversion à la volée, sauvegarde sur 30 jours et bien d’autres options).

Cette solution ayant un coût non négligeable en terme de licences, nous avons donc soumis aux clients potentiels quelques questions pour juger la viabilité d’une telle offre.

Les résultats de ce sondage seront publiés en un seul article.

 

Nous vous donnons donc rendez vous dans quelques jours pour le premier article sur ces sondages !