Les accès VNC ne fonctionnent que via IPv4. Hier un adhérent a remonté que les noms de domaine permettant d’y accéder étaient configurés en IPv4 et IPv6. Les personnes qui tentaient d’y accéder via IPv6, n’arrivaient donc pas à se connecter.
Ce point vient d’être résolu, si vous n’avez jamais réussi à vous connecter à votre VPS en VNC, c’est peut être le moment d’essayer.
Pas de coupure à prévoir
EDIT: pour info ça a été annulé et c’est reporté à une date indéfinis
Les VPS présents sur le nœud hwhost-1 n’ont visiblement plus d’IPv6 depuis le début de la journée.
EDIT 15:03: C’est réparé avec un fix temporaire vers le tunnel Hurrican Electric de hwhost-2. Il y a donc actuellement perte de redondance sur l’ipv6. Affaire à suivre.
On est en train de s’en occuper. Le service devrait revenir d’un moment à l’autre.
EDIT 19:00 : c’est corrigé
EDIT 20:49: à priori seuls les tentatives de nouvelles connexions ne fonctionnaient plus, les serveurs qui ne se sont pas déconnectés ont continués de fonctionner.
Visiblement c’est pas le même soucis qu’hier même si c’est probablement lié.
Investigation en cours
Le VPN est de nouveau fonctionnel.
Nous allons redémarrer le serveur sans-nuage.fr pour y ajouter un peu de RAM.
EDIT: c’est fait, tous les services semblent fonctionnels 
EDIT 17 juin 18:00:on nous remonte un bogue bizarre sur nos pads (le curseur ne se place pas au bon endroit lorsque l’on écrit/supprime des choses)… On tente l’upgrade vers la 1.8.4
Une instabilité dans le code d’etherpad a déclenché une série d’erreur 502 sur nos PAD (en partie lié à notre utilisation de libreto).
Le problème est désormais résolu sur notre instance et un correctif a été proposé à etherpad.
17:03 Il semble que notre Wekan n’envoie plus de mail.
EDIT: ce problème semble avoir été résolu par un ou une de nos admins
Il y a actuellement un soucis d’ipv6 vers certaines destination.
EDIT: ce problème semble uniquement lié à ce nom de domaine donc plutôt lié à un soucis IPv6 sur ce miroir debian. Les nouveaux VPS sont déployés avec un autre miroir. Pensez à changer de votre côté si vous ne voulez pas avoir des délais de mise à jour.
EDIT2: finalement c’était bien de notre côté, ce soucis d’acheminement IPv6 est résolu
@ljf on dirait que c’est ce bug qui n’a pas été résolu par l’upgrade. Probablement lié aux plugin plutot.
Le switch et les routeurs ont été préparés.
Il reste des prises électriques PDU activées (par contre on ne peut plus se connecter aux PDUs pour en activer d’autres).
Demain nous brancherons le serveur, aucune coupure sur les services n’est à prévoir (sauf si on fait une fausse manipulation ou qu’on arrache un câble).
EDIT 2020/09/13 00:34: Suite à un test sur l’ampérage des serveurs, un disjoncteur a sauté, et malheureusement nous avons fait une fausse manipulation et avons éteint l’autre disjoncteur au lieu d’allumer celui qui était éteint (le code couleur étant étrange). En a suivi un redémarrage de l’ensemble de l’infra révélant divers soucis (essentiellement, un problème de routage et un lié à la mise à jour de grub). Nous venons de remonter les VM d’ARN et allons passer au remontage des VM des adhérent⋅es. Nous présentons nos excuses et espérons que vous n’avez pas été trop impacté
EDIT 2020/09/13 01:13: L’ensemble des VPS (sauf un des miens) ont été redémarré. N’oubliez pas de vérifier que tous vos services fonctionnent en testant à la main et en faisant « systemctl ». Il subsiste un problème de routage entre les IP ARN sur hw1 et celles sur hw2.
Les services ARN (sans-nuage.fr, netlib.re, vpn, …) vont être vérifiés, pour l’instant certains fonctionnent et d’autres non.
EDIT 2020/09/13 15:15: Le routage ipv6 et ipv4 est fonctionnel. N’hésitez pas à nous prévenir par mail si votre VPS n’est toujours pas joignable. Pensez à vérifier avec la console VNC aussi.
D’après nos tests l’ensemble des services sont rétablis (sauf une vm reflexlibre).
Le transfert de fichiers temporaires sur sans-nuage.fr est actuellement indisponible car l’espace alloué a été remplis.
Le service devrait être disponible d’ici 48h.
EDIT Vendredi 2 octobre: le transfert de fichier est de nouveau actif sur une nouvelle adresse : drop.sans-nuage.fr . L’ancienne sera supprimée une fois que tous les liens seront périmés en février 2021.
Nous avons finalement identifié l’erreur qui aboutissait au chargement incomplet du menu des libreto. Il était nécessaire de rafraîchir plusieurs fois pour obtenir le menu.
Depuis etherpad 1.8.3 un taux limite d’utilisation a été mis en place par IP, or notre libreto télécharge les pads toujours avec la même IP. Nous espérons que notre correctifs sera suffisant.
Mardi soir nous mettrons à jour sans-nuage.fr et ses applications, et si nous avons le temps, nous déploierons un ou plusieurs des services dont nous avons discuté (Framaforms, Matrix, Mobilizon).
La mise à jour étant importante, des déconnexions sont à prévoir et il est possible que certains services soient indisponibles pendant quelques heures.
Si l’opération vous intéresse vous pourrez vous joindre à nous probablement via un Big Blue Button (audio.sans-nuage.fr pouvant être indisponible durant la mise à jour).
EDIT Mercredi 14 octobre 2020 01:11: Mise à jour terminée.
Le bilan: le service hub.netlib.re/lufi est fermé plus tôt que prévu (il était déjà gelé depuis 10 jours). Le service jappix est fermé également (car caché et non utilisé).
Nous sommes passé à Nextcloud 19
Déploiement d’un serveur Matrix (home server synapse) sur matrix.sans-nuage.fr (domain) Les comptes seront de la forme @user:sans-nuage.fr (@user:server_name). Le serveur est réservé aux utilisateurs sans-nuage
Déploiement d’un client web Matrix (Element, ex-Riot) sur chat.sans-nuage.fr . Connexion directe grâce à un compte sans-nuage via single-sign-on.
Déplacement de framadate sur date.sans-nuage.fr
Déploiement de framaforms sur sondage.sans-nuage.fr en public,
Amélioration du paquet YunoHost mobilizon et test de déploiement.
Notre interface adherents.arn-fai.net était victime d’un bug affectant toutes les actions de l’interface adherents.arn-fai.net envoyant des emails, notamment:
Ce dysfonctionnement (qui date du 07/11/2020) est désormais résolu. Il était lié à l’échec d’une tache cron lancée toutes les 2 minutes, entraînant un refus d’envois des mails de ce cron mais aussi des autres mails envoyé par l’application.
L’IPv6 est injoignable depuis certains FAI et sur les VM positionnées sur hwhost-1.
https://smokeping.illyse.org/?target=ISP.FFDN.ARN_v6
Passionné et passionnée d’IPv6, n’hésitez pas à nous faire des retours plus précis.
EDIT 25/12/2020 : Alors j’ai (ljf) pu trouver un peu de temps ce soir pour regarder. Le soucis arrive si ces conditions sont réunies:
Il s’agit en fait du conflit entre HE et Free qui s’est déclaré en mars 2020. Free a coupé son lien de peering avec HE. De ce fait l’IPv6 de Free, ne discute plus totalement avec tout internet… https://lafibre.info/peering/free-hurricane-electric/
Toutefois ARN est chez Cogent, et Free a Cogent comme transitaire, donc on peut essayer d’arranger les choses avec BGP. Je suis en train d’essayer, désolé pour les perturbations sur IPv6.
EDIT 26/12/2020 à 2h : Bon j’ai pas réussi à avoir quelques choses de stable pour Free… Je remet comme c’était pour l’instant (pour éviter de faire pire que mieux)…