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

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

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

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 !

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.

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.

L’arrivée à Marseille

Départ tardif de Paris pour une arrivée à Marseille à 1h du matin. Un peu de marche pour atteindre l’hôtel, en passant devant le Vieux Port. Nous prenons possession des lieux avant une nuit légèrement trop courte : l’accueil des rencontres Django démarre à 9h15, j’inaugure, et on ne connait pas précisément l’itinéraire…

Les conférences, c’est parti !

Hop nous nous levons sans difficulté, sautons dans un taxi et arrivons à temps pour le lancement des conférences. En voici la liste (exhaustive je pense) :

SAMEDI

• Django 1.2 : un point de nouveautés, par Nicolas Ferrari (pour vous servir) ;
• Django pour les fainéants, par Mathieu Agopian ;
• Boîte à outils Django, par Eric Veiras Galisson ;
• Cours de géo, par Samuel Adam ;
• Discussion globale sur l’évolution de la communauté Django Francophone ;
• Une authentification pour les “contrôler” tous, par Olivier Meunier ;
• Tester son projet Django, par Bruno Renié ;
• Les dessous d’alwaysdata, par Cyril ;
• Django pour les développeurs Symfony, par Nicolas Perriault ;
• Beer over IP, par Bruno Bord.

DIMANCHE

• Django et XMPP, par Jean-Michel Armand ;
• Gunicorn, Django et WSGI, par Benoît Chesneau ;
• Des lapins et des poneys, quand AMPQ rencontre Django, par Olivier Meunier ;
• Lightning talks (quelques uns dont je me souviens : django-piston, la recherche par haystack, django ROA, django-extensions, mais aussi un comparatif intéressant Django/RubyOnRails par Jérémy Lecour) ;
• Introduction à Pinax, par David Paccoud ;
• “‘Tain cong’, Django speaks marseillais“, par Stéphane Raimbault ;
• Internationalisation de contenus avec Django, par Benoît Bryon ;
• CouchDB et Django, l’utilisation de CouchDBKit, par Benoît Chesneau ;
• Les limites de Django, par David Larlet.

Inutile de rentrer dans le détail de chacune des conférences car je peux vous assurer qu’elles étaient toutes réussies et intéressantes. Je vous encourage vivement à aller jeter un œil sur tout cela, que vous soyez débutant ou expert en Django, vous apprendrez beaucoup de choses c’est certain ! Il est possible d’avoir un peu plus de détails (et peut-être d’autres infos que j’aurais oubliées) sur cette page communautaire.

A noter que nous ferons un nouveau billet concernant nos conférences à chacun lorsqu’elles seront également disponibles en vidéo, soyez patients

DjangoCong, de vrais rencontres, un bel esprit

C’est sans langue de bois aucune que je peux dire, en mon nom mais également pour Cyril, que nous avons passé un excellent week-end, que nous avons appris beaucoup de choses sur tout ce qui entoure Django, et que nous avons fait des supers rencontres. C’était vraiment très agréable de rencontrer cette communauté dont les conférenciers ont démontré des compétences certaines et une ouverture d’esprit très prometteuse pour l’avenir de notre framework favori.

C’était également très plaisant de découvrir que notre plate-forme alwaysdata est -à peu près- connue de tous et nous avons reçu de nombreux encouragements et félicitations qui nous ont vraiment fait chaud au cœur. Encore un tremplin de plus pour pérenniser notre envie de proposer encore mieux, et de continuer à accompagner nos clients comme nous le faisons depuis le début de l’aventure !

Pour preuve que ce week-end est un véritable succès, vous pouvez lire les différents comptes-rendus que l’on peut trouver actuellement (ne pas hésiter à en rajouter en commentaire si j’en oubliais) :

• http://blog.providenz.fr/2010/04/djangocong-retour-sur-les-rencontres-django-a-marseille/
• http://copyleft.free.fr/wordpress/index.php/2010/04/27/succes-pour-les-premieres-rencontres-django-fr/
• http://neokraft.net/2010/rencontres-django
• http://jehaisleprintemps.net/blog/fr/2010/04/25/beeroverip-djangocong/
• http://blog.naeka.fr/2010-04-26-rencontres-django-feedback-djangocong.html
• http://tdto.wordpress.com/2010/04/26/djangocong-cest-finit-dommage/
• http://www.biologeek.com/conferences,django,python/bilan-personnel-sur-djangocong/
• http://j-mad.com/blog/2010/04/27/djangocong-bilan-perso-dun-gentil-organisateur/
• http://jeremy.wordpress.com/2010/04/25/djangocong-2010/
• http://mathieu.agopian.info/blog/2010/04/djangocong-rencontre-django-a-marseille/

Remerciements

Nous tenons donc, en toute logique, suite à ce beau week-end passé dans le sud de la France, à remercier les personnes qui ont rendu cela possible :

• David Larlet et Jean-Michel Armand : les 2 organisateurs principaux (ci-dessus) ;

• Samuel Adam, parce qu’on a toujours besoin d’un plus belge que soi, et pour les containers de houblon exportés de Belgique (à consommer avec modération, donc un container à la fois) ;

• Tous les autres, pour avoir été aussi enthousiastes que nous pour ces rencontres, et pour les prochaines (oui David ).

Bonus

Allez en bonus, une petite photo de nous, à l’apéro, non loin du Vieux Port

D’autres photos ici et là.

• 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