Mediawiki 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.

Quand Vulture 2.0 planne au dessus de la carcasse d’un Lenny et de son fidèle Mediawiki

Tue, 01 Nov 2011 17:03:35 +0000

Peut être que vous connaissez Vulture, mais peut être pas. Pour ceux d’entre vous qui ne se sont jamais vraiment posé la question de la sécurité pour les contenus web que vous diffusez sur Internet, protéger un minimum ses applications web devient très rapidement vital si elles sont autohébergées, et encore plus (*shock*) si vous les avez développées vous même. On aimerait bien éviter de devenir la porte ouverte à toute les fenêtres…

De plus, une fois la peur des pirates informatique américo-chinois (ou autre gouvernement soutenant ouvertement les pirates informatiques : il n’y a bien que la France pour n’avoir que des équipes de « défense ») étant partiellement écartée, on peut aussi disposer de beaucoup de contenus publiés, disposant chacun de leur propre méthode d’authentification, et souhaiter pouvoir faire du Single Sign On pour éviter d’avoir 50 comptes différents et de taper ses logins/passwords toute la journée! Aaaaah le Single Sign On. Les SSII nous en auront vendu, des solutions clés en mains permettant de s’interfacer avec tout en un clic, ou presque! Toute la nuance étant dans le « ou presque ».

Aujourd’hui, je ne vais donc pas vous vendre la solution ultime à tous vos problématiques de sécurisation de vos applications web ni vous donner un portail SSO universel, mais tout de même…

Présentation

Vulture est un projet open source, permettant de faire la plupart des tâches qu’on attend d’un portail Web SSO. Depuis plusieurs mois, il n’y avait pas eu beaucoup d’activité sur le projet, qui est resté pendant un bon moment aux versions 1.98 et 1.99. Cependant il manquait à la version 1.XX certaines fonctionnalités utiles, notamment la propagation de l’authentification via cookies (utilisé par exemple pour mediawiki). Un peu dommage pour un SSO si on doit se ré-authentifier pour aller sur son Wiki pour aller chercher des infos techniques rapidement.

Cependant, cet été, une version 2.0 a vu le jour, même si le fait que cela soit une beta ou non n’est pas très clair je trouve ([EDIT] A priori on est toujours en béta, donc pas de prod je vous prie).

Vulture est un reverse-proxy offrant des fonctions Web-SSO et firewall applicatif.

Un des gros points noir du projet Vulture est le manque de clarté dans leur documentation, notamment pour les débutants dans les reverse-proxy. A mon avis, un petit tutoriel pas à pas s’impose pour pouvoir configurer « au minimum » l’accès à quelques applications.

Installation

La première chose que je dois vous dire, c’est que j’ai effectué l’installation sur une machine virtuelle vieillissante en Debian Lenny. Je vais donc tout de suite commencer par vous déconseiller de tester sur une Lenny, mais plutôt de le faire sur une Squeeze, pour des raisons de paquets non disponibles dans les dépôts…

La documentation relative à l’installation en elle même est disponible sur le site du projet

www.vultureproject.org/documentation/installation/

Une fois toutes les dépendances installées comme indiqué sur le site puis le paquet .deb installé, vérifiez que vous n’avez aucune erreur lors du lancement de l’application (automatique).

A priori vous devriez pouvoir vous connecter sur l’interface web de vulture en local sur le port 9090 (et local seulement). Pour ceux qui voudraient ne pas être obligés de faire ça en local justement (VM sans environnement graphique ou réseau local bien protégé), vous pouvez faire un tunnel SSH ou modifier les paramètres apache de Vulture, comme indiqué dans la doc d’installation.

Personnellement je suis sur un réseau NATé, donc le seul moyen d’accéder au port 9090 est d’être sur mon réseau local, et j’ai pu laisser des paramètres de sécurité apache très lights. Le plus propre serait évidemment d’interdire toutes les IP autres que votre poste d’administration.

Listen *:9090
[...]
<Virtualhost *:9090>

Pour ceux qui n’ont rien écouté et qui ont quand même voulu installer leur vulture sur un Lenny, si vous vous retrouvez avec l’erreur suivante, c’est parce que le paquet libdb4.8 n’est tout simplement pas installé pour une raison simple : elle n’est pas disponibles dans les dépôts standards.

Starting vulture: apache2: Syntax error on line 40 of /var/www/vulture/conf/1.conf: Cannot load /usr/lib/apache2/modules/mod_security2.so into server: libdb-4.8.so: cannot open shared object file: No such file or directory
apache2: Syntax error on line 40 of /var/www/vulture/conf/2.conf: Cannot load /usr/lib/apache2/modules/mod_security2.so into server: libdb-4.8.so: cannot open shared object file: No such file or directory

Une façon de s’en sortir est heureusement d’installer le fameux paquet depuis un site tiers

wget http://backports.debian.org/debian-backports/pool/main/d/db/libdb4.8_4.8.24-1~bpo50+1_i386.deb
dpkg -i libdb4.8_4.8.24-1~bpo50+1_i386.deb

Configuration

Maintenant on entre dans le vif du sujet. Nous sommes parvenus à installer Vulture, et il est maintenant accessible en local ou pas (c’est selon).

Pour se connecter, c’est facile, le mot de passe administrateur est parfaitement secure puisqu’il s’agit de admin/admin, donc vous pouvez le laisser tel quel :-p.

Ceux qui connaissent déjà la version précédente de Vulture ne seront pas trop surpris : elle est strictement identique. Bien que la documentation soit assez claire sur la fonction de chacun des champs dans chacun des menus (documentation de Vulture), il n’y a pour l’heure aucun tutoriel pour permettre à tout le monde d’installer Vulture.

Voici donc, une liste d’étapes commentées pour vous permettre de mettre en place le strict minimum : un portail commun pour vos application web faisant office de firewall applicatif, avec une authentification simple, ainsi que l’ajout d’une application (mediawiki ici) sans SSO.

Les problématiques plus poussées seront développées dans un prochain article (SSO, ajout d’une authentification LDAP, …).

Gestion des utilisateurs

Comme dit plus haut, la première priorité est donc de changer le mot de passe de l’administrateur. Pour se faire, il suffit de cliquer sur le menu Users puis de cliquer sur la petite icône représentant une feuille et un crayon pour éditer l’utilisateur.

Pour une raison que j’ignore, même si je doute que ce soit une nouvelle fonctionnalité révolutionnaire, le mot de passe est affiché via son hash MD5. Et pour le modifier il faut entrer également un hash MD5 du nouveau mot de passe.

Une fois qu’on a modifié le mot de passe de l’administrateur, on peut ensuite créer tous les utilisateurs qu’on veut autoriser à se connecter au portail et au applications.

Creation d’un module de log

Pour générer les fichiers de journalisation sur les erreurs et les accès apache de chacun des composants interfacés au portail, Vulture se base sur le module apache mod_log.

Contrairement à la version précédente de Vulture, il est nécessaire de créer/paramétrer son propre module de logging avant de pouvoir commencer à déclarer les interfaces. A mon avis, là aussi, c’est juste un oubli, qui sera rajouté par la suite.

En attendant, voici les champs à remplir pour pouvoir disposer d’une journalisation correcte sur chaque interfaces et chaque application :

Name : Combined
Error Log Verbosity : error
Access Log Format : « %h %l %u %t « %r » %>s %b « %{Referer}i » « %{User-agent}i » »
Directory where to place Logfiles : /var/log/

Création d’une interface

Vulture permet de créer un certain nombre d’interfaces, qui correspondent en fait aux virtualhosts en écoute pour le portail qui regroupe toutes les applications.

Il est donc nécessaire d’en créer au moins une, que l’on liera par la suite à toute nos applications.

Dans mon cas, j’ai souhaité que toutes les applications web que je publie sur Internet soient centralisées par un portail HTTPS. Pour ce faire, j’ai créé plusieurs alias DNS qui pointent tous vers l’IP du portail vulture (192.168.0.XX), ainsi qu’un alias pour le portail lui même (portail.example.org).

J’ai ensuite généré les certificats SSL (autosignés ici). Pour générer plus rapidement les certificats, il est possible d’utiliser le modèle fournit sur le site vulture.open-source.fr (lien mort, j’utilise Internet Archive), puis exécuter la commande :

openssl req -x509 -days 1825 -newkey rsa:1024 -batch -out server.crt -keyout server.key -nodes -config openssl.cnf

Pour créer l’interface il suffit donc de remplir les champs correspondants

Creation de l’application

Une fois l’interface créée sans encombre, reste maintenant à définir les paramètres de vulture pour l’application que l’on souhaite protéger derrière le Vulture. Ici, il s’agit d’un Mediawiki, sur lequel on peut s’authentifier via une base de données interne, ou via LDAP. Dans les deux cas, il n’était pas possible d’interfacer Mediawiki avec Vulture 1.99. Ici, je ne détaillerai pas la méthode pour effectuer ce SSO normalement disponible depuis la 2.00, pour la simple raison que je ne l’ai pas encore testé, mais cela fera l’objet d’un prochain article.

Ici, les champs à remplir sont :

Internet Name : l’alias que l’on a décidé pour l’application, mediawiki.example.org par exemple
Interface : L’interface qu’on vient de créer
Private URL : L’url complète vers laquelle on doit pointer pour trouver l’application web. Ici il s’agit de l’IP et du numéro de port du mediawiki
Authentication : les méthodes qui sont autorisées pour décider si l’utilisateur à l’accès ou non. Ici la seule méthode dont on dispose pour l’instant est vulture (il faut donc la sélectionner)

Après une petit redémarrage de l’interface (logo avec les deux flèches vers en cercle), le portail et l’application devraient être disponible

Enjoy