Ces dernières semaines, nous avons essentiellement travaillé sur des aspects peu visibles d’alwaysdata. Rien de transcendant, pas de nouvelles fonctionnalités extraordinaires, mais je suis sûr que certaines améliorations raviront certains d’entre vous.

Perfectionnement de notre firewall en sortie

Jusqu’à présent, notre firewall était assez simpliste : en sortie, seuls certains ports classiques étaient autorisés : HTTP, SMTP, FTP, etc. Désormais, tous les ports sont autorisés, à quelques exceptions près (P2P et IRC notamment). Cela ouvre la voie à de nombreuses applications auparavant impossibles. Par exemple, déclencher l’allumage de votre ordinateur via Wake-On-LAN

Parallèlement, un mécanisme de logging a été mis en place pour ces ports non standards. Cela nous permet de détecter et bannir automatiquement les utilisateurs qui voudraient utiliser leur compte pour des activités malicieuses.

Authentification SMTP optionnelle, renforcement de l’anti-spam en sortie

L’authentification SMTP est devenue optionnelle lorsque vous êtes sur nos serveurs (HTTP, SSH). Vous n’avez donc plus besoin de spécifier de nom d’utilisateur et mot de passe lorsque vous configurez vos applications. Naturellement, vous devrez toujours vous authentifier si vous souhaitez utiliser nos serveurs SMTP depuis l’extérieur, par exemple votre poste de travail.

Par ailleurs, tous les emails envoyés depuis nos SMTP sont désormais passés à l’anti-spam. Jusqu’à présent, certains ne l’étaient pas, à cause de limitations techniques. Cela va donc contribuer à améliorer la réputation de nos serveurs SMTP.

Lutte contre le phishing

Grâce à notre pack gratuit, des comptes de phishing s’ouvrent hélas régulièrement chez alwaysdata, jusqu’à ce que nous les détections et fermions. Néanmoins, il arrive parfois que certains comptes passent à travers et restent en opération plusieurs semaines.

Nous avons depuis peu renforcé (encore !) notre lutte contre ces comptes malicieux. Nous ne rentrerons pas dans les détails, mais les mesures prises semblent avoir considérablement réduit le nombre de comptes frauduleux.

Grâce à cela, nous avons pu éliminer la vérification de l’IP à l’inscription. Pour lutter contre le phishing, nous avions auparavant utilisé un service externe qui, à partir d’une adresse IP, renvoyait un taux de risque d’avoir à faire à un fraudeur. Hélas, cela donnait lieu à nombreux faux-positifs. C’est terminé.

Le SSL en beta

Le SSL tourne déjà depuis plusieurs semaines en beta sur certains comptes. La seule chose qu’il manque avant le lancement officiel, c’est rénover notre système interne de facturation qui n’est pas capable aujourd’hui de gérer les options payantes sur un pack.

Si vous avez besoin de SSL, contactez-nous directement. Cela ne vous coûtera rien tant que nous sommes en beta, vous n’aurez qu’à nous fournir le certificat (et la clé).

Amélioration du serveur WebDAV

Notre serveur WebDAV a récémment amélioré sa compatibilité avec certains clients, notamment Windows 7 et XBMC. Pensez-y, cela permet d’accéder à vos fichiers alwaysdata en natif sur la quasi-totalité des OS, c’est extrêmement pratique !

Rénovation du monitoring

Nous avons commencé à rénover notre système interne de monitoring pour détecter (et corriger) plus tôt les problèmes. Nous avons aussi dans les cartons une application qui affiche l’état en temps réel des services alwaysdata. Elle est déjà développée, mais nous la déploierons lorsque nous aurons terminé nos travaux sur EC2 (pour éviter de l’héberger sur notre architecture principale).

Les vraies grosses nouveautés sont toujours prévues pour… bientôt

Comme vous le savez peut-être, nous avons décidé dès le lancement d’alwaysdata de redonder nos serveurs principaux dans un second datacenter, en temps réel (via DRBD). Le but était de pouvoir rapidement pallier les pannes graves si besoin, en basculant le cas échéant l’activité sur le second serveur.

Je sais que cette nouvelle réjouira beaucoup d’entre vous : PHP 5.3 est enfin disponible chez alwaysdata. Plus précisément : la version 5.3.2 est désormais installée et sélectionnable dans l’administration, ainsi que la 5.2.13 rajoutée au passage. Comme d’habitude, rien ne change automatiquement : c’est à vous de passer à 5.3 volontairement, si vous le souhaitez. Les nouveaux comptes, eux, sont par défaut en 5.3.

Cette version aura mis du temps à être disponible pour plusieurs raisons. La première, c’est que nous étions très occupés par la nouvelle architecture, entre autres. La seconde, c’est que le déploiement d’une nouvelle version majeure d’un langage (que ce soit PHP, Python ou Ruby) est une opération beaucoup plus compliquée qu’il n’y paraît. Le support de plusieurs versions d’un même langage non compatibles entre elles (par exemple, PHP 5.2 et 5.3) demande de gros efforts de cohabitation, et même des développements internes assez conséquents. C’est la raison pour laquelle alwaysdata est probablement l’un des seuls hébergeurs à vous proposer simultanément autant de versions différentes de PHP, Python et Ruby.

Message personnel à tous les Rubyistes : la version 1.9.1 est sur les rails, encore un peu de patience

Et une huitième langue pour alwaysdata ! Merci à Profpy pour sa traduction en turc, langue parlée par plus de 70 millions de locuteurs. Je ne me lasse pas de rajouter de nouvelles langues

Nous allons prochainement¹ rénover la liste des bibliothèques (Python, Ruby, PHP, Perl) préinstallées chez alwaysdata. L’ensemble des bibliothèques actuellement installées sera au passage mis à jour.

C’est le moment de nous dire quelles bibliothèques vous aimeriez voir installées (via les commentaires de ce billet). Nous ne promettons pas qu’elles le seront, mais cela nous donnera une idée des plus populaires. Sachez toutefois que plus une bibliothèque est connue, maintenue et stable, plus elle a des chances d’être sélectionnée.

Nous garderons parallèlement l’ensemble des bibliothèques déjà installées avec leurs versions actuelles, pour éviter de casser les applications existantes. Le principe sera le même que pour Django ou Ruby on Rails : une sélection des versions dans l’administration alwaysdata.

C’est à vous.

¹ dans une semaine ou dans 3 mois, on ne sait pas encore. Ne nous harcelez pas

Vous nous soumettez fréquemment vos remarques et suggestions pour améliorer alwaysdata. Aujourd’hui, nous ouvrons pour la première fois un appel public à débattre sur une proposition de remaniement d’une partie cruciale de l’administration alwaysdata : la gestion des domaines et sous-domaines.

Cette proposition est détaillée dans un fil de discussion de notre forum. Nous vous invitons tous à participer et à donner vos avis. Nous n’hésiterons pas à corriger notre proposition si de bonnes idées ou remarques émergent. Merci !

Hier vers 12h40, une erreur humaine nous a fait perdre un petit nombre de bases de données clients. Nous avons été contraints de restaurer les bases concernées à partir des dernières sauvegardes. Tous les clients concernés ont reçu un email indiquant les bases touchées ainsi que la date de la sauvegarde précédente utilisée. Nous vous présentons nos plus sincères excuses, et revenons en détail dans ce billet sur ce qui s’est passé, ainsi que les mesures que nous allons prendre pour éviter que cela ne se reproduise à nouveau.

Ce qui s’est passé

Une commande de suppression (rm -fr) a été exécutée sur le serveur de production alors qu’elle était destinée à un serveur de développement. Cette commande a eu le temps de tourner environ une seconde avant d’être arrêtée, mais cela a suffi à supprimer une partie des bases de données. Nous avons alors immédiatement commencé à faire la liste des bases disparues. Une fois cette liste obtenue, nous avons recréé les bases à partir des dernières sauvegardes (effectuées chaque jour).

Et la redondance ?

Comme vous le savez, nos serveurs sont systématiquement redondés dans un second datacenter. Mais ce mécanisme n’est utile que lors des pannes de serveur ou de datacenter, pas pour les erreurs humaines. La synchronisation entre les datacenters se fait en temps réel, et les données modifiées sont immédiatement répercutées sur le serveur de secours.

Sitôt un fichier supprimé sur le serveur principal, il l’est également sur le serveur secondaire. Ce dernier ne nous est donc d’aucune aide dans ce cas précis, et seules les sauvegardes régulières peuvent nous aider à récupérer une version précédente des bases et fichiers.

Comment éviter un nouvel incident ?

Disons-le tout de suite : on ne pourra jamais exclure complètement l’erreur humaine, et cet incident n’a pas pour origine une négligence particulière de notre côté. Mais ça ne veut pas dire qu’on ne va rien faire suite à cet incident.

Il y a deux axes sur lesquels nous allons travailler : comment éviter une nouvelle erreur humaine, et comment être mieux préparé si elle devait se reproduire.

Éviter l’erreur humaine

À nouveau, il y a deux composantes pour atteindre cet objectif : par la technique, et par la prévention humaine.

Techniquement, nous allons réfléchir à mettre en place :

• un système de protection des suppressions sur les serveurs en production. safe-rm pourrait être une première solution ;
• un système de distinction visuelle (par exemple, des prompts de couleur différente) entre les serveurs en production et les autres.

Humainement, nous allons réfléchir à édicter des règles d’utilisation pour limiter les risques, par exemple :

• se déconnecter systématiquement d’un serveur en production une fois qu’on a effectué ce qu’on avait à faire dessus, pour éviter qu’une session inutile ne reste ouverte ;
• si on doit malgré tout garder une session ouverte, s’obliger à différencier le terminal, par exemple en évitant de rester sur le shell mais en démarrant une commande de type top ou nano.

Se préparer au pire

Une fois les fichiers supprimés, nous avons dû travailler à restaurer au plus vite les bases de données perdues. Une telle suppression sauvage des fichiers internes aux bases de données rend MySQL et PostgreSQL instables, et nous avons donc dû nous hâter de faire des tests sur un serveur temporaire pour s’assurer de la marche à suivre.

Par ailleurs, nous n’avions aucune méthode éprouvée pour détecter les bases supprimées puis réinstaller les dernières sauvegardes. Ce n’était pas très compliqué, mais cela a nécessité l’écriture de scripts et de tests pour s’assurer du bon fonctionnement de la procédure. C’est seulement ensuite que nous avons pu restaurer pour de bon les bases supprimées, d’où environ 2 heures de délai entre la suppression des fichiers et la restauration effective des bases.

Nous avons décidé il y a quelques semaines de lancer un programme de simulation des différents problèmes possibles sur notre architecture (panne de machine/réseau/datacenter, pénétration de nos systèmes, suppression de données). Ce n’est pas encore en place parce qu’il y a tout un travail technique en amont pour pouvoir dupliquer un serveur de production et y faire des simulations, mais cet incident nous montre une fois de plus l’intérêt d’être préparé à de multiples scénarios catastrophe.

Par ailleurs, nous sommes en train de travailler sur un nouveau système de redondance. Rien n’est encore fait, nous en sommes encore au stade de l’expérimentation, mais ce système pourrait nous permettre de faire des « snapshots » réguliers (par exemple, toutes les heures) de l’intégralité de nos données. S’il avait été en place, ce système nous aurait permis non pas de partir sur des sauvegardes datant de plusieures heures, mais maximum d’une heure. Nous aurons l’occasion de faire un billet à ce sujet si ce système se concrétise.

Ce qui a bien fonctionné

Terminons sur une note positive : nous pouvons relever que notre politique de communication en temps réel et de transparence, via notre compte Twitter, fonctionne bien en cas d’incident. Il faudrait encore l’améliorer en affichant, dans l’administration alwaysdata et sur notre forum, les incidents en cours (tout le monde n’est pas sur Twitter). Nous avons également pu contacter personnellement chacun de nos clients par email en leur indiquant précisément les bases touchées et la date de dernière restauration.

En outre, les sauvegardes ont été d’une grande utilité. Ce n’est pas une surprise, et chacun peut d’ailleurs accéder librement à ses sauvegardes via un répertoire de son compte. Mais c’était la première fois qu’elles ont été utilisées à grande échelle.

Pour conclure, j’aimerais présenter une nouvelle fois toutes nos excuses au nom de l’équipe alwaysdata pour ce malheureux incident. Merci à tous les messages d’encouragement que nous avons reçus, ils sont toujours très appréciés, a fortiori en situation de crise.

Après plusieurs mois de développement et un retard à l’allumage, la nouvelle architecture est désormais en production sur tous les comptes depuis quelques jours

Ce billet ne rentrera pas dans les détails techniques de cette nouvelle architecture, pour la simple et bonne raison que j’ai donné une conférence abordant largement le sujet aux DjangoCong. Cette dernière sera disponible sous peu en vidéo – nous l’annoncerons sur le blog – et permettra alors aux curieux d’en savoir plus sur l’envers du décor.

Concrètement, cette architecture ajoute une souplesse qui va nous permettre, au fil des semaines et des mois prochains, de considérablement étoffer les fonctionnalités que nous proposons. Dans un premier temps, vous bénéficiez déjà d’un ajout important : vous avez désormais accès aux logs d’erreur et d’accès en temps réel. Deux fichiers, error.log et access.log, sont accessibles dans ~/admin/log/.

Si les logs d’accès sont un petit bonus, les logs d’erreur sont en revanche une avancée considérable : vous pourrez désormais savoir plus précisément pourquoi votre application ne démarre pas, sans avoir à nous solliciter (mais nous restons bien entendu à votre disposition, cela ne change évidemment pas).

Mais le meilleur reste à venir, et les vraies nouveautés arriveront progressivement. Le support du SSL, par exemple, qui est déjà disponible en beta (ceux qui en ont un besoin urgent peuvent nous contacter). Le support de nouvelles technologies, également (WSGI, Passenger, langages exotiques comme Erlang ou OCaml, etc.).

Nous avons profité du passage à cette nouvelle architecture pour mettre à jour le serveur HTTP principal. Cela signifie de meilleures performances, mais aussi la suppression du redémarrage régulier de vos applications, ce qui entrainait un temps de latence désagréable au premier accès.

Dernière évolution récente, sans rapport avec la nouvelle architecture HTTP : les mails sont désormais stockés sur un serveur à part, autonome. Cela veut dire qu’il y a une totale étanchéité entre nos services HTTP et mail : si un serveur HTTP devait avoir un souci, cela n’impacterait plus les mails comme c’était le cas jusqu’à présent. Par ailleurs, les lenteurs qui pouvaient être visibles en IMAP devraient être éliminées.

Ces évolutions sont un véritable tournant dans l’histoire (technique) d’alwaysdata. Nous avons commencé à y réfléchir dès 2008, et le développement a mobilisé toutes nos ressources au cours des derniers mois. Maintenant que cela est derrière nous, nous allons vraiment pouvoir vous (et nous) régaler avec des fonctionnalités concrètes.

Un grand merci, enfin, à tous ceux qui nous ont aidés : en participant au beta-test, en remontant des bugs parfois obscurs, ou tout simplement en se montant patients et confiants. Champagne¹ !

¹ avec modération.

Comme nous l’avions annoncé dans le billet précédent, nous nous sommes rendus ce week-end du 24/25 avril 2010 aux rencontres Django (djangocong) qui ont eu lieu à Marseille. Quand je dis “nous”, je dis Cyril et moi-même. Voici donc un compte-rendu de ce week-end qui fut plein de richesses ! Lire la suite de cet article »

alwaysdata sera présent aux rencontres Django à Marseille les 24 et 25 avril 2010. Nicolas et moi-même vous présenterons deux conférences :

• les dessous d’alwaysdata, qui abordera certains détails internes de notre architecture ;
• les nouveautés de Django 1.2, prévu pour le mois d’avril.

De nombreuses conférences sur Django – et en français – sont prévues pendant ce week-end. Venez nombreux pour ce premier évènement dédié au fameux framework Python en France, c’est gratuit