Posts Tagged ‘migration’

World IPv6 Launch le 6 juin 2012

Monday, May 21st, 2012

Après avoir participé à l’IPv6day l’année dernière, c’est maintenant le World IPv6 Launch le mercredi 6 juin 2012. Si l’IPv6day a été l’occasion de tester IPv6 en production pendant une journée, le but du World IPv6 Launch est d’activer définitivement l’IPv6 ! C’est ainsi que les sites comme Google, Facebook, Youtube, Yahoo!, Bing… et Evolix seront désormais directement accessibles en IPv6 !

Si votre serveur est hébergé chez Evolix, nous activerons ainsi l’IPv6 sur votre serveur (sauf contre-indications) avec des règles de firewall similaires à celles en IPv4. Pour vos services (sites Internet, messagerie, etc.), il suffira ainsi d’ajouter un enregistrement DNS AAAA vers votre adresse IPv6 (2a01:9500::XXX) pour les rendre accessibles en IPv6. D’ici le 30 mai, vous pouvez d’ailleurs inscrire votre site Internet sur worldipv6launch.org (et ça ne fera pas de mal à votre référencement ;-). Pour plus d’infos, contactez nous par les moyens habituels (Ticket, mail, IRC, Twitter, machine à café, bière, etc.).

WORLD IPV6 LAUNCH is 6 June 2012 – The Future is Forever

Autres exemples de migration Etch->Lenny [1]

Sunday, January 24th, 2010

La fin du support officiel de Debian Etch approchant, il est grand temps de migrer vers Lenny pour les machines pas encore à jour. Après un premier exemple de migration Debian Etch->Lenny, je poursuis la série avec des informations tirées de plusieurs migrations récentes sur des serveurs en production.

Je ne rappellerais pas toutes les précautions nécessaires (tests préalables, sauvegardes, désactivations des services, etc.) ni la classique question  sur  “quand faut-il migrer ?”, vous trouverez tout cela dans mes exemples précédents. Je rappelle simplement l’idée de base : prendre les précieuses Release Notes, mettre à jour le fichier sources.list, puis exécuter les commandes aptitude update && aptitude upgradex, puis mettre-à-jour les services les plus critiques via aptitude install <PACKAGE>, et enfin aptitude dist-upgrade && aptitude dist-upgrade (répéter dist-upgrade est souvent nécessaire).

Passons désormais aux différentes remarques sur ces migrations :

– PostgreSQL : on passe de la version 8.1 à 8.3. Notez qu’il s’agit de paquets différents, il est donc possible de garder la version 8.1 en Etch, et d’installer en parallèle la version 8.3, afin de faciliter encore plus la migration. Pour migrer les données, on réalisera un dump avec pg_dumpall qui sera réinjecté dans la nouvelle base. On pourra ensuite adapter le port dans postgresql.conf pour passer la version 8.3 en production.

– phpPgAdmin : avec PostgreSQL 8.3, on ne peut plus se connecter à la table template1 : c’est le comportement par défaut de phpPgAdmin, qu’on devra donc modifier en mettant postgres à la place (pour la variable $conf[‘servers’][0][‘defaultdb’] dans le fichier config.inc.php)

– Apache : la configuration de l’alias /icons/ est déplacé dans le fichier mods-available/alias.conf, il peut donc faire doublon avec la déclaration dans apache2.conf, ce qui sera signalé via le warning suivant : [warn] The Alias directive in /etc/apache2/apache2.conf at line 240 will probably never match because it overlaps an earlier Alias. Commenter les directives dans le fichier apache2.conf résoudra ce petit soucis.

– OpenLDAP : on passe d’une version 2.3 à 2.4, mais le plus marquant pour la migration est que cela force le processus à tourner avec un utilisateur/groupe dédié. Pour diverses raisons (dist-upgrade interrompu par exemple), on pourra rencontrer des soucis plus ou moins alarmants. Ainsi, j’ai pu rencontrer cette erreur :
bdb(dc=example,dc=com): PANIC: fatal region error detected; run recovery
bdb_db_open: database “dc=example,dc=com” cannot be opened, err -30978. Restore from backup!
backend_startup_one: bi_db_open failed! (-30978)
slap_startup failed
On veillera donc sur l’utilisateur/groupe propriétaire des fichiers dans le répertoire /var/lib/ldap et, au besoin, on ajustera : chown -R openldap:openldap /var/lib/ldap/
Mon conseil : mettre-à-jour le paquet slapd de façon spécifique avant le dist-upgrade

– Postfix : on passe de 2.3 à 2.5. On notera simplement la valeur par défaut de $smtp_line_length_limit characters qui passe à 990, ce qui coupe les lignes trop longues pour se conformer au standard SMTP. Si cela posait problème, on pourrait revenir à l’ancien comportement en positionnant smtp_line_length_limit=0

– SpamAssassin : l’utilisant en stockant la configuration des utilisateurs dans un annuaire LDAP, le daemon spamd s’est mis à râler : cannot use –ldap-config without -u
Le problème sera résolu en ajoutant l’option -u nobody, ce qui fera tourner spamd en tant que nobody (ce qui n’est pas une mauvaise chose, au contraire).

– Amavis : apparemment, lors de la détection d’un virus, le code retourné n’est plus 2.7.1 mais 2.7.0 : 2.7.0 Ok, discarded, id=13735-07 – VIRUS: Eicar-Test-Signature
Rien de bien grave, mais cela a nécessité d’adapter un plugin Nagios pour qu’il attende le bon code de retour.

– Courier-imapd-ssl : après une mise-à-jour gardant mon fichier /etc/courier/imapd-ssl actuel, j’obtenai des erreurs avec certains clients IMAP :
couriertls: accept: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
En regardant de plus près, certaines directives changent dans ce fichier de configuration, et il est donc conseillé de repartir du fichier proposé par Lenny, et d’y apporter ses modifications (souvent, cela se limite à préciser le certificat).

– Horde : si vous utilisez une base de données pour stocker les paramètres ou autres, la paquet php-db (déjà en Recommends: en Etch) est d’autant plus nécessaire, sous peine d’obtenir l’erreur : PHP Fatal error:  _init() [<a href=’function.require’>function.require</a>]: Failed opening required ‘DB.php’ (include_path=’/usr/share/horde3/lib:.:/usr/share/php:/usr/share/pear’) in /usr/share/horde3/lib/Horde/DataTree/sql.php on line 1877

– Sympa : on attaque là le cauchemard de mes migrations. À chaque fois, tellement de soucis majeurs et mineurs, que j’ai l’impression d’être le seul à utiliser ce paquet. Voici en vrac tous les soucis rencontrés : les accents dans les descriptions ont sautés (une sorte de double encodage) et cela a nécessité des corrections manuelles, la table logs_table doit être créée à la main (j’utilise Sympa avec PostgreSQL), et enfin une typo surprenante un “GROUP BY” à la place d’un “ORDER BY” (j’ai ouvert le bug #566252 à ce sujet).

– Asterisk : on passe de la version 1.2 à la version 1.4. Lors de la migration, j’ai constaté un bug étrange, le fichier modules.conf qui charge les modules additionnels a disparu. Du coup, sans lui, Asterisk ne charge pas les modules nécessaires (SIP, etc.). Il a donc fallu le restaurer.

– udev : le meilleur ami des sysadmins (ou pas). Si les migrations douloureuses Sarge->Etch sont loin derrière nous, il reste néanmoins quelques blagues. La dernière en date a été un renommage des interfaces réseau : eth0->eth1 et eth1->eth2. Classique mais étonnant, ce genre d’humour est sensé être dépassé grâce aux “persistent rules” qui nomment les interfaces en fonction de l’adresse MAC. À rester vigilant sur ce point avant le redémarrage donc.

Voilà pour les remarques. Vous noterez que je n’ai pas abordé le noyau Linux. C’est parce que pour la majorité de nos serveurs, ils sont gérés de façons spécifiques (au lieu d’utiliser les noyaux officiels Debian). Ainsi, ils restent dans leur version actuelle (2.6.31 à cette heure) pendant la migration. Bien sûr, cela n’empêche pas d’effectuer un redémarrage de la machine suite à la mise-à-jour : cela permet de s’assurer que tout est bien en place et le sera toujours après un éventuel redémarrage d’urgence.

Rendez-vous pour de prochaines migrations !

New GPG key

Monday, May 11th, 2009

With last attacks against SHA-1 digest algo, I create a new GPG key (following instructions from Daniel Kahn Gillmor):

pub   4096R/B8612B5D 2009-05-10
uid                  Gregory Colpart <reg@gcolpart.com>
uid                  Gregory Colpart (Evolix) <reg@evolix.fr>
uid                  Gregory Colpart <reg@debian.org>
sub   4096R/7D40310B 2009-05-11

A good excuse for beer^Wkey exchange next weeks :-)

Fichier special /dev/megaraid0 pour les noyaux Linux récents

Sunday, May 10th, 2009

En février 2008, la gestion du fichier spécial pour le management des cartes SCSI Megaraid (en général, /dev/megaraid0) a changé dans le noyau Linux. Auparavant, on notait la présence de megadev dans /proc/devices, car un numéro majeur (et dynamique) de périphérique lui était attribué. Les différents scripts utilisaient donc des scripts ressemblant à :

MAJOR=`grep megadev /proc/devices|awk '{print $1}'`
mknod /dev/megadev0  c $MAJOR 0

Mais un numéro majeur ne semblait pas utile, car seul un fichier spécial est nécessaire (même avec plusieurs cartes Megaraid) et le numéro mineur n’était jamais utilisé. Cela a donc changé à partir du noyau Linux 2.6.25, et c’est désormais un numéro mineur (et dynamique) et un numéro majeur correspondant à misc qui définit le périphérique /dev/megaraid0. On retrouve ainsi des bugreports chez Debian (#399783) et Gentoo (#233295) à propos de ce changement.

Concrètement, ce matin lors d’une mise-à-jour d’un noyau Linux de 2.6.21 en 2.6.28, le fichier spécial /dev/megaraid0 avec les numéros majeur/mineur 253/0 n’était plus utilisable par les outils de management du RAID. La suppression de ce fichier et l’installation d’udev a permis de retrouver un /dev/megaraid0 fonctionnel.

Driver bnx2 du noyau Lenny et carte Broadcom NetXtreme II

Friday, May 8th, 2009

Le driver bnx2 du noyau Linux 2.6.26 de Debian Lenny (et du 2.6.24 d’half-and-etch) nécessite un firmware pour fonctionner avec les cartes réseau Broadcom NetXtreme II (présentes par exemple sur les serveurs DELL PowerEdge 1950/2950), au contraire du noyau Linux 2.6.18 de Debian Etch. Lors de la mise-à-jour vers l’un de ces noyaux, il faut donc installer le paquet firmware-bnx2 (section non-free) et s’assurer de mettre à jour les images initramfs (update-initramfs -u -k all).

Migration from GNU Arch to Git for Horde packages

Sunday, May 3rd, 2009

All Horde packages (horde3, imp4, kronolith2…) were in GNU Arch repository. After Lenny release, we decided to migrate to Git. Git has a lot cool features, and I was convinced by Pierre Habouzit talk about Packaging with Git. Technically, I used git-archimport to keep all history of packaging. Each package has a Git repository with some branches: upstream, upstream+patches, upstream+repack (if needed), pristine-tar, debian-sid (imported from GNU Arch) and debian-<release>. The hardest step was to set up a common ancestor for debian-sid and upstream branches: I found git-merge-unrelated-branch script to do it automagically. I write guidelines for packaging Horde with Git on Debian Wiki with some notes about migration from GNU Arch to Git. Comments welcome!

Chroot SSH et PTY allocation avec Debian Lenny

Saturday, April 25th, 2009

Pour mettre en place des serveurs de backup, j’utilise un script chroot-ssh.sh qui permet la construction d’un chroot minimal pour faire tourner un serveur SSH et faire du rsync. Avec la mise-à-jour vers Lenny, l’allocation PTY réalisée par SSHD change : il ne semble plus possible de mettre en place un serveur SSH sans monter PROCFS et DEVPTS. Sans cela, on rencontre les erreurs suivantes côté serveur SSH :

debug1: Allocating pty
openpty: No such file or directory
session_pty_req: session 0 alloc failed

Si uniquement DEVPTS est monté, et pas PROCFS :

debug1: Allocating pty
openpty: returns device for which ttyname fails.

Voici donc les étapes pour lancer le serveur SSH chrooté avec Debian Lenny :

#  chroot /backup/jails/myserver mount -t proc proc-chroot /proc/
#  chroot /backup/jails/myserver mount -t devpts devpts-chroot /dev/pts/
#  chroot /backup/jails/myserver /usr/sbin/sshd > /dev/null

Un exemple de migration Debian Etch->Lenny [0]

Sunday, April 19th, 2009

Dans la même optique que mes précédents exemples de migration Debian Sarge->Etch ([0], [1], [2] et [3]), je repars sur une série portant sur des migrations Debian Etch->Lenny. Je rappelle rapidement le principe : j’administre une centaine de serveurs pour plusieurs dizaines de sociétés, et la plupart vont être concernés par une migration vers Debian Lenny d’ici un an. Je vais en choisir quelques uns pour illustrer les opérations nécessaires et problèmes recontrés. Et j’incite tout le monde à faire de même afin d’avoir de multiples astuces disponibles sur le web.

Pour ce premier post, la question classique : quand faut-il migrer sa machine vers Debian Lenny ? Tout d’abord, Etch reste maintenu environ un an après la sortie de Lenny, soit jusqu’en février 2010. Il n’y a donc aucune raison d’être pressé à migrer si l’on a pas besoin de nouveaux logiciels. Et surtout, je recommande le principe de précaution, à savoir attendre un certain temps ce qui permettra d’avoir une grande quantité d’informations disponibles sur Internet (ressources Debian, moteurs de recherche, blogs). Enfin, il est important de bien planifier sa migration en fonction du métier de la société (haute/basse saison, vacances, etc.).

Évidemment, les précautions suivantes sont nécessaires : faire des essais de migration sur des serveurs de test, avoir des backups tout frais, couper les services durant la migration et bien prévenir à l’avance tous les utilisateurs et personnes concernées.

Entrons dans le vif du sujet. Au menu, un serveur web situé chez un hébergeur low-cost français. Ce serveur fait parti d’un pool de plusieurs serveurs (load-balancing via du round-robin DNS), donc il faut au préalable le désactiver et attendre que le time-to-live le rende totalement inactif. Ensuite, on reprend les Releases Notes, on modifie le sources.list et on se lance.

On s’assure que les partitions /usr et /tmp ont les bonnes options de montage:

# mount -o remount,rw /usr && mount -o remount,exec /tmp

On lance une mise-à-jour minimale :

# aptitude update && aptitude upgrade

Puis une mise-à-jour complète :

# aptitude dist-upgrade

Rien de bien complexe. Il reste à croiser les doigts pendant les opérations ci-dessus, mais si votre système est « propre », cela se passe très bien, comme souvent sur un système Debian. Il est ensuite important de lire les éventuelles instructions de mise-à-jour situées dans le fichier NEWS d’un paquet (en utilisant apt-listchanges, cela peut être affiché automatiquement).

En ce qui concerne la mise-à-jour du kernel, de mauvaises surprises sont possibles après le redémarrage. Il est notamment recommandé d’avoir un accès à la machine (accès physique, accès « rescue », etc.) pour corriger d’éventuels problèmes. Dans mon cas, l’interface réseau a été renommée de eth0 à eth1 suite à la mise-à-jour d’udev : le fichier  /etc/udev/rules.d/z25_persistent-net.rules se transforme en /etc/udev/rules.d/70-persistent-net.rules, jusqu’ici tout est normal, mais un problème surnaturel semble s’être produit, la carte e1000 (MAC=00:0c:29:65:ae:04) est « devenue » une r8168 (MAC=00:1c:c0:51:12:45) ; au final, c’est plutôt un soucis lié au matériel, enquête en cours chez l’hébergeur low-cost…

Un vrai problème s’est par contre posé avec la mise-à-jour du paquet nginx (un petit serveur web très performant). Suite à sa mise-à-jour, il ne démarre plus :

Starting nginx: 2009/04/19 20:45:26 [emerg] 28783#0: could not build the server_names_hash,
you should increase server_names_hash_bucket_size: 32

Il faut donc ajouter dans la section http {} du fichier nginx.conf :

http {
include       /etc/nginx/mime.types;
default_type  application/octet-stream;

# Necessaire depuis l'upgrade Etch->Lenny
# (ajoute le 19.06.2009 by reg)
server_names_hash_bucket_size 33;
...

Voilà pour ce premier exemple de migration. Il s’agissait d’un serveur « simple » sans installation particulière, donc assez peu de problèmes rencontrés. Les prochains exemples seront certainement un peu plus complexes !

Autre exemple de migration Debian Sarge->Etch [3]

Sunday, April 20th, 2008

Un nouvel exemple de migration (après [0],[1] et [2]) qui concerne cette fois un serveur de messagerie (Postfix/Courier-IMAP/OpenLDAP/Amavis/SpamAssassin/Horde) et d’un intranet (Apache/PHP/MySQL) pour plusieurs centaines d’utilisateurs. La migration a duré environ 3 heures (pizzas comprises) sans accroc majeur mais avec un bon nombre de remarques plus ou moins importantes :

– Les Release Notes dispensent de bons conseils : Backup any data, inform users in advance, etc. J’ajoute que je préconise de prévoir une période d’arrêt des services d’au moins une heure avec quelques heures de marge au cas où (dans pas mal de cas, cela peut correspondre à prévoir cela un soir et se réserver la possibilité de passer la nuit dessus !). Je dis bien que je conseille d’arrêter les services (par exemple, mettre en place des règles de firewall les rendant inaccessibles) : en effet prenons l’exemple d’un service SMTP, il est nécessaire de bien vérifier que le système mis-à-jour est fonctionnel avant d’autoriser à nouveau les mails entrants (car si un problème survient, on risque de perdre des mails). Bien sûr, si aucun arrêt n’est possible, une infrastructure permettant une tolérance de panne est sûrement place et l’arrêt des services sur une machine ne posera pas de problème.

– J’utilise en général un noyau Linux patché grsec sur les serveurs mail ou web. Et avant une mise-à-jour majeure, j’ai pris l’habitude redémarrer sur un noyau non-grsec, à savoir celui par défaut… sauf quand il ne contenait pas les pilotes du controleur RAID/SCSI. À retenir :-)
Toujours au sujet du noyau, après quelques installations/désinstallations de noyaux, le paquet module-init-tools a disparu, d’où d’inquiétants messages QM_MODULES: Function not implemented. Solution triviale : aptitude install module-init-tools.

– J’ai perdu mon périphérique /dev/megadev0 (correspondant au controleur RAID/SCSI) que j’ai du recréé via mknod /dev/megadev0 c 253 0 pour avoir un monitoring fonctionnel.

– Un problème de conflit entre les paquets libfam0 et libfam0c102 s’est posé, empêchant d’ailleurs de préparer la mise-à-jour avec un aptitude -d dist-upgrade pour télécharger d’avance tous les paquets à mettre à jour (j’ai finalement du le faire en précisant les paquets manuellement). Pour forcer la résolution de ce conflit : aptitude install libfam0.

– J’ai obtenu l’erreur suivante pendant la mise-à-jour : E: Internal Error, Could not perform immediate configuration (2) on debian-archive-keyring Ack! Something bad happened while installing packages. Pour la résoudre : aptitude install debian-archive-keyring.

– Parlons Apache/PHP/MySQL. En ce qui concerne la migration d’Apache, aucun problème. Pour MySQL 4 vers 5, rien à noter non plus mis à part de bien conserver les mots de passe compatibles avec la v4 (old_passwords=1) comme nous le propose debconf. Enfin pour PHP, je suis resté (pour le moment) sur la version 4 car l’Intranet tourne sous Typo3 et le module calendrier en place semble être incompatible avec PHP5. J’ai eu par contre une activation “surprise” du module eaccelerator dans le php.ini : PHP Warning: Unknown(): Unable to load dynamic library ‘/usr/lib/php4/20050606+lfs/eaccelerator.so’ – /usr/lib/php4/20050606+lfs/eaccelerator.so: cannot open shared object file: No such file or directory in Unknown on line 0

– Pour SpamAssassin, mettre à jour les require_version des règles sur mesure ! Et quelques adaptations mineures (ok_languages, use_dcc plus valables).

– Quelques petits coups de pioche à mettre :

freshclam: error while loading shared libraries: libgmp.so.3: cannot enable executable stack as shared object requires: Permission denied

Solution : execstack -c /usr/lib/libgmp.so.3.3.3

Uncaught exception from user code: Can’t load ‘/usr/lib/perl5/auto/Quota/Quota.so’ for module Quota: /usr/lib/perl5/auto/Quota/Quota.so: cannot enable executable stack as shared object requires: Permission denied at /usr/lib/perl/5.8/DynaLoader.pm line 225, <DATA> line 225. at ./add.pl line 26

Solution : execstack -c /usr/lib/perl5/auto/Quota/Quota.so

– Pour garder Vim en tant qu’éditeur par défaut (aucun troll n’est caché dans ce point…), ne pas oublier le fameux update-alternatives –config editor

– Pour Courier-LDAP, la syntaxe a apparemment changé :
authdaemond: You need to specify a ldap server in config file
authdaemond: authldaplib: error in LDAP configuration file, aborting

Il faut désormais préciser LDAP_URI (LDAP_SERVER et LDAP_PORT ne sont plus valables) :

#LDAP_SERVER 127.0.0.1
#LDAP_PORT 389
LDAP_URI ldap://127.0.0.1

– Postfix 2.3 génère maintenant par défaut des DSN (Delivery Status Notifications) qui peuvent s’avérer gênantes avec les demandes de confirmation de lecture d’Outlook. Pour désactiver les DSN, ajouter dans le main.cf : smtpd_discard_ehlo_keywords = silent-discard, dsn

Voilà, ce fut donc loin de passer comme une lettre à la poste, mais ça ne fut pas un calvaire non plus. Les services ont été réactivés en temps et en heure, et aucun soucis majeur ne s’est produit dans les jours suivants. Au serveur suivant !

Migration web-mutu de zidane vers hosting

Saturday, April 12th, 2008

Il n’est pas aisé de maintenir un serveur LAMP car les mises-à-jour majeures du système nécessitent un travail important de vérification (et correction) de toutes les applications web. Et cela s’avère carrément impossible dans le cadre d’un serveur LAMP mutualisé où l’on ne peut pas imposer à tous une migration à un instant défini. La seule alternative viable est de mettre en place un second serveur permettant aux webmasters d’avoir deux comptes en parallèle et ainsi de réaliser une migration en douceur.

C’est donc ce cas de figure qui se pose le serveur web-mutu zidane.evolix.net (Debian 3.1, Apache 2.0.54, PHP 4.3.10, MySQL 4.0.24) qui a désormais une espérance de vie très limitée. Tous les hébergés restants sont donc priés de migrer vers hosting.evolix.net (Debian 4.0, Apache 2.2.3, PHP 5.2.0, MySQL 5.0.32) où un compte leur a été créé. Voici un petit concentré des détails techniques sur lesquels il est nécessaire de se concentrer pour cette migration :

  • Migration PHP 4.3 vers PHP 5.2 : vous pouvez consulter les pages suivantes 4.x->5.0, 5.0->5.1 et 5.1->5.2 pour voir les évolutions (nouvelles fonctionnalités, incompatibilités, etc.).
  • Migration MySQL 4.0 vers 5.0 : vous pouvez consulter les pages suivantes : 4.0->4.1 et 4.1->5.0.
  • Charset ISO8859-1 VS UTF8 : il faut prendre garde aux problèmes d’encodage de caractères. Il est désormais conseillé d’utiliser du full-UTF8 (encodage des fichiers, stockage MySQL, content-type des pages HTML, etc.). Notez que MySQL5 offre la possibilité de stocker ses bases en UTF8, mais cela peut poser des problèmes avec certaines web-applications (des problèmes ont été constatés avec WordPress, Dotclear) et cela peut nécessiter de convertir votre base. Si les commandes “SET NAMES”, “SET CHARACTER”, etc. vous sont iconnues, reportez vous à la documention MYSQL sur l’internationalisation/localisation.
  • Pour la gestion des droits, le serveur web d’hosting.evolix.net tourne avec un groupe commun avec votre utilisateur. Vous devez donc vous assurer que vos fichiers sont en lecture pour le groupe pour qu’ils puissent être lus par le serveur web, et en écriture si le serveur web doit écrire dedans.
  • En ce qui concerne les modules PEAR, seuls des modules de base sont installés sur le nouveau serveur (Archive_Tar, Console_Getopt, Log, Net_Sieve). Sur demande, nous pourrons installer certains modules supplémentaires ou alors il faudra envisager une installation locale.
  • Au niveau DNS, vous avez la possibilité de forcer le pointage vers le nouveau serveur afin de vérifier que tout fonctionne correctement avant de réaliser la bascule réelle de votre site. Si vous souhaitez une bascule rapide en minimisant les délais de propagation DNS, vous pouvez réduire le TTL juste avant le changement effectif (mettez le à 1 heure par exemple, ce qui donnera un délai moyen de 15 minutes pour vos visiteurs).
  • Au niveau des statistiques Awstats, vos anciennes statistiques peuvent être récupérées. Il suffit de nous demander de les transférer quelques minutes avant le changement effectif de DNS.

N’hésitez pas à nous contacter par mail ou via le canal IRC #evolix sur Freenode.