Import on Zwindler's Reflection

Migration facile de Mediawiki vers XWiki

Fri, 16 Dec 2016 08:30:00 +0000

Convertir simplement des pages d’un Mediawiki vers une instance XWiki

Une fois de plus, encore un article sur XWiki ! J’ai déjà pas mal profité de cet outil de gestion de la connaissance pour m’initier à Docker et même gérer le cycle de vie de l’application avec des containers. Mais il reste au moins un sujet pourtant récurrent que je n’avais pas encore traité. Comment réaliser simplement la migration des pages qui me restaient (150 !) de mon Mediawiki vers le XWiki pour que je puisse définitivement le désactiver ?

Les méthodes trouvées sur Internet

Et le moins que l’on puisse dire, c’est que cet épineux problème comporte de nombreuses solutions. Rien que sur le site des extensions XWiki :

un script groovy pour convertir la syntaxe Mediawiki en syntaxe XWiki, mais peu documenté et datant de 2007 et dont la version date de 2013
le Migration Toolkit qui détaille comment réaliser la migration. A priori bien documenté mais la migration a vraiment l’air complexe

En écumant la dev-list je suis également tombé sur des sites externes ou des méthodes alternatives mais rien qui ne m’ait donné envie de sauter le pas. Je vais néanmoins citer cet article qui détaille une méthode qui marche a priori (lien mort, j’utilise Internet Archive), mais ce n’est pas encore simplissime.

Une autre méthode également mise en avant par Vincent Massol de XWiki est aussi de faire appel à leurs services pour assurer la migration. Dans le cas d’un wiki d’entreprise très complexe et avec un fort enjeux business, cela mérite probablement considération.

Et la solution ?

Courant de l’été, j’avais un peu mis le problème de côté. Puis j’ai lu dans la dev-list qu’une nouvelle méthode avait été mise au point, à tester. J’ai mis un peu de temps à me décider, mais j’ai fais le test.

Cette nouvelle extension dispose d’une page sur le magasin des extensions XWiki, disponible à l’adresse suivante :

extensions.xwiki.org/xwiki/bin/view/Extension/MediaWiki/MediaWiki+XML

Il y a deux composants en jeux en réalité. Le convertisseur en lui même Filter Streams Converter Application qui est le composant générique qui fait le travail et MediaWiki XML le composant spécifique à la syntaxe Mediawiki pour ce module.

Tout ceci peut s’installer en téléchargeant les packages sur le site ou directement (et c’est même plutôt conseillé) depuis le magasin d’extension dans l’administration de votre XWiki :

A noter, l’extension Filter Streams Converter Application semble être intégrée par défaut au cœur de XWiki. Et comme c’est un dépendance de l’extension MediaWiki XML, je n’ai initialement pas pu l’installer car l’application Filter Streams Converter Application était en version 8.4.1 alors que la 8.4.2 était nécessaire !

J’ai donc du mettre à jour le XWiki de 8.4.1 vers 8.4.2 avant de pouvoir installer MediaWiki XML.

Note : Dans le cas où vous ne pourriez pas mettre à jour votre XWiki, vous pouvez toujours installer temporairement un XWiki à jour à la dernière version (avec Docker par exemple?), réaliser la conversion, faire un export XAR que vous pourrez réimporter dans votre XWiki de production.

Export

Maintenant que nous avons récupéré les extensions, nous allons pouvoir procéder à l’export du Mediawiki. Cette partie est très bien outillée et documentée côté Mediawiki. Il existe de nombreuses extensions permettant d’extraire la totalité du mediawiki mais vous pouvez également vous contenter des fonctionnalités par défaut avec un peu d’astuce. L’important est d’avoir à la fin un export XML contenant toutes vos pages au format Mediawiki.

Pour ma part j’ai utilisé la méthode « manuelle ». Dans Mediawiki il existe des pages spéciales, que vous connaissez certainement. J’en ai utilisé 2 :

La première est la page « Toutes_les_pages » que l’on peut accéder avec une URL du type http://@IP_mon_wiki/mediawiki/index.php?title=Sp%C3%A9cial:Toutes_les_pages et qui comme son nom l’indique nous liste toutes les pages du wiki. Un simple copier coller avec un peu de remise en forme nous donner une liste de toutes les pages.

La seconde est tout simplement là aussi la page spéciale d’export de pages, que l’on accède via un lien du type https://@IP_mon_wiki/mediawiki/index.php?title=Sp%C3%A9cial:Exporter. Après un petit copier/coller de la liste de pages qu’on vient de récupérer, un obtient un fichier XML avec toutes nos pages.

Si vous êtes curieux, voilà à quoi ressemble en vrai une de vos pages mediawiki (en ouvrant le XML) :

Import

Paramétrage

Si l’installation des modules s’est bien passée, vous devriez avoir une nouvelle application installée dans la liste des applications en haut à gauche de votre xwiki :

Attention : Un avertissement nous rappelle que l’application Filter Streams est encore jeune et qu’il y a des risques à l’utiliser.

Comme vous pouvez le voir, cette application à de nombreuses options. La première option à renseigner est le type de de l’entrée. Ici nous avons un fichier XML Mediawiki, il faut donc renseigner MediaWiki XML input stream (mediawiki+xml). Si vous ne voyez pas cette ligne, c’est que vous n’avez pas correctement installé l’extension MediaWiki XML.

On doit ensuite descendre un peu et renseigner la source (ici notre export XML). Vous pouvez soit le déposer sur le serveur et utilise « file:.xml » pour accéder au fichier, mais j’ai trouvé plus simple d’y accéder à l’aide d’un serveur HTTP et d’une URL.

Pour la partie Output, si vous n’avez peur de rien, vous pouvez copier les pages XWiki converties directement dans votre XWiki avec XWiki instance output stream (xwiki+instance). C’est l’option que j’ai utilisé mais rien ne vous empêche d’être prudent et de générer un XAR en sélectionnant l’option XAR ouput stream.

Par défaut, toutes les pages de mon Mediawiki étaient au même niveau hiérarchique (contrairement à mon XWiki où les pages sont organisées selon une arborescence). Ces pages sont copiées directement à la racine du XWiki. J’ai donc préféré les placer en dessous d’une page que j’ai appelé Import.

Attention : cette option est située plus haut car l’ajout d’un parent est réalisé lors de l’import. On retrouve l’option juste au dessus de là où on configure la source.

Vous pouvez aussi les copier dans un sous-wiki si vous le souhaitez.

Avant de cliquer

2 options par défaut sur lesquelles je vous invite à réfléchir :

Par défaut Delete existing document est à true => les documents existants sont écrasés !
Personnellement je l’ai passé à false !
Par défaut Stop when document save fail est à true => s’il y a une erreur dans le XML, l’import s’arrêtera.
Je l’ai laissé tel quel par sécurité, mais j’ai du recommencer le processus d’export en excluant les pages concernées et en recommençant le processus. C’est assez fastidieux surtout si vous avez beaucoup d’erreurs. Dans ce cas, on pourra tenter de passer le Booléen à false, pour voir.

Conversion !!!

Maintenant que tout est prêt, on peut valider en cliquant sur Convert ! Vous pouvez voir en temps réel la conversion et l’import en haut de la page.

Personnellement, sur 150 pages importées, je n’ai eu que 4 pages qui n’ont pas pu être importées et qui ont causés une exception Java :

Exception thrown during job execution
class org.xwiki.filter.FilterException: Failed to parse XML
at org.xwiki.filter.mediawiki.xml.internal.input.MediaWikiInputFilterStream.read(MediaWikiInputFilterStream.java:255)
at org.xwiki.filter.mediawiki.xml.internal.input.MediaWikiInputFilterStream.read(MediaWikiInputFilterStream.java:81)
[...]
at java.lang.Thread.run(Thread.java:745)
Caused by: class java.lang.NullPointerException: null
at org.xwiki.filter.mediawiki.xml.internal.input.MediaWikiInputFilterStream.getFile(MediaWikiInputFilterStream.java:612)
at org.xwiki.filter.mediawiki.xml.internal.input.MediaWikiInputFilterStream.sendAttachment(MediaWikiInputFilterStream.java:581)
[...]
at java.lang.Thread.run(Thread.java:745)
Finished job of type [filter.converter] with identifier [filter/converter/mediawiki+xml/xwiki+instance]

Mais la très grande majorité de mon mediawiki a été converti. L’ensemble des pages ont bien été déplacée dans un page Import, et la syntaxe est correctement convertie.

En conclusion

On a vu à de multiples reprises que l’outil est jeune et qu’il y a quelques risques pour votre xwiki du fait du manque de retours sur l’outil.

Mais si vous prenez vos précautions (import dans un xwiki temporaire, un sous-wiki ou en XAR), vous avez maintenant à votre disposition un outil simple pour migrer vos volumineux mediawiki de manière automatisées vers xwiki : A vos conversions !

Notes complémentaire, un nouveau parser

A priori depuis l’été, il existe également une extension MediaWiki Syntax qui ajoute un parser compatible avec la syntaxe Mediawiki. Je ne l’utilise pas puisque j’ai réussi à migrer toutes mes pages, mais pour la copie de pages longues et complexes, cela peut éventuellement être une solution alternative.

Paramètre caché XWiki pour résoudre l’erreur « fichier trop gros » lors de l’import d’un XAR

Sat, 12 Mar 2016 11:30:04 +0000

[Edit]

Ludovic DUBOST, CEO et fondateur de XWiki SAS m’a répondu (voir les commentaires). Le bug est connu mais a priori on doit utiliser les attachements de type Filesystem Attachment (pas le choix par défaut qui est le Database Attachment).

On trouve plus d’informations sur l’article suivant

www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Attachments

The Filesystem attachment store saves your attachments in files in a directory tree. This means you will have one more thing to do when you back up your data but it also means you can save larger (over one gigabyte) files.

[/Edit]

Lorsque j’ai voulu importer une sauvegarde XAR un peu importante sous XWiki, je me suis retrouvé bloqué par la taille maximale des fichiers XAR que je pouvais importer. En effet par défaut, on est limité à 32 MB ce qui peut arriver rapidement avec des images/captures d’écran.

Et comme on ne peut pas faire un XAR avec uniquement une partie d’un wiki, il n’y a pas trop de solutions pour réduire la taille du XAR (vous pouviez quand même jouer sur la présence de l’historique des révisions ou pas, je ne sais pas si c’est toujours le cas).

[Edit]On peut faire des imports/exports plus précis avec des extensions comme LargeXARImport ou ImportExport, etc. [/Edit]

Pour autant, modifier cette limite purement logicielle (et arbitraire), il faut passer par des pages d’administration cachées.

La solution

Pour une raison que j’ignore, on ne peut ni accéder à ce paramètre dans les pages d’administration classique du wiki ni modifier une valeur dans les fichiers de configuration.

Il faut ouvrir une URL directement en mode « édition » sur les préférence du type :

http://@IPwiki:8080/xwiki-enterprise-web-7.2/bin/edit/XWiki/XWikiPreferences?editor=object

Si vous êtes au bon endroit, cela devrait ressembler à ça :

Cliquez sur la liste « XWikiPreferences 0 » **juste en dessous **de la ligne « XWiki.XWikiPreferences (1) ». Pas évident évident…

On y retrouve également des valeurs comme le serveur SMTP ou le serveur LDAP qu’on a paramétré côté xwiki.cfg, bizarrement ?

Modifiez le paramètres à la hausse pour correspondre à votre taille de fichier XAR, puis cliquez sur « Enregistrer et Fermer » pour valider.

Dans mon cas (PostgreSQL), ça marche, pas besoin de modifications supplémentaires, juste un redémarrage de tomcat.

Et la base de données ?

Pour autant, vous pourriez quand même avoir des ennuis si jamais votre base de données n’accepte pas les fichiers trop gros elle aussi, comme par exemple MySQL/MariaDB. Vous trouverez plus d’informations sur le sujet dans ce topic de la mailing list (lien mort, j’utilise Internet Archive) :

Pay also attention that your DB configuration could prevent you from uploading such a package. For exemple, with Mysql, you have to fix the value of max_allowed_packet in my.cnf file. If you want to upload a package of 35 MB for example, you need the value max_allowed_packet to be at least « 75M ».

Je ne suis pas certain de comprendre pourquoi il faut mettre max_allowed_packet à 75M pour un fichier de 35 MB. Visiblement il y a un coefficient x2 ?

Mais ça ne marche toujours pas

C’est fini ? Et bien non. Malheureusement, l’import de fichiers .XAR de XWiki est a priori une fonctionnalité très gourmande en mémoire et plante parfois juste après la fin de la barre de transfert :

Dans le fichier de log on pourra trouver une erreur de ce gout là :

Nov 12 17:02:23 @IPxwiki server: 2015-11-12 17:02:23,152 [http://@IPxwiki:8080/xwiki-enterprise-web-7.2/bin/upload/XWiki/XWikiPreferences] WARN c.x.x.w.UploadAction - Saving uploaded file failed
Nov 12 17:02:23 @IPxwiki server: Caused by: java.lang.OutOfMemoryError: Java heap space

Bon il semblerait que ce soit un problème connu depuis au moins 2008, si on en crois ce post (lien mort, j’utilise Internet Archive) et la réponse de Sergiu Dumitriu :

This is a major design flaw of the current attachment storage model. As stated in a previous mail, handling attachment consumes about 27 time the size of the attachment, so 90M * 27 ~= 2.5G. This needs to be fixed ASAP. In the meantime, you can either increase the heap size to more than 2.5G, or request an sql dump from the myxwiki farm admins.

27 FOIS

Effectivement, lorsque j’importe des XAR d’environ 60-70 Mo dans mon instance tomcat sizée à environ 2 Go, ça fonctionne, mais pas pour les fichiers de 80 Mo. La règle semble correspondre.

J’écrirais un autre article pour expliquer ce qu’on peut y faire dès que j’aurai un peu plus de matière.

Source

www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Attachments

Migration KVM Ubuntu vers Redhat et problème /usr/libexec/qemu-kvm: No such file or directory

Sun, 04 Oct 2015 19:20:58 +0000

Je suis en train de migrer de KVM vers ProxMox. Et du coup, je ressors de mes tiroirs tous les articles que je n’ai pas eu pris le temps d’écrire à propos des problèmes que j’ai pu rencontrer, notamment lors de ma migration VMware ESXi vers KVM/Uubuntu puis KVM/Ubuntu vers KVM/CentOS.

Processsu de migration (à froid)

On pourrait penser que migrer une machine virtuelle KVM Ubuntu vers une machine virtuelle KVM sous RHEL/CentOS ne pose pas de problème particulier puisqu’il s’agit d’une même technologie : qemu. Et pourtant !

Lorsque j’ai voulu passer sous CentOS pour des questions d’habitude d’administration (et aussi parce que la philosophie RHEL me plait plus que celle d’Ubuntu), je me suis rendu compte que ça n’est pas tout à fait vrai.

Voici la procédure que j’ai suivi pour migrer :

copie de mes machines virtuelle sur un volume séparé, ainsi que dump de leur fichiers de configuration
réinstallation from scratch de l’OS de l’hyperviseur, j’en ai profité pour passer sur un OS installé en RAID1 pour plus de sécurité
récupération des machines virtuelles et réimport de leur configuration

Pour ceux qui ne sont pas familier avec l’import/export de configuration de machines virtuelles via virsh, voici un petit aparté sur la marche à suivre :

virsh list #affiche la liste des machines virtuelles actives sur le serveur
virsh list --all #affiche toutes les VMs enregistrés sur l'hôte, même celles inactives
virsh dumpxml GuestID > guest.xml #dump XML du fichier de configuration pour sauvegarde ou import futur
virsh define guest.xml #réimporter le fichier de configuration XML (sans démarrer la VM à la suite)

En cas d’erreur No such file or directory lors de l’import

Lors qu’on importe la machine virtuelle, on peut avoir l’erreur suivante :

virsh define MaVM.xml
error: Failed to define domain from MaVM.xml
error: Cannot find QEMU binary /usr/bin/kvm: No such file or directory

La première chose à vérifier bien entendu est que tous les packages sont bien installés mais dans mon cas c’était bien le cas (le package qemu contenant l’émulateur KVM était bien installé).

Sur Ubuntu, l’émulateur est stocké dans le binaire /usr/bin/kvm. A l’inverse, sur RHEL ou CentOS, il n’est pas situé dans le même dossier, et ne s’appelle même pas kvm mais /usr/libexec/qemu-kvm !

On doit donc passer sur chaque fichier XML de configuration de machine virtuelle pour modifier le chemin vers le binaire. On en profitera également pour mettre à jour le chemin vers le disque dur virtuel si jamais l’arborescence de stockage n’est pas la même entre les deux serveurs.

vim MaVM.xml
<emulator>/usr/bin/kvm</emulator>

A partir de là, vous pouvez importer correctement vos VMs et les démarrer !

Pour aller plus loin

A noter, par défaut sous RHEL/CentOS les fichiers sont répartis de la façon suivante :

/etc/libvirt/qemu/ pour tous les fichiers de configuration VM, storage, etc.
/var/log/libvirt/qemu/ pour les fichiers journaux des machines virtuelles
/var/run/libvirt/qemu/ contient les fichiers de fonctionnement de la machine, à avoir le .pid pour stocker le PID du process maitre de ma VM, ainsi qu’un fichier XML contenant une copie de la configuration de la VM en fonctionnement
/var/lib/libvirt/qemu/ contient des fichiers permettant de suivre les performances de la VM, de stocker les éventuels dump/snapshots/sauvegardes

Un peu de documentation clairement expliquée sur l’utilisation de virsh sur la communauté Ubuntu : Virsh

Et pour aller plus loin dans le Troubleshooting, voici un guide de RedHat listant les erreurs courantes avec Qemu/KVM.

[Tutoriel] Migrer facilement son blog de WordPress.com vers un hébergement mutualisé OVH

Sat, 11 Apr 2015 21:23:20 +0000

Petit aparté avant le début de ce tutoriel, je rédige le premier article de mon blog géré par moi même (hébergé sur OVH). Ce matin même, j’étais encore hébergé en tant que blog gratuit chez WordPress.com. J’ai décidé de sauter le pas cars je trouvais le compte wordpress.com trop bridé, notamment au niveau de la limite pour les médias et l’impossibilité d’ajouter de plugins ou de toucher au CSS sans devoir mettre la main au porte monnaie.

Et puis bon… cela fait plus sens de gérer moi même mon blog sachant que je passe mon temps à bidouiller sur mes OS et que j’administre tout à la maison ;-)

Ce n’est pas pour faire de la pub pour OVH, mais il faut reconnaître que leurs offres « premier prix » sont vraiment bon marché. Entre 2 et 5€ par mois, on peut avoir un hébergement « web » en mutualisé, un VPS, voire même un serveur physique dédié (kimsufi en Atom, mais quand même!). Imbattable (enfin, allez quand même vérifier, hein?).

Si vous êtes sur ce tuto, c’est probablement que vous voulez que la migration se passe le plus simplement possible. Du coup, même si les trois options que je cite sont toutes viable, la plus simple est quand même à mon avis est d’ouvrir un compte pour de l’hébergement mutualisé, qui bénéficie chez OVH d’un module « 1-clic » dédié à WordPress.

En réalité, il y a un peu plus d’un clic pour réussir votre migration. Je vais vous guider.

Création de l’instance de base de données pour WordPress

La première chose à faire est de se connecter sur votre Manager OVH, de sélectionner votre nouvel hébergement mutualisé.

La partie hébergement mutualisé se gère dans la partie « Plateforme » sous les noms de domaine.

OVH a beau proposer des module « 1-click » pour installer WordPress, en réalité il faut quand même d’abord commencer par créer l’instance de base de données pour stocker le tout.

Dans l’offre d’éhbergement la moins chère d’OVH, on dispose d’une instance de 200 Mo, avec au choix MySQL ou PostgreSQL. C’est largmeent suffisant pour un blog, même avec beaucoup d’articles, car les médias (photos, vidéos) ne sont pas stockées en base.
Professionnellement parlant, je préfère PostgreSQL, mais pour pouvoir utiliser le module 1-click de votre hébergement, il faut donc absolument créer une instance de type MySQL.

Une fois la création de la base de données validée, le message suivant s’affiche.

On doit également avoir la ligne suivante dans les Tâches en cours.

Comme toutes les opérations chez OVH, ce n’est pas immédiatement opérationnel, il faut attendre quelques secondes voire quelques minutes selon l’opération. Une fois que c’est terminé, on peut procéder à l’installation de WordPress à proprement parler.

Déploiement du nouveau WordPress

Ouvrir l’onglet « Modules en 1 clic » et cliquer sur Ajouter

Le processus d’installation est relativement simple à suivre

Dans le cas où la base de données à été mal créée ou n’est pas encore opérationnelle, vous obtiendrez le message suivant en étape 2

A l’inverse, si tout est bien paramétré, vous pourrez rentrer les informations de connexion à la base de données de votre compte OVH.

Et voilà le message qui indique que tout s’est bien passé

Une fois l’email reçu, vous pouvez vous connecter sur votre nouveau WordPress, qui sera vite (mis à par l’utilisateur d’administration et quelques pages d’exemple).

Export des données existantes

Pendant que le WordPress est installé par OVH, on peut se connecter sur l’ancien blog et récupérer les données existantes.

Ce n’est pas la première migration que je fais. J’avais débuté ce blog sur une page perso Free (pendant très peu de temps, encore plus bridé que wordpress à l’époque) et j’avais migré rapidement vers wordpress.com. A l’époque, il faut savoir qu’il n’était pas possible de réaliser la bascule inverse. Quand vous étiez chez WordPress.com, vous étiez ferrés (sauf probablement si vous étiez prêt à payer, j’imagine). Mais aujourd’hui c’est possible et même très simple. Il suffit d’ouvrir les outils dans la partie wp-admin.

Une fois le menu ouvert, laisser les options par défaut et sauvegarder le fichier XML généré.

Prise en main du nouveau blog, mise à jour et création d’un nouvel utilisateur

Le temps qu’on réalise cette opération, le site web est probablement installé et vous avez du recevoir l’email d’OVH pour vous dire que tout est prêt. Connectez vous sur votre nouveau site.

La première chose qui saute aux yeux lorsqu’on se connecte pour la première fois, c’st WordPress qui nous indique que la mise à jour vers la dernière version a été faite, mais qu’il reste les extensions à mettre à jour. C’est un bon conseil ;-)

Par souci de sécurité là encore, je préfère toujours séparer le compte d’administration (déjà créé lors de l’installation) du compte que j’utilise tous les jours.

Ainsi, ce n’est pas le même compte que j’utilise pour administrer le site (et il n’est pas « visible » car il ne poste jamais) et le compte moins privilégié qui lui poste les articles.

Je vous conseille de le faire également.

Import des données dans le nouveau WordPress

Ça y est, le plus urgent a été fait! On peut maintenant réutiliser le fichier XML pour réimporter les pages, les posts, les commentaires.

Tout ce qui est « média » n’est pas présent dans le fichier XML, mais on pourra tout de même le récupérer grâce à une option lors de l’import. Pratique !

Lorsqu’on tente d’importer, WordPress nous redirige vers le module permettant de le faire. Il faut l’installer et l’activer avant de pouvoir importer notre XML.

Ce message indique de l’installation s’est bien passée. N’oubliez pas de cliquer sur « Activer l’extension & lancer l’importateur » !

Récupérer le fichier XML, cocher l’option « Download and import file attachments » si vous voulez récupérer les fichiers « Média » présents sur vos pas (typiquement, toutes les photos, images, vidéos, … que vous avez importé et intégré à votre blog sur WordPress.com).

Dernière astuce, dans cette même page vous pouvez également indiquer à WordPress de changer l’auteur des posts au moment de l’import. Même si c’est modifiable après coup, c’est très pratique si vous ne voulez pas que l’auteur de TOUS les posts soit signés comme provenant de l’utilisateur « admin » que vous avez utilisé pour réaliser l’import.