Voici un petit pense-bête avec pour exemple une config Nginx / WordPress / php5-cgi sur Ubuntu.

serveura.com = serveur sur lequel se trouve l’ancien WordPress à migrer
serveurb.com = nouveau serveur qui va accueillir WordPress

1. on sauve la db et on l’upload sur le nouveau serveur (on peut le faire à la fin si le blog a pas mal d’activité)
Sur le serveur A:

mysqldump -u user_toto -ppass_toto base_a_toto > /tmp/base_a_toto.sql
rsync -P -azc /tmp/base_a_toto.sql user@serveurb.com:/tmp/base_a_toto.sql

2. On copie wordpress sur le nouveau serveur
Sur le serveur A:

rsync -P -azc /home/monsite/wordpress/ user@serveurb.com:/home/monsite/

3. Setup et configuration du nouveau serveur
Sur le serveur B:
Installer les packets necessaires:

apt-get install php5-cgi php5-mysql mysql-server nginx spawn-fcgi sendmail

Il faut lancer les services nginx et spawn-cgi (pour ce dernier on peut utiliser supervisord)

Nginx:
Editer le fichier /etc/nginx/conf.d/monsite.conf . Attention à bien indiquer le chemin absolu vers votre site pour root

server {
    listen      80;
    server_name  monsite.com www.monsite.com;                   # your domain name
    root         /home/monsite/wordpress;  # absolute path to your WordPress installation
    index index.php index.html;
 
    error_log "/var/log/nginx_error.log";
    access_log  "/var/log/nginx_access.log";
 
    try_files $uri $uri/ /index.php;
 
    location ~ \.php$ {
        include        /etc/nginx/fastcgi_params;
        fastcgi_pass   127.0.0.1:53217;
        fastcgi_index index.php;
        fastcgi_buffers 8 16k;
        fastcgi_buffer_size 32k;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
    }
 
location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
}
 
# Deny all attempts to access hidden files such as .htaccess, .htpasswd, .DS_Store (Mac).
location ~ /\. {
        deny all;
        access_log off;
        log_not_found off;
}
 
# Deny access to any files with a .php extension in the uploads directory
location ~* ^/wp-content/uploads/.*.php$ {
        deny all;
        access_log off;
        log_not_found off;
}
 
# Deny access to any files with a .php extension in the uploads directory for multisite
location ~* /files/(.*).php$ {
        deny all;
        access_log off;
        log_not_found off;
}
 
}

Spawn-Fcgi: C’est lui qui va lancer php5-cgi pour faire la liaison entre php et nginx. on va le lancer avec supervisor comme si c’était un service mais mieux.

Installation de Supervisor:

apt-get install python-setuptools
easy_install supervisor
echo_supervisord_conf > /etc/supervisord.conf

Editez le fichier /etc/supervisord.conf pour y rajouter spawn-fcgi, c’est mieux de lancer php5-cgi avec un user autre que root (www-data ou autre) :

[program:php5-cgi]
command=/usr/local/bin/spawn-fcgi -n -a 127.0.0.1 -p 53217 -u www-data -f /usr/bin/php5-cgi
redirect_stderr=true 
stdout_logfile=/var/log/php5-cgi.log
stdout_logfile_maxbytes=10MB

Pour lancer Spawn-fcgi:

supervisorctl restart php5-cgi

Mysql: on ajoute mysql au demarrage et on le lance

chkconfig mysql on
service mysql start

Dump de la DB: il faut créer un user et une base sur la nouvelle install, si possible le même que sur l’ancien serveur pour faciliter la transition.
Sur le serveur B:

mysql -u root -prootpass
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 42
Server version: 5.5.28-0ubuntu0.12.04.3 (Ubuntu)
 
Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.
 
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
 
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
 
mysql> create database base_a_toto;
Query OK, 1 row affected (0.00 sec)
 
mysql> GRANT ALL PRIVILEGES ON base_a_toto.* TO "user_toto"@"localhost" identified by "pass_toto";
 
Query OK, 0 rows affected (16.16 sec)
 
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

Et on importe la base de données de serveura.com:

mysql -u user_toto -ppass_toto base_a_toto < /tmp/base_a_toto.sql

4. Changer les dns
des fois on oublie :) alors changez les dns et attendez un peu, normallement ça devrait crystalliser…

Ca prend pas 5 minutes, même avec les paquets tous prêts. on peut avoir de mauvaises surprises en route. Moi par exemple erreur 500 , pour m’aperçevoir au bout de 2 heures que j’avais pas installé php5-mysql d’où ce tuto ;)

Etat du lard

Python 3 permet de s’affranchir de beaucoup de problèmes d’encoding en utilisant unicode par défaut. A partir de la version 3.3, il va venir avec un virtualenv intégré, et distutils2, rendant le packaging et le déploiement beaucoup plus simple. Sans compter la délégation à un sous générateur. Plus besoin non plus d’utiliser ‘object’ dans l’héritage, et des tas de libs nettoyées. Bref, un comportement plus simple et un langage plus beau.

Python 2 lui est néanmoins présent encore partout:

• Ubuntu est toujours en 2.7, et passera en 3 dans la prochaine version, mais laissant la possibilité d’installer la 2.
• Mac OS utilise toujours la 2.6 par défaut.
• Certains serveurs Web sont toujours en 2.4 (!) si bien que Max  recompile carrément Python 2.6 dessus (oui, c’est un acharné).
• Django est en phase de transition version Python 3, mais pour le moment ce n’est pas fait, et il sera toujours compatible avec Python 2.7 pour les deux prochaines versions.
• Une bonne partie des libs sur pypi et sur github sont toujours en Python 2, ou au moins compatibles avec.

Enfin, l’outil 2to3 permet de convertir automatiquement, et facilement, la plupart des codes de Python 2 vers Python 3.

Apprentissage et usage

Dans la vie de tous les jours, en tant que programmeur Python, vous allez donc forcément être confronté à Python 2 pendant encore 3 ou 4 ans. Je rappelle que Python 2.4 était encore assez courant il y a deux ans, et qu’il y a 5 ans je lisais encore des questions sur les fora concernant Python 2.2.

Or, Python 2 est plus compliqué que Python 3, il demande des connaissances particulières: gérer l’encoding, setuper son virtualenv, faire gaffe à bien utiliser ‘object’, connaitre les noms des libs mal standardisés, etc.

Dans tous les cas, il sera toujours beaucoup plus simple d’apprendre Python 2 et de passer à Python 3 que l’inverse, et il est improbable que vous n’ayez pas besoin de toucher un code en Python 2. Hey, nous même, nous codons encore tous nos projets en Python 2. On se posera la question de la migration quand Django l’aura fait, et même là, on aura des tas de projets qui resteront pour toujours en V2.

Donc, si vous apprenez (ou enseignez le Python), le choix le plus pragmatique est d’apprendre avec Python 2, et de rajouter l’apprentissage des différences entre la V2 et la V3. Ce faisant vous saurez aussi comment faire migrer un projet, ce dont il est possible que vous ayez un jour besoin.