Mes états d’âme

Hier, tant bien que mal, j’ai fini par migrer mon site qui tourne sous moinmoin vers la dernière version. La procédure de migration est pourtant simple, à condition de suivre les étapes préconisées. De plus, dans la package distribué par Debian, il manque un fichier et cela n’est indiqué nulle part. Voici, donc, les étapes à suivre :

• Faire une sauvegarde des répertoires data, underlay et /etc/moin.

• Installer les nouveaux packages.
• Modifier la configuration en éditant les fichiers sous /etc/moin.
  
  • Remplacer la ligne ‘from MoinMoin.multiconfig import DefaultConfig’ par ‘from MoinMoin.config.multiconfig import DefaultConfig’

  • Remplacer la ligne ‘from MoinMoin.util.antispam import SecurityPolicy’ par ‘from MoinMoin.security.antispam import SecurityPolicy’
    
• En cas d’utilisation des répertoires data et underlay déportés, vérifier les droits sur ces répertoires. Ils doivent être accessible en écriture à l’id utilisateur sous lequel tourne le serveur Web.

• Sous ID d’utilisateur sous lequel tourne le serveur WEB par su
• Créer dans répertoire data un fichier nommé meta. Ce fichier doit contenir une ligne data_format_revision: VERSION. VERSION est de la forme ‘XYZ’ (par exemple, lors d’une migration de la version 1.5.3, elle doit être ‘1050300′.
• Lancer la procédure de migration par /usr/share/python-support/python-moinmoin/MoinMoin/script/moin.py –config-dir=/etc/moin –wiki-url=URL_DU_WIKI migration data
• Suivre les instructions données par le script de migration.
  

Enfin de compte, la procédure est simple. Mais, il manquait l’indication concernant le fichier meta, contenant la version du metadata en place, à placer dans le répertoire data…

Je ne sais pas si je suis le seul à eu ce problème, dans le cas contraire, il faut faire un bug report sur le package de Debian.

EDIT 22/04/2008: C’est indiqué dans le fichier README.migration.gz, c’est moi qui n’avais pas pris le temps lire correctement les instructions de migration. Debian, c’est bien fait quand même!

{{{
La sauvegarde d’un système d’informations est toujours importante. On l’apprend toujours à ses dépends.

Je devais intervenir sur une dedibox pour mettre en place un groupware (eGroupware) afin de lui permettre de proposer à ces étudiants une plate-forme d’échange. Rien de compliqué à cela car la machine était déjà en place (sous Ubuntu, j’aurais préféré un Debian, mais bon…) avec une installation eGroupware qui était presque fonctionnelle. Afin, de ne pas casser l’existant, j’ai décidé de faire une nouvelle installation d’eGroupware en nommant cette nouvelle instance egroupwarenew. L’installation s’est déroulée sans problème. Arrive le moment fatidique de la configuration : la connexion vers la base de données (mySQL) ne se fait pas. Je décide, donc, de dropper la base egroupwarenew que j’avais créée à la main et laisser l’installeur effectuer cette opération. Je me connecte, donc, sur le serveur mysql, je tape “drop database egroupware;” et valide la commande joyeusement en tapant sur la touche “entrée”.
Et là, c’est le drame. L’instance d’eGroupware qui était en place utilisait une base nommée egroupware ; la base que je devais dropper était egroupwarenew. J’ai été incapable de trouver une sauvegarde de la base droppée sur la machine. Pourtant, egroupware propose, en option, une méthode pour effectuer une sauvegarde tous les jours. Malheureusement, cette option ne semblait pas avoir été activé. Après avoir déprimé pendant une demi-heure, j’ai terminé l’installation. Tout semble fonctionner…

Comme je le disais au début de mon poste, les sauvegardes sont importantes qu’on soit un particulier ou professionnel. Dans ma courte vie d’informaticien, j’ai dû faire 3 ou 4 grosses conneries et toutes étaient liées à des suppressions malencontreuse de fichiers.

• La première était une suppression de /etc : un malheureux “rm -rf *” en étant au mauvais endroit. Sur ce coup, j’ai eu de la chance. C’était sur une machine de prod au boulot et on avait une sauvegarde. Le truc à ne pas faire dans le cas de la suppression de /etc/, c’est surtout ne pas se déconnecter et ne pas paniquer (là ce n’est pas dur, je savais que j’avais un backup à jour). Donc, restauration du contenu sur une autre machine (car une fois que /etc n’existe, plus, il n’est plus possible de se connecter, hein) et transférer les données. D’ailleurs, quand il y a un truc marrant avec SSH lorsque le /etc/passwd n’existe plus et qu’on est encore connecté, il passe son temps envoyer des messages du genre “I don’t know you. Go away!“.
  

• La deuxième série de suppression était moins grave dans la mesure où c’était sur mes machines perso. Un script m’a viré tout mon home directory et un malheureux “rm -rf *” qui entraîné la suppression de la configuration de mon serveur Apache. J’ai pu récupéré mon “home” à partir d’une vieille sauvegarde car jusqu’à ce jour, je m’étais dit que cela n’arrive qu’aux autres. Concernant la config du serveur Apache, ce fût un peu plus compliqué. La configuration de base était simple à récupérer, il suffit de réinstaller les packages (merci Debian). Quant à la récupération des mes virtuelhosts et la configuration spécifique, j’ai eu de la chance, car j’avais activé le handler “server-info” qui liste la configuration du serveur. Ce n’est pas simple de récupérer la config. d’un serveur en partant d’une page html qui regroupe trop d’informations mais c’est quand même plus facile qu’à partir de rien.
  

• Les 2 autres fois, c’était vraiment débile. Je fais toujours des copies de sauvegarde en utilisant un schéma de nom un peu nul : par exemple, je fais une copie de fichier “index.php” en “index.php-ORI” ou appeler une base “egroupwarenew” alors qu’il existe déjà une base egroupware. Et, à chaque fois, la fatigue aidant, je n’allais pas jusqu’au bout du mot et finis par supprimer le mauvais fichier ou la mauvaise base (comme egroupware ou index.php).
  

En presque 10 ans, je n’ai pas encore perdu mes données suite à problème matériel. Chaque fois que j’ai perdu des données c’était suite à une suppression involontaire.

Donc,

• Il faut toujours réfléchir à 2 fois avant de faire des “rm -rf *“.

• Faire une sauvegarde régulièrement. Il existe pleins d’outils pour ça. J’utilise backupninja. Une page wiki du projet Debian en cite d’autres.
• Faire attention de la façon dont on nomme les copies de fichier de sauvegardes. Il vaut mieux faire une copie de fichier “index.php” en “ORI-index.php” plutôt que “index.php-ORI”
  

EDIT 14/10/2007 à 09h30

• Lorsqu’on accède à une machine pour la première fois, s’assurer qu’elle est bien sauvegardée.
  

Je viens de tomber sur un post qui parle aussi de l’importance des sauvegardes. C’est étrange de constater que d’autres font face aux mêmes soucis au même moment…

}}}

Qui pensait que moi, avec mes 3 neurones (sachez que le 3ème est mourant) étais assez intelligent pour violer des brevets? Pas moi, en tout cas, ni les gens qui me connaissent… Et pourtant, c’est vrai, j’ai écrit des programmes qui sont en flagrant délit de violation de brevets.

En effet, d’après UPSTO (US Patent & Trademark Office), le fait de “recevoir un e-mail, l’interpréter et entreprendre une action en fonction de règles définies” de façon automatique est protégé par une demande brevet depuis, 1998. D’ailleurs, Polaris IP a entamé un procès contre les entreprise violant ce brevet.

Ce qui est sûr dans cette histoire, c’est que je ne suis pas intelligent, mais que UPSTO fait n’importe quoi. Des boîtes déposent des demandes brevets débiles et cet organisme sensé protéger l’innovation valide leurs demandes sans rien comprendre aux contenus des demandes.

Tiens, pendant que je pense, pourquoi quelqu’un ne dépose-t-il pas un brevet sur le “fait de protéger les innovations par UPSTO“.?