Comme tous les mois depuis bien longtemps, le PLUG organise sa soirée mensuelle.

Ouverte à tous les fans de technologie, informatique, logiciels libres, … c’est la bonne occasion pour discuter de ses passions, rencontrer du monde, discuter de sujets connus ou pas et dans un endroit particulièrement sympa et confortable (La Bo[a]te).

Au programme de juin :

• quelques sujets courts et libres inspirés de l’actualité et/ou de découvertes (l’improvisation est encouragée)
• introduction pour la série sur le “Contrôle de version” ; c’est quoi ? pour quoi faire ? …

Et comme à chaque fois :

• convivialité
• apéro, pizza, …
• rencontres, découvertes, …

Tous les détails sont dispo sur le site du PLUG : http://plugfr.org/

Je viens de terminer et (assez longuement) raconter la migration que j’ai effectuée au boulot.

J’ai transformé le fonctionnement de plusieurs sites web à base de Nginx/Mongrel/Rails et Nginx/PHP-FCGI en Apache/Passenger et Apache/mod_php.

Tout est là :
- préambule
- Ruby Entreprise Edition
- VirtualHosts
- épilogue

Je me suis régalé à faire ça tranquillement, mais avec tout de même une bonne pression, car c’est sur un serveur de prod et c’était une première dans le genre pour moi.

Un petit post rapide pour signaler que le PLUG, tel un vieux garçon, tient à ses habitudes.

La prochaine réunion aura lieu à La Boate le 6 frévrier 2009 à partir de 19h.

Tous les détails sur le site du PLUG.

J’annonce rarement les réunions du PLUG, ce qui est une honte vu mon role dans cette association, mais cette fois, ça vaut encore plus le coup que d’habitude.

Nous organisons une soirée spéciale sur le thème : les services web et leur infrastructure d’hébergement.

Le domaine est très vaste et relativement peu documenté vu la vitesse à laquelle les choses évoluent. L’idée est de réunir des gens qui souhaitent faire part de leur expérience et écouter celle des autres pour enrichir leur connaissance du sujet.

La soirée aura lieu en 2 temps, les vendredi 7 novembre et 5 décembre, à La Bo[a]te à Marseille.

Pour plus d’info, référez vous au site du PLUG et la page dédiée à l’annonce de cette soirée.

N’hésitez pas à m’écrire directement ou par les commentaire à ce post pour donner des idées, poser des questions sur la soirée, …

Je viens de m’artracher les cheveux pendant 2 bonnes heures pour un problème tout con, qui vient de moi en plus, mais comme le ridicule ne tue pas, j’en fais profiter.

Je travaille sur un Mac OS X (10.5.4) avec TextMate et j’ai un point de montage NFS provenant d’un serveur sous Debian Etch.

Ce matin, alors que je testais un plugin pour TextMate qui l’empêche de faire la mise à jour (très lente car sur le réseau) des metadonnées de chaque fichier de mon projet, la sauvegarde du moindre fichier met plusieurs dizaines de secondes et le montage NFS fini par disparaître, puis réapparaître.

J’ai commencé par désinstaller ce plugin, l’incriminant immédiatement de toutes les fautes du monde. J’ai rebooté mon serveur ET mon client mais rien n’y faisais

L’exploration des logs me dit que lockd ne réponds pas.

J’ai fini par comprendre incidemment que c’est l’activation de mon firewall local (hier soir alors que j’étais fatigué) qui empêchait le dialogue de se faire correctement. Evidemment après l’avoir désactivé, plus de soucis.

Il me reste encore à trouver comment régler manuellement mon firewall pour autoriser le dialogue au niveau de NFS, mais ça sera pour plus tard.

Contre toute attente, le PLUG tient sa réunion mensuelle le 4 juillet à partir de 19h à La Bo[a]te.

Vous êtes tous invités.

Bon, a priori vous connaissez la commande “ssh-copy-id” pour copier sa clé publique sur un serveur distant afin de s’identifier par clé et plus par mot de passe.

Le principe est d’avoir une paire de clés privée/publique, le plus souvent dans “~/.ssh/id_rsa(.pub)” et de la copier à l’intérieur du fichier “~/.ssh/authorized_keys” sur la machine distante.

$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@host

Mais si la machine distante n’accepte pas les connexions sur le port 22 ou bien qu’il y a une redirection de ports sur le routeur, il faut lui indiquer ce port, par exemple :

$ ssh-copy-id -i ~/.ssh/id_rsa.pub -p 2222 user@host

Mais ça ne marche pas car ssh-copy-id ne comprend que 2 paramètres et si on met “-p 2222″ en second, ça n’est pas un motif de type “[user@]host”, et si on le met après, en troisième, il est ignoré.

Et bien il suffit d’entourer les infos de connexion ssh par des guillemets pour qu’ils soient vus comme un seul paramètre :

$ ssh-copy-id -i ~/.ssh/id_rsa.pub “-p 2222 user@host”

J’oublie souvent de l’annoncer ici,mais comme chaque premier vendredi du mois, le PLUG oganise une réunion à La Bo[a]te.

Cette fois ci c’est le 6 juin, à partir de 19h.

Tous les détails sont sur le site du PLUG.

Description d’une situation type, avec 2 serveurs identiques, 1 pour le site en production (prod-server) et 1 pour le site en développement/tests (dev-server). Chaque serveur prend en charge les fichiers et les bases de données (Apache/PHP + MySQL).

L’utilisateur système utilisé est user.

Les fichiers du site sont dans /var/www/dev-site sur le serveur de dev-server et dans /var/www/prod-site sur prod-server

En situation mono-serveur, le principe est strictement identique sauf que les copies de fichiers se font par cp (attention aux optionsde préservation des permissions) au lieu de scp et les chemins d’accès ne comprennent plus la partie de connextion ssh au serveur distant.

Les bases de données s’appellent typo3_dev et typo3_prod et sont accessibles par l’utilisateur mysql typo3, avec le mot de passe typo3.
Il est important que cet utilisateur ait le droit FILE dans les privilèges de MySQL pour pouvoir faire des imports/exports de/vers des fichiers.

Sauvegarde ponctuelle

La base de données

prod-server: mkdir -p /var/backup/typo3/DUMPDIR/typo3_prod
prod-server: cd /var/backup/typo3/DUMPDIR
prod-server: chmod a+w /var/backup/typo3/DUMPDIR/typo3_prod
prod-server: mysqldump -u typo3 -ptypo3 -Q --tab=typo3_prod typo3_prod
prod-server: tar -czf typo3_prod.tgz typo3_prod

A ce stade, la base typo3_prod est totalement sauvegardée, dans une archive compressée /var/backup/typo3/DUMPDIR/typo3_prod.tgz.
Cette archive contient autant de fichiers que de tables dans la base. Un fichier ma_table.sql contient la structure de la table et un fichier ma_table.txt contient les données de la table. Cette séparation permet de recréer la structure sans les données et/ou d’injécter les donénes sans toucher à la structure.

Il est conseillé de nommer les archives avec la date du jour, par exemple typo3_prod-20080501.tgz, cela permet de conserver plusieurs versions de sauvegardes et de savoir à quelle date exactement elles ont été faites, indépendamment de la date de création du fichier.

Les fichiers du site et ceux de TYPO3

prod-server: cd /var/www/
prod-server: tar -xzf /var/backup/typo3/prod-site.tgz prod-site

Les fichiers du site sont alors sauvegardés et compressés sur la partition de sauvegarde.

Si les fichiers du cœur de TYPO3 n’ont pas été changés, il suffit de copier l’archive officielle de TYPO3, qui reste normalement à côté de sa version décompressée. Par exemple :

prod-server: cp typo3_src.4.1.1.tar.gz /var/backup/typo3/typo3_src.4.1.1.tar.gz

Sinon, on recrée l’archive contenant nos fichiers sources et on la copie

prod-server: tar -xzf /var/backup/typo3/typo3_src.4.1.1.mod.tar.gz typo3_src

Sauvegarde régulière

la procédure est identique, mais on peut l’automatiser dans un script shell, déclenché régulièrement par un tâche CRON.

Restauration d’une sauvegarde

Si les données sauvegardées sont stockées sur un autre serveur que celui sur lequel elles doivent être restaurées, il faut d’abord les rapatrier. Imaginons qu’elles soient sur le dev-server et qu’elles doivent être mises sur prod-server.

prod-server: mkdir -p /var/backup/typo3/DUMPDIR

dev-server: cd /var/backup/typo3/
dev-server: scp ./DUMPDIR/typo3_prod.tgz user@prod-server:/var/backup/typo3/DUMPDIR/typo3_prod.tgz
dev-server: scp ./typo3_prod.tgz user@prod-server:/var/backup/typo3/typo3_prod.tgz
dev-server: scp ./typo3_src.4.1.1.mod.tar.gz user@prod-server:/var/backup/typo3/typo3_src.4.1.1.mod.tar.gz

La base de données

On restaure la structure de la base. Ici les tables existantes dans la sauvegardes seront détruites avant d’être recrées

prod-server: cat /var/backup/typo3/DUMPDIR/*.sql | mysql -u typo3 -ptypo3 typo3_prod

Puis on restaure les données dans la base. Attention au chemin d’accès qui, ici, doit être absolu.

prod-server: mysqlimport -u typo3 -ptypo3 typo3_prod /var/backup/typo3/DUMPDIR/*.txt

Les données sont injectées table après table dans la base de données, avec un arrêt en cas d’erreur sur une table.
La progression est indiquées, avec le nombre de lignes traitées, ainsi que le nombre d’avertissements et d’erreurs.

Lorsqu’on n’a pas procédé à la ré-initiamisation des tables, il est possible de fournir des options à mysqlimport, telles que :

• -r (ou—replace) permet de remplacer les lignes qui comportent la même clé (et donc ne provoque pas d’erreur et d’arrêt de l’import). C’est à utiliser lorsqu’on veut mettre à jour la table en conservant ce qui n’existe pas dans l’import.
• -d (ou—delete) permet de vider la table avant la lecture du fichier d’import. C’est à utiliser lorsqu’on veut totalement remplacer le contenu des tables.

Le cœur de TYPO3

La restauration du cœur de TYPO3 n’est nécessaire que si les fichiers sources ont été corrompus.

cd /var/www/
mv typo3_src typo3_src_trashed
tar -xzf /var/backup/typo3/typo3_src.4.1.1.mod.tar.gz

Si tout est OK, on peut supprimer typo3_src_trashed

rm -rf typo3_src_trashed

Restauration des fichiers du site

Le principe est identique, sauf qu’il risque d’être beaucoup plus long selon le nombre de fichiers stockés dans le site.

cd /var/www/
mv prod-site prod-site_trashed
tar -xzf /var/backup/typo3/prod-site.tgz

Si tout est OK, on peut supprimer prod-site_trashed

rm -rf prod-site_trashed

Mise en production d’un site préparé en développement

Compression et transfert

Il faut commencer par exécuter toutes les étapes de la sauvegarde ponctuelle.
Cette fois, la sauvegarde de la base se fait dans le répertoire du site ce qui nous permet de tout compresser et transférer de dev-server à prod-server en une seule fois

dev-server: mkdir -p /var/www/typo3_dev/DUMPDIR/typo3_dev
dev-server: cd /var/www/typo3_dev/DUMPDIR
dev-server: chmod a+w /var/www/typo3_dev/DUMPDIR/typo3_dev
dev-server: mysqldump -u typo3 -ptypo3 -Q --tab=typo3_dev typo3_dev
dev-server: cd /var/www/
dev-server: tar -czf typo3_dev.tgz typo3_dev
dev-server: scp typo3_dev.tgz user@prod-server:/var/www/

Restauration

prod-server: cd /var/www/
prod-server: tar -xzf typo3_dev.tgz
prod-server: cd typo3_dev

Avant toute chose, il faut faire pointer cette copie vers la base de données de prod.
Cette config se situe dans typo3_dev/typo3conf/localconf.php.
La variable à vérifier est : $typo_db
On peut aussi vérifier les autres variables d’accès à la base : $typo_db_host, $typo_db_password et $typo_db_username

Il faut restaurer la base de données :

prod-server: chmod a+r ./DUMPDIR/*
prod-server: cat ./DUMPDIR/*.sql | mysql -u typo3 -ptypo3 typo3_prod
prod-server: mysqlimport -u typo3 -ptypo3 typo3_prod /var/www/typo3_dev/DUMPDIR/*.txt

Si les sources de TYPO3 ont été modifiées, il faut aussi les transférer :

dev-server: cd /var/www/
dev-server: tar -xzf typo3_src.4.1.1.mod.tgz typo3_src
dev-server: scp typo3_src.4.1.1.mod.tgz user@prod-server:/var/www/

prod-server: cd /var/www/
prod-server: tar -xzf typo3_src.4.1.1.mod.tgz

Dans tous les cas, il faut vérifier si le lien symbolique qui est dans typo3_dev pointe bien vers le dossier du cœur de TYPO3

Ensuite on renomme :

prod-server: mv typo3_prod typo3_prod_old
prod-server: mv typo3_dev typo3_prod

On vérifie en ligne si le changement est bien fait.
Si tout est OK, on supprime l’ancien dossier.

prod-server: rm -rf typo3_prod_old

Ajustements dans TYPO3

Dans l’interface d’admin de TYPO3, il y a quelques points à vérifier et adapter le cas échéant.

• vider tous les caches (2 liens en bas de la colonne de gauche)
• vérifier les paramètres baseURL des configs TYPOScript de chaque site
• vérifier les domaines de réponse si on a plusieurs sites (enregistrements de type “domaine” sur la première page de chaque site)
• dans le cas de la recherche indexée des pages, vérifier les paramètres baseURL dans la “configuration TS de la page” (sur la première page de chaque site)

Mise à jour du 6 mai :

Avant de faire un mysqldump, il faut vérifier si le dossier cible est accessible en écriture à l’utilisateur système “mysql” ainsi que l’utilisateur courant. Pour faciliter celà, j’ai ajouté l’écriture à tout le monde. Après tout, ça n’est qu’un répertoire de dump, très éphémère.

Mise à jour du 8 mai :

Il n’est pas nécessaire de donner les droits en lecture sur les dumps à tout le monde. Par contre il est impératif d’avoir le droit FILE dans les privilèges MySQL, aussi bien pour la phase d’export (mysqldump) que pour la phase d’import (mysqlimport).

Voici une petite note à mon attention, directement inspirée de l’article de Jamis Buck et du code source de attachement_fu (un superbe plugin Rails pour l’upload de fichiers joints).

Dans une application qui stocke des fichiers uploadés par les utilisateurs, je souhaite que les fichiers soient organisés proprement et que chaque compte ait son propre dossier de premier niveau au lieu de tout mélanger + ou – en vrac.

Le principe de attachement_fu est celui-ci, avec par exemple un fichier ayant l’ID 12345 dans la base de données : 

/0001/2345/mon_fichier.jpg

NB : tout est relatif à “RAILS_ROOT/public/fichiers_joints”

Comme chaque fichier est lié à un enregistrement dans la base de données, il n’y a pas de risque d’écrasement, mais si je dois sortir rapidement tous les fichiers d’un compte par FTP, je suis très embêté.

J’aimerai faire ceci :

/compte_482/0001/2345/mon_fichier.jpg

Mais comme les fichiers sont eux-mêmes classés par “groupe” au sein d’un compte et que le nombre de fichiers ne devrait pas excéder quelques petits milliers par groupe (le plus souvent quelques centaines), je peux simplifier

/compte_482/groupe_047/12345/mon_fichier.jpg

La limite est donc à ~100 000 fichiers par groupe, ~1 000 groupes par compte et ~1 000 comptes.
Si ma petite appli atteint 5% de ces volumes je serais déjà assez riche.

Et puis après tout, si se limiter à 100 000 fichiers par groupe est trop réducteur, reprenons le découpage en sous-dossiers selon l’ID sur x chiffres.
Et si le nombre de groupes par client ou le nombre de client devait exploser, on y ferait de même.

Bon, passons au choses sérieuses ; coder la méthode qui va surclasser celle de attachement_fu (exemple avec des découpes à 6 chiffres).

# La méthode doit renvoyer un tableau où chaque élément
# est un segment du path à utiliser, à partir du dossier
# principal de stockage "RAILS_ROOT/public/fichiers_joints/".
# "attachment_path_id" est une méthode interne du plugin
def partitioned_path(*args)
  a = []
  a << ("%06d" % @client_id).scan(/.../)
  a << ("%06d" % @group_id).scan(/.../)
  a << ("%06d" % attachment_path_id).scan(/.../)
  a <<  args
end