Tomcat on Zwindler's Reflection

Une issue ouverte sur un projet, 7 ans après ?

Fri, 24 Nov 2023 14:00:00 +0200

Introduction

Il y a 7 ans, en août 2016 (!!), je créais ma première “vraie” image docker.

Il s’agissait d’une image custom pour un outil que j’utilisais énormément XWiki, un outil de Knowledge management open source (et français) que j’apprécie particulièrement et qui remplace avantageusement un Confluence (si vous voulez mon avis).

A l’époque, mon image fournissait un XWiki prêt à l’emploi avec Tomcat 8 et le driver JDBC pour postgresql.

github.com/zwindler/docker-xwiki

J’avais fait ce projet car les images officielles du projet étaient encore balbutiantes (ça date !) et ne proposaient pas cette alternative.

J’avais d’ailleurs écrit un article pour l’occasion (Installer XWiki 8.2.1 avec Docker (compose) en 2 lignes de commandes) et fourni au fil des mois suivants des manifests pour Kubernetes.

Et aujourd’hui ?

Ca fait bien longtemps que ce projet n’a plus aucun intérêt, même si mes images ont été téléchargées environ 30000 fois (quand même !), avec un dernier téléchargement l’an dernier, malgré une version vielle de plus de 6 ans (mais pourquoiiiiii ?).

hub.docker.com - zwindler/xwiki-tomcat8

Les images officielles proposent désormais (depuis bien longtemps) toutes les options les plus courantes pour toutes les versions supportées

Pourtant ?!?

Pourtant, début novembre, j’ai reçu une issue, d’un utilisateur qui m’informait qu’il ne pouvait pas rebuild mon image car l’URL permettant de télécharger les artefacts WAR ne répondait plus (effectivement, elle a changé).

Même si au début j’étais un peu interloqué, je me suis dis que ça pouvait être fun de remettre les mains dedans et de tenter de mettre à jour mon image sur toute la stack, pour voir si ça fonctionne encore.

Voyons voir ce qui a changé depuis 2016…

Évidemment, beaucoup de choses !

D’abord, les versions de XWiki (de 10 à 14), qui ont forcément évoluées, ainsi que cette fameuse URL de téléchargement des artefacts qui avait changé.

La version de postgres est passée de 9.5 à 16, les versions du driver JDBC ont évoluées de plusieurs mineures.

Plus impactant, tomcat est passé de la version 8 à la version 10, avec un gros breaking change entre la 9 et la 10, notamment à cause de JEE, renommé en JakartaEE !

Ca parlera aux Javaistes ;-)

Plus anecdotique, le MAINTAINER a disparu depuis bien longtemps des Dockerfile (remplacé par un LABEL opencontainers), le MaxPermSize n’existe plus en Java et le format des fichiers docker-compose est passé en version 3.

Les modifs

Pour le fun, j’ai donc réparé mon image pour qu’elle marche (et pas plus), puis j’ai passé le repo en readonly, pour la postérité, en prenant soin d’informer l’auteur de l’issue qu’il valait mieux regarder du côté des images officielles ;-).

Le code de fix est disponible ici, pour les curieux/curieuses.

Mais… ça fonctionne :-p

Installation xwiki 10.6.1 via un playbook Ansible

Wed, 05 Sep 2018 11:45:00 +0000

Ansible + XWiki

Je sais ce que vous vous dites :

Ça fait longtemps que zwindler n’a pas écrit un article sur Ansible ou XWiki !

Non ? Vous ne vous dites pas ça ? Bon tant pis c’est pas grave. Aujourd’hui, je rédige ENFIN l’article pour parler d’un playbook que j’ai déjà rédigé il y a presque un an déjà (et mis à jour et déployé de nombreuses fois). C’est dire si j’ai du retard dans les articles du blog…

Petit rappel des épisodes précédents

J’ai déjà rédigé de manière extensive sur XWiki qui est un belle solution open source de gestion de la connaissance. Parmi les articles les plus susceptibles d’intéresser, il y a déjà :

Il y en a plein d’autre (voir ici).

Et Ansible ?

Et bien oui. Je vous rabâche aussi les oreilles avec Ansible, l’Infrastructure as Code, et l’Idempotence. (Là encore, il y en a plein)

Alors pourquoi pas un playbook Ansible pour automatiser l’installation de XWiki, si vous n’avez pas de cluster Kubernetes sous la main et que vous êtes un Gaulois réfractaire à Docker ?

Ya quoi dans ton playbook ?

Trêve de suspense, les sources sont disponibles sur Github à cette adresse.

Ce playbook a été testé pour des RHEL/CentOS 7, en particulier de la version 7.2 jusqu’à 7.4. Une installation de RHEL/CentOS en mode minimale, même sans environnement graphique, devrait être suffisante. Je l’ai faite tourner en production sur des environnements Desktop dans des VMs, mais aussi en Minimal sur un container LXC dans Proxmox VE sans aucun souci.

L’installation n’utilise pas les serveurs web et de bases de données par « défaut » (MySQL), mais Tomcat 8 et PostgreSQL. Pour la version de Tomcat, c’est une version très particulière qu’il faut utiliser car des bugs ont étés introduits dans une version, puis RE-introduits quelques mois plus tard. Vous pouvez modifier la version par défaut qui est une variables de mon playbook (8.5.32) si elle ne vous convient pas. Les instructions d’installation se basent sur la documentation officielle.

- tomcat_version: 8.5.32

Vous pouvez également modifier la version de XWiki directement dans le playbook (c’est une variable là aussi) :

- xwiki_version: "10.6.1"

A noter, les vielles versions de XWiki n’étaient pas hébergées sur le même dépôt, qui a changé récemment, d’où les deux URLs dans le playbook.

Prérequis

On va utiliser git pour récupérer le playbook et ansible (version de l’OS, rien d’exotique).

yum install ansible git
git clone https://github.com/zwindler/ansible-deploy-xwiki-tomcat-postgresql
cd ansible-deploy-xwiki-tomcat-postgresql

Quand est ce qu’on installe XWiki ?

Maintenant !

Sur un poste qui dispose de git et Ansible :

ansible-playbook -l localhost ansible-deploy-xwiki-tomcat-postgresql.yml

Le playbook devrait vous prompter pour un mot de passe pour l’utilisateur de base de données PostgreSQL, n’hésitez pas à mettre quelque chose de complexe. Vous ne devriez pas en avoir besoin.

Si vous avez une erreur qui vous dit que localhost est ignoré, vous pouvez l’ajouter à votre fichier d’inventaire global : /etc/ansible/hosts

sudo vim /etc/ansible/hosts
[local]
localhost ansible_connection=local

Et Paf ! Vous avez un XWiki installé, disponible à l’adresse http://@IP:8080/. Il n’y a plus qu’à le configurer :)

Installer XWiki 8.2.1 avec Docker (compose) en 2 lignes de commandes

Thu, 15 Sep 2016 11:00:28 +0000

Automatiser l’installation du XWiki avec Docker compose

Pour ceux qui ne le savent, XWiki est une plateforme collaborative de gestion de la connaissance (généralement appelé wiki, KMDB en ITIL). L’exemple le plus connu de wiki est bien entendu Wikipedia qui tourne par contre lui sous Mediawiki (un autre wiki, moins convivial mais très répandu). J’ai déjà écris pas mal au sujet du XWiki donc si vous voulez un petit tour d’horizon de ce qu’on peut faire avec, vous pouvez cliquer ici.

Je commence à en avoir installé un certain nombre :

que ce soit pour tester les nouvelles version
en recette ou en production pour de nouvelles équipes
faire des tests sur Docker

Si l’installation d’un XWiki est simplissime si vous utilisez les outils préconfigurés par défaut dans l’installeur JAR, l’installation d’une instance XWiki avec Tomcat et PostgreSQL est un peu plus complexe. Du coup, j’ai eu besoin à plusieurs reprise d’ouvrir mon propre tutoriel qui guide pas à pas l’installation de la version 7 de XWiki sur un Redhat Entreprise Linux 7 (ou CentOS).

Vous avez dit Docker ?

Et c’est notamment grâce au besoin que j’ai eu de faire des tests sur Docker que j’en suis venu à réaliser une image Docker XWiki.

XWiki était le parfait exemple pour s’initier à :

la création d’un service multi-conteneurs séparés par Tiers (Tomcat, PostgreSQL)
la rédaction d’un DockerFile qui automatise entièrement l’installation et la configuration de l’application java XWiki à partir de l’image standard Tomcat 8
l’ajout d’une orchestration de base avec Docker Compose
la mise en ligne d’une image publique avec Docker Hub

Un des avantages de Docker, c’est que grâce à l’aspect « portable » des conteneurs :

Avec ce conteneur, je peux garantir que les fichiers de configuration que j’embarque avec l’image seront compatibles.
Sans conteneur, avec un serveur Tomcat déjà existant et en fonction des fichiers de configurations embarqués selon telle ou telle distribution, les instructions que je donne dans mon article « pas à pas » pourraient ne pas toujours fonctionner.

Pour les plus pressés

Quelque soit la méthode que vous choisirez, le XWiki sera opérationnel et accessible sur le port 8080 à l’issue de ces commandes. Il faudra juste passer le « First Installation Wizard » et commencer à configurer le XWiki.

Avec Docker Compose

Docker compose se charge pour vous, à partir du fichier docker-compose.yml, de :

télécharger/builder l’image des conteneurs Postgresql et XWiki
configurer ces conteneurs
démarrer les conteneurs.

C’est donc forcément plus simple de le faire marcher en 2 lignes de commandes ;-).

[Edit]
A priori il n’est plus nécessaire de faire un « chmod +x xwiki-tomcat/xwiki-tomcat-entrypoint.sh » sinon ça ne fonctionne pas, j’ai corrigé les permissions sur le github
[/Edit]

git clone https://github.com/zwindler/docker-xwiki.git && cd docker-xwiki
docker-compose -f compose/docker-compose.yml up -d

Avec Docker depuis les sources

Avec Docker uniquement, il faudra forcément tout faire à la main. Donc il faudra créer le network, démarrer successivement l’image PostgreSQL puis l’image Tomcat modifiée par mes soins.

docker network create -d bridge xwiki-nw
docker run --net=xwiki-nw -itd --name xwiki-postgres -e POSTGRES_DB=xwiki -e POSTGRES_USER=xwiki -e POSTGRES_PASSWORD=xwiki postgres

git clone https://github.com/zwindler/docker-xwiki.git && cd docker-xwiki
chmod +x xwiki-tomcat/xwiki-tomcat-entrypoint.sh
docker build -t zwindler/xwiki-tomcat8:latest .
docker run --net=xwiki-nw -itd --name xwiki-tomcat -p 8080:8080 -e POSTGRES_INSTANCE=xwiki-postgres zwindler/xwiki-tomcat8

Avec Docker et Docker Hub

Un cran plus simple que la version précédente car je viens d’uploader l’image zwindler/xwiki-tomcat sur Docker Hub. Elle est donc automatiquement téléchargée depuis Docker hub lors de la commande docker run. Pas besoin de « chmod » ni de builder l’image.

docker network create -d bridge xwiki-nw
docker run --net=xwiki-nw -itd --name xwiki-postgres -e POSTGRES_DB=xwiki -e POSTGRES_USER=xwiki -e POSTGRES_PASSWORD=xwiki postgres
docker run --net=xwiki-nw -itd --name xwiki-tomcat -p 8080:8080 -e POSTGRES_INSTANCE=xwiki-postgres zwindler/xwiki-tomcat8

L’image en question

L’ensemble des sources sont disponibles sur Github dans mon repository docker-xwiki.

Voici le contenu du DockerFile :

FROM tomcat:8-jre8
MAINTAINER Denis GERMAIN <denis@example.com>
ENV POSTGRES_INSTANCE=xwiki-pgsql
ENV POSTGRES_PORT=5432
ENV POSTGRES_DB=xwiki
ENV POSTGRES_USER=xwiki
ENV POSTGRES_PASSWORD=xwiki
RUN rm -rf webapps/* && \
curl -L \
'http://download.forge.ow2.org/xwiki/xwiki-enterprise-web-8.2.1.war' \
-o xwiki.war && \
unzip -d webapps/xwiki xwiki.war && \
rm -f xwiki.war
RUN curl -L \
'https://jdbc.postgresql.org/download/postgresql-9.4.1208.jar' \
-o 'webapps/xwiki/WEB-INF/lib/postgresql-9.4-1208.jdbc42.jar'
COPY hibernate.cfg.xml webapps/xwiki/WEB-INF/
COPY xwiki.cfg webapps/xwiki/WEB-INF/
COPY setenv.sh bin/setenv.sh
RUN sed -i "s/redirectPort=\"8443\" /redirectPort=\"8443\" URIEncoding=\"UTF-8\" /" conf/server.xml
COPY xwiki-tomcat-entrypoint.sh /
ENTRYPOINT ["/xwiki-tomcat-entrypoint.sh"]

Des variables d’environnement ENV sont à votre disposition pour adapter à votre contexte (on en parlera un peu plus loin). La première étape consiste à télécharger la dernière version en date du XWiki, puis le pilote JDBC PostgreSQL correspondant.

Les fichiers de Tomcat sont adaptés pour un fonctionnement avec XWiki (Xmx java, autorisation des « / » dans les URLs, …) et les fichiers de configuration de XWiki sont paramétrés pour accepter l’instance PostgreSQL.

Personnalisation

Pour permettre un peu plus de souplesse dans l’utilisation de la base de données, j’ai volontairement ajouté des variables d’environnement et un script « ENTRYPOINT ». Ce script sert à paramétrer à la première exécution les valeurs définies en début de DockerFile (ENV).

Ceci permet à la fois de mettre à disposition une image Docker clé en main si l’utilisateur ne souhaite rien modifier et tout laisser par défaut, ou à l’inverse, de fournir des variables qui lui sont propres et personnaliser automatiquement son instance.

Vous pourrez ainsi par exemple changer le mot de passe et/ou le nom de l’instance PostgreSQL (soit via modification du docker-compose.yml, soit directement en modifiant le DockerFile).

Problème ALLOW_ENCODED_SLASH=true

Malgré l’ajout de ALLOW_ENCODED_SLASH=true dans catalina.properties, j’avais des problèmes pour ouvrir les pages avec des / dans les noms de pages.

J’en ai profité pour essayer de déplacer l’application du paramètres et l’intégrer au niveau du setenv.sh avec la variable d’environnement CATALINA_OPTS. Ca n’a pas corrigé le problème (situé à un autre niveau) mais a permis de simplifier le Dockerfile, ce qui est toujours bon à prendre.

En réalité, la variable était bien prise en compte dans les deux cas. Je l’avais vérifié et cela marchait depuis le début. En réalité, j’ai un reverse proxy Apache (ProxyPass) qui lui aussi fout le boxon avec les « / » dans mes titres de pages de XWiki.

La réponse suivante sur StackOverflow explique très bien ce qu’il se passe. Pour autant dans mon cas, impossible d’accéder à ces pages, quelque soit le paramètre essayé, dans le cas où le XWiki est derrière mon proxy Apache. Je peux y accéder sans, je vais donc devoir les renommer pour contourner le problème. De toute façon, ça ne me plait pas que ces pages aient un « / » dans leur URL ;-).

[Tutoriel] Mise à jour XWiki depuis un war dans Tomcat

Sat, 23 Apr 2016 10:30:59 +0000

Cette procédure donner les étapes pour mettre à jour un XWiki depuis la nouvelle version du fichier war dans Tomcat. L’exemple que je donne permet de faire une mise à jour (mineure) entre la 7.2 et la 7.4.2 qui corrige plusieurs bugs de la version 7.2 et ajoute quelques fonctionnalités supplémentaires.

Mise à jour WAR

Coupez le serveur d’application

service tomcat stop

Récupérez le dossier xwiki dans webapps pour archive

cd /var/lib/tomcat/webapps/
mv xwiki /distrib/archive_xwiki_7.2

Déposez le fichier xwiki-enterprise-web-7.4.2.war dans /var/lib/tomcat/webapps puis relancer T0mcat pour démarrer l’extraction du war

service tomcat start

Vérifiez dans les logs que l’application se déploie bien

tail -f /var/log/messages
Dec 30 10:43:48 xwiki01 server: INFOS: Démarrage du service Catalina
Dec 30 10:43:48 xwiki01 server: déc. 30, 2015 10:43:48 AM org.apache.catalina.core.StandardEngine startInternal
Dec 30 10:43:48 xwiki01 server: INFOS: Starting Servlet Engine: Apache T0mcat/7.0.54
Dec 30 10:43:48 xwiki01 server: déc. 30, 2015 10:43:48 AM org.apache.catalina.startup.HostConfig deployWAR
Dec 30 10:43:48 xwiki01 server: INFOS: Déploiement de l'archive /var/lib/t0mcat/webapps/xwiki-enterprise-web-7.4.2.war de l'application web

Une fois que c’est fait, nettoyez les fichiers. Habituellement je renomme le dossier pour simplifier la gestion de l’URL d’accès à l’application mais on pourrait le faire avec une redirection nginx/apache/vultureSSO ou tout simplement un lien symbolique sur le dossier.

[root@xwiki01 webapps]# rm xwiki-enterprise-web-7.4.2.war
rm : supprimer fichier « xwiki-enterprise-web-7.4.2.war » ? y
[root@xwiki01 webapps]# ll
total 0
drwxr-xr-x. 7 t0mcat t0mcat 94 30 déc. 10:43 xwiki-enterprise-web-7.4.2
[root@xwiki01 webapps]# mv xwiki-enterprise-web-7.4.2 xwiki
[root@xwiki01 webapps]#

Arrêtez tomcat pour modifier les fichiers de configuration

service tomcat stop

Copiez du connecteur java postgresql (ou mysql) dans les libs de XWiki

cp /distrib/archive_xwiki/WEB-INF/lib/postgresql-9.2-1004.jdbc41.jar /var/lib/tomcat/webapps/xwiki/WEB-INF/lib/
#ou /distrib/archive_xwiki/WEB-INF/lib/mysql-connector-java-5.1.22-bin.jar

En théorie, il faut faire attention et comparer les nouveaux fichiers de configuration apportés par la nouvelles version dans le cas où il y aurait des modifications entre les deux versions.

[root@xwiki01 webapps]# cd /distrib/xwiki_archive_7.2/WEB-INF/
cp hibernate.cfg.xml xwiki.cfg xwiki.properties /var/lib/tomcat/webapps/xwiki/WEB-INF/
cp : voulez-vous écraser « /var/lib/t0mcat/webapps/xwiki/WEB-INF/hibernate.cfg.xml » ? y
cp : voulez-vous écraser « /var/lib/t0mcat/webapps/xwiki/WEB-INF/xwiki.cfg » ? y
cp : voulez-vous écraser « /var/lib/t0mcat/webapps/xwiki/WEB-INF/xwiki.properties » ? y

Pour mettre à jour le schéma de la base de données, ajoutez la ligne suivante dans le fichier xwiki.cfg. N’oubliez pas de le retirer une fois la mise à jour effectuée, car ce paramètre rallonge le temps de démarrage du Xwiki.

xwiki.store.migration=1

Maintenant que le WAR est mis à jour et les fichiers de configuration remis à niveau, on peut passer à la mise à jour dans l’application elle même.

[root@xwiki01 lib]# systemctl start tomcat

Mise à jour application XWiki

Se connecter sur le XWiki, le serveur s’initialise.

L’assistant de distribution, identique à celui qui s’ouvre lors du premier lancement après installation apparait.

L’assistant nous propose la version 7.4 qu’on souhaite installer.

Cliquer sur « Installer ». Le wiki se met à jour. Dans le cas où certaines pages importés entrent en conflit, l’assistant propose soit de mettre à jour, soit de laisser tel quel. Dans la plupart des cas, il vaut mieux tout accepter mais si vous savez ce que vous faites, vous pouvez refuser l’écrasement de la page.

Une fois le processus terminé, le wiki redevient accessible.

[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

Mise en place de Guacamole 0.9.5 sur CentOS 7

Sun, 31 May 2015 09:49:36 +0000

Pour information : je me suis basé sur le très bon article de Deviant Engineer, qui est concis, s’affranchit de la conf par fichier plat au profit du module MySQL, et surtout qui fonctionne, ce qui n’est pas le cas de tous les tutoriels que j’ai pu croiser sur la toile.

Aujourd’hui, au même titre que l’informatique s’est généralisée, Internet est de plus en plus présent, où qu’on se trouve. Mais ce n’est pas toujours un Internet comme à la maison.

Pour des raisons de sécurité et/ou de bande passante, certains ports/protocoles/site web sont souvent bloqués sur les points d’accès public ou d’entreprise. Il n’est pas rare que seul l’HTTP et l’HTTPS soient disponible, me privant ainsi de mes accès SSH/VPN/FTP/…
C’est un vrai casse tête pour moi : je déploie des services chez moi et j’en deviens dépendant au point d’être agacé de ne pas y avoir accès en toutes circonstances. Et plutôt que de relativiser cet absence d’accès absolu à mes services/données, je préfère chercher des moyens de contournement ;).

Si l’autohébergement d’applications web et l’utilisation d’un reverse proxy (Vulture/Apache) répond à une partie de cette problématique, des fois, j’ai parfois besoin d’avoir accès aux machines qui hébergent ces services. C’est pourquoi j’utilisais jusqu’à présent Ajaxterm, puis Gateone pour disposer d’un accès SSH à mes serveurs en cas de filtrage.

Cependant, j’ai aussi besoin de me connecter en mode graphique sur mes serveurs. En présentant au travers d’une interface HTML5 des clients pour les protocoles SSH, VNC et RDP, Guacamole répond à ce besoin.

Quelques ressources pour bien commencer :

La documentation officielle décrit comment l’installer à partir des sources. Cependant, sur certains systèmes, les applications ont été packagées et sont disponibles (0.8.4 si je ne m’abuse sur RHEL et CentOS). Je voulais avoir la version la plus récente, je me suis donc penché sur la solution « compilation ».

Et pour avoir une compatibilité maximale en terme de fonctionnalités, il faut disposer de Tomcat 7, présent nativement dans RHEL7/CentOS7, que j’ai donc installé (mon premier CentOS7, youhou !)

Prérequis

Forcément, la première chose à faire lorsqu’on installe une application web un peu exotique sur un CentOS, c’est d’installer les dépôts additionnels pour les dépendances (ici EPEL).

rpm -Uvh http://mirror.metrocast.net/fedora/epel/7/x86_64/e/epel-release-7-5.noarch.rpm # EPEL Repo
yum -y install wget
wget http://download.opensuse.org/repositories/home:/felfert/Fedora_19/home:felfert.repo && mv home\:felfert.repo /etc/yum.repos.d/ # Felfert Repo
yum -y install tomcat libvncserver freerdp libvorbis libguac libguac-client-vnc libguac-client-rdp libguac-client-ssh
yum -y install cairo-devel pango-devel libvorbis-devel openssl-devel gcc pulseaudio-libs-devel libvncserver-devel \
freerdp-devel uuid-devel libssh2-devel libtelnet libtelnet-devel tomcat-webapps tomcat-admin-webapps java-1.7.0-openjdk.x86_64

Installation du composant « serveur »

Le logiciel est découpé en deux parties. Une partie « serveur » qui correspond au portail web, et une partie dite « cliente », qui se charge de la connexion aux différents serveurs SSH/~~telnet~~/VNC/RDP que vous aurez configurés. J’ai rayé telnet car je refuse d’utiliser ce protocole (à l’exception de certaines contraintes de travail très particulières).

cd /distrib
wget http://sourceforge.net/projects/guacamole/files/current/source/guacamole-server-0.9.5.tar.gz
tar -xzf guacamole-server-0.9.5.tar.gz && cd guac*0.9.5
./configure --with-init-dir=/etc/init.d
make
make install
ldconfig

Installation du du composant « client »

La partie client peut directement être récupérée tel quel sur le site du projet.

mkdir -p /var/lib/guacamole && cd /var/lib/guacamole/
wget http://sourceforge.net/projects/guacamole/files/current/binary/guacamole-0.9.5.war -O guac.war
ln -s /var/lib/guacamole/guac.war /var/lib/tomcat/webapps/
rm -rf /usr/lib64/freerdp/guacdr.so
ln -s /usr/local/lib/freerdp/guacdr.so /usr/lib64/freerdp/

MariaDB (MySQL)

Ne soyez pas surpris de découvrir MariaDB. MariaDB, c’est MySQL. Ou plutôt ce que MySQL aurait du devenir. Il s’agit d’un fork de MySQL initié par son créateur qui a réalisé qu’Oracle (qui a racheté Sun Microsystems en 2009) risquait d’envoyer le produit dans le mur (en concurrence avec Oracle Database).
MariaDB a donc progressivement remplacé MySQL dans les communautés Open Source et les entreprises (citons Google en 2013), et RedHat a suivi le mouvement avec la version 7 de RHEL.
Pas de mauvaise surprise si vous êtes habitués à MySQL : tout est identique en terme d’administration. Vos scripts fonctionneront toujours, les binaires n’ont pas changés.

Installation de la base de données

yum -y install mariadb mariadb-server
cd /distrib
wget http://sourceforge.net/projects/guacamole/files/current/extensions/guacamole-auth-mysql-0.9.5.tar.gz
tar -zxf guacamole-auth-mysql-0.9.5.tar.gz
wget http://dev.mysql.com/get/Downloads/Connector/j/mysql-connector-java-5.1.32.tar.gz
tar -zxf mysql-connector-java-5.1.32.tar.gz
mv mysql-connector-java-5.1.32/mysql-connector-java-5.1.32-bin.jar guacamole-auth-mysql-0.9.5/lib/
mkdir /var/lib/guacamole/classpath/
cp /distrib/guacamole-auth-mysql-0.9.5/lib/* /var/lib/guacamole/classpath/
systemctl restart mariadb.service

Configuration de la base de données

mysqladmin -u root password MySQLRootPass
mysql -u root -p # Enter above password
create database guacdb;
create user 'guacuser'@'localhost' identified by 'guacDBpass';
grant select,insert,update,delete on guacdb.* to 'guacuser'@'localhost';
flush privileges;
quit

Création du schéma pour Guacd

cd /distrib/sqlauth/guacamole-auth-mysql-0.9.5/schema/
cat ./*.sql | mysql -u root -p guacdb # Enter SQL root password set above

Configuration, création du fichier « .properties »

mkdir -p /etc/guacamole/ && vi /etc/guacamole/guacamole.properties
# Hostname and port of gucamole proxy
guacd-hostname: localhost
guacd-port: 4822
# Location to read extra .jar's from
lib-directory: /var/lib/guacamole/classpath/
# Authentication provider class
auth-provider: net.sourceforge.guacamole.net.auth.mysql.MySQLAuthenticationProvider
# MySQL properties
mysql-hostname: localhost
mysql-port: 3306
mysql-database: guacdb
mysql-username: guacuser
mysql-password: guacDBpass
# Additional settings
mysql-disallow-duplicate-connections: false

Post-installation

Ne pas oublier de nettoyer les répertoires contenant les sources (dans /distrib chez moi), ajouter un lien symbolique vers le fichier de configuration et ajouter le démarrage automatique des services

mkdir -p /usr/share/tomcat/.guacamole
ln -s /etc/guacamole/guacamole.properties /usr/share/tomcat/.guacamole/
systemctl enable tomcat.service && systemctl enable mariadb.service && chkconfig guacd on

Le serveur devrait être accessible à l’adresse http://@IP_serveur:8080/gucamole**/**. A partir de là, vous pouvez configurer vos serveurs SSH/RDP/VNC, créer des utilisateurs et vous connecter.

Deux derniers points :

les logs ne sont pas toujours très locaces. Chez moi, il se trouvent dans /var/log/messages et /var/log/tomcat/
il manque selon moi un menu pour gérer les connexions actives. Typiquement, dans le cas de VNC, le soft m’indique que j’ai 4 ou 5 sessions ouvertes. Elles n’ont pas l’air concurrentes (je n’en ai qu’une réellement active), mais me parait potentiellement même problématique