Some systems are experiencing issues

Stickied Incidents

Tuesday 15 August 2023

nitter.fdn.fr Instance Nitter : erreur « Tweet not found »

Suite à de nouveaux changements côté Twitter (encore…), toutes les instances sont bloquées car la consultation des tweets nécessite à un compte. Le problème est identifié sur le Git de Nitter, ticket 983. La recherche ne fonctionne également pas.

L'équipe adminsys

Sunday 23 July 2023

lns22.fdn.fr xDSL / FTTH : certaines destinations sont injoignables

Certains adhérents nous ont remontés que certaines destinations pouvaient être injoignables, aussi bien en HTTP/HTTPS, Ping ou SSH. Exemples non exhaustifs : irc.geeknode.org, github.com, linuxfr.org, sa.debian.org…).

Vers 23:30 le 23/07/2023 les quelques adhérents ayant le problèmes ont été exclu de l'accélération noyau L2TP.

Le défaut semble se situer dans la gestion de la route retour entre les LNS. Exemple : routeur adh > LNS11 > GWx > LNS22. En désactivant l'accélération sur LNS22, le défaut disparaît.

L'accélération noyau a été laissé active afin que le mainteneur L2TPNS puisse investiguer. Si vous rencontrez un problème similaire, n'hésitez pas à nous en faire part par e-mail via support (a) fdn.fr ou via les messageries instantanées IRC/Matrix.

L'équipe adminsys

  • La supervision a été mise en place le 21/08 dans la nuit. Ainsi dans le cas où le nombre de tunnel pour chaque LNS vers les LAC Ielo n'est pas strictement 4, on recevra un e-mail pour agir.

    Un ajout de logs dans L2TPNS en cas de souci pour avoir plus de billes lors de la création des tunnels L2TP a été rajouté et une tentative de correction de ce bug hypothétique également.

    Nous soupçonnons de plus en plus un bug dans la gestion des tunnels L2TP au sein du cluster :

      1. Changement d'IP sans créer le tunnel L2TP sur le LNS secondaire
      1. Le tunnel est créé mais vers la mauvaise IP.

    Quelques anciens tunnels L2TP fantômes vus par le noyau mais pas par L2TPNS ont été constaté sur LNS22 (secondaire), ce qui est visiblement sans incidence mais peut-être également un bug.

    L'accélération a été réactivée sur les deux LNS pour tout le monde vers 14:30 en incluant les modifications indiqués plus haut.

    L'équipe adminsys FDN

    • 15/08/2023 00:33 : nouvelle coupure impactant certaines lignes. L'accélération noyau a de nouveau été coupée sur le LNS22 vers 07:48.

    Le problème semble aléatoire mais ne se produire que sur le LNS22 qui est le secondaire et avec l'accélération noyau Linux active sur les deux LNS. Nous avons de quoi mettre en place une supervision pour détecter et agir pour corriger, le temps de trouver l'origine de la panne.

    Hypothèses :

      1. un défaut dans la gestion du cluster entre les deux LNS lorsque l'accelération noyau est active dans L2TPNs ;
      1. un bug du noyau Linux.

    Dans le fonctionnement on a un mirroir dans le noyau Linux des tunnels l2tp du l2tpns et quand le problème se manifeste sur LNS22 toutes les sessions qui sont sur le tunnel en défaut sont à destination d'une des deux IP du LAC Ielo, ce qui ne devrait pas arriver. Chaque LNS a 4 tunnels : 1 tunnel vers chacun des deux IP des LAC Ielo et deux autre depuis l'IP de l'autre LNS.

    La supervision va être mise en place sous peu.

    L'équipe adminsys FDN

    • 25/07/2023 05:00 : de nouvelles traces ont été prises. Lors de la réactivation de l'accélération sur LNS22, une demie-douzaine d'IP d'adhérent ne répondaient plus au ping. RAS sur LNS11. Un tcpdump a permit de voir que lorsque ça ne fonctionne pas, les paquets sont envoyés au mauvais LAC Ielo.

    Il s'agit peut-être d'un bug dans L2TPNS ou dans le noyau Linux qui se manifeste parfois et pas pour tout le monde.

    Actuellement, l'accélération est désactivé sur LNS22 mais active sur LNS11 car aucune erreur n'a été constaté sur ce dernier.

    L'équipe adminsys

    • 24/07/2023 17:57 : désactivation de l'accélération noyau pour tout le monde suite à de nouvelles remontées

    L'accélération est uniquement active pour un adhérent afin de permettre de creuser et trouver la cause.

  • Maintenance
    Messagerie : migration de RainLoop à SnappyMail

    C'est un projet en cours depuis de nombreux mois, RainLoop n'est plus activement maintenu et SnappyMail, son fork, l'est beaucoup plus.

    La principale motivation a été une vulnérabilité découverte fin 2021, nécessitant une application d'un patch manuel par les adminsys FDN et non fourni par l'éditeur. Voir le ticket #2142 sur Github ou le blog des auteurs de la découverte pour les détails.

    La nouvelle machine sous SnappyMail étant prête, la migration va pouvoir avoir lieu. Peu de changement visuel sont à prévoir, vous n'aurez rien à faire de votre côté. Le webmail sera toujours accessible à https://webmail.fdn.fr/ et le nouveau peut déjà être testé si vous êtes curieux à https://new-webmail.fdn.fr.

    Les adminsys

    Past Incidents

    Tuesday 15 August 2023

    nitter.fdn.fr Instance Nitter : erreur « Tweet not found »

    Suite à de nouveaux changements côté Twitter (encore…), toutes les instances sont bloquées car la consultation des tweets nécessite à un compte. Le problème est identifié sur le Git de Nitter, ticket 983. La recherche ne fonctionne également pas.

    L'équipe adminsys

    Sunday 23 July 2023

    lns22.fdn.fr xDSL / FTTH : certaines destinations sont injoignables

    Certains adhérents nous ont remontés que certaines destinations pouvaient être injoignables, aussi bien en HTTP/HTTPS, Ping ou SSH. Exemples non exhaustifs : irc.geeknode.org, github.com, linuxfr.org, sa.debian.org…).

    Vers 23:30 le 23/07/2023 les quelques adhérents ayant le problèmes ont été exclu de l'accélération noyau L2TP.

    Le défaut semble se situer dans la gestion de la route retour entre les LNS. Exemple : routeur adh > LNS11 > GWx > LNS22. En désactivant l'accélération sur LNS22, le défaut disparaît.

    L'accélération noyau a été laissé active afin que le mainteneur L2TPNS puisse investiguer. Si vous rencontrez un problème similaire, n'hésitez pas à nous en faire part par e-mail via support (a) fdn.fr ou via les messageries instantanées IRC/Matrix.

    L'équipe adminsys

  • La supervision a été mise en place le 21/08 dans la nuit. Ainsi dans le cas où le nombre de tunnel pour chaque LNS vers les LAC Ielo n'est pas strictement 4, on recevra un e-mail pour agir.

    Un ajout de logs dans L2TPNS en cas de souci pour avoir plus de billes lors de la création des tunnels L2TP a été rajouté et une tentative de correction de ce bug hypothétique également.

    Nous soupçonnons de plus en plus un bug dans la gestion des tunnels L2TP au sein du cluster :

      1. Changement d'IP sans créer le tunnel L2TP sur le LNS secondaire
      1. Le tunnel est créé mais vers la mauvaise IP.

    Quelques anciens tunnels L2TP fantômes vus par le noyau mais pas par L2TPNS ont été constaté sur LNS22 (secondaire), ce qui est visiblement sans incidence mais peut-être également un bug.

    L'accélération a été réactivée sur les deux LNS pour tout le monde vers 14:30 en incluant les modifications indiqués plus haut.

    L'équipe adminsys FDN

    • 15/08/2023 00:33 : nouvelle coupure impactant certaines lignes. L'accélération noyau a de nouveau été coupée sur le LNS22 vers 07:48.

    Le problème semble aléatoire mais ne se produire que sur le LNS22 qui est le secondaire et avec l'accélération noyau Linux active sur les deux LNS. Nous avons de quoi mettre en place une supervision pour détecter et agir pour corriger, le temps de trouver l'origine de la panne.

    Hypothèses :

      1. un défaut dans la gestion du cluster entre les deux LNS lorsque l'accelération noyau est active dans L2TPNs ;
      1. un bug du noyau Linux.

    Dans le fonctionnement on a un mirroir dans le noyau Linux des tunnels l2tp du l2tpns et quand le problème se manifeste sur LNS22 toutes les sessions qui sont sur le tunnel en défaut sont à destination d'une des deux IP du LAC Ielo, ce qui ne devrait pas arriver. Chaque LNS a 4 tunnels : 1 tunnel vers chacun des deux IP des LAC Ielo et deux autre depuis l'IP de l'autre LNS.

    La supervision va être mise en place sous peu.

    L'équipe adminsys FDN

    • 25/07/2023 05:00 : de nouvelles traces ont été prises. Lors de la réactivation de l'accélération sur LNS22, une demie-douzaine d'IP d'adhérent ne répondaient plus au ping. RAS sur LNS11. Un tcpdump a permit de voir que lorsque ça ne fonctionne pas, les paquets sont envoyés au mauvais LAC Ielo.

    Il s'agit peut-être d'un bug dans L2TPNS ou dans le noyau Linux qui se manifeste parfois et pas pour tout le monde.

    Actuellement, l'accélération est désactivé sur LNS22 mais active sur LNS11 car aucune erreur n'a été constaté sur ce dernier.

    L'équipe adminsys

    • 24/07/2023 17:57 : désactivation de l'accélération noyau pour tout le monde suite à de nouvelles remontées

    L'accélération est uniquement active pour un adhérent afin de permettre de creuser et trouver la cause.

  • Monday 10 July 2023

    Coupure franche de la collecte FTTH Axione

    Chers adhérents, chères adhérentes,

    Nous subissons un incident qui impact les FTTH collectées via Axione.

    Nous n'avons pas plus d'information pour le moment.

    L'équipe adminsys

  • La panne a été corrigée par Axione vers 15:40, la cause est un script ayant mis la configuration BGP en défaut, d'où le problème d'annonce des routes.

  • 12:51 : dam64 a mis une rustine en place, en attendant qu'Axione fassent le nécessaire (Aquilenet ne recevait plus de routes de leur part). Suite à la rustine, les lignes FTTH sont remontées.

  • Friday 30 June 2023

    nitter.fdn.fr Instance Nitter : erreur « Tweet not found »

    Suite à de récents changement côté Twitter, toutes les instances sont bloquées car la consultation des tweets nécessite à présent un compte. Le problème est identifié sur le Git de Nitter, ticket 919

    Aucune solution pour le moment.

    L'équipe adminsys

  • 03:50 : l'instance a été mise à jour afin de corriger la recherche de Tweets. Tout est désormais fonctionnel !

  • Depuis 16:51, l'instance est de nouveau opérationnelle après mise à jour afin d'inclure les changements de la pull request #927.

    Seule la recherche de tweet ne fonctionne toujours pas.

    L'équipe adminsys.

  • Thursday 29 June 2023

    invidious.fdn.fr Invidious : lecture des vidéos impossible

    Chers adhérents, chères adhérentes,

    L'erreur « Can't load the video on this Invidious instance. YouTube is currently trying to block Invidious instances. » survient lors de la lecture d'une vidéo sur notre instance.

    Le ticket 3822 du dépôt Github d'Invidious en parle, c'est un phénomène qui commence à être récurrent, de nombreuses autres instances sont étalements bloquées. Le passage en qualité « DASH », en désactivant le proxy ou en forçant la résolution en IPv4/IPv6 ne changent rien pour nous.

    Le changement d'IPv6 de la VM semble être une solution à envisager.

    L'équipe adminsys

  • Après changement de l'IPv6 depuis cette nuit vers 2:00, l'instance est de nouveau fonctionnelle. Le changement se fait toutes les cinq minutes ;).

    L'équipe adminsys.

  • Monday 26 June 2023

    lns11.fdn.fr Coupures Internet xDSL / FTTH collecte Ielo

    Cher adhérents, chères adhérentes,

    Des pertes de connectivités à Internet en IPv6 ou IPv4 se sont manifestés par des déconnexions et reconnexions régulières ainsi que des possibles soucis d'accessibilité en IPv4 (routage). Nos LNS semblent être en cause et plus particulièrement la partie L2TP. Le processus nous indiquait des erreurs d'allocation mémoire mais sans en trouver la cause précise pour le moment malgré quelques heures de recherches (RAM, slabs, max_size IPv6, optmem_max, nombre de sockets, nombre de routes apprises…).

    Les messages en question :

    For generic netlink request 6 on 24, got a netlink error: No such device
    00/00 DHCPv6: could not join DHCPv6 group: Cannot allocate memory
    00/00 ICMPv6: could not join all routers group: Cannot allocate memory
    
    • 26/06/2023 23:47 : LNS11 a été rétabli pendant une dizaine de minute
    • 27/06/2023 00:00 : LNS22 est rétabli après redémarrage du processus L2TP
    • 27/06/2023 00:12 : de nouveau les dysfonctionnements mais plus d'erreur « Cannot allocate memory », seulement « For generic netlink request 6 on 24, got a netlink error: No such device »
    • 27/06/2023 00:22 : un redémarrage du serveur s'impose car les deux processus L2TP se sont suicidés après avoir voulu les relancer sans l'accélération noyau
    • 27/06/2023 00:28 : LNS22 est de nouveau opérationnel

    À noter que les erreurs « For generic netlink request 6 on 24, got a netlink error: No such device » sont toujours présentent. LNS11 étant isolé, cela va permettre d'approfondir le diagnostics et effectuer des tests.

    Désolé pour ces perturbations :/.

    L'équipe adminsys

  • RAS depuis les changements du 27/06. Ces deux actions ont sans doute permis de stabiliser : ajustement de l'option net.core.optmem_max ainsi que le blocage du compte qui avait pour conséquence de créer/supprimer des interfaces réseau et des routes en boucle.

    L'option net.core.optmem_max a été sauvegardé de façon permanente via notre outil de gestion des configurations ainsi que l'iptables pour l'ajustement du MSS, ce qui évitera les déboires causées en cas de redémarrage du serveur.

    L'équipe adminsys

  • Après quelques debug, nous avons constaté une augmentation de la table des inodes, mais ça semble être seulement du cache, sans incidence. L'erreur « For generic netlink request 6 on 24, got a netlink error: No such device » semble être une fausse piste, c'est la suppression des routes IPv6 mais IPv6CP peut ne pas être activé.

    • 27/06/2023 13:20 : augmentation de la valeur net.core.optmem_max de 1MB à 10MB et blocage des requêtes d'une ligne qui revenait sans cesse dans les logs pouvant solliciter de manière agressive les LNS et causer un effet de bord
    • 27/06/2023 ~21:00 : remontées d'accès à de nombreux sites web, ça ressemble à un problème MTU. Des comptes radius de personnes nous l'ayant remontés sont exclus de l’accélération noyau (tous ceux en %idf), ça fonctionne de nouveau.
    • 27/06/2023 ~23:20 : il ne s'agit pas d'un problème sur la MTU mais sur la MSS. Il est ajusté à 1420 sur les deux LNS et sauvegardé de façon persistante.

    Encore désolé pour ces interruptions et merci à toutes les personnes qui nous ont aidé dans le debug ;). Le sujet reste sous surveillance.

    L'équipe adminsys