XAR on Zwindler's Reflection

Résoudre les erreurs de fichiers trop gros lors des imports XWiki, XAR notamment

Sat, 30 Apr 2016 13:30:41 +0000

Pourquoi je n’arrive pas à uploader mon gros XAR

Cet article fait suite à mon précédent article indiquant comment corriger les erreurs lors d’imports de fichiers XAR dans XWiki. J’avais un bon gros export au format XWiki (XAR donc) et j’avais plusieurs erreurs lors de l’import qui me bloquait.

A la suite de l’article, j’ai reçu une réponse de Ludovic DUBOST, CEO et fondateur de XWiki SAS qui m’a donné une piste supplémentaire pour régler le problème.

Cette limite de taille du fait de la consommation mémoire est réglé dans le mode « File System Attachment » de XWiki. Il y a déjà eu des discussions pour que ce soit la configuration par défaut. Nous allons la réactiver.

Pour plus d’infos sur le mode FS:
platform.xwiki.org/xwiki/bin/view/AdminGuide/Attachments#HFilesystemAttachmentStore (lien mort, pas dispo sur Internet Archive)

Filesystem attachment store

Et oui, des fois dans la vie, il suffit de lire la documentation entière et ne pas se contenter du premier paragraphe.

Dans la documentation à propos des attachements, si on va au delà de la première partie, on peut lire :

The directory in which the attachments are stored in the filesystem is defined with the parameter environment.permanentDirectory in the xwiki.properties file. By default it’s defined to be data, which is a directory relative to where the Java Servlet Container was started. It’s recommend to modify this value to be absolute sure that you can start the Servlet Container from any directory and still have XWiki find the attachments located in this work directory.

environment.permanentDirectory=/opt/tomcat6/data

En gros, plutôt que de fonctionner dans le mode classique avec l’ensemble des objets (pièces jointes) et donc les imports XAR en base de données, il est possible de stocker sur le filesystem local les fichiers dans une arborescence standard de type /opt/tomcatX/data.

(Lien image mort)

Sur le papier, cette méthode permet de s’affranchir des tailles maximales des objets envoyés en base (entre autre un pb de stream avec MySQL selon Ludovic DUBOST?). Elle apporte cependant son lot de considérations supplémentaires :

Il ne faut évidemment pas manipuler les fichiers en dehors du wiki (i.e. aller virer des fichiers directement dans le FS côté OS pour faire un peu de place. Ne faites pas les innocents, je sais que vous y pensiez)
Sauvegarder la base de données ne suffira plus puisque les objets ne sont plus en base. Il faudra ajouter à votre script de sauvegarde un petit bout de script pour zipper les fichiers uploadés contenus dans le fameux dossier
Basculer d’un mode à l’autre n’est pas une opération à prendre à la légère : si vous avez déjà des objets en base, il faut les récupérer pour les redéposer sur le FS.

Pour la première, on va dire que je vais vous faire confiance ;). Pour la seconde aussi, vous êtes sérieux.

Pour ceux qui sont dans l’ancien mode de fonctionnement

Et pour la dernière, l’équipe de XWiki met gentiment à disposition une extension pour passer automatiquement d’un mode à l’autre : Filesystem Attachment Porter ! Ca tombe bien, je n’avais pas envie de le faire à la main ;-).

La procédure est assez bien documentée et détaille même ce dont je viens de parler un peu plus haut (sauvegarde des répertoires, bascule dans le nouveau mode de stockage des PJ).

Pour les nouveaux utilisateurs

Le problème ne se pose pas vraiment. Si le wiki vient d’être créé il n’y a pas encore d’objets en base. Vous pouvez simplement basculer dans le mode « Filesystem attachment » en modifiant quelques options dans le fichier xwiki.cfg

xwiki.store.attachment.hint = file
xwiki.store.attachment.versioning.hint = file
xwiki.store.attachment.recyclebin.hint = file

Au delà de ça

N’ayant pas suivi l’ensemble des discussions à propos des choix de garder le mode par défaut avec tout en base, je ne peux pas savoir ce qui a conduit à ne pas basculer dans le mode Filesystem attachment « par défaut ». Cependant, je pense qu’effectivement cela pourrait être une bonne idée de le faire, à minima pour éviter que d’autres utilisateurs continuent de poser la question sur la devlist.

FAQ

Également, vous auriez pu tomber sur la solution via une FAQ qui a été rédigée début 2016, probablement suite au nombre de personnes qui ont eu ce problème et qui le remontent dans la devlist (premiers résultats jusqu’à il y a peu quand on tappe le message d’erreur dans Google) :

www.xwiki.org/xwiki/bin/view/FAQ/How+to+import+a+XAR+larger+than+100MB

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

[Tutoriel] Installer XWiki 7.X sur RedHat/CentOS 7 (Tomcat + PostGreSQL)

Wed, 16 Dec 2015 17:30:53 +0000

XWiki, c’est quoi ?

En entreprise, il n’est pas rare que les utilisateurs expriment leur besoin de stocker l’information de manière intelligente aux administrateurs systèmes. Ça peut passer par une GED, une plateforme de travail collaboratif, et même dans certains cas, un wiki (l’exemple le plus connu de wiki est Wikipedia, au cas où ça ne voyez pas de quoi on parle).

Comme je travaille dans l’IT, je ne suis pas encore tombé dans un contexte où un wiki n’avait pas sa place et c’était même souvent un projet pris très au sérieux.

Très au sérieux, d’accord, mais quand même, le mieux serait que ça soit gratuit ! Argument que j’entends relativement souvent de la part des directions, et c’est de bonne guerre ;-).

Du coup, le choix est tout de suite plus restreint. De ce que j’ai pu trouver dans le marché du gratuit et/ou opensource et pas trop confidentiel pour avoir une chance que le projet survive quelques années, j’ai trouvé :

Mediawiki => le logiciel sur lequel est basé Wikipedia, que j’ai utilisé à titre personnel mais qui nécessite de connaitre un peu la syntaxe pour obtenir un rendu visuel correct
Dokuwiki =>que je n’ai pas utilisé ni même testé, mais j’ai eu de bon retours
XWiki => un logiciel en Java dont la syntaxe est proche des autres logiciels wiki mais qui dispose surtout de manière native d’un éditeur WYSIWYG (what you see is what you get, autrement dit : comme word. Le resultat final est visible en temps réel)

La nécessité d’avoir un éditeur WYSIWYG étant un prérequis pour les utilisateurs, je n’ai pas vraiment cherché plus loin : nous avons installé XWiki.

Pour débuter, XWiki vous propose un fichier installeur sous Linux ou Windows où tout est pré-parametré avec une base de données interne et un serveur d’application web java intégré. Cependant, j’aime avoir un minimum la main sur ce que j’administre, je ne maitrise pas la base HSQLDB et j’ai eu des soucis avec les options de Jetty. C’est pourquoi j’ai préféré installer moi même le serveur de base de données PostgreSQL et le serveur java Tomcat.

Je vous propose donc d’installer XWiki via le WAR, avec un serveur RedHat Entreprise Linux 7 (ou CentOS 7, c’est pareil), un serveur Tomcat 7 et une base de données postgreSQL 9.2.

Ce tutoriel décrit de manière séquentielle l’ensemble des opérations nécessaires pour y parvenir, à partir des informations qu’on peut trouver dans plusieurs pages éparpillées dans la documentation officielle (et avec quelques captures d’écran en bonus track).

Installation de l’OS

Comme indiqué plus haut, j’ai commencé par installer une machine virtuelle RedHat Entreprise Linux 7.1 au format Desktop (poste de travail). L’ensemble des prérequis sont listés dans la documentation officielle.

Une fois que c’est réglé, on peut aller récupérer les sources sur le site officiel. Au moment où j’ai écris ces lignes, la version Xwiki 7.2 est la version dite stable (en fait en vrai on est pas loin de la 7.4, mais j’ai tardé à publier l’article. Le principe reste le même).

[EDIT 26/01/16] Attention si vous utilisez PostGreSQL, il y a un bug en cours sur le widget qui affiche l’arborescence, du coup j’ai du rollback en 7.2.

J’avais voulu faire la mise à jour car la 7.4 corrige un bug qui date de la version 3.X sur certains PNG qui font planter l’export PDF.

[/EDIT]

Récupérez les fichiers suivants :

xwiki-enterprise-web-7.2.war
xwiki-enterprise-ui-mainwiki-all-7.2.xar

Installation et configuration de Tomcat 7

Je n’ai pas voulu installer à la main tomcat, RHEL 7 propose une version relativement récente de tomcat 7 qui convient très bien dans les repository officiels.

yum install tomcat

Les instructions pour configurer Tomcat pour XWiki sont listées dans la page suivante.

Copiez le war dans l’arborescence /var/lib/tomcat/webapps :

[root@monwiki webapps]# pwd
/var/lib/tomcat/webapps
[root@monwiki webapps]# ll
[...]
-rw-r--r--. 1 root root 227064164 6 nov. 15:16 xwiki-enterprise-web-7.2.war

Passez le serveur en UTF-8 (au niveau du connector dans /etc/tomcat/server.xml) :

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" URIEncoding="UTF-8" />

Ajoutez l’option suivante dans la configuration tomcat :

vi /etc/tomcat/tomcat.conf
CATALINA_OPTS="-Xmx1024m -XX:MaxPermSize=192m"

Ajoutez l’option suivante dans les propriétés de tomcat :

vi /etc/tomcat/catalina.properties
org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true

Déployez le war en lançant une première fois le service tomcat :

systemctl start tomcat
systemctl enable tomcat

Vérifiez que tout se passe bien avec tail -f /var/log/tomcat/catalina.2015-11-10.log #remplacer par la date du jour

INFOS: Deployment of web application archive /var/lib/tomcat/webapps/xwiki-enterprise-web-7.2.war has finished in 31 a 560 ms
nov. 10, 2015 4:07:47 PM org.apache.coyote.AbstractProtocol start
INFOS: Starting ProtocolHandler ["http-bio-8080"]
nov. 10, 2015 4:07:47 PM org.apache.coyote.AbstractProtocol start
INFOS: Starting ProtocolHandler ["ajp-bio-8009"]
nov. 10, 2015 4:07:47 PM org.apache.catalina.startup.Catalina start
INFOS: Server startup in 31609 ms

Le seul inconvénient à choisir la version de tomcat présente dans les repositories est qu’un des mécanismes intégrés de scan des jar (archives java) dans cette version provoque l’apparition dans le log d’un très grand nombre de « stack trace » dans votre catalina.out :

GRAVE: Unable to process Jar entry [javassist/util/proxy/SerializedProxy.class] from Jar
[jar:file:/usr/share/tomcat/webapps/xwiki-enterprise-web-7.2/WEB-INF/lib/javassist-3.19.0-GA.jar!/] for annotations
java.io.EOFException
at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:340)
at org.apache.tomcat.util.bcel.classfile.Utility.swallowMethodParameters(Utility.java:797)
at org.apache.tomcat.util.bcel.classfile.Attribute.readAttribute(Attribute.java:171)
[...]

Avec une version plus récente de tomcat, un warning est simplement indiqué dans le log. Cette erreur n’est pas bloquante, juste désagréable.

Copiez le driver jdbc 41 (.jar) pour postgreSQL 9.2 dans WEB-INF/lib du répertoire de XWiki dans tomcat. Vous pouvez le télécharger à l’adresse suivante.

cd /var/lib/tomcat/webapps/xwiki-enterprise-web-7.2/WEB-INF/lib
chown tomcat:tomcat postgresql-9.2-1004.jdbc41.jar

Installation et configuration de PostGreSQL 9.2

La encore, j’ai préféré installer PostGreSQL par le biais des dépôts RPM plutôt que de l’installer à la main.

yum install postgresql postgresql-server postgresql-jdbc

Les informations permettant de configurer la base de données PostGreSQL pour XWiki sont disponible sur la documentation officielle.

La première commande à passer sur la base PostGreSQL est de l’initialiser avec la commande suivante :

postgresql-setup initdb

Pour information, sur RHEL/CentOS 6, la base est en version 8.4 et pour l’initialiser il faut utiliser :

service postgresql initdb

Personnellement j’aime ajouter un lien symbolique pour retrouver mes logs dans /var/log mais c’est totalement un choix personnel.

ln -s /var/lib/pgsql/data/pg_log /var/log/pgsql

Mdofier la sécurité pour l’authentification des utilisateurs sans utiliser les utilisateurs Unix (changer ident par md5 ou éventuellement trust) :

vi /var/lib/pgsql/data/pg_hba.conf
# IPv4 local connections:
host all all 127.0.0.1/32 md5

Démarrez la base de données puis créer la base qui sera dédiée au xwiki et son utilisateur associé :

systemctl start postgresql
systemctl enable postgresql
su - postgres
createuser xwiki -S -D -R -P -Upostgres
createdb xwiki -Eunicode -Oxwiki -Upostgres

Je vous conseille aussi de faire un petit test de connexion pour vérifier que tout est bien configuré côté authentification :

psql -Uxwiki -h 127.0.0.1 -W

Pour information si jamais vous aviez besoin de la détruire a posteriori, la commande est :

dropdb -Upostgres xwiki

Configuration de XWiki 7.2

Maintenant qu’on dispose d’une base de données et d’un serveur d’application java, on peut commencer à configurer l’application XWiki en elle même. Configurer hibernate pour que xwiki stocke sa base sur pgsql

vi /var/lib/tomcat/webapps/xwiki-enterprise-web-7.2/WEB-INF/hibernate.cfg.xml

Supprimez les lignes liées à la base hsqldb (interne) et décommenter les lignes « PostgreSQL configuration » (en affectant les bonnes valeurs).

<property name="connection.url">jdbc:postgresql://localhost:5432/xwiki</property>
<property name="connection.username">xwiki</property>
<property name="connection.password">VOTREMOTDEPASSE</property>
<property name="connection.driver_class">org.postgresql.Driver</property>
<property name="dialect">org.hibernate.dialect.PostgreSQLDialect</property>
<property name="jdbc.use_streams_for_binary">false</property>
<property name="xwiki.virtual_mode">schema</property>
<mapping resource="xwiki.postgresql.hbm.xml"/>
<mapping resource="feeds.hbm.xml"/>
<mapping resource="activitystream.hbm.xml"/>
<mapping resource="instance.hbm.xml"/>
<mapping resource="mailsender.hbm.xml"/>

Remplacez la clé de chiffrement du cookie dans le xwiki.cfg (pour éviter qu’un attaquant puisse déchiffrer les cookies) et activez temporairement le superadmin pour se connecter au wiki pour la première connexion

vi /var/lib/tomcat/webapps/xwiki-enterprise-web-7.2/WEB-INF/xwiki.cfg
xwiki.authentication.validationKey=1234totototototototototototototo
xwiki.authentication.encryptionKey=1234titititititititititititititi
[...]
xwiki.superadminpassword=system

Redémarrez tomcat

systemctl restart tomcat

Ouvrir un navigateur sur l’URL de votre Wiki http://wiki.example.org:8080/xwiki-enterprise-web-7.2/bin/view/Main/.

Le wizard de « premier déploiement » doit apparaître. Vous le verrez à nouveau en cas de mise à jour.

Déployer le XAR « Main » qui contient l’ensemble des pages par défaut

Attention : Ce qu’il faut savoir c’est que par défaut, les XWiki sont installés sans aucunes pages. Les pages par défaut doivent être chargées manuellement via un import la première fois. C’est à ça que sert le fichier xwiki-enterprise-ui-mainwiki-all-7.2.xar que vous avez téléchargé au début de la procédure.

Tout est expliqué dans la documentation officielle.

Ici on peut voir que la « User Interface » n’est pas disponible. J’ai l’impression que c’est le cas si votre VM n’a pas accès à Internet. Dans ce cas là, vous devez récupérer le xar contenant l’ensemble des pages par défaut pour les réimporter en tant que superadmin. Dans le cas où le bouton « Install » sous « User Interface », ce qui suit n’est pas nécessaire.

Cliquez sur [Later].

Normalement une page pratiquement vide doit apparaître. Il s’agit du squelette du XWiki 7.2.

Se connecter sur le wiki en tant que superadmin / system et ouvrir la page d’administration (sur le côté droit)

Cliquez sur « Import » et uploadez le fichier xwiki-enterprise-ui-mainwiki-all-7.2.xar préalablement téléchargé. Après upload, le package apparait dans « Available Packages »

En cliquant sur le fichier xar qui vient d’être uploadé, on peut sélectionner les pages qu’on ne souhaite pas utiliser (typiquement j’ai désactivé Blog et Sandbox qui ne me servent pas).

Cocher « Import as backup package », puis cliquer sur « Import ».

Maintenant que les pages par défaut sont importées, on a un compte administrateur local pour se connecter (Admin / admin).

Voilà un wiki fonctionnel utilisable en entreprise.

Bonus, pousser un peu la configuration du XWiki

Ok ça fonctionne. Mais bon, la première chose que vous voudrez peut être faire c’est passer le XWiki en Français.

Pour se faire, allez dans Administration, Localization, positionner les deux paramètres « en » à « fr » et enregistrer. La langue devrait changer automatiquement (sans redémarrage).

Et enfin voici les différents paramètres pour désactiver le superadmin, ajouter l’authentification LDAP (exemple Active Directory, mais je l’ai fais aussi marcher en Novell et en OpenLDAP) et activer les statistiques (désactivées par défaut pour améliorer les performances).

vi /var/lib/tomcat/webapps/xwiki-enterprise-web-7.2/WEB-INF/xwiki.cfg
# xwiki.superadminpassword=system
[...]
xwiki.authentication.ldap=1
xwiki.authentication.ldap.server=dom
xwiki.authentication.ldap.port=389
xwiki.authentication.ldap.bind_DN=CN=ldapreadonly,OU=xxx,DC=xxx,DC=xxx
xwiki.authentication.ldap.bind_pass=xxxxxxxxx
xwiki.authentication.ldap.base_DN=OU=xxx,DC=xxx,DC=xxx
xwiki.authentication.ldap.UID_attr=sAMAccountName
xwiki.authentication.ldap.fields_mapping=name=sAMAccountName,last_name=sn,first_name=givenName,fullname=displayName,email=mail,ldap_dn=dn
[...]
xwiki.stats=1
xwiki.stats.default=1

Redémarrez Tomcat pour prise en compte des nouveaux paramètres.

systemctl restart tomcat