attention maintenance prévue lundi après midi

[copain des copeaux]

Bonjour à tous
Suite aux déboires informatiques de ces derniers jours, nous allons changer de serveur. Le forum sera donc indisponible pendant 24 h environ si tout va bien, plus si tout va moins bien.
La maintenance commencera lundi à 14h. Tous les messages seront récupérés. Le déplacement prévu ce vendredi n'a pas pu se faire. En effet en cas de problème, l'informaticien n'aurait pas pu rétablir le forum pendant le weekend.

( en fait la plupart des messages sont déjà copiés sur le nouveau serveur et il faudra juste injecter les dernières 24h. Pour les connaisseurs, le futur serveur fonctionne, il suffit juste de changer les dns et cela prend un peu de temps).


[message édité le 27 après midi suite à l'ajournement du changement des dns]

[woodpecker54]

Bon courage pour cette opération. J'ai eu la chance de me lever tôt ce matin et de passer un peu de temps auprès de notre forum avant qu'il ne parte pour le bloc opératoire

[DeD]

Hé Hé. Pareil.

[tienda]

Itou

[th60]

Bon courage à toute l'équipe, et que toutes les richesses de ce forum soit au maximum restaurées.
Bien cordialement

[dom.rkb]

je vais brûler quelques copeaux et prier Ste Wastringue.
Que le grand Copeau soit avec vous.

[copain des copeaux]

Merci! Il n'y a pas de risque de pertes de données. Elles sont déjà sur le nouveau serveur. Il faut juste faire pointer l'adresse du forum dessus. Par contre la "propagation" met toujours un peu de temps.

[alrj]

L'astuce, quand on peut prévoir la migration suffisamment longtemps à l'avance, c'est de diminuer le TTL des enregistrements DNS concernés, le passer par exemple à 300 (5 minutes) ou même 60. Une fois le nouveau TTL propagé, on peut lancer la migration, et la propagation de la nouvelle adresse se fait assez rapidement.
Bien sûr, il ne faut pas oublier de remettre un TTL correct après.

Quoi ? Ah, on n'est pas sur copaindesip ? Mince, désolé

[copain des copeaux]

lol là ca me dépasse total!
blague à part, à l'origine j'avais le projet de décliner copain des copeaux en copain des tuyaux, de l'électro, des autos etc. Pas avec ma bobine à chaque fois mais une plateforme de tutos certifiés. Bref un autre gros projet qui verra le jour quand j'aurai le temps c'est à dire pas gagné quoi...

[Klug]

Jouer sur le TTL (300 c'est une valeur tout à fait envisageable en prod') n'est pas la bonne solution parce qu'on ne contrôle pas le TTL dans les resolvers (oui, les gros FAI avec des resolvers menteurs, on pense à vous là).

Une des "bonnes" méthodes c'est le reverse-proxy qui va transférer de manière totalement transparente le trafic de l'instance source à l'instance destination (on remplace le daemon web par un reverse-proxy sur la VM source, on synchronise la DB et voilà, coupure de quelques minutes seulement).
Une fois que la VM source ne reçoit plus de trafic (quelques minutes si les TTL sont respectés, plusieurs heures sinon), on shoote le reverse-proxy et voilà, fini.

[woodpecker54]

Si le nouvel hébergeur propose une adresse IP fixe (ou une URL technique), il est aussi possible de mettre en place une redirection de l'ancien site vers le nouveau. Et ainsi, l'interruption est très courte, de l'ordre de quelques minutes.

[copain des copeaux]

Si le nouvel hébergeur propose une adresse IP fixe (ou une URL technique), il est aussi possible de mettre en place une redirection de l'ancien site vers le nouveau. Et ainsi, l'interruption est très courte, de l'ordre de quelques minutes.

j'ai une ip fixe. Tu pourrais me faire un petit fichier à mettre à la racine de l'ancien site stp?

[woodpecker54]

Si le nouvel hébergeur propose une adresse IP fixe (ou une URL technique), il est aussi possible de mettre en place une redirection de l'ancien site vers le nouveau. Et ainsi, l'interruption est très courte, de l'ordre de quelques minutes.

j'ai une ip fixe. Tu pourrais me faire un petit fichier à mettre à la racine de l'ancien site stp?

Pas de problème, je vais regarder ça. Normalement, un fichier .htaccess (qui doit déjà exister) permet de le faire. Je vias regarder la syntaxe exacte.

[woodpecker54]

Bon, je dois te prévenir que je ne suis pas un spécialiste de ce genre de manip, moi je suis plutôt côté développement

Mais en mettant ceci au début du fichier .htaccess à la racine de l'ancien site, ça devrait marcher :

Code : Tout sélectionner

RewriteEngine On
RewriteBase /
RewriteRule .* https://1.2.3.4 [R=307,L]

Bien sûr, tu remplaces 1.2.3.4 par l'adresse IP du nouveau site.
Le code 307 indique que c'est temporaire, parce qu'au final l'URL du site ne changera pas.

[Klug]

Je peux ?
Ça ne fonctionnera pas.

Parce que la redirection vers l'IP (et pas un FQDN) en face implique (entre autre) que :

• le vHost soit configuré sur l'IP (pas l'idée du siècle, sauf si le forum est le seul site sur l'instance)
• l'appli qui répond sur l'URL (phpBB) doit être configurée pour utiliser l'IP comme URL de base (et pas https://forum.copaindescopeaux.fr/) et ça ne va pas trop lui plaire à phpBB
• toutes les sessions (stockées dans la base et générées par rapport à l'URL actuelle) doivent être détruites (ça, à la rigueur, c'est juste une question de se reloger, éventuellement en shootant ses sookies)
• il n'y aura plus de SSL "propre" (parce que letsencrypt - ou autre non auto-signé) sur une IP, c'est juste pas possible

Il y aura le même problème (à part le vHost et le SSL - si c'est bien fait) en utilisant une URL intermédiaire.
Aussi, ne pas oublier de déplacer le certificat et la clef privée, au fait, pour ne pas avoir à attendre les DNS pour les regénérer.

La dernière migration de forum que j'ai faite en mai dernier (1 million de posts environ à l'époque pour 39'000 inscrits et 700 actifs), la coupure a été de moins d'un quart d'heure.
D'une instance dédiée au Quebec à une instance dédiée chez moi.
Mais bon, OSEF.

[copain des copeaux]

bon ben je confirme que ca me passe bien au dessus! On cherche toujours des informaticiens pour gérer le serveur et la maintenance si ca dit quelqu'un. La suite en mp si ca vous tente!

[woodpecker54]

Je peux ?
Ça ne fonctionnera pas.

Parce que la redirection vers l'IP (et pas un FQDN) en face implique (entre autre) que :

• le vHost soit configuré sur l'IP (pas l'idée du siècle, sauf si le forum est le seul site sur l'instance)
• l'appli qui répond sur l'URL (phpBB) doit être configurée pour utiliser l'IP comme URL de base (et pas https://forum.copaindescopeaux.fr/) et ça ne va pas trop lui plaire à phpBB
• toutes les sessions (stockées dans la base et générées par rapport à l'URL actuelle) doivent être détruites (ça, à la rigueur, c'est juste une question de se reloger, éventuellement en shootant ses sookies)
• il n'y aura plus de SSL "propre" (parce que letsencrypt - ou autre non auto-signé) sur une IP, c'est juste pas possible

Il y aura le même problème (à part le vHost et le SSL - si c'est bien fait) en utilisant une URL intermédiaire.
Aussi, ne pas oublier de déplacer le certificat et la clef privée, au fait, pour ne pas avoir à attendre les DNS pour les regénérer.

La dernière migration de forum que j'ai faite en mai dernier (1 million de posts environ à l'époque pour 39'000 inscrits et 700 actifs), la coupure a été de moins d'un quart d'heure.
D'une instance dédiée au Quebec à une instance dédiée chez moi.
Mais bon, OSEF.

Comme je le disais, je ne suis pas spécialiste, il est donc fort probable que tu aies raison

[xlemoine]

Bonjour à tous,
Merci pour vos conseils, le changement de serveur s'est bien passé.

Juste un petit point que vous avez oublié dans vos conseils : lors d'un passage d'un serveur à un autre, les outils "dupliqués" font appel à des ressources souvent encodées via le nom de domaine. Hors, à partir du moment où "l'ancien" site est toujours en fonctionnement, en faisant un test, on ne peut le faire qu'en prenant en compte 2 choses :
- les ressources servies à partir du nom de domaine vont bien répondre (puisque le domaine est toujours actif sur le premier serveur), on ne peut donc pas vérifier la copie avant application des pointages,
- le test sur le nouveau serveur ne peut se faire qu'à partir d'un nom de domaine différent, ce qui peut poser alors des soucis de fonctionnement liées encore une fois aux ressources chargées (ressources pouvant être bloquées en cross par le serveur initial). En associant cela à une montée de version de php + un fonctionnement serveur différent (ne chargeant pas les mêmes modules Apache), il fallait être présent et vérifier le fonctionnement avant, pendant et après le transfert.

Tout s'est donc correctement déroulé et il a fallu simplement finaliser la transition en vérifiant les redirections et fonctionnements divers (un gros htaccess avec de la réécriture entre le site et le forum et des règles à vérifier). Il reste des points qui devront être réglés par Nicolas au niveau des personnes qui ne peuvent plus se logguer suite à la perte de certaines données après le crash précédent, mais vous semblez (pour plusieurs participants ici) savoir ce que cela implique, vous pourrez sans doute conseiller Nicolas !!

Si vous constatez des soucis de fonctionnement, parlez en à Nicolas qui se chargera de faire remonter si nécessaire ces messages (je ne suis pas très souvent sur le forum je l'avoue !!).

A bientôt !!
Xavier

[Klug]

Tricher sur /etc/hosts (et/ou utiliser un resolver menteur) permet de pointer sur la nouvelle VM avec le bon FQDN.
Il n'y a que les autres services en ligne sur lesquels on n'a pas la main (pour pouvoir tricher) qui ne fonctionneront pas.

Enfin, bon, encore une fois, OSEF.

[Artzain]

Et bien merci pour le travail effectué. Pour ma part je ne comprends qu'un mot sur deux de tout ce qui a été dit. .

Encore bravo et merci.