Tutoriel on Zwindler's Reflection

[Tutoriel] XWiki, ma premier appli Statefull sur Kubernetes

Tue, 24 Oct 2017 11:30:52 +0000

Pourquoi déployer XWiki sur Kubernetes ?

Vous le savez surement maintenant vu le nombre d’article que j’ai écrit sur le sujet, j’aime bien XWiki. C’est un super projet mené par des gens passionnés, réactifs et surtout, c’est cet outil qui a permis à mon entreprise d’adopter ENFIN le wiki comme outil de documentation, que ce soit pour documenter les procédures, mais aussi documenter entièrement les concepts de l’outil que nous développons.

D’un outil quasi-confidentiel utilisés par quelques admins peu motivés (sous Mediawiki), nous sommes donc progressivement passés à un outil utilisé par toutes les équipes, du dev. au support en passant par les ergo. et les CPs, utilisés par plusieurs entités internes et même accepté comme document contractuel par nos prestataires. J’ai d’ailleurs documenté la migration sur cet article.

Mais j’aime aussi XWiki car c’est selon moi l’exemple parfait d’une appli 2 ou 3 tiers relativement simple pour explorer l’écosystème Docker (construction des images, les problématiques réseau et stockage, …). Je joue régulièrement avec ma propre image sur le Dockerhub pour explorer un peu plus cet écosystème riche (c’est rien de le dire).

Quelle meilleure application donc pour réellement tester mon tout nouveau cluster Kubernetes (je ne compte pas nginx ou helloworld) ?

Kubernetes ?

Pour ceux qui ont besoin d’un rappel sur Kubernetes ou des premiers concepts et/ou comment l’installer, je vous invite à lire/relire mon article précédent sur le sujet.

A noter également (j’ai pas mal communiqué là-dessus sur les réseaux sociaux), la Linux Foundation, qui gère également la Cloud Native Computing Foundation (et qui elle-même gère Kubernetes), a mis à disposition gratuitement un cour en ligne de type MOOC sur edX. Vous pouvez même vous « certifier » à la fin si vous réussissez le QCM, moyennant 100$.

A l’issue de ces lectures, vous devriez donc avoir :

la connaissance des différents concepts de Kubernetes
un cluster Kubernetes opérationnel (une ou plusieurs machines, ou simplement un minikube en local)

Ce sont les prérequis pour la suite de cet article, même si je vais essayer de détailler tout ce qui va suivre.

Plan de bataille

Je ne vais pas vous le cacher, si on veut tout faire soit même, ce n’est pas « trivial ». Mais en décomposant toutes les étapes, vous allez voir que c’est logique.

Pour faire tourner mon image Docker zwindler/xwiki-tomcat8, j’ai besoin, sur mon cluster Kubernetes, des choses suivantes :

un Deployment qui exécute la partie PostgreSQL. Ce Deployment contiendra :
- un ReplicaSet avec une seule instance car on ne souhaite avoir qu’un seul Pod avec l’image postgresql officielle
- Un Service de type ClusterIP pour lui permettre de communiquer avec le XWiki mais pas avec le monde extérieur
- Un PersistantVolumeClaim et son PersistentVolume associé pour stocker les données de la base
- Des Secrets pour permet de configurer les mots de passes de postgres et de l’utilisateur XWiki
un Deployment qui exécute la partie XWiki. Ce Deployment contiendra :
- un ReplicaSet avec une seule instance car on ne fait tourner qu’un seul Pod avec l’image zwindler/xwiki-tomcat8, car on n’utilise qu’un tomcat à la fois pour exécuter XWiki
- Un Service de type NodePort (ou mieux si vous avez des LoadBalancers ou des Ingress à dispo.) qui permettra d’exposer le port interne au cluster Kubernetes vers le monde extérieur
- Un PersistantVolumeClaim avec le PersistentVolume pour stocker les pièces jointes car mon image Docker utilise l’option filesystem_store pour éviter de surcharger la base pour les PJ
- et aussi le Secret défini précédemment pour accéder à la BDD.

OK.

Voir ça posé dans une liste comme ça, ça peut faire peur.

Alors vous allez me dire : « c’est plus facile de lancer ton DockerCompose » (car j’ai montré qu’avec DockerCompose on peut démarrer une instance XWiki en 2 ou 3 lignes de commandes). Mais au final, tout ce que j’ai écris ici peut être concaténé dans un seul et même fichier YAML et le résultat est aussi simple dans l’absolu.

Créer les Secrets

Clairement, c’est un des gros points forts par rapport à la solution plus simple avec juste Docker / DockerCompose : la gestion des Secrets (et des configurations, dans une moindre mesure).

Ici, plutôt que d’avoir un mot de passe en clair dans mon fichier compose, le mot de passe est renseigné à part, soit via un fichier, soit via l’API. Et ces mots de passes ne pourront plus être consultés via la CLI, mais pourront être utilisés.

Pour créer un secret dans Kubernetes en CLI, il existe plusieurs méthodes. Soit on utilise la CLI directement depuis le prompt ou depuis un fichier plat (qui va se charger d’encoder le secret en base64 et de générer le YAML pour nous), soit on décide de créer le YAML nous-même. Je vous met les deux méthodes :

echo -n "xwikidb" > ./POSTGRES_USER.txt
echo -n "xwikipwd" > ./POSTGRES_PASSWORD.txt
kubectl create secret generic postgresql-xwiki-user-password --from-file=POSTGRES_USER.txt --from-file=POSTGRES_PASSWORD.txt
secret "postgresql-xwiki-user-password" created
#ou
cat > postgresql_xwiki_user_password.yaml << EOF
apiVersion: v1
kind: Secret
metadata:
name: postgresql-xwiki-user-password
type: Opaque
data:
username: $(cat POSTGRES_USER.txt| base64 -w 0)
password: $(cat POSTGRES_PASSWORD.txt| base64 -w 0)
EOF

Au final, pour un déploiement unitaire pour vous même, ça ne change pas grand-chose bien sûr. Vous avez renseigné en clair le mot de passe (ou en base64 mais c’est pareil) à un moment donné.

Cependant, dans le cadre d’un gros projet avec des développeurs qui poussent du code régulièrement d’un côté et des admins qui gèrent de l’autre les utilisateurs et les mots de passes, on peut permettre aux développeurs consommer les mots de passe sans jamais avoir à les connaitre (et laisser trainer sur Gitlab, ou pire, Github !).

kubectl describe secret postgresql-xwiki-user-password
Name: postgresql-xwiki-user-password
Namespace: default
Labels: <none>
Annotations:
Type: Opaque
Data
====
password: 8 bytes
username: 7 bytes

Créer les Persistent Volumes

Dans mon infrastructure, j’ai déjà un cluster GlusterFS. GlusterFS étant un SDS, il est particulièrement indiqué comme stockage persistant dans le cadre d’un cluster Kubernetes (comme Ceph, Cinder, S3 ou autre). Ces types de méthodes de stockage peuvent facilement se piloter par API et sont hautement disponibles.

Création de l’endpoint GlusterFS

cat > gluster-endpoints.yaml <<EOF
apiVersion: v1
kind: Endpoints
metadata:
name: gluster-cluster
subsets:
- addresses:
- ip: 10.0.0.1
ports:
- port: 1
protocol: TCP
- addresses:
- ip: 10.0.0.2
ports:
- port: 1
protocol: TCP
EOF
kubectl apply -f gluster-endpoints.yaml
endpoints "gluster-cluster" created
kubectl get endpoints gluster-cluster
NAME ENDPOINTS AGE
gluster-cluster 10.0.0.1:1,10.0.0.2:1 39s
cat > gluster-service.yaml << EOF
apiVersion: v1
kind: Service
metadata:
name: gluster-cluster
spec:
ports:
- port: 1
EOF
kubectl apply -f gluster-service.yaml
service "gluster-cluster" created
kubectl get service gluster-cluster
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
gluster-cluster 10.96.114.181 <none> 1/TCP 1m

La partie GlusterFS a été configurée côté Kubernetes. On peut maintenant s’atteler à la création des PV et PVC associés. D’abord la base de données :

cat > gluster-pv-xwiki-pg.yaml << EOF
apiVersion: v1
kind: PersistentVolume
metadata:
name: gluster-pv-xwiki-pg
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteMany
glusterfs:
endpoints: gluster-cluster
path: /xwiki-pg-storage
readOnly: false
persistentVolumeReclaimPolicy: Retain
EOF
kubectl create -f gluster-pv-xwiki-pg.yaml
persistentvolume "gluster-pv-xwiki-pg" created
cat > gluster-pvc-xwiki-pg.yaml << EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: gluster-pvc-xwiki-pg
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 5Gi
EOF
kubectl create -f gluster-pvc-xwiki-pg.yaml
persistentvolumeclaim "gluster-pvc-xwiki-pg" created

Et maintenant l’application XWiki

cat > gluster-pv-xwiki-app.yaml << EOF
apiVersion: v1
kind: PersistentVolume
metadata:
name: gluster-pv-xwiki-app
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteMany
glusterfs:
endpoints: gluster-cluster
path: /xwiki-app-storage
readOnly: false
persistentVolumeReclaimPolicy: Retain
EOF
kubectl create -f gluster-pv-xwiki-app.yaml
persistentvolume "gluster-pv-xwiki-app" created
cat > gluster-pvc-xwiki-app.yaml << EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: gluster-pvc-xwiki-app
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 5Gi
EOF
kubectl create -f gluster-pvc-xwiki-app.yaml
persistentvolumeclaim "gluster-pvc-xwiki-app" created

Dans le cadre d’un test, vous pouvez vous contenter de faire simplement appel à un partage NFS ou même à du stockage local (si vous n’avez qu’un worker) mais sachez que vous n’aurez pas le même niveau de résilience ni les même facilités d’administration.

Si vous voulez un exemple de PersistentVolume utilisant NFS, je vous conseille cet article qui traite d’un sujet peu plus complexe mais qui donne les étapes de base pour mettre en place le PV et PVC : Créer un cluster PostgreSQL avec un seul et même Deployment en utilisant les StatefulSets.

Créer le Deployment postgreSQL

Voilà, on a tous les prérequis ! Il ne reste plus qu’à créer dans un premier temps notre base de données, puis notre XWiki. Comme indiqué au début, le Deployment contiendra tous les éléments qu’on a créé plus tôt, dont les Secrets et le Persistent Volume. Il manquera aussi un Service, que nous verrons plus tard.

cat > xwiki-pg.yaml << EOF
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: xwiki-pg
labels:
app: xwiki-pg
application: xwiki
spec:
replicas: 1
selector:
matchLabels:
app: xwiki-pg
application: xwiki
template:
metadata:
labels:
app: xwiki-pg
application: xwiki
name: xwiki-pg
spec:
containers:
- image: postgres:9.6
name: xwiki-pg
env:
- name: POSTGRES_DB
value: xwiki
- name: PGDATA
value: /var/lib/postgresql/data/pgdata
- name: POSTGRES_USER
valueFrom:
secretKeyRef:
name: postgresql-xwiki-user-password
key: username
- name: POSTGRES_PASSWORD
valueFrom:
secretKeyRef:
name: postgresql-xwiki-user-password
key: password
ports:
- containerPort: 5432
name: xwiki-pg
volumeMounts:
- name: xwiki-pg-storage
mountPath: /var/lib/postgresql/data/pgdata
volumes:
- name: xwiki-pg-storage
persistentVolumeClaim:
claimName: gluster-pvc-xwiki-pg
EOF
kubectl create -f xwiki-pg.yaml

Normalement, un Pod devrait se créer et monter le disque Gluster, puis s’initialiser avec les variables d’environnement qu’on lui a donné.

A partir de là, on ne peut cependant pas accéder à la base de données car on a pas encore créé le Service associé au Deployment. Par défaut, on ne donne pas de type, c’est donc un ClusterIP. Pour « savoir » vers quoi le Service doit rediriger, on a ajouté un Selector, qui pointe sur le tag « app » avec la valeur « xwiki-pg » définie plus haut.

cat > xwiki-pg-svc.yaml << EOF
apiVersion: v1
kind: Service
metadata:
name: xwiki-pg-svc
labels:
app: xwiki-pg
spec:
ports:
- port: 5432
protocol: TCP
selector:
app: xwiki-pg
EOF
kubectl create -f xwiki-pg-svc.yaml
service "xwiki-pg-svc" created

Créer le Deployment XWiki

Youhou ! Plus qu’un ! Ici pas de grosses différences, le principe est le même. On doit créer un Deployment puis un Service.

cat xwiki-tomcat.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: xwiki-app
labels:
app: xwiki-app
application: xwiki
spec:
replicas: 1
selector:
matchLabels:
app: xwiki-app
application: xwiki
template:
metadata:
labels:
app: xwiki-app
application: xwiki
name: xwiki-app
spec:
containers:
- image: zwindler/xwiki-tomcat8
name: xwiki-app
env:
- name: POSTGRES_INSTANCE
value: xwiki-pg
- name: POSTGRES_DB
value: xwiki
- name: POSTGRES_USER
valueFrom:
secretKeyRef:
name: postgresql-xwiki-user-password
key: username
- name: POSTGRES_PASSWORD
valueFrom:
secretKeyRef:
name: postgresql-xwiki-user-password
key: password
ports:
- containerPort: 8080
name: tomcat-port
volumeMounts:
- name: xwiki-app-storage
mountPath: /usr/local/tomcat/work/xwiki
volumes:
- name: xwiki-app-storage
persistentVolumeClaim:
claimName: gluster-pvc-xwiki-app
kubectl apply -f xwiki-tomcat.yaml
deployment "xwiki-app" created
cat xwiki-tomcat-svc.yaml
apiVersion: v1
kind: Service
metadata:
name: xwiki-app-svc
labels:
apps: xwiki-app
spec:
type: NodePort
ports:
- port: 8080
targetPort: tomcat-port
protocol: TCP
selector:
app: xwiki-app
kubectl apply -f xwiki-tomcat-svc.yaml
service "xwiki-app-svc" created

Est-ce que ça marche ?

kubectl get svc
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
gluster-cluster 10.96.114.181 <none> 1/TCP 4h
kubernetes 10.96.0.1 <none> 443/TCP 10d
xwiki-app-svc 10.103.218.140 <nodes> 8080:31484/TCP 4m
xwiki-pg-svc 10.108.219.88 <none> 5432/TCP 16m

Tout d’un coup

Chose promise chose due ! Je vous ai dit en début d’article que vous pouviez tout déployer en quelques lignes de commandes. Dans l’absolu, vous pourriez tout déployer via un seul fichier. Je préfère découpler la partie stockage (qui va dépendre du stockage que vous allez utiliser) et la partie secret du reste pour les raisons que j’ai énoncé plus haut. Voilà ce que ça donne :

On récupère les sources sur github

git clone https://github.com/zwindler/docker-xwiki

A adapter en fonction de votre contexte, à minima les adresses IP si vous avez du gluster, et carrément à réécrire si vous utilisez autre chose (NFS ou CEPH par exemple) :

kubectl apply -f docker-xwiki/kubernetes/gluster-endpoints-service.yaml
endpoints "gluster-cluster" created
service "gluster-cluster" created

On injecte ensuite les secrets. A vous de les changer comme on a vu plus haut.

kubectl apply -f docker-xwiki/kubernetes/postgresql_xwiki_user_password.yaml
secret "postgresql-xwiki-user-password" created

Et on fini par… tout le reste ! Là normalement il n’y a rien à changer à part éventuellement des ports, les seules « variables » dans ce déploiement étant le stockage et les mots de passes (qu’on vient de gérer).

kubectl apply -f docker-xwiki/kubernetes/xwiki-tomcat-pg-allinone.yaml
persistentvolume "gluster-pv-xwiki-pg" created
persistentvolume "gluster-pv-xwiki-app" created
deployment "xwiki-pg" created
persistentvolumeclaim "gluster-pvc-xwiki-pg" created
service "xwiki-pg-svc" created
deployment "xwiki-app" created
persistentvolumeclaim "gluster-pvc-xwiki-app" created
service "xwiki-app-svc" created

Le mot de la fin

Voilà, avec ce tutoriel vous avez maintenant une vue détaillée, étape par étape, de ce qu’il faut mettre en place pour gérer « proprement » le déploiement d’une application java + postgreSQL via Kubernetes.

Clairement, c’est bien plus complexe qu’un simple Docker compose comme j’ai pu le présenté dans l’article sur ce sujet. Pour autant, il faut comparer ce qui est comparable, les deux installations n’ont rien à voir !

D’un côté, vous avez une application déployée sur un nœud docker simple (éventuellement avec Swarm maintenant que les deux sont compatibles).

De l’autre, vous avez une application qui est déployée sur un cluster de machines :

Si l’une tombe en panne, la haute disponibilité est gérée : pas seulement sur le runtime, mais aussi sur le stockage !
Vous pouvez segmenter votre cluster en namespaces, et donner des droits à certains namespace à certains utilisateurs avec un gestion fine des autorisations (RBAC)
Vous disposez d’un dashboard et d’une API pour automatiser tous les déploiements (via Jenkins par exemple). Si vous voulez faire une mise à jour ou besoin de modifier un paramètre, c’est une simple commande ou un fichier de conf à appliquer à nouveau.
Vous avez la possibilité de faire du scaling up/down, voire de l’autoscaling.
…

La liste est longue ! En bref, vous passez d’une bidouille à la production.

Sources additionnelles

docs.openshift.org/latest/install_config/storage_examples/gluster_example.html (lien mort, pas dispo sur Internet Archive)
coderjourney.com/using-kubernetes-persistent-volumes/
www.xenonstack.com/blog/how-to-deploy-postgresql-on-kubernetes

[Tutoriel] Installer VultureOS (Vulture 3) et configurer sa première application

Thu, 07 Jul 2016 10:30:27 +0000

Installer pas à pas VultureOS et faire une configuration minimale

Une fois n’est pas coutume, même si je suis habituellement assez peu « tutoriel pas à pas avec des screenshots dans tous les sens », je vous propose aujourd’hui de plonger dans l’installation du VultureOS de Vulture WebSSO 3 qui vient de sortir (1er juin) jusqu’à la redirection de votre première application.

Prérequis

Pour ceux qui ne le savent pas, je vous propose de relire mon article où je rappelle brièvement ce qu’est Vulture 3.

Voici les prérequis de VultureOS pour fonctionner dans de bonnes conditions :

VultureOS doit être installé sur une machine virtuelle ou un serveur physique ayant 2 Go de RAM et 30 Go d’espace disque
avoir une ou plusieurs adresses IP pour recevoir des connexions Web
pouvoir contacter les applications Web qu’il protège sur leurs ports habituels (80 et 443 en général)
disposer d’une résolution de noms fonctionnelle (soit par serveur DNS soit via /etc/hosts sur l’OS Vulture) et avoir accès à un serveur NTP
avoir un accès HTTPS vers dl.vultureproject.org pour s’enregistrer et télécharger les mises à jour

Démarrage de l’installation

Comme je l’ai déjà dis, Vulture s’appuie maintenant sur une distribution FreeBSD modifiée et est donc livré clé en main. Pour peu que vous ayez accès à Internet et respecté les prérequis énoncé juste au dessus, tout s’installe donc tout seul.

Next next next

Classiquement, le disque dur va être formaté par le bootstraping de FreeBSD

Lors du test de la keymap, je n’ai pas trouvé de clavier FR correspondant. Peut être un bug entre FreeBSD et KVM ?

J’ai volontairement sauté toute la partie configuration du hostname et des cartes réseaux car cela dépend fortement de vous mais rappelez vous surtout que l’aspect DNS doit être particulièrement soigné pour que VultureOS fonctionne correctement !

Attention, contrairement à la bêta où nous étions « prompté » pour un mot de passe, le mot de passe de vlt-adm pour l’accès SSH est ici prégénéré (peut être pour éviter les erreurs de saisies clavier?)

Une fois le bootstraping FreeBSD terminé et les prérequis installés, l’OS reboote et vous affiche le message suivant

Connectez vous en SSH avec le login vlt-adm (ou en console, peu importe) et exécuter la commande demandée ci dessus et gentiment recopiée à la main ci dessous pour vos copier coller ;-) :

sudo /home/vlt-gui/env/bin/python2.7 /var/bootstrap/bootstrap.py

yes !

L’installation de Vulture (en tant qu’application) commence réellement. On vous demande ensuite si vous voulez joindre un cluster existant ou en créer un puis de renseigner un email pour recevoir la clé d’activation de votre Vulture WebSSO.

Une fois la clé reçue, on l’applique (attention aux spams, gmail ne me l’a pas flaggé en bêta pas pour la V1 si).

Le processus de génération de certificat est maintenant inclus dans l’installation.

Une fois terminé, un login/mdp sera demandé pour la connexion à la GUI et les services de WebSSO seront démarrés.

Ouverture de l’interface graphique

A partir de là on peut donc se connecter en HTTP sur l’URL fournie.

Une fois la mire passée, on arrive sur un Dashboard avec quelques métriques sympathiques sur l’état de la machine.

Le menu est accessible sur la gauche en haut, au niveau des 3 tirets horizontaux

On y retrouve, bien que dans un ordre un peu modifié, les menus que l’on connaît des précédentes versions.

La gestion des interfaces réseaux se fait dans Network/Listeners. La gestion de l’HTTPS se fait dans Configuration Profiles/TLS.

Entre la bêta et la version 1, le menu a été renommé de de SSL profiles à TLS, mais on voit encore SSL Profile en titre dans cette capture.

La documentation de Vulture donne des indications complémentaires pour la configuration TLS dans des cas où l’on souhaite être compatible HTTP/2.

Des menus qui vous intéresserons sûrement assez rapidement :

Vulture Management/PKI si vous voulez importer de nouveaux certificats
Configuration Profiles/Logs pour gérer vos logs comme vous l’entendez

Configuration de votre première application

Ouvrez le menu Applications/Applications, puis cliquez sur ADD AN ENTRY.

Voici maintenant la liste des champs que nous avons maintenant pour habitude de remplir dans Vulture. Un nom « friendly name » ; « public FQDN » l’URL publique pour accéder à l’application ; « Private URI » l’URL interne que doit utiliser Vulture pour accéder au serveur web qu’il doit protéger.

Ajouter un listener (une interface réseau)

Il est également obligatoirement ajouter un format de log.

Une fois le tout validé, l’application apparaîtra dans la liste. Il faudra recharger la configuration en cliquant sur les flèches en rond (clignotantes) puis sur le triangle pour démarrer l’application.

Et voilà. Pour ceux qui ont des problèmes pour ajouter des applications dans Vulture, les principes restent les mêmes que dans les versions précédentes et que j’ai déjà pas mal traité dans ces articles

Happy SSOing ;)

[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

[Tutoriel] Reconstruire le fichier de définition « .vmdk » manquant lorsqu’on a que le « -flat.vmdk »

Sat, 01 Aug 2015 10:30:48 +0000

Introduction de principe sur les disques durs virtuels par VMware

Quite à enfoncer des portes ouvertes, les disques virtuels chez VMware ont l’extension .vdmk. Mais en vrai, il y a deux types de fichiers VMDK et chaque disque dur virtuel VMware dispose des deux fichiers pour fonctionner :

le fichier contenant les données brutes, avec comme nom mavm_X-flat.vmdk
un fichier de configuration en mode texte avec des informations sur l’emplacement des données, le contrôleur à utiliser, la taille, … et nommé mavm_X.vmdk

Généralement, les fichiers VMDK sont nommés comme leur VM et un indice (X) apparaît quand il y en a plusieurs. Cependant, ces fichiers peuvent être renommés pour placés dans d’autres dossiers et fausser la numérotation donc ne prenez pas les informations fournies par le nom du fichier pour argent comptant.

Récupérer les informations nécessaires

Au même titre que perdre le fichier -flat qui contient les données serait problématique pour le fonctionnement de votre VM, la perte du fichier de définition est assez fâcheux. Le disque n’est tout simplement pas utilisable car l’ESXi ne sait pas interpréter le fichier -flat seul.

Cependant, on peut le reconstruire. Ouf !

D’ailleurs, on peut reconstruire le fichier -flat.vmdk aussi, mais sans les données bien entendu. Du coup je trouve que c’est quand même nettement moins intéressant que le contraire. Je ferai peut être quand même un article là dessus.

La première chose à faire est de déterminer le type de contrôleur virtuel que la machine virtuelle utilise pour se connecter au disque.

C’est très important et il peut parfois y en avoir plusieurs sur une même VM. On trouve ces informations dans le fichier de définition de la VM (.vmx) ou directement depuis la console VMware.

En règle générale, ce paramètre est souvent laissé par défaut et dans mon cas, la VM utilisait un lsilogic en position 0 (scsi0). Le disque était lui branché sur l’emplacement 0 du contrôleur, aussi visible dans la console comme 0:0.

scsi0.present = "true"
scsi0.sharedBus = "virtual"
scsi0.virtualDev = "lsilogic"

L’étape d’après consiste à savoir quelle est la taille du disque virtuel. En se connectant en SSH sur l’ESXi qui a accès au datastore, vous pouvez retrouver simplement cette information via un ls -l qui vous donnera la taille totale que peut avoir le disque.

# ls -l mavm-flat.vmdk
-rw------- 1 root root 1036160860160 Dec 11 12:30 mavm-flat.vmdk

Maintenant qu’on dispose de toutes les informations nécessaires, on va recréer un disque virtuel vierge temporaire. On récupérera et adaptera son fichier .vmdk pour pouvoir réutiliser notre fichier -flat.vmdk.

# vmkfstools -c 1036160860160 -a lsilogic -d thin temp.vmdk

La commande devrait créer deux fichiers temp.vmdk et temp-flat.vmdk. Pour plus d’options concernant la commande, je vous invite à lire le kb suivant : kb.vmware.com (lien mort)

Thin provisioning ou pas ?

Vous avez peut être noté le -d thin dans la commande un peu plus haut. Tous mes disques sont en Thin Provisioning car ça permet de ne consommer que l’espace réellement nécessaire. VMware a prouvé que les performances étaient similaire à l’allocation normale du disque à sa création et dans la majorité des cas c’est donc 100% gagnant.

Cependant, dans le cas où votre disque n’est pas en Thin provisioning, il y a quand même intérêt -pour le disque temporaire- à le créer avec l’option -d thin. Comme nous n’allons réutiliser que le fichier de définition .vmdk, le fichier temp-flat.vmdk aurait mis du temps à se construire, et aurait consommé de l’espace disque pour rien. J’indiquerai comment corrigé le tir dans la partie suivante.

Paramétrage du fichier reconstruit

On peut supprimer le fichier temp-flat.vmdk (le fichier de données donc) qui n’est plus nécessaire, et renommer le fichier temp.vmdk avec le nom correspondant au fichier manquant.

# rm -i temp-flat.vmdk
# mv -i temp.vmdk mavm.vmdk

A l’aide d’un éditeur de texte (soit via vi si vous êtes directement sur l’ESXi soit vous le récupérez pour l’éditer sur votre poste), on va modifier les sections qui ne correspondent pas encore à notre disque -flat :

vérifiez que la taille annoncée (en nombre de blocs de 512 octets, donc multiplier par 2 le nombre obtenu plus haut) sous #Extent Description
modifiez le nom du fichier après VMFS pour qu’il corresponde au fichier -flat
adaptez si besoin le contrôleur (si vous n’avez pas rentré le bon lors du lancement de la commande plus haut)
supprimez la ligne ddb.thinProvisioned = « 1 » si le fichier -flat.vmdk n’était pas en thin provisioning initialement.

[...]
# Extent description
RW 2072321720320 VMFS "mavm-flat.vmdk"
[...]
ddb.adapterType = "lsilogic"
ddb.thinProvisioned = "1"

Vous devriez avoir un disque virtuel de nouveau fonctionnel.

Bonus track : vérifier l’intégrité du « disk chain »

Vous pouvez vérifier que le fichier .vmdk correspond au fichier -flat avec les commandes suivantes :

Pour ESXi 3.5/4.x:

# vmkfstools -q mavm.vmdk
mavm.vmdk is not an rdm

Pour ESXi 5.x et 6.x :

# vmkfstools -e mavm.vmdk
Disk chain is consistent

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

Partage de VMDK entre plusieurs VMs

Wed, 07 Jan 2015 16:05:17 +0000

Si vous déjà voulu faire un POC de cluster Linux sur des machines virtuelles VMware, vous vous êtes déjà demandé comment vous alliez faire pour partager entre deux serveurs un espace de stockage commun à ces deux machines.

Une façon de faire consiste à rajouter une couche d’abstraction du stockage au dessus de l’OS (via GlusterFS ou DRBD par exemple), mais dans le cas d’un POC pour valider un cluster connecté au SAN, ce n’est pas forcément la première solution qui vient à l’esprit. Personnellement, la plupart des clusters que je construis sont encore dans un schéma plus simple à base de LUNs iSCSI ou FC partagés sur un SAN en actif/actif ou actif/passif.

Cependant, pour simuler ce fonctionnement sur vos VMs, il va falloir bidouiller un peu.

En effet, pour éviter toute erreur malencontreuse (et même désastreuse), VMware interdit par défaut le démarrage de toute machine virtuelle qui aurait un disque en cours d’utilisation par une autre machine virtuelle. Aïe…

Voici un petit mode opératoire pour s’en sortir ;-)

Dans ce mode opératoire, les disques qu’on souhaite partager entre les deux serveurs sont des disques LVM en miroir, hébergés sur les baies de disques qui sont accessibles depuis les deux serveurs ESXi.

Cet exemple permet de valider la fiabilité de la méthode dans le cadre d’un cluster Linux virtuel de type RedHat Cluster Suite. Le principe reste tout de même valide pour une utilisation en dehors de RedHat Cluster Suite, certaines opérations ne seront juste pas nécessaires (qui peut le plus peut le moins).

Prérequis

Pour les besoins de la documentation, deux machines virtuelles test_partage_vmdk_1 et test_partage_vmdk_2 ont été créés. Elles disposent des caractéristiques techniques suivantes :

test_partage_vmdk_1
- hébergée sur ESXi1
- RedHat Entreprise Linux 5.8
- 2 vCPU, 1 Go de RAM
- 50 Go de disque interne sur un espace partagé
- IP 192.168.111.1/24 sur un réseau virtuel
test_partage_vmdk_2
- hébergée sur ESXi2
- RedHat Entreprise Linux 5.8
- 2 vCPU, 1 Go de RAM
- 50 Go de disque interne sur un espace partagé
- IP 192.168.111.2/24 sur un réseau virtuel

Création des disques virtuels

Les machines test_partage_vmdk_1 et test_partage_vmdk_2 doivent être éteintes avant de réaliser les modifications.

Ouvrir les paramètres de la machine virtuelle test_partage_vmdk_1, et ajouter un nouveau périphérique (Disque dur).

Le provisionnement du disque doit impérativement être « statique immédiatement mis à zéro ». De plus, il doit aussi être hébergé sur un datastore commun aux deux machines physiques ESXi.

Créer le disque et l’affecter à un Nœud périphérique virtuel qui n’est pas encore utilisé.

Ici, le disque interne est stocké sur l’adresse SCSI (0:0). Par défaut VMware propose de créer le disque à la suite en SCSI (**0:**1).

Il faut impérativement dérouler la liste pour affecter le disque à l’adresse SCSI (**1:**0) qui représente un nouveau contrôleur SCSI.

De plus, pour permettre l’usage des snapshots sur la partie disque dur interne, les disques doivent être créés en Mode Indépendant/Persistant. Dans le cas contraire, les snapshots seront impossibles sur la machine virtuelle.

Une fois le disque créé, un nouveau contrôleur SCSI est également créé. Avant de valider la création du disque et du contrôleur SCSI, il faut modifier le paramètre de Partage de bus de SCSI en mode « Physique ».

[4]Le second disque dur devra être créé de la même manière, et affecté au même contrôleur SCSI (on prendra l’adresse 1:1).

Remettre test_partage_vmdk_1 sous tension.

Ajout des disques virtuels sur la deuxième machine virtuelle

Ouvrir les paramètres de la machine virtuelle test_partage_vmdk_2, ajouter un nouveau périphérique (Disque dur) puis sélectionner « Utiliser un disque virtuel déjà configuré ».

Sélectionner le premier disque créé précédemment.

De la même manière que précédemment, on doit créer un disque dur virtuel sur un nouveau contrôleur SCSI et en mode Indépendant-Persistant.

Modifier le nouveau contrôleur SCSI comme précédemment :

Ajouter enfin le second disque de la même manière à l’adresse SCSI (1:1).

Valider et mettre la machine virtuelle sous tension. Si elle boot correctement c’est que le partage fonctionne.

Créer le miroir LVM partagé

Sur les deux serveurs, exécuter les commandes suivantes :

chkconfig acpid off #seulement pour RHCS
service acpid stop #seulement pour RHCS
vi /etc/lvm/lvm.conf
     filter = [ "a/.*/" ]
   #filter = [ "a|/dev/cciss/.*|", "a|/dev/mpath.*|", "r|.*|" ] #utiliser cette ligne en cas d’utilisation de multipath et de disques locaux présentés en tant que /dev/cciss. A adapter au contexte
[…]
volume_list = [ "vg01" , "@[TAG]" ]

Dans le cas de RedHat Cluster Suite, remplacer [TAG] par le nom de la machine tel qu’il est définit dans le fichier /etc/cluster/cluster.conf.

En dehors du cas d’un traitement automatisé par cluster, n’importe quel tag convient du moment qu’il est unique à la machine. Dans le cas présent, les tags choisis sont respectivement tag_vm1 et tag_vm2.

Quelques précisions :

filter permet de traiter les cas où on doit ignorer certains disques. C’est typiquement nécessaire lorsque l’on utilise LVM avec multipath ou powerpath, car l’OS voit plusieurs « disques » sda ,sdb, … pour un même disque mpath (1 sdX pour chaque chemin vers mpathY).
volume_list indique à LVM que seul le vg01 (interne) et les VG explicitement taggués avec le nom de la machine qui peuvent être utilisés. Cela permet de s’assurer qu’il n’y a qu’une seule machine qui peut activer le VG du moment qu’on n’ajoute jamais plus d’un tag au VG.

Même si les modifications du fichier lvm.conf sont prises en compte immédiatement, RedHat Cluster Suite impose une recompilation de l’initrd. Dans le cas d’un cluster RHCS, il faut donc lancer la commande suivante :

mkinitrd -f /boot/initrd-$(uname -r).img $(uname -r)

Sur un seul nœud (le premier) :

pvcreate /dev/sdb
pvcreate /dev/sdc
vgcreate -c n vg_mirror /dev/sdb /dev/sdc

Tagger le VG pour pouvoir travailler dessus sur ce nœud.

vgchange --addtag tag_vm1 -ay vg_mirror
lvcreate -n lv_mirror -m1 -l 5116 /dev/vg_mirror
Logical volume "lv_mirror" created

Le journal des écritures doit lui aussi être en miroir

lvconvert --mirrorlog mirrored /dev/vg_mirror/lv_mirror
Logical volume lv_mirror converted.

Il est enfin possible de formater le disque, et de le monter sur le test_partage_vmdk_1

mkfs.ext3 /dev/vg_mirror/lv_mirror
mount /dev/vg_mirror/lv_mirror /mnt

Tester la bascule

Scanner les VGs pour vérifier que le nouveau VG est bien disponible sur le test_partage_vmdk_2

vgscan
vgs

Même s’il le VG est visible, il n’est pas possible de le monter car il n’a pas le bon tag (tel que spécifié dans le lvm.conf). Cela permet de vérifier que l’on ne pourra pas écrire sur les disques sur les deux nœuds en même temps.

Not activating vg_mirror/lv_mirror since it does not pass activation filter.
0 logical volume(s) in volume group “vg_mirror” now active

On peut démonter le FS, désactiver le vg et enlever le tag sur le serveur test_partage_vmdk_1 et vérifier qu’on peut bien le monter et écrire dessus sur le test_partage_vmdk_2.

Ce comportement est automatique sous RedHat Cluster Suite, qui gère lui même les tags lors de la bascule d’un VG/LV.

Sur test_partage_vmdk_1

umount /mnt
vgchange --deltag tag_vm1 -an vg_mirror

Sur test_partage_vmdk_2

vgchange --addtag tag_vm1 -ay vg_mirror
mount /dev/vg_mirror/lv_mirror /mnt

Have fun