Renouveau de JabberFR

JabberFR est une association née en 2012 à partir de la structure officieuse existant depuis environ 2003 sous le même nom, qui a avec le temps fusionné avec les services fournis par (feu) l’APINC. JabberFR était plus une fédération de services qu’un simple serveur, avec pour but affiché de rendre la vie plus facile aux utilisateurs francophones de Jabber, via des services mis en commun et exposés de la même façon sur chaque serveur de la fédération :

• l’annuaire des utilisateurs (JUD), pour faciliter la découverte de contacts ;
• le serveur de discussions chat.jabberfr.org ;
• la passerelle IRC irc.jabberfr.org, pour faciliter la transition ;
• un serveur mandataire SOCKS (XEP-0065) pour assurer un transfert de fichiers efficace.

Les buts affichés de l’association sont :

• mettre à disposition (enfin, continuer la mise à disposition) des services de messagerie instantanée libres à travers les serveurs gérés par l’association, tels que jabber.fr, chat.jabberfr.org, ou im.apinc.org ;
• promouvoir les applications et services qui y sont liés, notamment grâce au wiki, ou par la présence de membres à des évènements grand public ;
• améliorer l’existant en développant des logiciels ou composants lorsque le besoin est ressenti.

Sommaire

• Fermeture de l’APINC et migration des services
  • Évolutions
  • Détails techniques de la migration
  • Hébergement
• Rétrospective sur l’année passée
• Évolutions à venir
  • Finalisation de la réécriture d’Omnipresence
  • Réouverture et nettoyage des domaines personnalisés
  • Réouverture des inscriptions aux services Web
  • Recherche de volontaires pour moderniser le site Web
  • Recherche de volontaires pour la mise à jour du wiki
  • Spécifications pour les clients et serveurs
  • Clients Web complets accessibles sur le site
• En bref

Fermeture de l’APINC et migration des services

Évolutions

Les serveurs Jabber étant hébergés historiquement et à titre gracieux chez l’APINC, qui a annoncé la fin de l’association en avril dernier, il a fallu déménager les services vers de nouveaux horizons afin de garantir la continuité du service après l’arrêt planifié des machines courant juillet.

La migration et le passage d’une ancienne version d’Ejabberd à la dernière version de Prosody (la future version stable, actuellement en période de gel des fonctionnalités) permet, tout d’abord, de ne pas avoir à couper quoi que ce soit en cas de changement de certificat, ce qui est une obligation quand on utilise Let’s Encrypt, en raison de la fréquence des renouvellements.

De plus, il permet également de se débarrasser du composant pour salons [MU-Conference],(http://gna.org/projects/mu-conference) qui n’est plus maintenu depuis des années, au profit du module intégrable dans Prosody, auquel a été ajouté, par exemple, la gestion des archives ou un pastebin, dès qu’un message dépasse une certaine taille.

De la même façon, le service de salons accessible par navigateur sur chat.jabberfr.org est passé de MUCkl, qui n’est plus maintenu, à Candy. Il utilise maintenant un serveur anonyme au lieu d’un compte unique dont les identifiants étaient en clair dans les sources JavaScript. Ce serveur anonyme, en conjonction avec mod_muc_banip_ permettra une modération plus aisée et fine des utilisateurs anonymes qui abuseraient du service, là où l’on devait auparavant bannir toute personne passant par l’interface Web pour être débarrassé d’une seule.

L'ancienne passerelle IRC a été remplacée par biboumi, qui est activement maintenu, simple à utiliser, et performant.

Les utilisateurs auront également droit aux « nouveautés » (comprendre post‐2008) du protocole telles que :

• Stream Management (XEP-0198), qui permet de savoir si l’on a bien reçu tous les messages du serveur et vice versa, ainsi que de restaurer une session qui s’est terminée de façon impromptue (pour des problèmes de réseau, par exemple) ;
• Message Carbons (XEP-0280), qui fait que le serveur duplique les messages émis ou reçus aux différents clients connectés qui prennent en charge l’extension, garantissant une transition totalement transparente d’un appareil à un autre ;
• Message Archive Management (XEP-0313), qui est la spécification de référence pour les archives de messages XMPP côté serveur, et qui succède à Message Archiving (XEP-0136), bien que n’étant pas encore totalement stabilisée ;
• Client State Indication (XEP-0352), qui permet à un client de signaler son état d’inactivité au serveur, auquel cas le serveur aura l’autorisation de filtrer un certain nombre d’éléments non essentiels quand le client est inactif, diminuant ainsi la bande passante utilisée et améliorant l’autonomie d’autant ;
• XMPP Subprotocol for WebSocket (RFC 7395), qui vient rejoindre XMPP over BOSH (XEP-0206) pour fournir aux clients Web un moyen de se connecter directement au serveur, cette fois‐ci en collant mieux au fonctionnement par TCP classique, tout en permettant de contourner le blocage mis en place sur certains réseaux ;
• Blocking Command (XEP-0191), qui vient remplacer Privacy Lists (XEP-0016) pour le filtrage des communications indésirables, d’une façon beaucoup plus simple à implémenter pour les clients et beaucoup plus efficace côté serveur ;
• HTTP Upload (XEP-0363), pour permettre aux utilisateurs d’envoyer de petits fichiers sur le serveur, certains clients comme Conversations ou Gajim l’utilisent pour envoyer des images à l’intérieur des messages ;
• Push Notifications (XEP-0357), pour les clients mobiles tournant sur un système d’exploitation restrictif quant aux connexions restant ouvertes (iOS, Windows Phone, Android 6+), permet de notifier au serveur du fabricant que le client a reçu un message, qui le transférera à ce dernier pour le réveiller. Il est à noter qu’à aucun moment les serveurs du développeur de l’application, ni ceux d’Apple, Google ou Microsoft n’ont accès au contenu ni à l’expéditeur du message : uniquement « tel téléphone a reçu un message ».

La plupart des clients mobiles (tels que Conversations ou Yaxim) savent tirer parti de ces extensions pour réduire la consommation de batterie, la bande passante utilisée et fournir une meilleure expérience à l’utilisateur. Des clients de bureau tels que Gajim ou poezio peuvent également en bénéficier, par exemple en cas de connexion instable.

Détails techniques de la migration

Le passage à Prosody ne s’est pas fait sans accroc, à commencer par le script de migration fourni par Prosody qui a des difficultés sur les bases de données de taille supérieure à ce qui est habituel. Il a donc fallu développer des modules Prosody dédiés (depuis Ejabberd et depuis Mu-Conference), afin de réaliser la migration sans tomber à court de mémoire.

Un certain nombre de services s’appuyaient sur des technologies obsolètes voire franchement périmées, telles que Ruby 1.8. Un des effets néfastes est qu’il est impossible de mettre à jour les bibliothèques pour éviter les problèmes de sécurité, puisqu’elles ont évolué avec le langage et ses ruptures de compatibilité. Cette dette technique est bien sûr due au fait que les projets sont uniquement en mode « maintenance » une fois leur but atteint, et Debian oldstable permettait de retarder le compte à rebours des modifications majeures à effectuer.

De la même façon, les morceaux de services écrits en PHP laissaient des warnings indésirables dans les journaux système et utilisaient directement l’interface PHP MySQL, qui n’existe plus depuis PHP 7, au lieu de passer par le plus moderne PDO. Il a donc fallu procéder à une légère mise à niveau. Une partie des services en PHP n’est d’ailleurs toujours pas accessible, car leurs données étaient hébergées sur un autre serveur MySQL que celui qui a été l’objet de sauvegardes (et la connexion n’étant réalisée que dans le fichier .php du service, le problème n’a été détecté que tardivement).

La migration a été l’occasion de mettre en œuvre une certaine automatisation des services et d’avancer sur l’empaquetage de ces derniers, les serveurs de l’association étant restés assez statiques pendant de nombreuses années. Cela permettra, si le besoin apparaît, de migrer à nouveau, en ayant simplement à restaurer les bases de données et en réinstallant les paquets de services et en les reconfigurant, sans avoir de surprises.

Hébergement

Le serveur est actuellement un dédié chez online.net (DC3) fourni par mathieui et administré par Link Mauve. Côté technique, il est équipé d’un processeur Xeon E3-1220, 8 Gio de mémoire vive, 2 × 1 Tio de disque et d’une connexion gigabit, ce qui devrait être plus que suffisant pour tous les services que fournit JabberFR.

Rétrospective sur l’année passée

Bien que le serveur ait subi assez peu de perturbations durant l’année passée (principalement une interruption des composants), nous tenons à présenter nos excuses pour le manque de réactivité quant à la mise à jour du certificat de jabber.fr et des domaines associés, qui a été victime de la procrastination ainsi que des problèmes de dépendances en chaîne (passage à Let’s Encrypt → vieil Ejabberd → impossible de recharger un certificat → volonté de passer à Prosody → bloqué par la version de Debian → bloqué par des problèmes techniques → etc.). Cela faisait un certain temps qu’un certificat valide avait été généré pour jabber.fr, mais devoir recharger à la main Ejabberd tous les deux mois n’était pas une alternative raisonnable.

Évolutions à venir

Finalisation de la réécriture d’Omnipresence

Omnipresence, le service disponible sur presence.jabberfr.org qui permet d’afficher son état, son statut ou son avatar XMPP sur le Web fait partie des services en Ruby 1.8, MySQL et PHP qui ont été cassés par la migration. Il est donc maintenant réécrit en Python 3.5, mais toutes les fonctionnalités ne sont pas encore rétablies et la base de données est encore une exportation vers une base temporaire SQLite.

Réouverture et nettoyage des domaines personnalisés

JabberFR propose depuis longtemps d’héberger un serveur Jabber aux gens qui n’ont pas le temps ou l’envie de le faire eux‐mêmes. Cela se traduit techniquement par un enregistrement DNS sur le domaine pointant vers jabber.fr, et un hôte virtuel rajouté dans la configuration de notre serveur. Une bonne partie des domaines ajoutés depuis l’ouverture du service soit n’existe plus, soit pointe ailleurs, ce qui n’intéresse personne. Nous allons donc vérifier au cas par cas quels domaines fonctionnent encore, notifier le propriétaire, si possible, dans le cas contraire, et les enlever de notre configuration s’ils ne sont plus intéressés. Les outils d’inscription automatisée ne sont pas encore remis en route, mais vous pouvez d’ores et déjà nous contacter si vous avez envie de mettre en place ce service pour votre domaine. Nous vous encourageons, bien sûr, à vous auto‐héberger si vous en avez les capacités, et vous fournissons notre aide et ressources dans ce but.

Réouverture des inscriptions aux services Web

Les inscriptions au wiki et au forum étaient fermées depuis un moment. Un des objectifs est de mettre en place le composant pour la XEP-0070 de Chteufleur, afin de fournir une validation via XMPP des comptes utilisateurs. Le greffon MediaWiki nécessaire est en cours d’élaboration.

Recherche de volontaires pour moderniser le site Web

Comme exposé plus haut, JabberFR a tout un héritage de services, notamment Web, qui lui permettent d’être une vitrine pour les fonctionnalités offertes par XMPP. Cependant, il y a des éléments dont l’âge se fait sentir, tels que le design du site Web ou des choses moins visibles comme le code derrière. Il n’est, bien sûr, pas question de devenir un site flashy réclamant du JavaScript pour tout avec des animations dans tous les sens (ce serait mal nous connaître), mais JabberFR est quand même à la recherche de volontaires pour donner un coup de fraîcheur visuelle et technologique pour son site.

Recherche de volontaires pour la mise à jour du wiki

Le wiki de JabberFR est une ressource très complète sur les différents clients, serveurs et autres entités de l’écosystème XMPP. Malheureusement, le contributeur principal du wiki nous a quittés pour de nouveaux horizons il y a quelques années, et la fermeture des inscriptions pour cause de pourriel n’a pas aidé (ce qui est en passe d’être résolu, voir plus haut). JabberFR est donc à la recherche de volontaires pour défricher un peu le contenu du wiki et remettre les fiches d’information au goût du jour.

Spécifications pour les clients et serveurs

Afin d’éviter un travail quasi‐quotidien de maintien du wiki, une spécification pour les clients, serveurs et autres logiciels XMPP est à l’étude, pour pouvoir tirer les informations directement depuis les projets concernés. Tout progrès accompli dans ce sens sera bien évidemment proposé à la XSF, afin de ne pas disperser les efforts.

Clients Web complets accessibles sur le site

Un sujet qui nous tient à cœur est bien évidemment l’accessibilité d’XMPP et, comme ces dernières années ont vu l’arrivée d’un nombre de clients XMPP Web de qualité tels que Salut à Toi, Libervia ou Movim, nous souhaiterions en mettre à disposition directement via le portail JabberFR, afin qu’installer un client lourd ou faire confiance à une tierce partie ne soit pas un prérequis.

En bref

Ce déménagement aura été l’occasion de dépoussiérer nos services de fond en comble, mais ce n’est que le début ! Les prochaines étapes sont les plus importantes, pour améliorer l’ergonomie du site, pour fournir des services que les gens attendent, pour faciliter au maximum la venue d’un nouvel utilisateur et bien plus encore. Nous comptons également rouvrir les adhésions à l’association, afin de subventionner le serveur et pour venir aux différents événements du Libre ; et nous comptons sur vous pour nous y aider !

Aller plus loin

• JabberFR (524 clics)
• Dépôts Git des projets de JabberFR (128 clics)
• Wiki JabberFR (121 clics)
• Ancien site de l’APINC (136 clics)