• 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. <
  li> 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 <ata et underlay déportés, vérifier les droits sur ces répertoires. Ils doivent être accessible en <stroure à 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é <ema. 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. <

EDIT 22/04/2008: C’est indiqué dans le fichier <span class=”caps”>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!</p>]]> http://blog.glennie.fr/2008/04/21/migration-de-moinmoin-15x-vers-16x-sous-debian/feed/ 0 http://blog.glennie.fr/2007/10/13/de-limportance-des-sauvegardes/ http://blog.glennie.fr/2007/10/13/de-limportance-des-sauvegardes/#comments Sat, 13 Oct 2007 13:24:52 +0000 Glennie Vignarajah http://blog.glennie.fr/2007/10/13/de-limportance-des-sauvegardes/ {{{
La sauvegarde d’un système d’informations est toujours importante. <n l’apprend toujours à ses dépends.</p>

Je devais intervenir sur une dedibox pour mettre en place un http://fr.wikipedia.org/groupware“>groupware (http://www.egroupware.org“>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 <a href=http://www.ubuntu.com“>a>, j’aurais préféré un <a http://www.debian.org“>ian, 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 <emoupwarenew. 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 <em>epwarenew 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 “<em> 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…</p>

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.</p>

• 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 <emonnecter 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 <span class=”caps”>SSH lorsque le /etc/passwd n’existe plus et qu’on est encore connecté, il passe son temps envoyer des messages du genre “< 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 <em>hoirectory 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 <a href=”<a hrehttp://www.debian.org“>ant à 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. </UL><br

• 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). </UL><

<strong>E</strong>n 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 <del>in</del>volontaire.<br /><br /><br /><br />
 <br /><br /><br /><br />
<strong>D</strong>onc,<br /><br /><br /><br />

• Il faut toujours réfléchir à 2 fois avant de faire des “<st-rf *“.
• Faire une sauvegarde régulièrement</Il existe pleins d’outils pour ça. J’utilise <http://packages.debian.org/backupninja“>ackupninja. Une page http://wiki.debian.org/DebFrBackup“>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 “<ndex.php” en “ORI-index.php” plutôt que “<ndex.php-ORI”

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

}}}