C'est fait. Depuis le temps que je m'étais lancé dans la migration du moteur de blog actuel (wordpress) vers quelque chose de plus simple, c'est maintenant chose faite. L'ensemble des posts et les commentaires ont été migrés sous pyblosxom.

Cette migration longue (elle a duré plusieurs mois) m'a permis d'apprendre à programmer en python et comprendre CSS et HTML.

Python parce que le pyblosxom est écrit en python, tout comme moinmoin. La version de pyblosxom (1.5 rc-2) contient quelques bugs, nottament dans la gestion des previews AJAX des commentaires. Il a fallu les corriger (le patch a été posté sur le bug tracker. Je voulais également continuer à utiliser la syntaxe de moinmoin pour écrire mes posts. Or, il n'existait pas de parser, donc, j'ai dû en écrire moinmoin.py un.

HTML et CSS car pour réutiliser le thème Moniker du site principal, il fallait comprendre CSS et HTML et l'adopter afin que le thème fonctionne correctement avec pyblosxom. Le code n'est pas propre, mais est disponible.

Enfin, la migration des posts de wordpress vers pyblosxom s'est faite par le script wp-to-pyblosxom.

Il reste encore à remettre le tout au propre et faire la documentation...


Il y a quelques semaines, ma machine (Processeur Intel E Quelque chose, pas de virtualisation assistée, pas de 64Bits) hébergeant mes sites, le serveur Mail, DNS etc. a rendu l’âme.
J‘en ai profité pour upgrader l’hardware: j’ai donc remplacé la carte mère par une MSI et le processeur (Intel) par AMD 64 X2, qui propose à un prix dérisoire la fonctionnalité SVM (support de la virtualisation en hardware).

Après le changement des pièces, la machine boote correctment, puis GRUB propose son menu et commencer à charger l’OS. Au bout de quelques secondes, écran noir, puis peu de temps après, je me trouve devant le prompt busybox m’indiquant que la partition correspondant à l’UUID dont je n’ai pas retenu la chaîne n’a pas été trouvé…

Là commence un petit moment de panique: je commence à me dire “Hé merde, il va falloir réinstaller lOS (dont l’installation date d’époque de Dibian Potato/Sarge) et j’ai bien fait de graver le CD Net Install“. Mais comme tout utilisateur de Debian et informaticien, par conséquent partisan du moindre effort, je commence regarder de près ce qui pose problème: ce qui me saute au yeux dés les premières secondes, c’est que disk n’est pas reconnu. Nn lsmod me permet de remarquer que dans la liste des modules chargés, il manque le module sata correspodant au nouveau chipset(VIA pour la nouvelle carte mère, alors que sur l’ancienne le chipset devait être INTEL).

Et là, je commence à dire Et si c’était ça le problème? S’il suffissait de recréer uniquement l’initrd avec les bon modules…

Un arrêt éléctrique de la machine et connexion d’un lecteur CD, un tour dans le bios pour indiquer que la machine doit booter sur CD, j’insère le CD Netboot de Lenny pour AMD64.

La machine(pour la petite histoire elle s’appelle Nemesis) boote sur le CD et m’affiche les choix possibles. Je sélectionne Rescue et après quelques questions (langue de l’interface, type de clavier), l’assisstant m’affiche la liste de partitions et demande d’indiquer la partition root. Là, je commence me dire que j’aurais peut-être pas besoin réinstaller la machine et indique /dev/sda5 (dans mon cas la réponse était simple: toutes machines que j’installe suivent la même norme:



  • Première partition est dédiée au /boot
  • La deuxième est dédiée au swap
  • La première partition étendue (Xd5) contient toujours le /
  • L‘installeur monte la partition, puis lance un shell chrooté. Après quelques ls et des pwd, mount -a effectue le montage de toutes les partitions.
    Le fichier de configuration de initramfs (/etc/initramfs-tools/initramfs.conf) indique que update-initramfs n’inclus que les modules nécéssaires (MODULES=dep) lors de la génération du initrd. Le coeur palpitant, je le modifie en most, relance la génération des initrds par update-initramsfs -u -k all, reboote la machine et éjecte le CD de boot afin de laisser la machine booter sur le disk.

    Après quelques secondes d’angoisse, GRUB charge, et dans les lignes qui défilent, je remarque que le disk est bien reconnu et / est monté sans erreur, et au bout de quelques secondes, je me trouve devant le prompt

    Cette migration inattendue et réussie, à partir d’une carte mère avec un chipset pour processeur Intel X86 vers un chipset avec un processeur AMD64, souligne encore une fois la flexibilité de Linux et la facilité de maintenance d’une Debian.

    En postant cette histoire, je suis entrain de me dire que il faut quand même que je migre Nemesis vers AMD64 au lieu de la laisser sous X86, mais ce sera pour quand j’aurais un peu plus temps….


    Ce matin en arrivant au boulot, j’ai trouvé une de nos veilles machines, qui servait de serveur DNS et MX pour nos domaines, plantées. Les erreurs affichées sur la console semblaient être liées au disk. Ne pouvant plus se logguer, je la reboote brutalement. Elle redémarre sans problème, mais affiche des messages d’erreurs sur la console (ide: failed opcode was: unknown, end_request: I/O error, dev hda, sector 36684151, Buffer I/O error on device hda12, logical block 691607, hda: dma_intr: status=0×51 { DriveReady SeekComplete Error }, hda: dma_intr: error=0×40 { UncorrectableError }, LBAsect=36684154, sector=36684151) puis commence à ramer. Du coup, arrêt des services(postfix, amavis), démontage du file system et vérification par reiserfsck. Aucune erreur est trouvée. Je remonte le file system et relance les services.

    Rebolotte. Les mêmes messages commencent à défilier. Je me décide, donc, à prendre les choses sérieusement: je lance une sauvegarde du file system par tar, après avoir arrêté postfix. Le tar dure plus de 2 heures pour une sauvegarde d’environ 1.5Go de données.

    Une fois la sauvegarde terminée, je démonte le file system et le reformate en ext3 (je commence à croire que dans certaines conditions, la version 3 reiserfs par dans les choux, mais je n’arrive pas à déterminer précisément ces conditions) avec les options ‘-c -c‘, qui permettent tester le file system crée avec écriture puis une lecture, les blocs illisibles n’étant plus utilisés. Après cette opération, dont je ne sais plus la durée (de tête, environ 2 heures), un coup de tunefs pour définir les options de montages par défaut (errors=remount-ro et data=journal) et modification de /etc/fstab, le file system en question est remounté. La sauvegarde est restaurée et les services sont relancés.

    Après plus d’une heure de fonctionnement, toujours aucun message d’erreur.

    Cette expérience montre comment avec quelques outils de base (tunefs, mkfs.ext3, tar) utilisés correctement sur un OS stable (GNU/Linux Debian), on peut continuer à tirer parti d’un matériel éventulement défectueux.



    Les Français avaient rejeté le traité de constitution européenne. Une fois élue, notre cher président Sarkozy, avec son immense respect pour la démocratie, avait fait passer ce traité devant le parlement qui, en piétinant la volonté du peuple, avait validé ce traité.

    Cette manière de faire, quelque soit l’opinion qu’on avait de ce traité, était clairement anti-démoratique.. Aujourd’hui, le peuple Irlandais vient de rejeter la constitution.

    Bien que je ne connaisse pas clairement les raisons de ce rejet, je ne peux que remercier le peuple Irlandais pour ce rejet, qui par cette action vient de laver l’affront de notre cher président et de nos chers députés (y compris les députés socialistes) envers le Peuple.

    Spéculons un peu maintenant : quelle va être la réaction de notre cher président? Faire pression sur le gouvernement Irlandais pour qu’elle accepte le traité? Isoler l’Ireland ou l’exclure de la communauté européenne afin de applique le mini traité sans le peuple Irlandais ou une prise de compte de la volonté de peuple par la mise en place de la rédaction d’une nouvelle constitution par une assemblé constituante élue à la proportionelle dans l’ensemble des états membres?. Oui, je sais, je suis d’un nature optimiste qui crois nos élus sont capables d’écouter la voix du peuple….


    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!