MySQL on Zwindler's Reflection

Se simplifier Kubernetes avec Helm et les Charts

Tue, 06 Feb 2018 12:45:16 +0000

Helm, Tiller, Charts : c’est quoi tout ça ?

Ceux qui suivent un peu le blog savent que je bidouille pas mal avec Kubernetes en ce moment. Dans mon travail précédent on commençait à peut être se dire que Swarm n’allait pas être suffisant (ahaha) et j’avais donc décidé de prendre les devants histoire de savoir de quoi je parle au moment où la décision serait prise de foncer ;-). Et rapidement je me suis rendu compte, qu’avec Kubernetes, on se retrouve vite à devoir écrire du YAML à tour de bras pour configurer nos ressources (« petit » exemple avec XWiki, une application Tomcat + SGBDr). C’est là que Helm (et Tiller) et les Charts entrent en jeu.

L’idée derrière Helm et les Charts ? Avoir un magasin en ligne d’applications multi-tiers déployables en une seule ligne de commande.

The package manager for Kubernetes

Il faut voir celà comme un magasin un peu sur la philosophie de Dockerhub (applications officielles ou fournies par la communauté), permettant de déployer sur notre cluster des applications potentiellement complexes et/ou multi-tiers de manière automatique (un peu comme un docker-compose mais pour Kubernetes).

Avant d’aller plus loin, un peu de terminologie :

Charts : Collection de fichiers YAML variabilisés décrivant des ressources qui, misent bout à bout, donnent une application déployable sur Kubernetes
Helm : Client permettant de récupérer des Charts et de les appliquer sur un cluster Kubernetes
Tiller : Partie serveur permettant à un client Helm donner des ordres au cluster Kubernetes visé

Installation de Helm

Ne faisons pas durer le suspens plus longtemps et attaquons nous à l’installation des composants nécessaires !

A noter, je pars du principe que vous disposez d’un cluster Kubernetes fonctionnel et que celui ci tourne sous Linux. Si ce n’est pas le cas je vous propose de lire mes tutoriels sur le déploiement de cluster Kubernetes, soit avec Ansible (Kubespray) soit avec l’outil Kubeadm.

A l’heure où j’écris ces lignes, l’outil Helm est disponible à sa version 2.8.0. Vous pouvez retrouver la documentation officielle sur le Github et sur le site de Helm.

En réalité, il s’agit simplement d’une copie du binaire.

curl -o helm.tar.gz https://kubernetes-helm.storage.googleapis.com/helm-v2.8.0-linux-amd64.tar.gz
tar xzf helm.tar.gz
mv linux-amd64/helm /usr/local/bin

Contexte

Dans le cas où vous ne seriez pas directement sur une des machines du cluster, il est nécessaire de disposer de kubectl et surtout d’avoir correctement configuré son « contexte ».

Dans le cas où le contexte n’est pas configuré vous aurez le message suivant :

kubectl config current-context
error: current-context is not set

Cependant, si vous vous mettez en SSH directement sur un serveur qui est master, cette étape est potentiellement inutile (le contexte par défaut est administrateur dans ce cas).

On vérifie qu’on arrive bien à requêter le cluster :

kubectl cluster-info
Kubernetes master is running at http://localhost:8080
KubeDNS is running at http://localhost:8080/api/v1/namespaces/kube-system/services/kube-dns/proxy

Tiller

Maintenant qu’on dispose d’un client Helm ayant accès au contexte de notre cluster, on peut installer Tiller. Utiliser la commande « helm init ». Attention : Tiller sera installé dans le contexte courant, ne vous trompez pas de cluster ;-).

helm init
Creating /root/.helm
Creating /root/.helm/repository
Creating /root/.helm/repository/cache
Creating /root/.helm/repository/local
Creating /root/.helm/plugins
Creating /root/.helm/starters
Creating /root/.helm/cache/archive
Creating /root/.helm/repository/repositories.yaml
Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com
Adding local repo with URL: http://127.0.0.1:8879/charts
$HELM_HOME has been configured at /root/.helm.
Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.
Happy Helming!

Et maintenant, on fait quoi ?

Maintenant qu’on a installé tous les composants dont nous avions besoin (et oui déjà), on va se contenter de dans un premier temps de suivre les exemples fournis. La documentation officielle nous propose de déployer une base MySQL.

Bonne idée, voyons ce que ça donne !

La première étape qu’on nous demande de faire est de mettre à jour la liste des Charts disponibles sur le dépôt officiel :

helm repo update #mettre à jour la liste des charts disponibles sur le store officiel
Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈

J’adore le petit caractère « barre de navigateur » ;-)

Plus sérieusement, l’étape d’après est simplement de faire un helm install, qui va se charger de récupérer tous les YAML nécessaires pour déployer MySQL. La liste des composants Kubernetes créés apparaitra ensuite à l’écran (et vous pouvez les retrouver sur votre cluster avec un kubectl).

helm install stable/mysql
NAME: silly-moose
LAST DEPLOYED: Tue Dec 5 10:12:58 2017
NAMESPACE: default
STATUS: DEPLOYED
RESOURCES:
==> v1/Secret
NAME TYPE DATA AGE
silly-moose-mysql Opaque 2 1m
==> v1/PersistentVolumeClaim
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
silly-moose-mysql Pending 1m
==> v1/Service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
silly-moose-mysql ClusterIP 10.233.54.164 3306/TCP 1m
==> v1beta1/Deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
silly-moose-mysql 1 1 1 0 1m
==> v1/Pod(related)
NAME READY STATUS RESTARTS AGE
silly-moose-mysql-3998799777-hk5fj 0/1 Pending 0 1m

Sans surprise on retrouve un Secret (le mot de passe de votre utilisateur), un PersistentVolumeClaim (pour stocker vos données), un Service de type ClusterIP pour accéder et un Deployment pour MySQL lui même.

A noter : par défaut, Kubernetes donne un petit nom aléatoire à nos composants pour les rendre uniques, car nous n’avons pas donné de nom en arguments.

On remarquera la délicate attention des gens qui ont écrit le Chart et qui affiche, une fois le déploiement terminé, les étapes suivantes pour vérifier que tout fonctionne et se connecter une première fois.

NOTES:
MySQL can be accessed via port 3306 on the following DNS name from within your cluster:
silly-moose-mysql.default.svc.cluster.local
To get your root password run:
kubectl get secret --namespace default silly-moose-mysql -o jsonpath="{.data.mysql-root-password}" | base64 --decode; echo
To connect to your database:
1. Run an Ubuntu pod that you can use as a client:
kubectl run -i --tty ubuntu --image=ubuntu:16.04 --restart=Never -- bash -il
2. Install the mysql client:
$ apt-get update && apt-get install mysql-client -y
3. Connect using the mysql cli, then provide your password:
$ mysql -h silly-moose-mysql -p

OK je teste alors !

Et normalement, si vous essayez, ça ne marchera pas !

Pourquoi ça ? On a bien tous les composants pour faire marcher MySQL.

Tous ?

Non ! Un irréductible gaulois résiste à l’envahisseur. Vous l’avez trouvé ?

Et oui ! La documentation nous dit juste de faire un helm install… sans nous rappeler que le PersistentVolumeClaim qui sera créé nécessite … un PersistentVolume ! Pour ceux qui n’auraient pas révisé leur terminologie Kubernetes, en gros MySQL attend qu’un disque se libère mais aucun n’est disponible.

Le Deployment se bloque donc à l’étape de Claim et y restera indéfiniment tant qu’un PV compatible n’est pas disponible.

On doit donc créer un PV. Personnellement j’ai créé un volume gluster parce que j’aime bien GlusterFS et j’ai créé le PV manquant dans Kubernetes.

gluster volume create gluster-pv-mysql replica 3 node01:/brick/gluster-pv-mysql node02:/brick/gluster-pv-mysql node03:/brick/gluster-pv-mysql force
volume create: gluster-pv-mysql: success: please start the volume to access data
gluster volume start gluster-pv-mysql
volume start: gluster-pv-mysql: success
cat > gluster-pv-mysql.yaml << EOF
apiVersion: v1
kind: PersistentVolume
metadata:
name: gluster-pv-mysql
spec:
capacity:
storage: 20Gi
accessModes:
- ReadWriteOnce
glusterfs:
endpoints: gluster-cluster
path: /gluster-pv-mysql
readOnly: false
persistentVolumeReclaimPolicy: Delete
EOF
kubectl apply -f gluster-pv-mysql.yaml

A partir de là, votre Deployment devrait reprendre la main.

Facile, hein ?

Ouais ok mais moi je veux modifier le nom de ma base MySQL

Ok on est capable de déployer MySQL, super. Mais généralement on veut personnaliser les composants qu’on déploie !

C’est bien évidemment prévu par les Charts, c’est même leur but premier.

Pour savoir ce qui peut être personnalisé et qui dépendra de chaque Chart que vous utiliserez, pas le choix : il faut aller lire la documentation du Chart de MySQL (ici sur Github).

Pour vous donner un petit exemple de ce qu’on peut faire avec notre MySQL, voici quelques arguments utiles que vous pouvez personnaliser :

helm install --name test \
--set mysqlLRootPassword=secretpassword,mysqlUser=zwindler,mysqlPassword=supermotdepasse,mysqlDatabase=zwindlerdb \
stable/mysql

Après déploiement, on peut retester la connexion via un container ubuntu temporaire (comme la fois d’avant), et s’assurer qu’on peut se connecter sur notre base MySQL avec notre nouvel utilisateur zwindler et son supermotdepasse !

[root@node01 ~]# kubectl run -i --tty ubuntu --image=ubuntu:16.04 --restart=Never -- bash -il
If you don't see a command prompt, try pressing enter.
root@ubuntu:/#
root@ubuntu:/# apt-get update && apt-get install mysql-client -y
[…]
mysql -h test-mysql -u zwindler -p
#supermotdepasse

Et on nettoie tout : supprimer un Chart

Dans le cas où vous voudriez tout nettoyer d’un coup, vous pouvez utiliser Helm pour supprimer en même temps tous les composants que vous auriez déployés via un « helm install mon-chart ».

Ici, je peux supprimer l’ensemble des composants qui ont été créés dans cet exemple « silly-moose-mysql ».

helm delete silly-moose-mysql
release "silly-moose-mysql" deleted

Sortie de XWiki 9.5 et mise à jour Docker

Fri, 30 Jun 2017 10:30:12 +0000

Adieu à 8.4, bonjour XWiki 9.5 (.1)

J’évite de faire un article à chaque fois qu’une nouvelle version de XWiki sort, surtout les versions mineures. Le projet XWiki est assez dynamique : les versions (et les fonctionnalités supplémentaires qui vont avec) s’enchaînent assez vite. Effectivement, depuis mon dernier article sur comment mettre à jour en 8.4 votre XWiki si vous utilisez mon image Docker de XWiki date d’à peine plus de 6 mois !

Mais j’ai deux occasions pour faire ce petit article.
D’abord parce que je continue à maintenir mon image zwindler/xwiki-tomcat8 qui fonctionne avec postgresql. Et je viens de déployer la dernière version sur le dockerhub.
Et ensuite parce qu’au delà des nombreuses améliorations et modifications de l’interface (j’en fais la liste dessous), la gestion des pages par défaut du XWiki (Flavor) a été découplée du Distribution Wizard pour permettre à la communauté de créer son propre « set » de pages par défaut.

Une bonne nouvelle car personnellement la première chose que je fais quand je déploie un XWiki, c’est supprimer la Sandbox et le Blog. J’attend donc les premiers Flavors avec impatience :).

Pourquoi maintenir une version non officielle ?

Depuis mon dernier post, les gens de chez XWiki (surtout Vincent Massol) ont sorti leur propre version de XWiki sous Docker.

100k pulls dépassés, respect !

Vincent est même allé assez loin dans le travail, avec la promotion de son image en tant qu’image « officielle » (titre réservé aux éditeurs, et si j’ai bien compris gagner ce titre n’a pas été une mince affaire), ainsi que la création d’un build automatisé multiple pour plusieurs version de XWiki et le support de plusieurs bases de données :

De nombreuses versions disponibles, comme les plus grands

Alors dans ces conditions, à quoi bon maintenir ma propre image ?

Eh bien déjà parce que XWiki a été ma première expérience avec Docker et que construire cette image m’a permis de mettre le pied à l’étrier. Aujourd’hui encore, quand je teste une techno ou un outil dans l’écosystème Docker, une installation simple XWiki + postgresql me sert de base de comparaison.

Du coup j’utilise XWiki avec ma propre image, et la mettre à jour lorsque je veux profiter des dernières version. Accessoirement, ça me permet aussi de faire la course avec Vincent et de parfois mettre à jour ma version de XWiki containerisé avant l’image officielle (je plaisante ;-) ).

(Elle est aussi plus légère car je n’embarque pas le serveur Open Office que je n’utilise pas, mais ce n’est probablement pas un argument en ma faveur).

Quoi de neuf docteur ?

J’aurais bien fais la blague « quoi de neuf, Docker » mais j’ai découvert récemment que c’est une chaine Youtube qui existe déjà…

Pour ceux qui n’ont pas le temps de lire l’ensemble des releases notes depuis la 8.4, voici la liste des fonctionnalités et des changements les plus notables qui ont été ajoutées depuis (de 9.0 à 9.5) :

La 9.0 a surtout servi à marquer le changement de branche et n’ajoute que quelques ajustements sur la taille max des pièces jointes et de la corbeille
Depuis la 9.1, ajout d’une protection contre la suppression accidentelles de page du système

Depuis la 9.1, l’export HTML prend mieux en compte les nested pages (pages filles) ! Un grand soulagement pour ceux qui font des exports pour avoir des versions figées comme moi !
Depuis la 9.2, les options en terme de notification (pour les utilisateurs en cas d’abonnement, etc) a été enrichi. Et depuis la 9.4, on peut s’abonner aux commentaires d’une page, une fonctionnalité qui m’a déjà été demandé et qui manquait, effectivement ! Des filtres ont également été ajoutés pour plus de finesse dans les notifications.

Depuis la 9.2, et à la suite d’un sondage parmi les utilisateurs de XWiki, les ergonomes de chez XWiki on réorganisé la page d’administration pour améliorer l’expérience utilisateur. Certains changements sont subtils mais bienvenus (notamment l’ordre des menus).

Depuis la 9.4, pour répondre de nombreuses remarques venant de novices et suite à une consultation sur la dev-list, les menus pour interagir avec une page ont été refondus et des labels (pour modifier et créer) ont été ajoutés pour être plus explicites. Ce n’est pas forcément vrai pour tout le monde, mais c’est vrai que dans certain cas, trouver comment faire une action sur une page (renommer pour déplacer) n’était pas toujours intuitif.

l’éditeur CKEditor a été amélioré à plusieurs reprise pour une meilleure intégration avec XWiki et notamment ses macros, …
l’API REST a été améliorée et permet maintenant (entre autre) de déployer des XWiki de manière non interactive et d’interagir avec les différents éléments du XWiki (dont la corbeille). Personnellement je sous-utilise énormément l’API et c’est une erreur car je pense que nous pourrions gagner beaucoup de temps…
Diverses améliorations graphiques dans les diff entre révisions d’une page/extension, sur les calendriers, des preview sur les images en attachement, …

Bon et donc la 9.5, on fait comment pour l’avoir ?

Rien ne vous empêche d’installer la 9.5 vous même, ou bien d’attendre que la version XWiki Docker officielle ne sorte, mais si vous utilisez mon image, elle est disponible :-p.

Pour rappel, les sources sont disponibles sur Github et l’image est elle accessible sur Dockerhub ou encore via une simple commande du type :

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

Si vous voulez un tutoriel plus complet sur ma version, je vous conseille cet article ou tout simplement de suivre les instructions sur Dockerhub.

Have fun !

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

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

Pourquoi je n’arrive pas à uploader mon gros XAR

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

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

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

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

Filesystem attachment store

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

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

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

environment.permanentDirectory=/opt/tomcat6/data

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

(Lien image mort)

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

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

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

Pour ceux qui sont dans l’ancien mode de fonctionnement

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

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

Pour les nouveaux utilisateurs

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

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

Au delà de ça

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

FAQ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Déploiement du nouveau WordPress

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

Le processus d’installation est relativement simple à suivre

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

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

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

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

Export des données existantes

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

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

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

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

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

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

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

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

Je vous conseille de le faire également.

Import des données dans le nouveau WordPress

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

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

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

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

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

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

Pas de journaux d’événements dans Centreon, logAnalyser already running

Wed, 22 Jan 2014 10:32:21 +0000

[Edit]Commandes affinées et source de la solution ajoutée dans l’article[/Edit]

Si vous avez installé Nagios/Centreon, vous utilisez surement la fonctionnalité permettant d’afficher l’historique de tous les événements passés. Cependant, il arrive (notamment après un crash) que cette fonctionnalité se fige.

Les logs sont toujours visibles dans Nagios (http://@IP-Nagios/nagios/cgi-bin/history.cgi?host=all) ou directement dans les fichiers nagios/var/nagios.log, mais plus dans Centreon alors que cela fonctionnait avant (Si ça n’a jamais fonctionné, c’est autre chose ; probablement un problème de permissions ou de chemin lors de l’installation).

Dans mon cas, en lisant le log dans centreon/log/logAnalyser.log, j’avais des lignes et des lignes avec le message suivant

22/1/2014 11:15:02 - logAnalyser already running...
22/1/2014 11:16:01 - logAnalyser already running...

Pourtant aucun processus logAnalyser n’était visible sur le serveur.

Une recherche sur Internet m’a mis sur la voie : forums.monitoring-fr.org/index.php?topic=5545.15 (lien mort, pas sauvegardé par Internet Archive)

En fait, c’est tout simplement que le logAnalyser était en cours d’exécution lors d’un plantage, et n’a pas pu libérer le lock, stocké dans la base MySQL. Pour débloquer la situation, et après avoir revérifié qu’il ne tournait effectivement pas :

mysql
use Centreon
select * from cron_operation;
+----+-----------------+---------+-------------+-------------------+--------+--------+---------+---------------------+----------+
| id | name | command | time_launch | last_modification | system | module | running | last_execution_time | activate |
+----+-----------------+---------+-------------+-------------------+--------+--------+---------+---------------------+----------+
| 2 | centAcl.php | NULL | 1431338042 | 0 | 1 | NULL | 0 | 1 | 1 |
| 3 | nagiosPerfTrace | NULL | 1393761601 | 0 | 1 | NULL | 1 | 1 | 1 |
| 4 | logAnalyser | NULL | 1430113466 | 0 | 1 | NULL | 1 | 167 | 1 |
+----+-----------------+---------+-------------+-------------------+--------+--------+---------+---------------------+----------+
update `cron_operation` set running = 0 where id = 4;
exit

Un petit redémarrage du démon centcore pour prise en compte et le tour est joué

service centcore restart