Le conseil d’administration de l’association a décidé de voter pour
engager le collectif des CHATONS dans la signature de la tribune.
L’extrême-droite porte un projet de société raciste et xénophobe, de rupture d’égalité et de mise au pas la société à tous les niveaux, qui s’oppose frontalement aux valeurs émancipatrices portées par le logiciel libre ainsi que les réseaux de communications fédérés.
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.
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 :
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.
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.
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 !
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.
Détails de la tenue
Présents
Ordre du jour
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
Nouvelles actions à définir
Renouvellement du bureau
Proposition de reconduite du bureau actuel, avec :
La proposition de bureau est votée à l’unanimité.
Présents
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 :
JabberFR a commencé l’année avec 229.49€ sur le compte en banque, et la termine avec 310,53€.
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.
Proposition de reconduite du bureau actuel, avec :
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é.
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.
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 :
Le 23/04 :
Le 24/04 :
Le 25/04 :
Le 27/04 :
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 :
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.
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).
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.
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.
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.
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 :
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.
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.