Le but de ce document est de lister les problèmes connus, les pannes et la maintenance annoncée. Nous utilisons aussi un système de gestion automatisé de tickets, (rt.alphanet.ch), non accessible au public.
les anciens problèmes.
.
Date |
quoi |
2014-04-20 22h-23h |
Passage à nouveau serveur wheezy |
2014-08-22 |
Remplacement du certificat HTTPS *.alphanet.ch (wildcard) de CAcert par un de http://startssl.com/ -- avantage: reconnu par tous les navigateurs; risque: invalidable par OCSP |
2015-01-23 |
Débit accès principal de 75/7.5 MBit/s à 200/20 MBit/s |
2015-03-07 |
Mise à jour de 16 à 32 GB de RAM |
2015-09-11 |
Remplacement de l'UPS par l'ancienne, avec de nouvelles batteries |
2016-01-29 19h-22h |
Mise à jour login.alphanet.ch (panne de tous les services: cf RT#624). Reprise de la plupart des services vers 22h15. Tests vont se poursuivre ces prochains jours. |
2016-09-06 |
Activation du certificat SSL validé pour le SMTP (postfix) |
2016-12-09 |
mise à jour virtual samedi 21h-22h30 |
2017-01-16 |
Mise à jour débit ligne secondaire init7 à 80M/15M (~8 mégaoctets/s downstream, 1.5 mégaoctets/s upstream |
2017-03-04 |
Mise à jour kernel virtual vers 3.16.39-1+deb8u1 de 3.16.36-1+deb8u2, recréation clé USB; redémarrage et test |
2017-03-12 |
Mise à jour kernel virtual vers 3.16.39-1+deb8u2, recréation clé USB; redémarrage et quicktest |
2018-05-10 |
Redémarrage virtual avec nouveau kernel |
2018-07-29 |
installé intel-microcode, à tester: intel-microcode: microcode will be updated at next boot; done 2018-08-15 19:50 |
2018-08-20 |
install new certif *.alphanet.ch upto 2020-11-15 |
2018-08-23 |
greylisting passé de 1000 secondes à 300 secondes, ne semble pas poser de problèmes |
2018-08-31 |
ns2.alphanet.ch / ipv6-dns.alphanet.ch est maintenant sur la nouvelle architecture Hetzner, l'ancienne encore déployée le temps que les requêtes disparaissent |
2018-09-05 |
activation de mon ancien 193.72.186.0/24, voir ces pings globaux, y compris le reverse DNS |
2018-10-17 |
ajout 193.72.186.6 pour HTTP/HTTPS www.alphanet.ch, puis le 18 suppression de 46.140.72.222 |
2018-10-26 |
au fur et à mesure, on a remplacé 46.140.72.222 par 193.72.186.6 dans le DNS, toutefois il a fallu corriger pour nntp.alphanet.ch et smtp.alphanet.ch, vu que ces deux adresses sont utilisées pour de "l'authentification" NNTP et SMTP (anti-spam sur Received: et ELO: il y a eu quelques warnings 4xx et éventuellement un délai) respectivement; on a mis les deux adresses IP sur smtp.alphanet.ch, ce qui a semblé fonctionné, et on a aussi doublé NNTP, ça semble ok le 27; on a mis aussi un forçage en sortie de 193.72.186.6/119; marche sauf pour poupinou, désactivé car le newsmaster ne répond pas; seul quelques services volumineux et ns1.alphanet.ch (pour éviter le 2/3 load-balancing) sont encore uniquement en 46.140.72.222 |
2019-12-29 |
nouveau système de gestion des comptes NNRP https://news.alphanet.ch/ |
mars 2020 |
la liaison de secours init7 passe maintenant par du FTTS Swisscom, débit max possible 250/50, actuellement environ 150/50, un débit plus élevé que 100/50 nécessite le changement de l'alix en apu2 et du modem pour G.fast |
2020-05-14 |
liaison principale UPC passe de 250/25 à 1000/100 |
2020-06-25 |
mise à jour modem init7, bon délai, meilleur débit ~ 160 MBit/s / 57 MBit/s |
2020-07-11 |
mise à jour de virtual à buster |
2020-07-28 - 2020-07-29 |
mise à jour shakotay à buster (tous services) |
2020-11-06 |
Routage de 193.72.186.0/24 via init7, qui est plus performant qu'UPC pour ce VPN: de plus cela nous permet un véritable load-balancing et haute disponibilité sur quelques services (web notamment) |
2020-12-04 |
Ajouté dans spamassassin: SPF, DKIM et DMARC |
2021-11-20 |
Activation du work-around SPF dans mes mailing-lists et celle de P. C., information des ml-admins |
Date |
quoi |
2014-03-23 3h-11h45 |
Panne routeur cablecom, symptôme: LEDs normales mais pas de trafic, routeur 46.140.72.217 répond au ping, mais TTL exceeded dans l'autre sens. Arrêt 30 secondes, rebranchement et OK |
2014-05-08 22:40 à 2014-05-09 7:00 |
panne totale liaison principale; ensuite problèmes de stabilité entre 7h et 7h40 |
2014-09-03 20:53 - 22:53 |
Panne totale liaison principale Cablecom |
2014-11-21 16:00 - 18:26 |
Abus par un utilisateur réel d'ALPHANET (spam); mot de passe pas si facile donc probablement phishing; changé le mot de passe et débloqué sur http://att.net/blocks; vérifié pas dans listes anti-spam une semaine après (cf ticket #593) |
2014-11-29 15:30 - 17:45 |
Panne routage externe Cablecom |
2015-05-28 |
certains sites inaccessibles, valeurs en dehors de 14/200/20 via test ookla; reboot routeur corrige le problème, informé Cablecom; le 2015-06-02 ils suggèrent reset hardware du modem/routeur. Effectué à 9:28. Dû changer de port car sinon pas en GBit et vitesse max 100 MBit/s descendant. Avec test ookla depuis vz204, 11 ms, 219.21 MBit/s et 21.93 MBit/s. |
2015-06-24 |
redémarrage de virtual par erreur |
2015-07-17 |
Panne CATV minuit à 9h |
2015-10-22 |
Certains subnet de cablecom ne peuvent plus nous atteindre; support contacté: problème de routage sur le routeur central |
2015-10-26 |
Panne entre minuit et 3h de cablecom |
2016-03-10 |
Panne annoncée init7 de 4h à 8h |
2016-04-21 03:00-23h45 |
Connexions et flux sortants impossibles; DNS et SMTP sortant dévié sur liaison secondaire. Pas de problème pour recevoir des connexions et flux; annoncé à Cablecom à 10:35. Problème résolu par restart routeur Cablecom. |
2016-02-15 |
Délais plus importants sur liaison principale, Cablecom investigue |
2016-04-29 |
Downgrade au modem/routeur et débit précédent: 250M/25M: les délais sont meilleurs, mais pas aussi bons qu'en février, le prix n'est pas baissé. |
2016-06-08 |
Panne de courant d'environ 30 minutes, UPS a tenu mais accès réseau principal en panne durant ce laps de temps ou un petit peu plus |
2016-08-03 8h30-10h |
Travaux sur réseau électrique |
2016-08-03 10h30-12h45 |
Problème d'authentification sur le serveur SMTP |
2016-07-28 |
Panne liaison secondaire init7. Annoncé le 2 août. Swisscom a apparemment temporairement câblé une liaison téléphonique de secours le 9 août, cela refonctionne. Finalisation du câblage autour du 22 août. Problème résolu. |
2016-09-05 14h30-15h30 |
Panne liaison principale Cablecom, apparemment due à des travaux sur le téléréseau. |
2016-10-21 7h30-8h40 |
Diverses coupures de courant affectant la liaison principale (contrôles électriques) |
2016-11-04 |
Remplacement du compteur électrique; l'UPS a tenu |
2016-11-03 -2016-11-05 |
Quelques erreurs éparses sur /dev/sdb rattrapées avec miroir RAID1; le disque est à changer car sa table de remplacement est pleine; Remplacement et reconstruction ont été faits sans downtime. |
2016-11-15 9h-11h |
Downtime ligne principale Cablecom |
2016-12-11 9h-11h15 |
Downtime ligne principale Cablecom |
2016-12-16 |
tests redémarrage virtual |
2016-12-22 |
coupure de courant de 1h30, arrêt virtual |
2017-02-02 4h30-7h50 |
Connexion principale en panne: eth1 down; dû resetter avec mii-tool -R puis -r; problème câble? |
2017-03-26 16h30-18h30 |
Routeur Cablecom planté; symptôme: pas de route sur l'extérieure, 46.140.72.217 atteignable de l'intérieur, reset, OK |
2017-04-28 au 2017-05-05 |
déménagement coupure probablement 1/2 journée, avec quelques plus petites coupures possibles. Finalement panne le jeudi 4, 2 heures dans la soirée |
2017-05-27 21h-23h |
Rebranchement définitif des serveurs, après mise à jour kernel, memtest86 et test UPS |
2017-06-30 1h-10h45 |
ligne principale cablecom down |
2017-07-24 |
Quelques pannes durant la nuit de la liaison secondaire init7, avec augmentation puis retour quasi à la normale du délai; probablement problème Swisscom |
2017-07-31 |
Mise à jour kernel virtual et redémarrage des services |
2017-08-04 |
Après redémarrage de l'authentification sur init7, CHAP auth failed; ouverture d'un ticket et appel du support le lundi matin: les informations ont disparues de la DB RADIUS sans explication, regénération, reconfiguration. Résolution du problème un peu lente par init7: pas de réaction au mail à noc@, tél à 11h15 et envoi des données incorrectes à 14h, puis correctes un peu plus tard. Ajout d'un reset de la liaison le lundi pour voir (aussi délai reconfiguration) |
2017-10-08 |
Remplacement du StartSSL wildcard par une autre entreprise, 1 an avant son échéance car Chrome a décidé d'invalider des domaines supplémentaires -- pas Firefox; dans un an on réfléchira à LetsEncrypt, car ils devraient supporter les wildcard d'ici là. Aussi profité de désactiver l'algo 3DES qui est faible. |
2017-11-24 - 2017-12-10 |
ventilateur disque 1 en panne, température jusqu'à 42 degrés, à changer; profiter de faire màj kernel voir aussi RT#741 -- fait; surveiller /dev/sda car plus vieux et surtout a chauffé |
2018-01-12 |
màj kernel pour meltdown |
2018-02-15 |
Disque USB de sauvegarde déconnecté; peut-être bug kernel; e2fsck et comparaison en cours; /backup dans les VM ne marche plus; rebranché, vérifié; tout ok. Reste que /backup ne sera pas disponible partout avant redémarrage de chaque VM. |
2018-04-23 |
quelques soucis avec postgrey et quelques domaines gérés par Microsoft (load-balancing); work-around; passage à postgrey 1.37 (upstream) via le package backporté localement |
2018-05-01 |
mise à jour shakotay à jessie |
2018-08-14 |
rack disque-dur à changer; done 2018-08-15 19:50 |
2018-08-22 |
crash UPS à cause surcharge due à travaux |
2018-10-06 9:30 - 2018-10-08 11:00 |
init7 link down, à nouveau config changée |
2018-07-06 - 2018-11-17 |
infrastructure déplacée pour travaux: remise en place; test I/O et CPU/RAM et regén clé boot, aussi nouveau microcode installé (voir #743), mise à jour kernel en hold, test fw y.c. v6; testé que le qrunner de mailman est lancé après reboot. |
2019-03-05 |
changement temporaire UPS (batterie probablement défectueuse depuis 2019-03-01), redémarrage de tous les services |
2019-03-22 |
changement batteries ancienne UPS et tests |
2019-03-23 |
remise ancienne UPS à la place, redémarrage de tous les services; test rapide sans alim |
2019-04-14 |
kernel mis à jour, retester UPS détection offline, testé clé USB, compare rsync running |
2019-05-16 |
désactivation hyperthreading par arrêt de core virtuels dans rc.local sur virtual en raison vulnérabilités MDS |
2019-06-09 |
installé nouveau package microcode, nouveau kernel & clé USB; reboot ok |
2019-06-22 |
nouveau microcode et nouveau kernel (surtout patch SACK TCP), clé USB; recâblages; reboot ok |
2019-07-27 |
nouveau kernel, reboot |
2019-09-27 |
nouveau kernel, reboot |
2020-02-28 |
https://www.alphanet.ch/ plante avec erreur RSA (avec openssl et w3m, et fait erreur de trust avec Mozilla), mais les autres serveurs virtuels (wiki, stats) fonctionnent. Redémarré apache2, semble corriger le problème. Curieux. S'est encore reproduit sous jessie. Voir si se reproduit avec buster (pas encore observé) |
2020-08-03 8h-8h45 |
panne téléreseau |
2020-08-06 14h-14h20 |
mise à jour firmware modem UPC suite aux problèmes relevés avec OpenVPN? UDP (cf RT#912), semble corriger le problème |
2020-08-08 |
redémarrage virtual pour derniers tests liés à la mise à jour |
2020-08-06 |
Depuis à mise à jour de virtual à buster, les I/O ne sont plus aussi fluides qu'avant. Le scheduler CFQ n'existe plus et le défaut semble être un scheduler plus agressif orienté desktop. Divers work-arounds sont en cours de test (p.ex. utilisation du scheduler I/O BFQ, limitation des tailles I/O écriture), voir RT#911 semblent avoir montré leur efficacité maintenant. |
2020-10-03 - 2020-10-09 |
Problème UDP Cablecom: à la fois pour les deux VPNs et pour Jitsi. Basculement VPN-SNN sur init7 en attendant. Réouvert RT#912. Problème semble corrigé le 2020-10-09 15h15 par changement de fw modem. |
2020-10-23 |
Changement de modem UPC, en espérant que cela corrige le problème de pertes de paquets UDP découvert depuis le 2020-10-03 (deux VPN, VoIP, Jitsi). Voir RT#912. A l'air de marcher. |
2020-10-26 23:00 - 00:00 |
Panne UPC |
2020-12-09 23:00 - 2020-12-10 08:00 |
Problème certificat SNN pour 193.72.186.0/24, mis dans RT le prochain changement en 2022 |
2020-12-10 |
machine bloquée, beaucoup d'I/O, sync+reboot nécessaire; est-ce lié aux dernières màj? ou problème mod_perl sur 103, voir RT#951, désormais mise en place limitation cyclique Apache 103/104 et limite dure mémoire sur conteneurs |
2020-12-19 |
mise à jour du kernel de 4.19.0-10-amd64 à 13; test clé USB boot; recâblage électrique |
2020-12-25 |
Reconfiguration Ethernet / VLAN / 10GBit en fin d'après-midi (RT#900) |
2021-01-15 (soir), 2021-01-17 (après-midi) |
Investigations des problèmes de redémarrage systemd RT#956, plusieurs redémarrages nécessaires. Semble OK |
2021-01-31 |
bl.spamcop.net plus valable, remis en mars avec surveillance automatique, voire RT#966 |
2021-04-20 |
Panne net2000 7h20-8h30 environ (ampli en panne dans la région), re-panne autour de 8h47, remarche à 8h53, replanté à 9h13, ok à 9h15 |
2021-05-07 |
Panne init7 17h-17h51 |
2021-05-07 20:06-20:24 |
Mise à jour kernel virtual, redémarrage de tous les services |
2021-07-09 11:02-11:28 |
Mise à jour kernel virtual à -17, pas vraiment nouveau microcode 0x21, redémarrage de tous les services |
2021-09-02 |
UPS plus beaucoup de capacité (RT#646) |
2021-09-24 11:30 |
Changement certificat SSL https et IMAP/POP/SMTP cf RT#711 |
2021-09-24 soir |
changement enclosure disque bruyant |
2021-09-18 |
IDS un peu trop sensible aux erreurs naturelles auth/basic Apache2, tentative d'amélioration (RT#1024); semble mieux |
2021-09-24 midi ou début d'après-midi |
ajout ventilateur: effectué, en test, OK |
2021-10-15 17h15-17h30 |
Mise à jour kernel, suppression LED ventilateurs, ajout câble série (RT#1033) |
2021-11-20 17:35 |
Arrêt intempestif à cause test UPS (vide), cf RT#646 |
2021-11-24 |
reboot intempestif de tout en raison coupure de courant et UPS en panne |
2021-11-25 16h20-16h40 |
changement UPS, arrêt virtual pour tests |
2021-12-15 |
Activé SPF, DKIM et DMARC (en mode soft, sur lists.alphanet.ch et alphanet.ch), en raison des problèmes d'envoi de notifications de mailing-lists, de mailing-lists et du test de ping gmail, semble corrigé |
2022-01-21 |
Reboot virtual |
2022-02-05 13h30-14h15 |
remplacement CMOS battery et reconfig BIOS (notamment AHCI) et test ventilateur CPU (RT#1052) |