On quitte donc LeaseWeb, qui nous a forcé à migré 3 fois avec ses machines qui ont planté. En plus deux fois la partition /tmp était corrompue, ce qui rend le backup particulièrement compliqué. On notera que leur SAV nous posait des questions du genre “si vous installez ça, et lancez cette commande, ça donne quoi ?”, alors qu’on leur a bien notifié qu’on avait un disque monté en lecture seul du fait du FS en vrac…

On est passé chez Cinfu, car on peut les payer en Bitcoin. Livraison du serveur rapide, installation sans histoire, et finalement une migration beaucoup moins chiante que la dernière fois car on a fait les gros bourrins : rsync + mysqldump bien large. Ce qui a pris le plus de temps c’était de résoudre les centaines de problèmes de permissions que ça a créé, les trucs que ça aurait pas du écraser, etc.

On avait + de 100000 spams dans la poubelle des commentaires, qui prenaient 300 Mo des 400 mo de la taille totale de la BDD du blog. Un petit :

DELETE FROM wp_comments WHERE comment_approved = 'trash';

A accéléré la migration vu qu’on a du transférer la base 3 fois et la réimporter autant à cause d’erreurs diverses. Note à nous-même : arrêter de mettre des .bak dans /tmp parce que c’est “juste pour 5 minutes”. Après on se fait avoir comme des débutants au reboot.

C’est là qu’on voit qu’on est dev, et pas admin.

Rajouter dans wp-config.php :

define('EMPTY_TRASH_DAYS', 30);

Nous évitera d’avoir à repenser à tout ça. C’est con mais faut le savoir.

J’en profite pour témoigner mon amour immodéré pour mosh. Parce que faire tout ça sur une connexion thai avec 300ms de ping minimum et une coupure toutes les 10 minutes, avec SSH, c’est juste un enfer.

Sous Centos, faut installer les repos EPEL et yum install mosh derrière.

Sous Ubuntu, fait installer le ppa ppa:keithw/mosh et apt-get install mosh derrière.

Certains serveurs ont un pare feu tatillon, et il faut rajouter dans la section :RH-Firewall-1-INPUT - [0:0] de iptable :

-A RH-Firewall-1-INPUT -p udp --dport 60000:61000 -j ACCEPT

D’autres ont des problèmes de locales:

apt-get install --reinstall language-pack-fr
dpkg-reconfigure locales

Parfois y a aucun problème. C’est juste qu’on a pas un parc homogène, avec des bécanes vieilles de 1000 ans, alors forcément…

Mais Max a fait des devis, et si on passe au cloud avec les 2G/s de BP et les To de disque dur qu’on consomme, on multiplie les prix par 10 d’hébergement. Faire les trucs à la main, c’est chiant, mais c’est économe.

Pour mosh, pas de serveur à lancer, juste remplacer ssh par mosh dans la commande quand on se connecte. Des fois je lance avec --predict=experimental car je suis impatient et le retour de frappe est plus rapide, mais le cursor fait des mouvements bizarres, faut s’habituer.

Bon, on retourne faire des trucs plus productifs.

Ça me fait penser que si vous connaissez des blogs fr sur Python, proposez les pour le planet.

Plusieurs personnes nous ont demandé le code source. La raison pour laquelle il n’est pas publié, c’est que c’est un amas de code vraiment peu ragoutant, et qu’il faudrait vraiment le nettoyer pour éviter que la honte ne s’abatte sur nous.

Max voudrait en faire un truc personnalisable, avec des widgets, et tout, à la netwibes mais en plus simple. Je pense que ça n’arrivera jamais :)

En gros, vous pouvez de nouveau lire vos articles techniques préférés. Et les autres aussi.

Par contre, feu notre ancien thème (snif, il était si… si… attachant…), et donc tous les easter eggs qui vont avec.

Vous noterez donc un blog moins fun, avec des bugs graphiques et surtout, sans plugins, donc ouvert aux 4 vents aux spams mais sans formulaire de contact. Mouarf.

Je vais corriger ça petit à petit, mais je ne me presse pas, l’avantage d’écrire un blog bénévole est qu’on ne doit rien à personne, donc on peut se gratter les couilles.

0bin, multiboards et allthatcount vont suivre. Je vais probablement les migrer avant de m’attaquer à la corrections des petits problèmes du blog d’ailleurs.

La base de données complète a été migrée. Félicitation à l’équipe de WP pour avoir mis en œuvre un outil de conversion des tables d’une version à l’autre parfaitement transparent. C’est pas facile à faire, et ça marche super bien. Mettez l’article en favoris, je ne dirais pas souvent du bien de cet outil.

Ça signifie que vos commentaires sont là, les pages statiques aussi, et bien entendu, pour les contributeurs, leurs comptes utilisateurs également. Il y a eu un bug de login ce matin, mais c’est réparé.

Si vous voyez des trucs qui pètent, merci de les lister en comment ici que je puisse avoir une check list à jour et sans doublons. Avec les URLS c’est mieux.

Parmi les problèmes que je vois venir : les iframes qui marchent pas, la barre de menu de droite qui déconne, et autres joyeusetés, des médias de mauvaise taille.

Et bonne lecture :)

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 ;)

Apprenez Python 3.

Il est plus simple, plus élégant, plus mieux.

Installez minimum Python 3.4, si possible.

Quelques exceptions à cette règle :

• Vous planifier d’utiliser une lib en rouge dans cette liste.
• Vous savez que vous allez bosser essentiellement sur du vieux code dans votre boîte.

Rappelez-vous qu’il est facile d’installer et utiliser Python 2 et 3 sur la même machine. Et un virtualenv peut contenir une version de Python particulière. Le choix de l’un n’exclus donc pas l’autre pour plus tard. On peut même écrire un code qui marche sur Python 2 ET Python 3 aujourd’hui. C’est moche, mais ça marche :)

Donc, bonjour Python 3 avec pip et venv installés par défaut, les accents qui marchent out of the box, pas de bizarreries qui traînent comme des noms incohérents et object…

Mac et Linux ont la 2.7 par défaut installé, mais ça se règle avec un coup de homebrew, apt-get install, yum install, etc. N’ayez pas peur.

Mon ancien article n’est donc plus valable.

Les deux versions étant incompatibles, et Python 3 ayant plein de super fonctionnalités que Python 2 n’a pas, mais la V2 étant encore très répandue, on peut se demander lequel on doit apprendre.

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.