voilà pourquoi j'avais proposé ce genre de chose dans une de mes demandes... (220 de mémoire...). C'est vrai qu'en tant qu'hébergé t'as plutôt tendance à te reposer sur ton hébergeur (surtout que tout le monde n'a pas forcément le temps ni l'énergie pour mettre en place de la redondance...).
Bon moi c'est le bordel avec 3 sites qui pourraient potentiellement servir (pas testé) mais bon au moins il reste un moyen d'information ;-) entre une ML sur gna / une sur Free, sf.net / gna.org / endor (à défaut de tuxfamily.org pour l'instant...). Et bien sûr linuxfr pour prévenir par encore une autre voie (c'est un peu réflexe quand même...).
M'enfin chui loin d'être à l'abri (je touche du bois ;-) )
Bon courage yeupou (euh Mathieu...) pour la remise en route.
Il y a une raison particulière pour que ça soit down et une date (prévisionnelle) de remise en service ? (bah ya pas le feu non plus, tu peux prendre le WE : s'il le faut on se débrouillera bien). Quels sont les risques de perte de données ?
La raison théorique, c'est qu'on dispose d'une plage d'IP qui est attribuée dans un autre batiment que celui dans lequel sont les machines. On doit donc faire le transfert. Ce qui est lourd, c'est qu'on ait pas été prévenu à l'avance (bon, en même temps on nous offre la BP et cette plage IP, on ne va pas donc trop chipoter).
Théoriquement ça aurait du être reparti hier dans la journée. Je constate que ce n'est pas encore le cas. Dans tout les cas, ça tournera lundi - ça doit tourner lundi.
Normalement les risques de pertes de données sont proches de 0. Certes les machines vont connaitre un transfert... mais ça sera fait proprement. Et dans le pire des cas, on dispose de backups sur une machine qui n'est pas concernée par ce déplacement.
A moins que toutes tes machines soient dans une seule baie et qu'ils bougent la baie en une fois, ils auraient quand même pu te garder une bécane opérationnelle... en ayant la main sur le routage ça aurait permis de conserver quelques services.
Si tu n'as la main que sur les DNS, pas besoin de faire quoique ce soit, le temps de faire l'aller-retour en modifiant l'IP dans le primaire et le secondaire, tu risques de te manger une propagation de 1 à 2 jours (puis idem dans l'autre sens) donc encore plus d'indisponibilité au final...
C'est tout de même étonnant que ça prenne autant de temps pour un "simple" transfert physique (je suppose bien sûr qu'il n'y a que les serveurs à éteindre proprement, décâbler, bouger, recâbler, redémarrer...). zont oublié de redémarrer tes serveurs ? ou alors les serveurs ne reprennent pas leur @IP au démarrage ?
Les mails en cours d'envoi des ML sont stockés dans l'intermède et vont tous être renvoyés au redémarrage ? Ah on peut plus envoyer sur la ML... (je viens d'essayer).
Pour la prochaine fois ce serait pas mal qu'ils fassent ça en semaine, genre tôt le matin vers 6h... c'est pas les horaires des geeks ;-) et yaura tout le monde sur le pont. M'enfin comme tu dis c'est cadeau, donc bon... c'est simplement des suggestions. Tu es en contact avec eux quand même ? Pour savoir quand il va falloir que tu ailles sur place ? :-(
Je te propose de lister les points à améliorer (ça permettra de voir comment réagir sur ce genre de souci...). En ce qui me concerne :
- identifier la cause si elle est connue
- identifier les services affectés (là tous, un peu dommage pour prévenir les utilisateurs...)
- annoncer le problème (cette fois-ci via linuxfr) et une date __prévisionnelle__ de reprise
- annoncer la reprise et debriefer sur les points restants à vérifier (s'il y en a : là aucun)
Autant le faire à chaud, ça permet d'avoir des retours pertinents et de faire un peu de publicité sur la manière de se renseigner la prochaine fois (tu n'as pas été trop assailli de mails au moins ?!).
La cause : externe à gna, problème réseau sérieux chez l'hebergeur.
Services affectés : tous, en effet
Annoncer le problème : j'ai crée une tache spécifique à cette question, je t'y ai mis en CC.
Annoncer la reprise : idem, et rien à vérifier (en fait si, j'ai passé un petit temps à saisir que mailman a foutu des locks sans les virer)
Pour la manière de se renseigner la prochaine fois, je pense qu'il faut être sur de son coup, et donc avec une solution parfaitement maitrisée. Ceci dit, quand la page "emergency" sera en place, ça sera annoncé.
# Tiens,
Posté par lezardbreton . Évalué à 4.
Alors, l'hebergeur, c'est Free ou pas ?
# scusez moi de vous demander pardon
Posté par Greg . Évalué à 1.
[^] # Re: scusez moi de vous demander pardon
Posté par chl (site web personnel) . Évalué à 0.
[^] # Re: scusez moi de vous demander pardon
Posté par Greg . Évalué à 7.
Ok =======>[] (tiens ça s'est rafraichi ce soir)
[^] # Re: scusez moi de vous demander pardon
Posté par Olivier Grisel (site web personnel) . Évalué à 2.
# ah la redondance ça a du bon parfois ;-)
Posté par BAud (site web personnel) . Évalué à 2.
Bon moi c'est le bordel avec 3 sites qui pourraient potentiellement servir (pas testé) mais bon au moins il reste un moyen d'information ;-) entre une ML sur gna / une sur Free, sf.net / gna.org / endor (à défaut de tuxfamily.org pour l'instant...). Et bien sûr linuxfr pour prévenir par encore une autre voie (c'est un peu réflexe quand même...).
M'enfin chui loin d'être à l'abri (je touche du bois ;-) )
Bon courage yeupou (euh Mathieu...) pour la remise en route.
Il y a une raison particulière pour que ça soit down et une date (prévisionnelle) de remise en service ? (bah ya pas le feu non plus, tu peux prendre le WE : s'il le faut on se débrouillera bien). Quels sont les risques de perte de données ?
[^] # Re: ah la redondance ça a du bon parfois ;-)
Posté par Anonyme . Évalué à 2.
Théoriquement ça aurait du être reparti hier dans la journée. Je constate que ce n'est pas encore le cas. Dans tout les cas, ça tournera lundi - ça doit tourner lundi.
Normalement les risques de pertes de données sont proches de 0. Certes les machines vont connaitre un transfert... mais ça sera fait proprement. Et dans le pire des cas, on dispose de backups sur une machine qui n'est pas concernée par ce déplacement.
[^] # ils auraient pu faire l'opération en plusieurs fois...
Posté par BAud (site web personnel) . Évalué à 2.
Si tu n'as la main que sur les DNS, pas besoin de faire quoique ce soit, le temps de faire l'aller-retour en modifiant l'IP dans le primaire et le secondaire, tu risques de te manger une propagation de 1 à 2 jours (puis idem dans l'autre sens) donc encore plus d'indisponibilité au final...
C'est tout de même étonnant que ça prenne autant de temps pour un "simple" transfert physique (je suppose bien sûr qu'il n'y a que les serveurs à éteindre proprement, décâbler, bouger, recâbler, redémarrer...). zont oublié de redémarrer tes serveurs ? ou alors les serveurs ne reprennent pas leur @IP au démarrage ?
Les mails en cours d'envoi des ML sont stockés dans l'intermède et vont tous être renvoyés au redémarrage ? Ah on peut plus envoyer sur la ML... (je viens d'essayer).
Pour la prochaine fois ce serait pas mal qu'ils fassent ça en semaine, genre tôt le matin vers 6h... c'est pas les horaires des geeks ;-) et yaura tout le monde sur le pont. M'enfin comme tu dis c'est cadeau, donc bon... c'est simplement des suggestions. Tu es en contact avec eux quand même ? Pour savoir quand il va falloir que tu ailles sur place ? :-(
[^] # Re: ils auraient pu faire l'opération en plusieurs fois...
Posté par Anonyme . Évalué à 1.
Ceci dit, on est en contact avec un herbergeur motivé par un miroir, qui pourrait peut-être faire un DNS secondaire.
Je ne suis pas sur Paris, c'est Loic Dachary ou Vincent Caron ou Henri Precheur qui doit s'occuper de ce bintz.
[^] # Re: ils auraient pu faire l'opération en plusieurs fois...
Posté par Anonyme . Évalué à 1.
[^] # c'est reviendu, merci !
Posté par BAud (site web personnel) . Évalué à 2.
https://gna.org/forum/forum.php?forum_id=388(...)
Je te propose de lister les points à améliorer (ça permettra de voir comment réagir sur ce genre de souci...). En ce qui me concerne :
- identifier la cause si elle est connue
- identifier les services affectés (là tous, un peu dommage pour prévenir les utilisateurs...)
- annoncer le problème (cette fois-ci via linuxfr) et une date __prévisionnelle__ de reprise
- annoncer la reprise et debriefer sur les points restants à vérifier (s'il y en a : là aucun)
Autant le faire à chaud, ça permet d'avoir des retours pertinents et de faire un peu de publicité sur la manière de se renseigner la prochaine fois (tu n'as pas été trop assailli de mails au moins ?!).
[^] # Re: c'est reviendu, merci !
Posté par Anonyme . Évalué à 1.
La cause : externe à gna, problème réseau sérieux chez l'hebergeur.
Services affectés : tous, en effet
Annoncer le problème : j'ai crée une tache spécifique à cette question, je t'y ai mis en CC.
Annoncer la reprise : idem, et rien à vérifier (en fait si, j'ai passé un petit temps à saisir que mailman a foutu des locks sans les virer)
Pour la manière de se renseigner la prochaine fois, je pense qu'il faut être sur de son coup, et donc avec une solution parfaitement maitrisée. Ceci dit, quand la page "emergency" sera en place, ça sera annoncé.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.