Archives de catégorie : JabberFR

Maintenance du 28 octobre 2023

Publié le par
Répondre

Le 28 octobre entre 11h et 13h environ (voir le statut pour les détails) nous avons procédé à une maintenance sur le serveur principal de JabberFR, ainsi que sur notre serveur de statistiques.

Côté XMPP

Le but premier de cette maintenance était de mettre à niveau prosody pour résoudre les problèmes rencontrés depuis la dernière fois, qui rendaient la vie des utilisateurs assez désagréable :

  • La désactivation de FAST pour l’authentification, qui a engendré un nombre incalculable d’erreurs affichées par notamment Conversations, qui avertissait d’un faux problème de sécurité, demandant à confirmer périodiquement des choses dans un sous-menu très peu facilement trouvable.
  • La désactivation de smacks (XEP-0198) qui fait que les déconnexions/reconnexions étaient plus coûteuses en batterie et moins « transparentes » pour les clients mobiles.

Ces deux objectifs ont, à priori, été atteints.

Nous avons également purgé l’historique des messages de notre service Biboumi, qui se comptaient dans les dizaines de millions, ce qui n’aidait pas les performances de ce service.

Côté système

Nous en avons aussi bien sûr profité pour faire une mise à jour complète du système, incluant le passage de Linux LTS 5.15 à 6.1, dans l’espoir qu’il corrige l’utilisation mémoire perdue à jamais (ici après 338 jours d’uptime, notre serveur arrivait au bout de sa mémoire disponible, car il ne dispose que de 8 Gio et plus de 3 étaient alloués et non libérables dans le noyau !).

Sans incidence sur les utilisateurs, nous avons également mis à jour la machine de statistiques.

HTTP Upload

Enfin, nous sommes passés au nouveau composant Prosody pour la gestion des envois de fichiers par les utilisateurs, http_file_share plutôt que l’ancien http_upload. Le nouveau module nous permet de tracer quels fichiers ont été envoyés par quel utilisateur, de gérer des quotas, des permissions, ainsi que l’expiration des fichiers.

Le nouveau module garantit donc un quota de 200 Mio par utilisateur et par jour (précédemment illimité), avec des envois limités à 100 Mio (contre 10 précédemment). De plus, les fichiers seront supprimés après deux semaines.

Les fichiers envoyés sur le précédent composant sont toujours accessibles, mais le dossier sera supprimé dans deux semaines, pensez-y si vous avez des fichiers que vous comptez préserver !

Enregistrements CAA

Suite à la découverte d’une attaque MitM (“Machine in the Middle”) sur le serveur jabber.ru, probablement réalisée à la demande d’agences gouvernementales ou de la justice sur leurs divers hébergeurs, nous avons mis en place des enregistrements CAA pour garantir que seul notre compte auprès de Let’s Encrypt a le droit de demander des certificats pour notre domaine.

JabberFR proposait déjà la variante « -PLUS » sur les différents mode d’authentification SCRAM, qui permet d’avoir du « Channel Binding » qui permet de garantir que la connexion est bien faite directement au serveur, et pas à un attaquant qui se placerait entre les deux, même avec un certificat valide.

Nous allons de plus ajouter prochainement des enregistrement TLSA (DANE) afin d’avoir un point de validation supplémentaire pour les clients qui l’implémentent.

Enfin, nous publions déjà depuis longtemps nos certificats actuels sur la page Certificats du site, mais un attaquant avec des certificats valides pourrait facilement la trafiquer au passage, elle n’est donc pas suffisante contre ce genre d’attaques.

Compte-rendu de l’AG de JabberFR du 2022-12-22

Publié le par
Répondre

Détails de la tenue

  • Date : 2022-12-22
  • Heure de début : 19h42
  • Heure de fin : 20h43
  • Président de séance : erwanb
  • Secrétaire de séance : mathieui

Présents

  • mathieui : Secrétaire
  • Nicosss : Administrateur
  • erwanb : Trésorier
  • Link Mauve : Président
  • Nawyel : Membre
  • pep. : Membre (peut-être pas à jour de cotisation)

Ordre du jour

  • Bilan d’activité
  • Point sur les adhésions et cotisations
  • Nouvelles actions à définir

Bilan d’activité (mathieui & Link Mauve)

Maintenance (mathieui)

Depuis la dernière AG, nous avons eu 4 maintenances planifiées et 5 incidents, ce qui donne dans l’ordre chronologique :

Les inscriptions via le web sont également indisponibles depuis plusieurs mois. On remarque qu’il y a eu peu d’incidents en 2022.

Activités (Link Mauve)

Avec la levée des restrictions liées au covid (mais toujours avec un FFP2), notre activité d’information et de rencontre des utilisateurs lors des évènements du libre a pu reprendre. Link Mauve s’est rendu à Lyon pour les Journées du Logiciel Libre (JDLL) en avril dernier, puis à Toulouse au Capitole du Libre (CdL) en novembre avec pep. Ils y ont tenu un stand où ils ont parlé de XMPP, de JabberFR, de Snikket, ainsi que de tout autre sujet en lien avec ce par quoi leurs interlocuteurs étaient intéressés. Ils ont tous deux effectués le voyage sur leurs fonds propres, mais avec les adhésions et dons nous espérons pouvoir imprimer davantage de flyers et autres stickers lors des prochains évènements. Le retour des visiteurs a été majoritairement enthousiaste, en particulier autour de Snikket et de la simplification de l’embarquement des utilisateurs qui en découle. Link Mauve y a également suivi un atelier d’étude du design du site web, afin de le rendre plus attractif et d’attirer l’attention des visiteurs sur les points importants, une refonte de la page d’accueil est en cours de réalisation !

Adhésions et bilan financier (erwanb)

L’association compte désormais 35 membres, dont ~40% à jour de cotisation (chiffre exact disponible dans quelques jours selon les aléas de la banque postale). Erwanb est toujours en train de s’occuper des démarches auprès de La Banque Postale pour passer à une formule moins chère et avec accès au compte en ligne.

On peut remarquer que les adhésions sont généralement supérieures au montant minimum. Toutefois, on est toujours un peu ric-rac ; encore une fois cette année notre seule dépense est le paiement du serveur et les frais de compte, mais on s’est retrouvé à quelque chose comme 10€ sur le compte au début de l’automne. Si la page d’accueil est effectivement en refonte, peut-être qu’il serait bien de plus mettre en avant les liens vers HelloAsso pour rendre l’adhésion/la donation plus simple (plutôt que de se cantonner à la page d’adhésion).

Au premier décembre, le solde du compte était de 14.98€ (avant relance et appels à cotisation).

Questions

  • Nicosss demande si on a les proportions de recette entre HelloAsso et virements
    • erwanb répond qu’en 2022 sauf erreur cela revient à 40€ et 165€
  • pep. propose de rendre l’hébergement de domaine tiers payant (ou contre adhésion)
  • Retours positifs (soit payant soit fortement incité à adhérer, erwanb note aussi que ça donne un vote dans le fonctionnement de l’association)

Nouvelles actions à définir

  • La refonte du site web mentionnée plus haut (navigation plus intuitive, guider mieux les utilisateurs)
  • Augmentation de la taille maximale des fichiers uploadés depuis les clients, ce qui nécessite des changements non-triviaux sur le serveur pour tenir la charge
  • Amélioration de l’interface des domaines hébergés, pour permettre aux gens qui hébergent leur service XMPP chez nous de gérer leurs utilisateurs (c’était déjà dans les actions futures de la précédente AG)
  • Suite aux retours de visiteurs d’évènements, l’intégration des avancées de Snikket pour faciliter l’onboarding de nouveaux utilisateurs (comme les invitations)
  • La présentation des finances de l’asso sur le site, comme déjà noté l’année précédente, mais on dépend ici des procédures de changement de formule à La Banque Postale déjà évoquées plus haut
  • Ouvrir un compte Mastodon « officiel » (quelqu’un avait créé un bot avec notre permission il y a plusieurs années, mamot.fr/@jabberfrbot, mais nous n’avons pas les accès)
  • Mise en place d’une courte réunion publique (informelle) mensuelle pour pouvoir faire des points d’étapes sur les différentes actions mises en place ou justement leur non mise en place
  • Trouver une solution de rechange pour les backups, qui sont actuellement chez mathieui qui n’a plus beaucoup de place

Renouvellement du bureau

Proposition de reconduite du bureau actuel, avec :

  • Link Mauve en tant que président
  • mathieui en tant que secrétaire
  • erwanb en tant que trésorier

La proposition de bureau est votée à l’unanimité.

Compte-rendu de l’AG de JabberFR du 2021-01-13

Publié le par
Répondre

Détails de la tenue

  • Date : 2021-01-13
  • Heure de début : 19h30
  • Heure de fin : 20h42
  • Président de séance : erwanb
  • Secrétaire de séance : mathieui

Présents

  • Nombre de membres présents : 8
  • mathieui : Secrétaire
  • erwanb : Trésorier
  • Link Mauve : Président
  • Simon : Administrateur
  • Nicoss : Membre
  • Pitchum : Membre
  • Nawyel : Membre
  • Arnaud J. : Membre

Ordre du jour

  • Bilan d’activité pour 2020
  • Bilan financier
  • Nouvelles actions et projets à définir
  • Renouvellement du bureau

Bilan d’activité (mathieui)

Serveur

Un gros incident : https://news.jabberfr.org/2020/05/compte-rendu-dincident-du-22-04-2020-et-suivants/

5 incidents mineurs :

Et 2 maintenances planifiées :

Wiki

  • Réouverture des inscriptions
  • Amélioration significative des performances
  • Purge du spam
  • Gros travail de réécriture de pages et de modernisation principalement par anubis, Nicoss et elghinn

Site Web

  • Travail sur l’accessibilité (via l’outil WAVE notamment), ainsi que l’adaptativité aux mobiles
  • Thème sombre (avec détection automatique)
  • Ajout de la page de demande d’hébergement qui nous notifie des demandes
    Associé au dernier élément, la réouverture publique des hébergements de domaine. Pour rappel, ce service offert par JabberFR permet de nous déléguer l’hébergement d’un domaine XMPP (sous la forme d’un virtualhost sur le serveur JabberFR).

Autres

  • Mise à jour des CGU pour plus de transparence sur les sauvegardes : https://wiki.jabberfr.org/CGU
  • Mise en place d’un serveur TURN/STUN et sa configuration dans Prosody pour permettre aux clients qui l’implémentent de passer des appels audio ou vidéo.
  • Lutte encore et toujours contre le spam.

Questions sur le bilan d’activité

  • Naywel demande si meet.jabberfr.org fonctionne à nouveau
    • Réponse: Non, mais c’est prévu de le remettre sur pieds
    • Link Mauve précise également qu’on peut désormais faire du chat audio/vidéo à deux avec les clients compatibles sans passer par Jitsi Meet
  • Manu demande s’il y a des statistiques disponibles sur les comptes actifs, salons, etc

Bilan financier (erwanb)

JabberFR a commencé l’année avec 229.49€ sur le compte en banque, et la termine avec 310,53€.

Objectifs précédents (pour 2020)

  • L’association règle désormais les frais d’hébergement du serveur (18€/mois) par prélèvement SEPA, alors qu’auparavant c’était réglé par mathieui
  • Cela crée donc une problématique qui est de sortir 18€ tous les mois, ce qui actuellement n’est pas possible sur le long terme (un an représente les 2/3 de ce qu’on a en banque), on a donc pensé à des façon de simplifier la collecte de dons et de cotisations.
  • Nous avons donc créé un compte sur HelloAsso, qui va permettre d’adhérer et de donner très simplement via les formulaires suivants :

HelloAsso ne nous coûte rien, et repose sur une donation « volontaire » des gens qui nous envoient de l’argent. Et en plus de la simplicité (ajout de bénéficiaire dans sa banque, récupération du rib), il nous permet surtout d’accepter les adhésions & donations par carte bancaire.

On peut et on pourra toujours adhérer ou donner sans passer par ce service bien entendu, mais on espère que ça facilitera les différentes démarches qui sont actuellement fastidieuses, et ainsi augmenter le nombre et le montant des cotisations.

Il nous faudra un minimum de 216€ tous les ans sur le compte, uniquement pour le serveur; pour information, les cotisations reçues en 2020 s’élèvent à 177€, ce qui est presque suffisant.

Les problèmes liés au COVID pourraient revenir à la normale à un moment, et on va donc pouvoir à nouveau participer à des évènements, salons ou encore imprimer des goodies/stickers/flyers ou n’importe quoi d’autre. Cela nécessitera d’une plus de ressources financières, mais également un moyen d’accéder facilement à l’argent de l’association (le compte bancaire ne nous permet pas d’autres moyens de paiement que le chèque ou le prélèvement SEPA). Dans cette optique, un compte Paypal a été ouvert.

Les ressources financières et le nombre d’adhérents sont en hausse par rapport à l’année dernière, et nous avons démultiplié nos façons de recevoir et de dépenser de l’argent, ce qui devrait simplifier la suite.

Questions

  • Pulkomandy demande si on envisage un compte Liberapay
    • erwanb et mathieui sont pour
  • Nicoss suggère de faire apparaître les nouveaux moyens de contribution sur la page d’accueil du site
    • erwanb répond que c’est prévu
  • manu demande si le bilan financier pouvait être mis en ligne et pas seulement dans les AG, pour plus de transparence
  • pitchum suggère de faire peut-être une « jauge des finances », Pulkomandy également en citant le cas de Haiku
    • mathieui répond que c’est prévu, mais que jusqu’à maintenant le bilan était surtout « adhésions – frais de tenue de compte ». Un bilan ne peut par contre être fait que mensuellement car c’est la seule vue que nous avons sur les comptes.
    • erwanb est d’accord pour dire que c’est une bonne idée et qu’on va s’y atteler

Nouvelles actions et projets à définir (Link Mauve)

Présentation des projets en cours

  • Améliorer l’accès au service d’hébergement de domaines. Le problème principal est l’absence de visibilité et de contrôle que le propriétaire du domaine peut avoir dessus. On pense notamment à ouvrir/fermer les inscriptions, pouvoir inviter des gens, etc. Depuis quelques temps on travaille sur xmpp-account-manager, un gestionnaire de compte par et pour XMPP qui permet d’aider un domaine (https://linkmauve.fr/xmpp-account-manager/build/fr/ pour une démo).
  • On voudrait aussi améliorer le mécanisme de création de compte web, en utilisant le système conçu par le projet Snikket.
  • Rétablir notre instance Jitsi Meet
  • Demande d’aide si quelqu’un veut écrire un système d’identification OAuth pour le wiki pour laisser les gens utiliser leur JID pour l’éditer
  • Améliorer l’utilisabilité du site (et donc trouver des designers ou testeurs)

Questions

  • Pulkomandy demande si les appels à contribution sont visibles sur le site car l’AG n’est pas forcément le meilleur moyen de communication
    • Link Mauve indique que ça fait un peu partie de la discussion mais note la suggestion
  • Arnaud J. demande si le site est statique
    • Link Mauve répond avec l’adresse du dépôt git (qui n’est pas tout à fait à jour)
  • pitchum demande si on a envisagé de passer un appel à l’aide (par exemple sur Twitter) pour trouver des designers
    • mathieui et Link Mauve indiquent qu’il faut surtout des gens spécialisés en UX
  • discussion sur les frameworks pour l’organisation du contenu

Renouvellement du Bureau

Proposition de reconduite du bureau actuel, avec :

  • Link Mauve en tant que président
  • mathieui en tant que secrétaire
  • erwanb en tant que trésorier

La proposition de bureau est votée à l’unanimité.

Un appel à administrateurs est passé de nouveau, pour venir s’ajouter à Simon.

Nicoss accepte la proposition, et est élu à l’unanimité.

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

Publié le par
3

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.

Adhésion de JabberFR à CHATONS

Publié le par
1

L’association JabberFR fait maintenant partie du Collectif des Hébergeurs Alternatifs, Transparents, Ouverts, Neutres et Solidaires. Nous arrivons donc avec la portée numéro quatre.

Cette adhésion est une suite logique de la démarche que JabberFR a toujours défendu : fournir un service Jabber de référence tout en accompagnant toutes les démarches indépendantes de création de serveurs et de communautés auto-hébergées.

N’hésitez pas à vous lancer, et rejoignez-nous sur le salon jabberfr@chat.jabberfr.org.

Ouverture d’un service de statut

Publié le par
2

Bonjour à toutes et à tous.

JabberFR se dote d’un outil de gestion de statut afin de pouvoir avoir en un coup d’œil l’état des services ainsi que les maintenances prévues.

Nous utilisons pour cela une instance de Cachet hébergé avec l’offre gratuite chez Alwaysdata, afin que le service soit disponible même si nous avons de grosses difficultés sur le serveur principal (ce qui est, quand même, un des objectifs).

Les données sont tout de même rentrées à la main, donc les mises à jour mettront le temps que nous nous rendions compte du problème, ou qu’un utilisateur nous le signale.

Nous n’abandonnerons bien sûr pas le blog pour les annonces de maintenance ou compte-rendus d’incidents, mais le nouveau service permet d’accéder aux informations importantes plus rapidement.

Le service est disponible sur statut.jabberfr.org, n’hésitez pas à vous abonner au flux RSS.

Maintenance du jeudi 13 juillet 23h50

Publié le par
1

Bonjour à toutes et à tous !

Le serveur sera redémarré brièvement ce jeudi 13 juillet à 23h50 afin d’opérer quelques ajustements découlant de l’incident du 19 juin, ainsi qu’une mise à jour de sécurité.

L’opération devrait être assez rapide, et nous tiendrons comme d’habitude ce billet à jour.

Mise à jour :

  • 23h50 : début de la maintenance
  • 23h58 : retour du serveur en ligne
  • 00h02 : constatation de problèmes techniques causant des erreurs aléatoires
  • 00h16 : redémarrage de prosody, retour à la normale

Incident du lundi 19 juin

Publié le par
1

Vers 17h15, on me signale que le service ne répond plus. Après une rapide investigation je me rends compte que Prosody, notre serveur XMPP, est en train de prendre 100% du CPU et ne log plus rien, ne répond plus sur aucun port, et ne fait rien d’utile du tout d’après strace. C’est le même symptôme que lors de l’interruption de source inconnue dans la nuit du jeudi 8 juin pour laquelle j’avais simplement relancé Prosody.

Je décide alors de prendre du temps pour analyser la situation en compagnie de Zash sur le salon d’aide de Prosody, mais je ne parviens pas à déterminer la cause du problème et restaure donc les services, qui reprennent leur cours normal à 18h51.

J’en ai profité au passage pour mettre à jour Prosody et le passer à lua5.2, pour bénéficier des dernières améliorations.

Édition le 22 juin : certains modules avaient disparus de la configuration, notamment Carbons et HTTP Upload, ils viennent d’être remis.

Chiffrement total des services à partir du 26 juin 2017

Publié le par
Répondre

Depuis 2005, Google fournissait un service de chat appelé Google Talk, reposant sur XMPP, notamment intégré à Gmail. Leur abandon progressif de ce service à partir de 2013 a rendu la fédération de plus en plus difficile pour les utilisateurs d’autres serveurs.

Les utilisateurs de Google Talk ayant migré vers leur nouveau service non-fédéré restent dans votre liste de contacts, mais apparaissent tout le temps connectés, absents, ne reçoivent pas vos messages, et ne vous voient même plus dans leur liste de contacts. La seule solution pour eux de continuer à communiquer avec vous était d’utiliser un autre client XMPP, mais la plupart de leurs utilisateurs ne sont pas conscients de ce choix.

Un autre problème est que ce service n’a jamais pris en charge le chiffrement des communications avec les autres serveurs, tous les échanges que vous avez eus avec des contacts Google Talk ont été transmis en clair sur Internet !

Le mois dernier, Google a annoncé mettre fin définitivement à Google Talk le 26 juin, nous profiterons de cette occasion pour forcer toutes les communications vers d’autres serveurs à être chiffrées. Pendant les deux prochains mois, nous vous conseillons de conseiller à vos contacts de migrer vers un serveur respectueux de leur vie privée.

Cette nouvelle mesure vous permettra donc de communiquer de façon plus sûre, sans que vous n’ayez à vous préoccuper par vous-mêmes du niveau de chiffrement de chacun des serveurs utilisés par vos contacts.

Édition du 26 juin : c’est chose faite, toutes les communications avec les serveurs externes sont désormais chiffrées ! Si l’un de vos contacts utilise encore l’un de ces serveurs non-sûrs, c’est le moment de lui conseiller de migrer vers un autre serveur, respectueux de sa vie privée.

Incident dans l’après-midi du mardi 25 avril

Publié le par
Répondre

À 17h50, je constate des irrégularités dans les performances du serveur, sur lequel je me connecte immédiatement pour voir que les IO sont très hautes, et que Prosody utilise énormément de mémoire. Je m’empresse donc de consulter les logs et constate qu’ils sont écrits très lentement.

Je décide donc d’arrêter tous les services auxiliaires, afin de libérer suffisamment de mémoire pour pouvoir analyser comment Prosody utilisait sa mémoire à ce moment là, et éviter que ça se reproduise.

À 18h37 j’ai enfin un dump de la mémoire, je mets à jour la distribution ainsi que Prosody lui-même, et entame un reboot de la machine.

À 18h50, tous les services sont de nouveau opérationnels.

Merci de votre patience et à bientôt !