Même souci qu’il y a 3 semaines, la coupure a eu lieu dimanche 26/05/2024, de 0h30 à 10h20 (10h de coupure).
Nous sommes désolés pour la gêne occasionnée.
Même souci qu’il y a 3 semaines, la coupure a eu lieu dimanche 26/05/2024, de 0h30 à 10h20 (10h de coupure).
Nous sommes désolés pour la gêne occasionnée.
Hello hello,
Le 14 mai, Nous avons eu un souci avec des répondeurs automatiques qui ont décidé de taper la conversation à des adresses inexistantes, le tout en boucle et échangeant des centaines de messages par heure) ; bavards les robots 🤖.
Ce souci de configuration a déclenché un bannissement temporaire de notre serveur car il envoyait trop de mails. Ce bannissement a été réalisé par un de nos serveurs « relai ». Cela a bloqué l’envoi des mails entre 18h et minuit ce jour là.
Lorsque le souci nous a été remonté, nous avons supprimé le bannissement et envoyé ~300 mails qui étaient retenus. Vous pouvez avoir reçu un message d’erreur, si celui-ci indique que le mail a été rejeté, vous pouvez ré-envoyer votre message.
Nous sommes désolés pour le désagrément.
Version courte : suite à un problème d’espace disque sur un de nos serveurs (mutu2 qu’on l’appelle), la plupart des espaces Nextcloud que nous hébergeons ont été indisponibles aujourd’hui lundi 6 mai 2024, de 4h37 du matin à environ midi, soit environ 8h d’indisponibilité. Nous sommes vraiment désolé⋅es pour les soucis que cela a pu poser.
Version plus longue : un de nos serveurs historique, mutu2, qui héberge près de 90% de nos instances Nextcloud, a depuis plusieurs mois, assez peu d’espace disque libre, il ne lui restait que quelques dizaines de giga-octets disponible.
Nous avons des alertes lorsque l’espace disque devient faible, et nous en avons régulièrement discuté ces dernières semaines… Sauf que…
Quelques dizaines de giga-octets, c’est peu, mais c’est largement assez pour fonctionner, et nous n’avons pas programmé d’intervention d’urgence (à part veiller régulièrement à libérer un peu d’espace en routine).
Nous avons depuis l’été un plan pour libérer plusieurs centaines de giga-octets, que nous devons migrer sur un autre serveur, mais la mise en place du serveur a pris pas mal de temps, son redimensionnement aussi, son paramétrage aussi, la reconfiguration aussi.
Bref, la dernière brique de configuration a été mise en place hier dimanche. Il ne nous restait qu’à faire la migration pour libérer l’espace promis… Et le serveur est arrivé à court d’espace disque quelques jours trop tôt.
Hello hello,
Depuis quelques semaines, les forums Discourse étaient devenus très lents, avec notamment un message de type « erreurs 502 » ou « mises à jour en cours » qui s’affichait régulièrement.
Nous avons mis du temps à le corriger car nous avons dû déplacer un logiciel que nous pensions héberger sur la même machine que les forums.
En effet, la machine qui héberge les forums est traditionnellement assez calme et peu chargée, nous avions donc décidé d’y installer un serveur d’objets S3 : un module de stockage de données que nous utilisons pour certains espaces Nextcloud.
Nous n’avions pas anticipé que ce module occasionnerait énormément d’accès disques, qui ralentiraient énormément l’intégralité des services.
Une fois le souci diagnostiqué, il nous a fallu trouver de la place sur une machine capable d’héberger ces données, ce qui nous a pris pas mal de temps.
Le service est normalement revenu à la normale, nous sommes vraiment désolé⋅es pour les difficultés à y accéder.
Les outils numériques sont centraux dans le fonctionnement d’un grand nombre d’associations : partage de fichiers, mails, communication, comptabilité, etc. Néanmoins, la plupart de celles-ci utilisent des outils pas forcément éthiques. Exemples :
La liste est souvent longue, mais heureusement, des alternatives existent ! Néanmoins, penser une transition numérique est un processus qui peut être complexe, qui doit être anticipé et qui ne consiste jamais à remplacer un outil « GAFAM » par un autre « libre ».
Alors, Framasoft et Animafac lancent le projet Émancip’Asso :
Le Cloud Girofle a suivi la formation Émancip’asso, et fait partie des prestataires référencés. N’hésitez pas à nous contacter pour :
Bonjour tout le monde. Avec un peu de retard, nous souhaitions communiquer sur des difficultés que nous avons eues durant le mois de janvier :
Tout a commencé au mois de décembre 2023. Nous remarquons une alerte sur un de nos serveurs, chif.fr. Cette alerte nous indique que le disque dur principal subit des erreurs de lecture.
Ce genre d’alerte est d’habitude un signe de « pre-fail » : aucune donnée n’est perdue pour l’instant, mais cela suggère que le disque est en fin de vie. chif.fr est le premier serveur que nous avions loué lorsque nous avions lancé le Cloud Girofle, en 2018. Six ans plus tard, il n’est pas absurde qu’un disque sollicité 24h/24 donne des signes de faiblesse.
Nous tentons d’en savoir plus sur l’erreur. Sur les quelques jours d’observation, le système d’alerte nous enverra une ou deux alertes supplémentaires, mais nous ne réussirons pas à la confirmer ou la préciser avec les outils d’analyse traditionnels. Nous nous demandons si c’est un faux-positf ou non.
chif.fr est le premier serveur que nous avons loué. Il a traversé notre inexpérience, nos expérimentations, et nos déboires. C’est aussi le serveur qui accumule le plus de dette technique, et qui nous demande le plus de maintenance. Nous avons également identifié depuis plus d’un an qu’il constitue un « SPOF », un single-point of failure (un élément critique du système) pour plusieurs services :
Ainsi, en cas de panne du disque, tous ces services se seraient retrouvés impactés. Par ailleurs, le disque n’étant pas redondé (pas de RAID), nous nous trouvons contraints de réaliser un changement de disque avec une interruption de service. Enfin, la machine étant hébergée chez notre prestataire Kimsufi, nous ne pouvons ni réaliser le changement de disque nous-même, ni un clone du disque, nous devrons repartir depuis nos sauvegardes. Kimsufi nous informe que le changement de disque peut être anticipé à une heure précise, et que l’opération prend une demi-heure environ.
Après prise en compte de tous ces éléments, du risque de pertes de données et de service, et malgré le fait que nous n’arrivons pas à isoler l’erreur du disque ou à confirmer qu’il ne s’agit pas d’un faux-positif, nous décidons de programmer le remplacement du disque.
Tout d’abord, nous listons les services qui seront impactés par le changement de disque, et la réinstallation qui va s’en suivre. Pour pouvoir minimiser les effets sur les utilisateur⋅ices. Nous choisissons de profiter de ce changement de disque pour réduire la concentration des services sur cette machine, ou pour les déplacer (semi)-temporairement :
Ensuite, nous nous assurons que nous disposons de sauvegardes intégrales du serveur (d’habitude, nous sauvegardons seulement les données, ce qui oblige à tout réinstaller si nous perdons le serveur). Nous rajoutons la sauvegarde de la racine « / » du serveur à nos backups.
L’opération démarre le samedi 13/01 au matin. Au début, tout se passe bien, Kimsufi a remplacé le disque à 1h du matin, nous attaquons la restauration à 9h. Nous pouvons accéder à la console de secours, et commencer la restauration.
Le partitionnement se déroule bien. L’objectif étant de remonter le service le plus rapidement possible, on avait décidé de garder le même partitionnement que sur le précédent disque. Les partitions sont simples, sans LVM ni RAID.
Une fois le partitionnement en place, il nous faut remonter le système. Pour cela, on se base sur une archive Borg de tout le système (toute la racine /, sauf les dossiers /sys/, /proc/, /tmp/, /dev/ et /run/ ) que nous avions lancé la veille.
Le système maintenant en place, on peut quitter la console de secours et redémarrer le serveur. C’est là que les choses se compliquent: le système ne semble pas démarrer. Sur ce serveur, il n’y a pas malheureusement pas de console IPMI, il nous est donc impossible de diagnostiquer la panne. Après plusieurs longues tentatives de redémarrage/console de secours, nous changeons le fusil d’épaule et décidons de repartir sur l’installation d’un Debian via l’installateur Kimsufi 😿
A partir de là, on arrive bien à démarrer le système et à s’y connecter, mais c’est un système vierge, sans nos services et outils. Nous retournons donc sur la console de secours, et nous tentons de remplacer les dossiers du système par ceux de l’archive Borg. Le système démarre ensuite correctement mais nous avons rapidement des messages d’alertes nous indiquant que tout n’est pas opérationnel. Certain fichiers n’ont pas été restaurés correctement (les liens symboliques n’ont pas été restaurés). Cette erreur aurait pu être évitée en testant des restaurations au préalable, chose que nous n’avions pas fait par manque de temps.
Nous avons finalement réussi à remettre en route les services « à la mano » un à un, sur plusieurs jours, jusqu’au mardi 16/01, en priorisant les services les plus critiques.
Au final, les utilisateur⋅ices ont été impactés de la manière suivante :
Nous sommes capables d’effectuer des interventions en cas de problème matériel, sans perte de données.
Nous avons encore des progrès à faire dans l’anticipation de toutes les étapes, et à l’avenir nous nous assurerons que deux administrateur⋅ices « racine » sont bien présents pour la migration.
Pour en savoir plus : nous essayons de rédiger un rapport technique (parfois succinct) pour chaque intervention majeure sur nos serveurs. Celle liée au changement de disque est disponible sur notre wiki technique.
En parallèle des soucis de disques, vous avez été nombreureuse à nous signaler une panne sur l’ouverture des documents collaboratifs. En effet, sur certaines instances Nextcloud, lors de l’ouverture d’un fichier Office (Word, Excel, etc…) il était proposé de télécharger le fichier, alors qu’il devait simplement s’ouvrir dans le navigateur.
Nous pensons que cette panne est liée à une nouvelle fonctionnalité introduite en 2023 qui vient vérifier périodiquement si le service Onlyoffice (l’outil d’édition collaborative que nous utilisons) est bien joignable depuis chaque Nextcloud. Nous avons pour l’instant désactivé cette fonctionnalité car nous disposons déjà d’outils de suivi de notre instance Onlyoffice.
Faites nous signe si vous rencontrez à nouveau ce problème 🙏
Nos services sont gérés par des bénévoles, sur leur temps libre. Nous faisons de notre mieux pour vous fournir des services performants et disponibles mais nous ne pouvons pas garantir une présence constante de nos équipes de support. Nous vous remercions donc de votre compréhension, patience et soutient 🥰
Le 15 octobre 2023, nous étions une dizaine de personnes réunies pour l’assemblée générale du Cloud Girofle. Merci à toutes les personnes qui étaient présentes, aux membres CHATONS et proches-CHATONS 🙏. Voilà ce qu’on s’est dit et quelques orientations pour l’année à venir 🐈.
Nous étions accueillis au Fuz, dans l’AERI. Merci à elleux !
Un des enjeux de l’AG 2023 était d’élargir et de diversifier un peu la communauté des personnes qui contribuent à l’asso et de décider des orientations à venir pour 2024. En effet, les personnes sensibilisées à la tech sont un peu sur-représentées. Mais voilà un résumé des décisions en quelques mots :
L’AG comportait également une partie statutaire, l’occasion de valider le bilan moral et financier de l’association (ci-dessous)
On décide de se consacrer principalement à la consolidation de l’existant : résoudre des bugs, etc. On ajourne donc la plupart des points de l’ODJ qui consistaient à développer de nouvelles fonctionnalités.
D’une part, l’asso souhaite avancer sur l’aspect écologique (consommer moins de ressource, réutiliser le materiel au max). Avancer vers une sobriété informatique. Ainsi, les machines du Cloud Girofle sont des anciennes machines d’OVH (reconditionnées par sa filiale Kimsufi). Par exemple, une des machines les plus puissantes de l’asso (chif.fr, qui héberge OnlyOffice), tourne sur un processeur Opteron 4122 (sorti en 2010). La machine qui a hébergé tous nos Nextcloud jusqu’à l’an dernier (et qui héberge le site web, le wiki, le monitoring) sur un Atom N2800 sorti en 2011. L’aspect reconditionné est vraiment très important pour nous.
Pour le dernier serveur loué (qui héberge les mails), OVH a fourni un document (dont on ignore la valeur), mais qui estime le bilan carbone sur le cycle de vie du serveur à 22kg-eqCO2/mois. On sait pas trop à quoi ça correspond mais ça donne des ordre de grandeur. Est-ce qu’on sait combien de CO2 émettent nos services ? Pas vraiment. On rappelle qu’a priori les terminaux consomment 80% des ressources, 10% réseau, 10% serveurs.
En même temps, il va y avoir de plus en plus en plus utilisateurs chez le Cloud Girofle. Comment faire ? De plus, Nextcloud est un outil qui demande beaucoup de ressources. Il a fallu beaucoup d’optimisations pour avoir ~80 utilisateur⋅ices simultanés sur une machine, et ça reste précaire.
On évoque un premier texte de positionnement, voire peut-être un manifeste sur ce que pourrait être un numérique écologique du point de vue d’un hébergeur. Suite au camp CHATONS 2022, on avait fait un premier jet du texte, mais voilà ça n’avait pas abouti. L’heure est peut-être d’avancer pour le finaliser… Ça pourrait être un travail inter-chatons.
Il y avait de grands mots dans ce texte comme acter la fin de l’obsolescence programmée, l’informatique à base d’ordinateurs trouvés dans une poubelle, etc. On note bien que ça concerne surtout les terminaux utilisateurs, mais que ça n’empêche pas de mener une réflexion sur les serveurs.
On décide de déterrer ce texte. Ou du moins de réfléchir à nous positionner/agir en fonction.
Il est compliqué de conjuguer sobriété et accessibilité/usabilité en général. De manière générale, on remarque qu’on ne sait pas vraiment ce qu’utilisent les collectifs. Il faudrait mieux comprendre ce qu’iels utilisent.
On part du constat qu’on confond souvent service et besoin. Souvent dur de comprendre les besoins, les usages, etc.
Souvent, on propose un outil, et l’outil induit une certaine forme d’usage. On se dit qu’on interroge assez peu la vision technique inclue dans les logiciels. Par exemple, les gens de cryptpad proposent 100 Mo, très très peu de données (alors que c’est des fonctionnalités similaires à Nextcloud, où les gens ont tendance à stocker des gigazédégigas).
On développe l’idée d’interroger les utilisateur⋅ices pour mieux connaître leurs usages et leurs besoins, ça pourrait prendre la forme de la prise de nouvelles bi-annuelle.
Deux Fleurs a commencé un jeu de cartes (physique) pour réfléchir à nos besoins, notamment anticiper les aspects négatifs du numérique, parler de greenwashing dans toutes ses subtilités.
La questions se pose comment bien animer cet outil. Idéalement c’est pour un public non technique.
Des membres du Cloud Girofle aimeraient découvrir l’outil. On s’organise pour organiser une session (ouiui).
La discussion prend un air plus théorique mais tout autant passionnant. Une personne joue le trouble-fête dans le doux consensus qui émergeait : « mais les datacenters ça mutualise des ressources. » Par exemple Amazon a créé AWS pour mutualiser des serveurs qui n’étaient utilisés que pour le pic de Noël en gros. Gros avantage de partager les ressources. Touché.
Plusieurs membres pointent qu’il y a des enjeux et des choses à redire sur l’impact spatial et énergétique des datacenters (rapport de l’ADEME, auquel Fanny Lopez a contribué, également détaillé dans À bout de Flux de la même autrice), sur la militarisation (au même titre que la militarisation des centrales nucléaires, on est en droit de se demander si c’est le monde dans lequel on a envie de vivre), au point que même une partie de l’industrie « trouve ça bizarre de devoir passer six portes blindées pour stocker des photos de chats ».
Plus proche des questions énergétiques, on note aussi que le datacenter encourage et favorise la redondance, il fait croire que « ça marche toujours, tout le temps ».
On se demande également dans quelle mesure les gains de mutualisation sont compensés/dépassés par le renouvellement rapide du matériel, annoncé parfois pour « réduire la consommation énergétique ». De manière générale, on se pose clairement la question de l’effet rebond dans ce contexte.
La discussion se poursuit avec les effets sociaux des datacenters, et leur origine notamment pour séparer les ingénieurs des machines, et de briser leur capacité à interrompre le service. Un membre pose la question des outils/méthodes qu’on souhaite mettre en place pour la grève. On cite un article, les datacenters enfoncent le cloud, qui évoquent les enjeux politiques et environnementaux d’internet.
Aujourd’hui le Cloud Girofle est essentiellement dans des datacenters (mais pas avec une offre cloud, sans redondance particulière outre ce qui vient avec l’offre datacenter), mais aussi un peu auto-hébergé (backups, machine de test). Une personne de DeuxFleurs rappelle que sortir des datacenters est une des origines de l’asso (ils ont donc à la fois un point de vue situé et un recul/une pertinence sur le sujet).
On se dit qu’on a envie d’approfondir la question, et de prendre le temps de voir comment ça peut infuser dans nos pratiques.
Des membres de l’asso accumulent des dizaines de références ainsi qu’un regard critique sur celles-ci (en AG Max a dit des centaines mais il a exagéré largement). On se dit qu’on aimerait bien en faire quelque chose : un article, une base de connaissances, etc.
Ça apporte des pistes pour nourrir le débat ci-dessus sur les datacenters, réfléchir à l’impact environnemental (analyse de cycle de vie notamment) du matériel qu’on utilise (que ça soit les serveurs ou les terminaux utilisateurs, etc), nous outiller, que ça soit avec des chiffres ou des réflexions. Bref, penser le numérique.
Ça tombe plutôt bien car DeuxFleurs a déjà une petite médiathèque en ligne ainsi qu’une collection sur Zotero.
On décide de contribuer à la base de connaissances de DeuxFleurs, pour l’enrichir/voir les parallèles qui peuvent être faits.
Après avoir bien discuté en théorie, on s’est rappelé que le Cloud Girofle commence à toucher les limites d’un de ses hébergements (sur le serveur mutu2, on a des soucis d’usage CPU et RAM et disque, bref, on touche à peu près toutes les limites à la fois). Le coupable ? C’est Nextcloud, avec ses dizaines de processus PHP-FPM qui consomment 500 MB chacun, son code brontosauresque et ses gazillions de fonctionnalités.
On soumet donc une hypothèse : peut-être qu’un client léger (webdav) solliciterait moins le serveur. En vrai on n’en est pas certains, mais on se dit qu’on pourrait tester. Notamment car ça permettrait de proposer deux « portes d’entrée » aux utilisateur⋅ices : une via Nextcloud et une via un client en ligne webdav. Les fichiers auxquels on pourrait accéder seraient les mêmes et tout le monde serait content.
Ça tombe bien car il existe plusieurs clients WebDAV-js, tous développés par des copains :
On décide de tester ces solutions pour voir si on peut gagner en performance
Aujourd’hui, plein de chatons et non chatons proposent de nombreuses alternatives à beaucoup de services fournis par les GAFAM (Google en particulier). Mais régulièrement (souvent pour le cas du Cloud Girofle), les personnes conservent leur adresse gmail (ou autre GAFAM), qui leur sert de porte d’entrée. Ça nous pose un souci à plein de points de vue. De plus, lorsqu’on quitte Gmail, il peut facilement y avoir un effet domino, où les outils Google ne sont plus tellement attractifs, et on peut extraire les utilisateur⋅ices d’autres services GAFAM en cascade (même si on peut avoir un compte Google sans utiliser Gmail).
Ça tombe bien, car il y a plein d’acteur⋅ices qui commencent à proposer des services de mail, que ça soit chez les chatons ou les non-chatons. On pense qu’il faut lancer une campagne de communication autour de la migration de mail vers des hébergeurs plus « propres ». On a un contact qui fait de la com et qui est intéressé par le sujet.
Les utilisateurices individuel.le.s ne sont pas forcément la cible du Cloud Girofle (car on s’adresse plutôt aux collectifs), mais il y a l’idée/l’intérêt de faire un truc un peu coordonné avec d’autres CHATONS.
Quelques questions sur l’organisation :
Quid de la temporalité ? on pourrait commencer avec quelques CHATONS motivés d’ici la fin de l’année, identifier les ressources que l’on pourrait impliquer, et publier les premiers messages ~Septembre 2024 (juste une idée pour l’instant, on est pas des communicants).
Décision que Max s’occupe de lancer une dynamique pour savoir combien on est.
Le budget prévisionnel retrace la trajectoire qu’on s’est donnée pour l’asso.
Dépenses
Truc | Montant | Remarque |
Location de serveurs, etc | 2500 | Ajout de mutu3 |
Achat de matériel (serveurs) | 2000 | |
Communication/impressions | 300 | |
Campagne de communication | 5000 | Cofinancement chatons |
Salaires | 4000 | 2 mois temps plein |
Banque & co | 100 | |
Soutien aux logiciels | 3000 | 20% |
TOTAL | 16900€ |
Recettes
Truc | Montant | Remarque |
Cotisation des membres | 7000 | |
Prestation de service | 7500 | |
Don | 400 | |
(trésorerie) | 2000 | |
TOTAL | 16900€ |
On discute des différentes lignes :
Le Cloud Girofle s’est proposé de prendre en charge les avances financières du Camp CHATONS 2024. On restera aussi transparent que possible. On aimerait une responsabilité partagée sur les pertes éventuelles.
Bonne nouvelle de l’année dans ces temps de centralisation massive de nos données chez les GAFAM : le Cloud Girofle ouvre son service de mails.
Après des années passées à peaufiner et assurer le suivi de l’envoi de mails internes et de notification, et six mois de travail intense pour élaborer une solution qui puisse répondre à la majorité des besoins, un sondage pour évaluer la demande, le Cloud Girofle ouvre enfin un service de boîtes mails.
Que vous soyez un individu ou un groupe/collectif/association/+, que vous souhaitiez utiliser votre propre nom de domaine, ou un nom de domaine en @girofle.org, @tchoutchou.org ou @jerepondspas.fr, nous pensons que le service peut répondre à vos besoins. Tout le fonctionnement est détaillé sur la page dédiée :
Youpi youpala, voilà qu’arrive l’assemblée générale annuelle du Cloud Girofle 🎈 !
Mais l’an dernier c’était en mai – me direz-vous ? Et bien oui, mais nous fûmes retardé⋅es, alors mieuvotarkejamé !
De quoi on parle 👩🎤 ?
C’est pour qui ? tous⋅tes les utilisateur⋅ices ! Car tous les utilisateur⋅ices sont membres de droit de l’association, et ont voix au chapitre. Aussi parce que c’est l’occasion de faire connaissance !
De quoi on a parlé les années précédentes ? Les compte-rendus d’AG de 2021-2022 et 2020-2021 sont disponibles en ligne pour que vous vous fassiez une idée.
C’est où ? à l’AERI, un super chouette lieu associatif à Montreuil (57 – 59 Rue Étienne Marcel 93100, Montreuil). Et aussi en ligne (nous contacter pour qu’on vous envoie le lien de connexion)
C’est quand ? Dimanche 15 octobre 2023, à partir de 14h. Fin prévue vers 17h.
C’est quoi le programme ? Après un petit temps d’accueil, on fait en général l’AG formelle (~1h), puis on enchaîne sur la discussion de l’avenir/ce qu’on veut faire cette année. Fin prévue vers 17h. Et ensuite on peut aller se désaltérer joyeusement !
On fête quoi ? Les 3 ans de l’asso, les presque 3 ans de notre entrée dans le collectif des CHATONS, les 6 ans de l’ouverture du premier service, et peut-être d’autres choses qui sait ?
[edit de jeudi 11h : nous pensons que le souci est réglé]
Hello,
Pour une raison non encore identifiée, la charge sur notre serveur hébergeant les instances Nextcloud est très élevée, et il est quasi-impossible d’y accéder. Ça dure depuis mercredi 13/09 16h45.
Nous travaillons pour résoudre le problème.
Mise à jour du 14/09 12h : nous pensons avoir identifié l’installation d’une application non compatible comme une (mais pas la seule) des causes du souci. L’application a été désactivée. Les services sont stables depuis 11h.
Mise à jour du 14/09 11h : nous pensons avoir mis en place une configuration qui stabilise le serveur. Un fichier de configuration dupliqué rendait inopérant les modifications que nous avions mises en place la veille à 23h. Nous gardons un œil sur la charge du serveur.