Compte-rendu d’incident du 22/04/2020 (et suivants)

Après les deux semaines compliquées qui viennent de passer pour JabberFR et la plupart des problèmes résolus, il est temps de faire le point sur la situation ainsi que d’expliquer en détail ce qu’il s’est passé.

Pour les gens qui ne veulent pas le détail technique et horodaté, sachez que tout JabberFR a été déplacé vers un serveur dédié chez Ikoula, quand il était précédemment chez Online depuis 2016, et que tout fonctionne à priori.

Historique

Le 21/04 : Tout à commencé le 21 avril par la dernière faille OpenSSL, qui permet de potentiellement provoquer un crash de service depuis un client en TLS 1.3, ce qui est assez gênant. Nous avons donc planifié une maintenance afin de relancer les services, et par la même occasion redémarrer avec un noyau LTS plus récent. Pour ça nous avons attendu la mise à disposition d’un paquet ArchLinux avec le correctif, qui est arrivé dans la nuit du 21. Une maintenance est planifiée.

Le 22/04 :

  • 13h25 : Un redémarrage du serveur est effectué, à la suite de la mise à jour des différents paquets.
  • 13h35 : Le serveur est toujours indisponible, nous basculons donc en mode « rescue » afin de diagnostiquer le problème
  • 13h35-15h50 : En dehors de quelques problèmes mineurs de fsck rapidement corrigés, nous ne trouvons rien de particulier. Quelques tentatives de reboot infructueuses et nous décidons d’ouvrir un ticket au service client pour éclaircir la situation.
  • 17h50 : Il y a visiblement un problème hardware avec notre disque, nous devons donc faire une sauvegarde, les autoriser à changer le disque, puis une réinstallation.
  • 18h30 : Mise en place d’un serveur temporaire avec l’espace disque suffisant chez Scaleway pour transférer les données, pendant qu’on trie un peu ce qu’on doit garder ou laisser tomber
  • 23h40 : Fin du transfert des données (ironiquement pas limité par la bande passante mais les entrées/sorties disque, les données Prosody étant composées de plusieurs centaines de milliers de fichiers mais faisant seulement 15 Gio, 1,7Gio après compression zstd)
  • 00h10 (le 23) : Demande de changement de disque faite auprès du service client
  • 01h25 (le 23) : Le disque a été remplacé

Le 23/04 :

  • 12h00 : Après avoir tenté en vain de démarrer sur une image ISO spécifique pour faire une installation personnalisée, il est décidé d’installer l’image ArchLinux standard puis de refaire une installation propre en chroot depuis le système de secours.
  • 16h06 : Après avoir fait l’installation, le système ne démarre toujours pas, et nous tombons pile pendant une plage de maintenance planifiée de la « console » online.net (qui contient à la fois les outils d’administration et de contact du support technique)
  • 17h00 : À la vue des nombreux problèmes rencontrés et après une journée complète d’indisponibilité, nous décidons de mettre en place un service temporaire ailleurs pour permettre une continuité de service, nous décidons de prendre une seconde machine temporaire (moins chère car avec moins d’espace disque et de ressources).
  • 18h47 : Le service principal est de retour sur l’IP 51.15.92.143, avec les enregistrements DNS à jour.
  • 20h00 : Le serveur Online est à nouveau disponible, nous mettons en place petit à petit notre installation personnalisée et rapatrions les backups.
  • 21h35 : Nous avions oublié de désactiver la limite de sécurité du nombre de fichiers ouverts par Prosody, qui a été assez vite atteinte, il est donc brièvement indisponible avant de revenir.

Le 24/04 :

  • 15h09 : Fin de la copie des backups, extinction du serveur Scaleway temporaire (utilisé uniquement pour stocker les backups).
  • 18h48 : Prosody arrête de répondre sur le serveur temporaire, suite à un bug dans un module tiers très utilisé, il n’est pas redémarré tout de suite afin d’enquêter sur le problème.

Le 25/04 :

  • 17h05 : L’installation du système est finalisée, mais un problème d’IPMI nous empêche d’y accéder après une demande de redémarrage.
  • 19h45 : Après avoir enchaîné les problèmes de redémarrage et un serveur à nouveau indisponible, la décision est prise de changer d’hébergeur plutôt que continuer avec un serveur plutôt vieux dont l’état matériel ne devrait pas aller en s’améliorant (et faute de trouver une offre équivalente au même endroit). Il se trouve qu’Ikoula avait à ce moment précis une promotion sur son serveur dédié Agile S qui offre la même configuration que celui qu’on avait chez Online, avec un CPU plus récent, la possibilité d’avoir un SSD, et un GPU inutile, pour 1€ de moins TTC.

Le 27/04 :

  • 22h10 : Prosody est à nouveau indisponible à cause d’un bug dans un module tiers. Le module est désactivé pour l’heure.

Du 26/04 au 08/05 : Mise en service progressive du serveur Ikoula, avec restauration des backups, tests, et amélioration de nos processus. Les services web sont les premiers à être remontés, avec un reverse-proxy depuis la machine temporaire. Nous y allons doucement car les jours précédents ont été un peu stressants.

Le 08/05 :

  • Le service est arrêté comme annoncé un peu après 22h, afin de garantir l’intégrité des données sur le nouveau serveur. Les enregistrements DNS sont mis à jour (on avait au préalable mis un TTL de 10 minutes).
  • 22h57 : Le service est lancé sur le nouveau serveur.
  • 23h01 : Le service est relancé avec les bons certificats 😀
  • 23h40 : Prosody est à nouveau en carafe à cause de module tiers, car nous avons oublié de les désactiver sur le nouveau serveur.
  • 23h42 : Le service est à nouveau disponible.

Détails de la nouvelle installation

Nous restons sous ArchLinux, qui est le système que nous savons le mieux administrer et qui nous apporte beaucoup de flexibilité.

En revanche, comme nous étions de toute façon partis pour faire une réinstallation complète dès le 22/04, nous avons décidé de mettre en place une configuration plus complexe mais qui sécurise plus les données de nos utilisateurs tout en nous facilitant la vie.

Après un certain temps passé dans des images de secours fournies par les opérateurs pas forcément aussi utiles qu’on le voudrait, on a également pris la décision de garder un système ArchLinux en clair de 5 Go, qui nous permet de démarrer dessus pendant les phases de maintenance longues, de monter les partitions du système principal voire de kexec dedans afin d’éviter un reboot et/ou des modifications du bootloader en série en cas de panne.

L’idée dès le départ a donc été de mettre en place un système chiffré via LUKS déverrouillable à travers SSH (nécessitant donc une clef SSH et la phrase de passe LUKS). Sous ArchLinux c’est plutôt simple à mettre en place à travers mkinitcpio-systemd-tool (nous comptons documenter un peu mieux la procédure pour pouvoir permettre à n’importe qui de faire de même).

À l’intérieur de ce volume LUKS chiffré, nous avons choisi une partition BTRFS, qui nous permet entre autre de gérer dynamiquement des subvolumes (partitions internes à la partitions, qui peuvent avoir des options différentes telles que de la compression à la volée, déduplication, etc), et qui permet des transferts de partitions incrémentaux sur le réseau plutôt sympathiques, par exemple « ssh serveur btrfs send | btrfs receive » (dd fonctionne aussi mais force à prendre tout l’espace alloué pour la partition, et ne permet pas de le faire en incrémental).

Le système de backups précédent utilisant duplicity était entre autres calibré pour les 100Go de backup FTP fournis par Online, ce qui n’est plus possible, il a fallu donc ré-évaluer nos possibilités. Pour le moment les backups sont donc effectués via borg, vers un espace mis à disposition sur un serveur de mathieui en attendant de prendre une décision, et englobent plus qu’auparavant (intégralité des données de prosody + configurations des logiciels dans /etc + données httpupload) pour un total d’une quarantaine de Go. Ils sont bien sûr chiffrés et la clef n’est pas présente sur le serveur distant.

Nous avons également mis en place etckeeper, plus pour garder une trace des changements (et ne pas les oublier lors de la prochaine réinstallation) que pour s’en servir comme point de restauration ou backup.

Conclusion

Cet incident nous aura permis de constater que la migration est plus simple qu’auparavant, mais qu’il nous faut un moyen de redondance rapide en cas de panne majeure du serveur principal. Les backups plus complets devraient être un bon pas dans cette direction, idéalement nous pourrions périodiquement faire un btrfs send/receive mais cela aurait un coût opérationnel trop important (payer un autre serveur en permanence en plus du principal).

Nous allons prendre le temps de faire des tests dans les semaines à venir pour voir si on peut faire repartir un service opérationnel à partir de ces backups en cas de grosse panne dans des délais raisonnables (en dessous de 2h si possible).

Pour les domaines utilisateurs

Les administrateurs de domaines « utilisateurs » (c’est à dire d’un service qui dont nous avons la gestion du service XMPP mais pas la main sur le DNS) sont invités à mettre à jour leur enregistrement DNS pour un CNAME qui pointe sur jabberfr.org, plutôt qu’un A qui pointerait sur une IP, ou un CNAME qui pointerait vers im/im2.apinc.org.

Sortie de Prosody 0.11

Ceci est la traduction de l’article Prosody 0.11.0 released, et est également disponible sur le blog de Prosody et sur LinuxFR.

Nous somme ravis d’annoncer la sortie longuement attendue de Prosody 0.11.0 !

Ceci est la première version de la série 0.11, qui sera maintenant considérée comme la série stable. Cette version, avec plus de 2000 commits, n’aurait pas pu se faire sans l’aide de nombreux contributeurs, testeurs, et autres membres de la communauté. Merci !

Continuer la lecture

Sortie de Prosody 0.9.0

Traduction de Prosody 0.9.0 released en français par Emmanuel Gil Peyrot.

Oui ! Prosody 0.9.0 est là !

Plus de 1500 commits ont été écrits par douze personnes depuis la version 0.8, et encore plus pour les bibliothèques tierces auxquelles nous avons contribué, comme LuaSocket, LuaSec et LuaEvent.

IPv6

IPv6 logo

Notre première fonctionnalité importante à annoncer est la prise en charge complète d’IPv6. Après la sortie de la 0.8, c’était de loin la fonctionnalité la plus demandée sur notre plate-forme de suivi. Un grand merci à Florian Zeitz, qui a travaillé sur la majeure partie de la prise en charge d’IPv6 à la fois dans Prosody et LuaSocket.

Pour plus d’informations sur la prise en charge d’IPv6 de Prosody, voir notre documentation.

Identifications entre serveurs par certificat

s2s security

Même si Prosody prend en charge le chiffrement SSL/TLS pour les connexions entre serveurs depuis longtemps, il n’était pas capable d’utiliser les certificats associés dans un but d’identification, se repliant à la place sur le plus traditionnel protocole dialback se basant sur le DNS.

Depuis Prosody 0.9, et avec une version appropriée de LuaSec, l’identification par certificat est automatiquement utilisée quand c’est possible. De plus, Prosody vous offre le contrôle complet sur la politique de sécurité pour la communication avec les domaines distants.

Un grand merci à Paul Aurich qui a réalisé une grande partie du travail pour rendre cela possible, aussi bien dans Prosody que dans LuaSec.

Plus d’informations sont disponibles dans notre documentation sur la sécurité entre serveurs.

Serveur HTTP

Prosody a un serveur HTTP intégré, qui était initialement conçu pour BOSH. Cependant, son usage s‘est progressivement élargi, notamment à l’hébergement des logs des salons, des indicateurs de statut, des APIs REST et une interface web.

Par conséquent dans la 0.9 nous avons beaucoup amélioré les entrailles de notre serveur HTTP et l’API qu’il expose aux modules. Il prend désormais en charge les hôtes virtuels, ce qui va permettre d’exposer les services plus simplement en environnement multi-hôtes.

Quelques options de configuration ont changé, donc si vous utilisiez BOSH avec une configuration personnalisée, ou n’importe quel autre module HTTP, n’oubliez pas de lire nos notes de version pour savoir comment mettre à jour en douceur vers la 0.9.

Les développeurs de modules peuvent avoir un aperçu de notre nouvelle API ici : API pour les modules HTTP de Prosody.

Pubsub

Fait qui intéressera tout particulièrement les développeurs d’applications XMPP, Prosody 0.9 dispose de base d’une implémentation de la XEP-0060, mod_pubsub. La XEP-0060 est une longue spécification, et nous ne la prenons pas encore entièrement en charge. Si une fonctionnalité particulière vous manque, faites-le nous savoir, nous allons continuer d’améliorer notre prise en charge de pubsub dans les prochaines versions.

Autres changements

Il y a eu d’autres changements, trop pour tous les lister ici. En voici quelques petits exemples :

  • la taille de l’historique d’un MUC (backlog) est configurable par salon ;
  • les modules peuvent désormais étendre dynamiquement le formulaire de configuration des MUCs ;
  • prosodyctl peut maintenant assister la génération des requêtes de signature de certificat (certificate signing requests, CSRs)
    et des certificats auto-signés ;
  • une autre nouvelle commande pour prosodyctl, « about » : affiche des informations sur une installation Prosody.

Téléchargement

Rendez-vous sur notre catégorie téléchargements, et n’oubliez pas de consulter nos notes de version si vous mettez à jour depuis une version antérieure.

Nous ne pouvons pas finir sans dire un grand merci à notre formidable communauté. Que vous ayez contribué au code, aidé à tester, rapporté un bug ou parlé de Prosody et XMPP à vos amis, vous avez contribué au succès de ce projet et de cette release.

Joyeux Jabberage,
l’équipe de Prosody

Publié le 20 août 2013 par l’équipe de Prosody
Traduit le 21 août 2013 par Emmanuel Gil Peyrot
Un grand merci également aux différents relecteurs de cette traduction.

Nouvelle version du serveur Tigase

Tigase est un serveur Jabber libre (licence GPL) écrit en Java qui supporte déjà une grande partie du protocole XMPP, malgré son âge relativement jeune (le projet a commencé en octobre 2004).

Il est sorti en version 2.8.3 qui apporte son lot de nouveautés :

  • Une intégration basique avec Yate, ce qui permet d’établir facilement des appels VoIP par Jingle en utilisant Yate.
  • Un composant nommé StanzaSender a été rajouté. Il permet d’envoyer facilement des paquets Jabber en les copiant dans un répertoire spécial. Cela peut être utilisé pour intégrer le serveur Jabber avec d’autres services.
  • Les utilisateurs de MS Windows peuvent utiliser un installateur graphique pour installer facilement le serveur.
  • Le parseur XML a été amélioré pour être plus conforme à la norme.
  • Le support des XEP 0049 (Private Storage) et 0199 (Ping) a été rajouté.
  • Plusieurs corrections de bugs

Liens :

Jabber et le Google Summer of Code 2007

Comme l’année dernière et l’année d’avant, Google sponsorise encore des étudiants travaillant sur des projets libres cet été à travers son Summer of Code. La XSF fait parti des organisations y participant, et plusieurs étudiants vont donc travailler sur des projets en relation avec Jabber cet été

Voici donc un petit aperçu des projets retenus :

  • Support de BOSH dans gloox : Gloox est une bibliothèque C++ pour développer des applications utilisant XMPP. BOSH (autrefois appelé http-binding) est un protocole permettant de se connecter à un serveur Jabber en passant par HTTP (donc permettant de contourner certains firewall et proxy).
  • Data Form Designer Suite for XMPP : Ce projet permettra de créer des formulaires Jabber graphiquement, et pourra servir par exemple à proposer facilement des sondages par Jabber.
  • Implémentation et suite de tests pour les Encrypted Sessions : Encrypted Sessions est une série de protocoles pour Jabber visant à fournir un chiffrage bout à bout des communications par Jabber. Ce projet établira des outils pour tester des implémentations de ces protocoles, et les implémentera dans Gajim.
  • Extended Stanza Addressing et d’autres XEP dans ejabberd : l’étudiant veut implémenter la XEP-0033 dans ejabberd. Ce protocole permet d’envoyer facilement un même message à plusieurs personnes, et réduit la bande passante utilisée pour émettre ce message. L’étudiant veut aussi implémenter les XEP 0133 (administration d’un serveur en utilisant des commandes ad-hoc), 0157 (spécifier les adresses des personnes à contacter pour les services XMPP) et 0203 (qui remplace la XEP 0091 pour signaler qu’un message a été délivré avec du retard).
  • Jingle Audio et Vidéo dans Gajim : implémentation de la visioconférence et de la voix sur IP en utilisant le protocole Jingle dans Gajim.

En plus des projets de la XSF, d’autres organisations ont des projets en relation avec Jabber :

Bien sûr, même sans participer au SoC, vous pouvez tout de même aider Jabber. La liste des idées pour le SoC est toujours disponible sur le wiki de Jabber.org.

Sources : Blog de stpeter, Blog de la XSF.

Les sorties de logiciels côté serveur

Voici une pile de news qui vont intéresser les administrateurs de services Jabber.

Wildfire, le serveur Jabber libre écrit en Java par Jive Software (également à l’origine du client libre Spark et de la bibliothèque libre Smack), est sorti en version 3.2.0 RC2 (liste des changements). Jive a également publié sa roadmap pour Wildfire et Spark : il y a du Jingle dans l’air au premier trimestre… Autre changement, Wildfire va changer de nom à cause d’une marque déposée par un éditeur de logiciel P2P.

Idavoll, le composant PubSub (XEP-0060 : Publish-Subscribe) libre écrit en Python, est sorti en version 0.6.0 et a changé de site web : http://idavoll.ik.nu/

JabberHTTPBind est un servlet Java implémentant HTTP Binding (XEP-0124), permettant le transport de XMPP au-dessus de HTTP en lieu et place de TCP, très utile pour traverser les NAT et firewalls. JabberHTTPBind est donc sorti en version 1.0 en novembre dernier et nécessite un conteneur comme Tomcat.

Process One, la société qui édite le serveur Jabber libre ejabberd, a annoncé une version de développement de Epeios, permettant de faire tourner un module ejabberd dans n’importe quel serveur utilisant le protocole de composants (XEP-0114). Sa roadmap à court terme : amélioration de l’empaquetage, des tutoriels et l’extension de la XEP-0114. D’autre part ejabberd 1.1.3 corrige une erreur de sécurité sur mod_roster_odbc.

En novembre dernier, Tigase, le serveur XMPP libre, est sorti en version 2.5.0. Cette version apporte une classe PacketFilter et des corrections de bugs mineurs.

Merci à Elghinn et Omega pour la relecture.