déplacement serveur CULButte.be vers OVH

De façon à réduire le temps de passage d'un serveur à l'autre, j'ai réduit le "lease time" (Time to live ? je ne sais pas exactement comment ça s'appelle) à 310 secondes dans le DNS.

Càd qu'après un accès DNS, l'adresse IP reçue par votre PC restera valable maximum 310 secondes. Ensuite, relecture DNS pour avoir l'IP.
Cela force la relecture régulière du DNS, ce qui fait que maximum 310 secondes après le basculement de serveur, vous devriez être redirigé vers le bon serveur.

Bon, mais encore un peu de préparation avant cet essais.

;-)

Bon, si je n'ai eu aucun problème avec l'exportation DB et fichiers, et l'importation vers le serveur OVH, j'ai des problèmes pour faire tourner tout ça !

C'est une bête question de droits de l'utilisateur MySQL sur la base de données pour Culbutte...

Ce n'est pas moi qui avait créé cette base MYSQL et visiblement l'utilisateur n'a pas les droits nécessaires.
Même avec PhpMyAdmin, je bloque... je ne dois pas avoir les droits suffisants pour modifier les droits sur cette base !

Faut dire que je ne suis pas un pro en MySQL !

Je vérifie ça demain...
sinon, si un de vous à l'habitude des droits dans MySQL, on regarde ce vendredi ?

Je pense avoir compris ce problème de base de données, de userid et de privilèges MySQL dans phpMyAdmin.

J'ai recréé le userid et la base de données. Ca devrait fonctionner !

Ok, on y va ;-)

Tout s'est très bien passé cette fois, à l'exeption de messages d'erreur Drupal / MySQL lors des premiers accès à des pages de CULButte.be

La raison était simple : j'avais fait les mises à jour Drupal et modules il y a quelques jours sur l'ancien site, et fait ces mises à jour hier sur le serveur OVH. Résultat, des mises à jour plus récentes pour certains modules sur le serveur OVH.

J'ai simplement fait tourner "update.php", prévu pour cela... et tout est rentré dans l'ordre.

En fait, l'exportation / importation d'un site vers un autre serveur est très facile !

• si vous gérez votre propre DNS, ou si le DNS de votre registrar le permet, descendre le "Time to live" (ou cache time) au minimum pour votre domaine, par exemple à 310 secondes, cela pour éviter que pendant DES heures, certains utilisateurs reçoivent l'adresse IP de l'ancien serveur, et d'autres celles du nouveau
• faire les mises à jour Drupal sur le serveur d'origine. Le but est d'éviter de trop grande différence de version entre les table MySQL d'origine, et les versions des codes PHP sur le serveur de destination
• faire les mises à jour sur le serveur de destination : il est important de mettre à jour le serveur de destination APRES celui d'origine. Je ne sais pas exactement ce qui se passerait en cas de régression de version (version d'un module plus ancienne sur le nouveau serveur)... "Update.php" est prévu pour faire des mises à jour, pas des retours en arrière
• mettre le site d'origine en mode maintenance
• archiver et compresser en .tar.gz le dossier d'origine (../drupal/site/culbutte.be)
• placer cette archive à un endroit sur l'ancien serveur accessible sur le Net
• depuis un accès console (SSH) sur le nouveau serveur, télécharger le fichier compressé : wget www.votreancienserveur.be/culbutte.tar.gz par exemple. C'est ce qui prend le plus de temps si votre ancien PC est derrière une ligne ADSL (dans mon cas presque 20 minutes à 740 Kbps upload)
• décompacter l'archive sur le nouveau serveur dans le dossier .../drupal/sites
• vérifier que les permissions sont correctes (il faut un owner www-data:www-data sur le dossier drupal/sites/culbutte, sinon Apache2 ne pourra pas écrire dans ce dossier.
• sur le serveur d'origine, sauver la base de donnée, par exemple avec le module "Backup and Migrate", ou avec phpMyAdmin. Avec Backup and Migrate, le script vous propose de sauver le fichier compressé directement sur votre PC
• sur le nouveau serveur, créer dans MySQL le userid "culbutte", la base de données, et lui donner les bons privilèges. L'idéal est un userid spécifique à ce site CULButte.be. Dans ce cas, par sécurité, ne donner des permissions QUE sur la base de données CULButte.
• avec MySQL (ou en console, ou autre programme), importer le fichier backup MySQL qui se trouve sur votre PC.
• définir le site web CULButte.be dans les "sites-available" et site-enable" d' Apache2
• Provisoirement, définir le nom du site dans la table /etc/hosts du nouveau serveur (car le DNS n'est pas encore à jour). Mettre l'IP du nouveau serveur
• Faire un "apache2 -t" pour tester si pas d'erreur
• "/etc/init.d/apache2 reload" pour recharcher la configuration Apache2
• pour vérifier si le nouveau serveur fonctionne, vous devez arriver avec votre navigateur sur la nouvelle IP : définir provisoirement le nom du site avec sa nouvelle IP dans la table /etc/hosts de votre Pc de travail
• tester, vérifier, corriger si nécessaire. En général, ce sont des erreurs soit sur des droits sur des dossiers, soit sur des privilèges MySQL, soit une mauvaise définition du VirtualHost Apache2.
• si tout est normal, repasser le site en mode normal pour qu'il soit accessible aux utilisateurs
• Après "un certain temps", dans mon cas 310 secondes car j'avais pu diminuer le "time to cache" DNS à 310 secondes pour ce domaine, le DNS sera correcte (attention, il l'est pour VOUS, pas nécessaire pour le monde entier). Ne PAS oublier de supprimer les définitions provisoires dans /etc/hosts sur votre serveur et sur votre Pc de travail
• Quand vous êtes certain que tout est normal, remonter le "time to cache" dans votre DNS. 310 secondes c'est beaucoup trop bas. Ca multiplie les accès DNS, donc ça charge le DNS et ça ralentit vos utilisateurs... Une valeur de 43200 secondes est une bonne idée. Vos utilisateurs iront relire le DNS que toutes les 12 heures (vous ne changez pas de serveur souvent...)

Il vous reste à donner VOTRE avis : est-ce plus rapide qu'avant ?

Voir la Gallerie Photos aussi