MaDoVi - Le wiki

Machines - Données - Virtualisation

Outils pour utilisateurs

Outils du site


services:web:tuto:guac_tuto1

Guacamole

est un service qui permet d'accéder à des machines à partir d'un simple navigateur web (Firefox, Chromium, etc…). Ces machines exposent évidemment un protocole pour les atteindre; Guacamole supporte à date: vnc, rdp, ssh, telnet. Également Kubernetes, mais là, pour l'heure et pour moi, c'est flou…


On en discute On en discute sur le forum


Pourquoi ? ☛ Cette application présente un grand intérêt pour nous, dans le cadre de ce projet « ».
En plus de l'intérêt évident de l'accès aux Machines Virtuelles (VM avec interface graphique de bureau par exemple), nous proposons tout un tas de services dans des containers, dont l'intérêt est d'être isolés et donc pas facilement atteignables.

Si par exemple on souhaite atteindre la console/terminal d'un container installé, pour y modifier une configuration ou y installer un nouveau composant, nous devons:

  • ouvrir un terminal depuis un client,
  • nous connecter au serveur hôte en ssh par exemple,
  • depuis cette console, nous attacher au container,
  • pour enfin disposer d'une interface dans le container et y faire nos actions…

Si l'on intègre systématiquement un serveur ssh à nos containers, tous deviennent alors accessibles avec cette solution, depuis un navigateur, directement par un simple connexion.
Donc, on prend

Guacamole n'est pas une application Web autonome: elles se compose de nombreux éléments.

L'application web est en fait conçue pour être simple et minimale, la majorité du travail étant effectuée par des composants de niveau inférieur.

Les utilisateurs se connectent à un serveur Guacamole avec leur navigateur Web. Le client Guacamole, écrit en JavaScript, est servi aux utilisateurs par un serveur Web au sein du serveur Guacamole. Une fois chargé, ce client se connecte au serveur par HTTP en utilisant le protocole Guacamole.

L'architecture du service est la suivante: Architecture

Nous nous proposons ici d'installer ces composants au sein d'un container LXC.

Placé dans notre ensemble de containers «non privilégiés», lxc-guacamole – service HTTP motorisé avec le fournisseur de servlets Tomcat – sera accessible par l’intermédiaire d'un reverse proxy sur le serveur «».


1. Création du container

On souhaite installer notre outil Guacamole – les composants du « cadre jaune » dans le schéma ci-dessus – dans un CT LXC qu'on va nommer lxc-guacamole (on pourrait demain y ajouter un autre service java sous forme de .war par exemple). Ce container sera «non privilégié», et on va donc le créer depuis le compte visto. On le construit, comme pour beaucoup de CT LXC, avec la distribution Alpine Linux, qui a une très faible empreinte système: «Les cibles principales d'Alpine sont les conteneurs et presque tous les appareils embarqués».

Mais au préalable, on peut fixer – optionnellement – une adresse au CT dans l'espace réseau LXC. Par exemple:

$ sudo nano /etc/lxc/dnsmasq.conf
...
# cid 150 -> 199; containers divers
dhcp-host=lxc-guacamole,10.0.3.151
...

☛ Relancer le service dhcp/dnsmasq pour prise en compte:

$ sudo service lxc-net restart

Puis:

  • Création:
    visto@wasabi:~$ lxc-create -n lxc-guacamole -t download -- -d alpine -r 3.15 -a amd64
  • Il est intéressant, dans un premier temps et pour vérifier au fil de l'eau nos opérations, de définir notre container avec une connexion (et reconnaissance donc, genre « http://lxc-guacamole ») sur le LAN plutôt qu'isoler dans le réseau des containers. On restaurera ensuite à la fin…
    Pour ce faire donc, éditer le fichier de configuration du container et inverser les lignes de commentaire entre lxcbr0 et br0:
    visto@wasabi:~$ nano $(lxc-config lxc.lxcpath)/lxc-guacamole/config
    [ ... ]
    # Network configuration
    lxc.net.0.type = veth
    #lxc.net.0.link = lxcbr0      ## <<== Commenter
    lxc.net.0.link = br0          ## <<== Décommenter
    lxc.net.0.flags = up
    [ ... ]

    Ctrl+x et y pour enregistrer et sortir.

  • Lancement:
    visto@wasabi:~$ lxc-start -n lxc-guacamole 
  • Contrôle:
    visto@wasabi:~$ lxc-ls -f
    NAME        STATE   AUTOSTART GROUPS IPV4         IPV6 UNPRIVILEGED 
    [ ... ]
    lxc-guacamole  RUNNING 0         -      192.168.1.xx -    true         
    [ ... ]

    Il tourne, il a une adresse dans l'espace du LAN, il est bien unprivileged.


2. Préparation

On commence par s' « attacher » au container pour faire ce qu'on a à faire dedans:

visto@wasabi:~$ lxc-attach -n lxc-guacamole 
/ # 

Les ajouts/installations/configurations de base: outils, sudo, ssh, … (l'outil de gestion de paquets s'appelle apk sous Alpine).

  • Commençons par les outils:
    /sbin/apk update
    /sbin/apk add attr dialog dialog-doc bash bash-doc bash-completion grep grep-doc
    /sbin/apk add util-linux util-linux-doc pciutils usbutils binutils findutils readline
    /sbin/apk add mandoc man-pages lsof lsof-doc less less-doc nano nano-doc curl curl-doc
    /sbin/apk add sudo sudo-doc openssh 
    export PAGER=less
  • On prend bash comme interpréteur de commandes: il suffit de remplacer, dans le fichier /etc/passwd la fin de la ligne associée au compte root (la 1ière) par celle-ci (ash par défaut devient bash):
    nano /etc/passwd
     
    root:x:0:0:root:/root:/bin/bash
    ...

    Ctrl+x et y pour enregistrer et sortir.

  • Lancer le service ssh (et l'ajouter au démarrage du container):
    /sbin/rc-update add sshd
    /etc/init.d/sshd start
  • Ajout d'un utilisateur «admin» …:
    /usr/sbin/adduser admin
    Changing password for admin
    New password: 
    Retype password: 
    passwd: password for admin changed by root
  • … avec droit root (sudo):
    /usr/sbin/visudo
    ##                                                               
    ## User privilege specification
    ##
    root ALL=(ALL) ALL       
    admin ALL=(ALL) ALL   ## <<<=== ICI

    NB: visudo utilise l'éditeur VI: donc i pour entrer en mode insertion, Esc pour en sortir; puis :w pour enregistrer et :q pour quitter.

  • On redémarre pour prise en compte, du coup on sort et on se retrouve avec le shell du serveur:
    /sbin/reboot
    visto@wasabi:~$
  • On va maintenant travailler à partir d'une connexion ssh:
    admin@wasabi:~$ ssh admin@lxc-guacamole
    ## accepter l'échange de clé
    admin@lxc-guacamole's password: 
    Welcome to Alpine!
     
    The Alpine Wiki contains a large amount of how-to guides and general
    information about administrating Alpine systems.
    See <http://wiki.alpinelinux.org/>.
     
    You can setup the system with the command: setup-alpine
     
    You may change this message by editing /etc/motd.
    lxc-guacamole:~$
  • On se positionne en root pour toutes les manip. à suivre (vous aurez droit au message de mise en garde à la première utilisation de sudo):
    lxc-guacamole:~$ sudo -i
     
    We trust you have received the usual lecture from the local System
    Administrator. It usually boils down to these three things:
     
        #1) Respect the privacy of others.
        #2) Think before you type.
        #3) With great power comes great responsibility.
     
    [sudo] password for admin: 
    lxc-guacamole:~# 

    Notez le changement de $ à #: on est bien administrateur dans notre container.

  • On fixe le fuseau horaire:
    lxc-guacamole:~# setup-timezone -z Europe/Paris
  • On sort de l'envrionnement root:
    lxc-guacamole:~# exit
    lxc-guacamole:~$

On est bon pour bosser dans notre container…


3. Téléchargements

On va récupérer ici, dans un répertoire dédié sur notre compte (ou l'on se retrouve après être sorti du mode root ci-dessus), l'ensemble des outils dont on va avoir besoin pour installer Guacamole.

Créons notre dossier et positionnons-nous dedans:

lxc-guacamole:~$ mkdir download; cd download

Si l'on « zoome » sur le schéma d'architecture, on a :

  • La dernière version à date de Guacamole est la v 1.4.0.
  • Le composant Guacamole est une application web en java (c'est un .war). On le récupère avec:
    $ wget https://dlcdn.apache.org/guacamole/1.4.0/binary/guacamole-1.4.0.war 
  • guac, charger de mettre en œuvre les protocoles et d'atteindre les machines. On le récupère à partir de la forge, a priori plus «fraiche» (on isntalle git d'abord):
    $ sudo apk add git
    $ git clone git://github.com/apache/guacamole-server.git
  • Il nous faut un « conteneur de servlet ». On prend Tomcat comme suggéré, dans sa dernière version 9.x, Guacamole n'est pas à date compatible avec Tomcat v10.x:
    $ wget https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.59/bin/apache-tomcat-9.0.59.tar.gz 


Testé pour vous: Incompatibilité à date entre guacamole v 1.4.0 et la dernière version de tomcat v 10.x , dans les classes java utilisées…

En effet, erreur constatée: java.lang.NoClassDefFoundError: javax/servlet/ServletContextListener.

Le paquet javax.* a été renommé en paquet jakarta.* depuis la version 9 de Jakarta EE. Cela signifie donc que l'application web déployée n'est en fait pas compatible avec Jakarta EE version 9. L'application web déployée est très probablement développée pour une ancienne version de JEE où le paquet javax.* est encore utilisé.

Donc, en résumé, les versions JEE visées ne correspondent pas et cela me cause des problèmes. Deux options :

  • Mettre à niveau Tomcat vers la version 9.x. Il s'agit de la dernière version disponible qui utilise toujours le paquet javax.*.
  • Mettre à niveau l'application web déployée pour cibler Jakarta EE 9 à la place. C'est-à-dire ajuster les dépendances du projet (par exemple pom.xml) pour référencer les versions basées sur JEE 9+, et effectuer un Find & Replace de javax.* à jakarta.* pour l'ensemble du projet (sauf bien sûr pour javax.naming.* et javax.xml.* et probablement quelques autres, mais le compilateur Java les signalera rapidement).

Bon… On est donc passé à Tomcat 9.0.59

  • Et pour finir, il nous faut… Java !
    $ sudo apk add openjdk11-jre-headless

4. Installation – « guacd »

Comme l'illustre le schéma d'architecture ci-dessus, Guacamole est séparé en deux parties : guacd, le « démon » qui fournit un proxy «protocoles» et les bibliothèques de protocoles associées, et guacamole, qui fournit le client à servir via un conteneur de servlets, généralement Apache Tomcat.

guacamole est disponible sous forme binaire, mais guacd doit être construit à partir des sources.

Et on ne se décourage pas ! Construire les composants de Guacamole à partir des sources n'est pas aussi difficile qu'il y paraît, et le processus de construction est automatisé. On doit simplement s'assurer que nous avons installé les outils à l'avance. Une fois les dépendances nécessaires en place, la construction de guacd ne prend que quelques minutes.


4.1. Dépendances

Il faut qu'on se fasse un petit travail de … « correspondance » des les librairies requises pour l'installation.
La documentation nous indique des noms de dépendances pour debian, ubuntu, fedora, etc… Pas pour Alpine qui est la distribution de notre container.

Le résultat de ce travail correspond au tableau suivant, dont la dernière colonne nous intéresse:

Dépendances «obligatoires»
Couverture Correspondances Distributions Pour Alpine v3.15
Cairo:
Cairo est utilisé pour le rendu graphique.
Guacamole ne peut pas fonctionner sans Cairo installé
Debian / Ubuntu: libcairo2-dev
Fedora / CentOS / RHEL: cairo-devel
cairo-dev
Libjpeg-turbo:
Est utilisée pour fournir le support JPEG.
Guacamole ne sera pas construit sans la présence de cette bibliothèque.
Debian: libjpeg62-turbo-dev
Ubuntu: libjpeg-turbo8-dev
Fedora / CentOS / RHEL: libjpeg-turbo-devel
libjpeg-turbo-dev
Libpng:
Est utilisé pour écrire des images PNG, le type d'image principal utilisé par le protocole Guacamole.
Guacamole ne peut pas fonctionner sans libpng.
Debian / Ubuntu: libpng12-dev
Fedora / CentOS / RHEL: libpng-devel
libpng-dev
Libtool:
Est utilisé pendant le processus de construction.
libtool crée les bibliothèques compilées nécessaires à Guacamole.
Debian / Ubuntu: libtool-bin
Fedora / CentOS / RHEL: libtool
libtool
Libuuid:
Est utilisé pour attribuer des identifiants internes uniques à chaque utilisateur et connexion Guacamole.
Ces identifiants uniques constituent la base de la prise en charge du partage des connexions.
Debian / Ubuntu: uuid-dev
Fedora / CentOS / RHEL: libuuid-devel
libuuid
Déjà installé avec le paquet util-linux
Dépendances «facultatives» mais qu'on prend toutes ici
Les dépendances optionnelles de Guacamole déterminent les parties de guacamole-server qui seront construites. Cela inclut la prise en charge de divers protocoles de bureau à distance, ainsi que toutes les fonctionnalités supplémentaires de ces protocoles : VNC, RDP, SSH, Telnet, le support Kubernetes.

- La prise en charge de VNC dépend de la bibliothèque libvncclient, qui fait partie de libVNCServer.
- La prise en charge de RDP dépend d'une version récente de FreeRDP (2.0.0 ou plus, mais s'il vous plaît pas une version non publiée de git).
- La prise en charge de SSH dépend de libssh2, OpenSSL et Pango (une bibliothèque de rendu de police et de mise en page de texte, utilisée par l'émulateur de terminal intégré de Guacamole).
- Telnet dépend de libtelnet et Pango.
- Le support Kubernetes dépend de libwebsockets, OpenSSL et Pango.

L'utilitaire guacenc, fourni par guacamole-server pour traduire les enregistrements d'écran en vidéo, dépend de FFmpeg, et ne sera construit que si au moins les bibliothèques libavcodec, libavformat, libavutil et libswscale fournies par FFmpeg sont installées.
Couverture Correspondances Distributions Pour Alpine v3.15
FFmpeg
Les bibliothèques libavcodec, libavformat, libavutil et libswscale fournies par FFmpeg sont utilisées par guacenc pour encoder les flux vidéo lors de la traduction des enregistrements des sessions Guacamole. Sans FFmpeg, l'utilitaire guacenc ne sera tout simplement pas construit.
Si vous ne souhaitez pas faire d'enregistrements graphiques de sessions Guacamole, ou si vous ne souhaitez pas traduire de tels enregistrements en vidéo, alors FFmpeg n'est pas nécessaire.
Debian / Ubuntu: libavcodec-dev, libavformat-dev, libavutil-dev, libswsccale-dev
Fedora / CentOS / RHEL: ffmpeg-devel
ffmpeg-dev
FreeRDP
FreeRDP 2.0.0 ou plus récent est requis pour le sulibtelnet est nécessaire pour le support de telnet. Si vous ne souhaitez pas construire le support telnet, cette bibliothèque n'est pas nécessaire.pport RDP.
Si vous ne souhaitez pas construire le support RDP, cette bibliothèque n'est pas nécessaire.
Debian / Ubuntu: freerdp2-dev
Fedora / CentOS / RHEL: freerdp-devel
freerdp-dev
Pango
Pango est une bibliothèque de mise en page de texte que Guacamole utilise pour rendre le texte des protocoles qui nécessitent un terminal (Kubernetes, SSH et telnet).
Si vous ne souhaitez pas construire de support de protocole basé sur un terminal, cette bibliothèque n'est pas nécessaire.
Debian / Ubuntu: libpango1.0-dev
Fedora / CentOS / RHEL: pango-devel
pango-dev
Libssh2
libssh2 est nécessaire pour le support SSH et SFTP.
Si vous ne souhaitez pas construire le support SSH ou SFTP, cette bibliothèque n'est pas nécessaire.
Debian / Ubuntu: libssh2-1-dev
Fedora / CentOS / RHEL: libssh2-devel
libssh2-dev
Libtelnet
libtelnet est nécessaire pour le support de Telnet.
Si vous ne souhaitez pas construire le support telnet, cette bibliothèque n'est pas nécessaire.
Debian / Ubuntu: libtelnet-dev
Fedora / CentOS / RHEL: libtelnet-devel
Rien … On s'en passera de Telnet…
LibVNCServer
libVNCServer fournit libvncclient, qui est nécessaire pour la prise en charge de VNC.
Si vous ne souhaitez pas construire le support VNC, cette bibliothèque n'est pas nécessaire.
Debian / Ubuntu: libvncserver-dev
Fedora / CentOS / RHEL: libvncserver-devel
libvncserver-dev
Libwebsockets
libwebsockets est nécessaire pour la prise en charge de Kubernetes.
Si vous ne souhaitez pas construire le support Kubernetes, cette bibliothèque n'est pas nécessaire.
ebian / Ubuntu: libwebsockets-dev
Fedora / CentOS / RHEL: libwebsockets-devel
libwebsockets-dev
PulseAudio
PulseAudio fournit libpulse, qui est utilisé par le support VNC de Guacamole pour fournir un support audio expérimental.
Si vous n'avez pas l'intention d'utiliser le support audio expérimental de VNC, vous n'avez pas besoin de cette bibliothèque.
Debian / Ubuntu: libpulse-dev
Fedora / CentOS / RHEL: pulseaudio-libs-devel
pulseaudio-dev
OpenSSL
OpenSSL fournit le support pour SSL et TLS - deux schémas de cryptage communs qui constituent la majorité du trafic web crypté.
Si vous avez installé libssl, guacd sera construit avec le support SSL, permettant à la communication entre l'application web et guacd d'être cryptée. Cette bibliothèque est également requise pour le support SSH, pour la manipulatlion des clés publiques/privées, et pour le support Kubernetes, pour les connexions SSL/TLS au serveur Kubernetes.
Sans le support SSL, il n'y aura pas d'option pour crypter la communication vers guacd, et le support pour SSH et Kubernetes ne peut pas être construit.
En fait ça n'a pas l'air très optionnel cette affaire …
Debian / Ubuntu: libssl-dev
Fedora / CentOS / RHEL: openssl-devel
openssl-dev
Libvorbis
libvorbis prend en charge Ogg Vorbis, un standard libre et ouvert pour la compression du son. Si elle est installée, libguac sera construite avec la prise en charge de Ogg Vorbis, et les protocoles supportant l'audio utiliseront la compression Ogg Vorbis lorsque cela sera possible.
Sinon, le son ne sera encodé qu'en WAV (non compressé), et ne sera disponible que si votre navigateur supporte également le WAV.
Debian / Ubuntu: libvorbis-dev
Fedora / CentOS / RHEL: libvorbis-devel
libvorbis-dev
Libwebp
libwebp est utilisé par libguac pour écrire des images WebP. Bien que la prise en charge de WebP ne soit pas obligatoire dans le protocole Guacamole, les images WebP seront utilisées si elles sont prises en charge à la fois par le navigateur et par libguac.
En l'absence de support WebP, Guacamole utilisera simplement JPEG dans les cas où il aurait préféré WebP.
Debian / Ubuntu: libwebp-dev
Fedora / CentOS / RHEL: libwebp-devel
libwebp-dev

Ouf… Que personne ne touche à ce tableau, c'est trop chiant à faire ! 8-o :-D


4.2. Installations des paquets

Connectons-nous avec des privilèges root:

$ sudo -i

Puis installons donc tout ces dépendances/librairies:

  • Les librairies «obligatoires»:
    # apk add --no-cache cairo-dev libjpeg-turbo-dev libpng-dev libtool 
  • Les librairies «facultatives»:
    # apk add --no-cache \
          ffmpeg-dev \
          freerdp-dev \
          pango-dev \
          libssh2-dev \
          libvncserver-dev \
          libwebsockets-dev \
          pulseaudio-dev \
          openssl-dev \
          libvorbis-dev \
          libwebp-dev 
  • Les outils de compilation:
    # apk add --no-cache autoconf automake alpine-sdk
  • L'outil serveur démon guacd qu'on compile et installe plus loin a besoin d'une font/police mono pour afficher la console SSH, et notre container super léger n'en n'a pas. On va lui en installer une tout de suite:
    # apk add ttf-dejavu
  • Et on sort du mode root:
    # exit

FIXME: Autres polices possibles (n'en choisir qu'une), à votre convenance:

# apk add font-terminus-nerd ttf-freefont unifont ttf-liberation ttf-mononoki

/ FIXME


4.3. Compilation

On est sortie à l'instant du mode console privilégié (sudo). On est donc revenu dans notre dossier de téléchargement de notre utilisateur admin:

lxc-guacamole:~/download$ 

Récupération des sources:
On a téléchargé plus haut les sources de puis la forge, qui a créé un dossier guacamole-server dans lequel on se rend et depuis lequel on génère le fichier de configuration qui va permettre la génération de l'exécutable:

lxc-guacamole:~/download$ cd guacamole-server
lxc-guacamole:~/download/guacamole-server$ autoreconf -fi  

On lance / vérifie la configuration:

lxc-guacamole:~/download/guacamole-server$ ./configure --with-init-dir=/etc/init.d

dont le résultat devrait avoir cette tête-là:

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
 
[ ... ]
 
------------------------------------------------
guacamole-server version 1.4.0
------------------------------------------------
 
   Library status:
 
     freerdp2 ............ yes
     pango ............... yes
     libavcodec .......... yes
     libavformat.......... yes
     libavutil ........... yes
     libssh2 ............. yes
     libssl .............. yes
     libswscale .......... yes
     libtelnet ........... no
     libVNCServer ........ yes
     libvorbis ........... yes
     libpulse ............ yes
     libwebsockets ....... yes
     libwebp ............. yes
     wsock32 ............. no
 
   Protocol support:
 
      Kubernetes .... yes
      RDP ........... yes
      SSH ........... yes
      Telnet ........ no
      VNC ........... yes
 
   Services / tools:
 
      guacd ...... yes
      guacenc .... yes
      guaclog .... yes
 
   FreeRDP plugins: /usr/lib/freerdp2
   Init scripts: no
   Systemd units: no
 
Type "make" to compile guacamole-server.
 
lxc-guacamole:~/download/guacamole-server$

Comme prévu, pas de Telnet…

On compile l'application:

lxc-guacamole:~/download/guacamole-server$ make

qui retourne quelque chose comme:

make  all-recursive
make[1]: Entering directory '/home/admin/download/guacamole-server'
Making all in src/libguac
 
[ ... ]
 
make[2]: Leaving directory '/home/admin/download/guacamole-server/src/guaclog'
make[2]: Entering directory '/home/admin/download/guacamole-server'
make[2]: Leaving directory '/home/admin/download/guacamole-server'
make[1]: Leaving directory '/home/admin/download/guacamole-server'
lxc-guacamole:~/download/guacamole-server$

Fini ! Pas si compliqué, hein… 8-)


4.4. Installation

On installe: Mais il faut être root

lxc-guacamole:~/download/guacamole-server$ sudo make install

Il baratine plein de choses, et il faut finir, toujours en root avec la commande ldconfig pour mettre à jour le cache des bibliothèques installées de notre système:

lxc-guacamole:~/download/guacamole-server$ sudo ldconfig

Mise en service: On va maintenant définir le mécanisme de service et de lancement automatique du serveur guacd.

  • On augmente notre niveau de privilège:
    lxc-guacamole:~/download/guacamole-server$ sudo -i
  • On crée le script de démarrage / init:
    lxc-guacamole:~# cat > /etc/init.d/guacd <<_EOF_
    #!/sbin/openrc-run
    description="Démon de triatement des protocoles pour Guacamole"
    command=/usr/local/sbin/guacd
    command_args="-b 127.0.0.1 -l 4822"
    command_background=true
    pidfile="/var/run/${RC_SVCNAME}.pid"
    _EOF_
  • On rend ce script exécutable:
    lxc-guacamole:~# chmod +x /etc/init.d/guacd
  • On lance le serveur:
    lxc-guacamole:~# rc-service guacd start
    Caching service dependencies ...                                                                  [ ok ]
    Starting Guacamole server ...
    guacd[16529]: INFO:	Guacamole proxy daemon (guacd) version 1.4.0 started                      [ ok ]
    lxc-guacamole:~# 
  • On met en place le lancement au boot:
    lxc-guacamole:~# rc-update add guacd default
    * service guacd added to runlevel default
    lxc-guacamole:~# 
  • Pour arrêter le service:
    # service guacd stop
  • Pour lancer le service:
    # service guacd start
  • Pour connaître le status:
    # service guacd status
  • Pour redémarrer le service:
    # service guacd restart

Guacd est en ligne.


5. Installation – « guacamole-client »

Nous abordons maintenant le côté guacamole-client de Guacamole, fournissant l'application web du service sous Tomcat (servlet java).

Nous n'avons pas ici besoin de compilation sur cette partie, guacamole-client étant écrit en Java et multiplate-forme. En revanche, il faut préparer l'environnement d'exécution, à savoir Java et Tomcat.

Plus haut, on a déjà installé Java et téléchargé Tomcat. On va installer ce dernier…


5.1. Environnement Java / servlet

Serveur Tomcat: Il s'agit de l'installer dans un répertoire dédié.

  • On retourne dans notre dossier de téléchargement:
    cd /home/admin/download
  • On se créé un répertoire cible pour Tomcat:
    lxc-guacamole:~/download$ sudo mkdir /opt/tomcat9
  • On décompresse Tomcat vers sa cible:
    lxc-guacamole:~/download$ sudo tar xvzf apache-tomcat-9.0.59.tar.gz --strip-components 1 --directory /opt/tomcat9
  • On vérifie que celà fonctionne (on regarde la version):
    lxc-guacamole:~/download$ sudo /opt/tomcat9/bin/catalina.sh version

Mise en service: On va maintenant définir le mécanisme de service et de lancement automatique du serveur Tomcat.

  • On augmente notre niveau de privilège:
    lxc-guacamole:~/download$ sudo -i
  • On crée le script de démarrage / init:
    lxc-guacamole:~# cat > /etc/init.d/tomcat9 <<_EOF_
    #!/sbin/openrc-run
    description="Apache Tomcat v9.x"
    command=/opt/tomcat9/bin/catalina.sh
    command_args=run
    command_background=true
    directory=/opt/tomcat9
    pidfile="/run/${RC_SVCNAME}.pid"
    _EOF_
  • On rend ce script exécutable:
    lxc-guacamole:~# chmod +x /etc/init.d/tomcat9
  • On lance le serveur:
    lxc-guacamole:~# rc-service tomcat9 start
     * Caching service dependencies ...     [ ok ]
     * Starting tomcat ...                  [ ok ]
  • On met en place le lancement au boot:
    lxc-guacamole:~# rc-update add tomcat9 default
     * service tomcat added to runlevel default
  • Pour arrêter le service:
    # service tomcat9 stop
  • Pour lancer le service:
    # service tomcat9 start
  • Pour connaître le status:
    # service tomcat9 status
  • Pour redémarrer le service:
    # service tomcat9 restart

Tomcat est en ligne. Vous pouvez les constater avec http://lxc-guacamole:8080, qui donne l'écran suivant:

Écran Tomcat 9.x

sources: https://wiki.alpinelinux.org/wiki/Tomcat


5.2. Installation du site web

On passe maintenant à guacamole-client, l'application web proprement dite.

On a récupéré cette application web plus haut, qu'on à dans /home/admin/download: guacamole-1.4.0.war

Donc, étant toujours en root, c'est parfait):

Copie et renommage de l'application vers sa cible:

lxc-guacamole:~# cp /home/admin/download/guacamole-1.4.0.war /opt/tomcat9/webapps/guacamole.war

Prise en compte: Il faut ensuite faire un arrêt/relance de Tomcat pour la prise en compte de cette nouvelle application :

lxc-guacamole:~# service tomcat9 restart

Et on vérifie avec l'URL http://lxc-guacamole:8080/guacamole que l'application est bien là:

Login Guacamole

A ce stade nous n'irons pas plus loin sans un passage préalable par une phase de configuration à suivre…


6. Configurations

Il s'agit ici d'ajuster les données de configuration et l'ensemble des fichiers et répertoires nécessaires et/ou utiles au fonctionnement de Guacamole.

Par ailleurs, nous sommes partis pour notre installation avec un container raccordé et LAN et pas au sous-réseaux «masqué» des containers LXC, cible de notre configuration.

C'est une cible pour deux raisons:

  • Une raison de sécurité qui permet de ne pas exposer nos services directement sur le réseau local, ou «pire» si nous souhaitons proposer ces services sur le web.
  • Ce faisant, nous n'avons qu'un seul accès ouvert pour les services web via un reverse proxy, accessible côté LAN avec une ouverture de ports «NATés», et du côté serveur «naturellement» par le réseau de container LXC qui se connaissent entre eux – notre reverse proxy lxc-proxy étant lui-même un container.

Les § suivants donnent les modes opératoires pour réaliser tout cela.


6.1. GUACAMOLE_HOME

Il s'agit ici de définir un dossier, qui va contenir l'ensemble des fichiers et répertoires nécessaires et/ou utiles au fonctionnement de Guacamole.

GUACAMOLE_HOME est le nom donné au répertoire de configuration de Guacamole, qui se trouve par défaut dans /etc/guacamole. Tous les fichiers de configuration, les extensions, etc. résident dans ce répertoire.

La structure de GUACAMOLE_HOME est rigoureusement définie, et se compose des fichiers facultatifs suivants :

  • guacamole.properties: Le principal fichier de configuration de Guacamole. Les propriétés de ce fichier indiquent comment Guacamole se connectera à guacd (le module qu'on à compilé plus haut) et peuvent configurer le comportement des extensions d'authentification installées.
  • logback.xml: Guacamole utilise un système de journalisation appelé Logback pour tous les messages. Par défaut, Guacamole n'enregistre que sur la console, mais vous pouvez changer cela en fournissant votre propre fichier de configuration Logback.
  • extensions/: L'emplacement d'installation de toutes les extensions de Guacamole. Au démarrage, Guacamole charge automatiquement tous les fichiers .jar de ce répertoire.
  • lib/: Le répertoire de recherche des bibliothèques requises par toutes les extensions#/client/VW5pcXVlIE5hbWUAYwBkZWZhdWx0 de Guacamole. Guacamole met les fichiers .jar de ce répertoire à la disposition de toutes les extensions. Si vos extensions nécessitent des bibliothèques supplémentaires, telles que des pilotes de base de données, c'est l'endroit approprié pour les placer.

Créons cette structure:

lxc-guacamole:~# mkdir -p /etc/guacamole/{extentions,lib}

Le ficher guacamole.properties, selon la documentation :

/etc/guacamole/guacamole.properties
# Langues: on garde l'anglais, des fois qu'il manque des traductions...
allowed-languages: fr, en
 
# Ignorer l'authentification par base de données si hors service
skip-if-unavailable: mysql
 
# Accès au démon proxy vers les machines ''guacd''
guacd-hostname: localhost
guacd-port:     4822

Le ficher user-mapping.xml: Il définit les utilisateurs et les connexions auxquelles ils ont droit. Par exemple (basique):

/etc/guacamole/user-mapping.xml
<user-mapping>
    <!-- 
         Utilisateur utilisant un hash MD5 pour son mot de passe, afin de ne pas le conserver ici en clair...
         Sous linux, un hash MD5 peut être généré avec la commande ''printf '%s' PASSWORD | md5sum'' retourne ==> 319f4d26e3c536b5dd871bb2c52e3178) 
    -->
    <authorize username="guacadmin" password="5cbd438413e8e3ca0e14e200fde621a9" encoding="md5" >
 
        <connection name="SSH NAS sesame">
            <protocol>ssh</protocol>
            <param name="hostname">sesame</param>
            <param name="port">22</param>
        </connection>
 
        <connection name="SSH NAS wasabi">
            <protocol>ssh</protocol>
            <param name="hostname">wasabi</param>
            <param name="port">22</param>
        </connection>
 
        <connection name="SSH lxc-proxy">
            <protocol>ssh</protocol>
            <param name="hostname">lxc-proxy</param>
            <param name="port">22</param>
        </connection>
 
        <connection name="VM moka (sesame)">
            <protocol>vnc</protocol>
            <param name="hostname">moka</param>
            <param name="port">5900</param>
        </connection>
 
    </authorize>
 
</user-mapping>

Prise en compte de cette configuration:
Dans le fichier user-mapping.xml on a défini des connexions à une VM et à 3 machines en SSH. Après le login (usr: guacadmin - psw: guacadmin), ces définitions apparaissent bien:

Évidemment, il faudra définir les vôtres pour pouvoir les utiliser, avec un serveur VNC installé sur vos VM avec bureau graphique…


6.2. Configuration Tomcat

Pour la configuration Tomcat / serveur d'application web, la documentation de Guacamole consacre un chapitre à la configuration en reverse proxy.

On intervient ici dans le container lxc-guacamole – auquel nous sommes toujours connecté – pour modifier un fichier de configuration du serveur Tomcat.

  • On est en mode root:
    lxc-guacamole:~#
  • On souhaite modifier les fichier server.xml de Tomcat (on précise un option nano pour afficher les lignes):
    lxc-guacamole:~# nano -l /opt/tomcat9/conf/server.xml
  • Vers le ligne #70, on va ajouter l'encodage UTF-8:
     69    <Connector port="8080" protocol="HTTP/1.1"
     70               connectionTimeout="20000"
     71               URIEncoding="UTF-8"
     72               redirectPort="8443" />
     73 
  • A la fin du fichier, avant la clôture de la balise <Host>, on ajoute ce bloc où internalProxies est une liste de noms de proxies en amont qui peuvent atteindre Guacamole (ici notre CT lxc-proxy):
         [ ... ]
    168         <!-- Ajout cram - 2022.03.12 - Gestion du reverse proxy en amont -->
    169         <Valve className="org.apache.catalina.valves.RemoteIpValve"
    170                internalProxies="lxc-proxy"
    171                remoteIpHeader="x-forwarded-for"
    172                remoteIpProxiesHeader="x-forwarded-by"
    173                protocolHeader="x-forwarded-proto" />
    174
    175       </Host>
    176     </Engine>
    177 [ ... ] 

    Ctrl+x et y pour enregistrer et sortir.

  • On relance le service Tomcat pour prise en compte:
    lxc-guacamole:~# service tomcat9 restart
    Stopping tomcat9 ...       [ ok ]
    Starting tomcat9 ...       [ ok ]
    lxc-guacamole:~#
  • On peut sortir du container:
    lxc-guacamole:~# exit
    lxc-guacamole:~$ logout
    visto@wasabi:~ $ 

6.2. Bridge LXC

Nous allons (re)définir la connexion réseau de notre container lxc-guacamole (dont on vient de sortir) sur le bridge lxcbr0 avec la modification du fichier de configuration du container.

  • On peut en profiter pour nommer les groupes auxquels il appartient:
    visto@wasabi:~$ nano $(lxc-config lxc.lxcpath)/lxc-guacamole/config
    [ ... ]
    lxc.group = onboot
    lxc.group = webserver        ## c'est bien un service web 
    [ ... ]
    # Network configuration
    lxc.net.0.type = veth
    lxc.net.0.link = lxcbr0      ## <<== Décommenter
    #lxc.net.0.link = br0        ## <<== Commenter
    lxc.net.0.flags = up
    [ ... ]

    Ctrl+x et y pour enregistrer et sortir.

    Il faut maintenant arrêter le container et le relancer, pour prise en compte des changements:

    visto@wasabi:~$ lxc-stop -n lxc-guacamole
    visto@wasabi:~$ lxc-start -n lxc-guacamole
  • On peut constater que notre container est bien désormais sur le réseau LXC (adresse en '10.0.3.x ici), et que sa nouvelle adresse «interne» correspond bien à celle fixée au tout début:
    visto@wasabi:~$ lxc-ls -f
    NAME          STATE   AUTOSTART GROUPS            IPV4       IPV6 UNPRIVILEGED 
    lxc-gitea     RUNNING 1         onboot, webserver 10.0.3.52  -    true         
    lxc-guacamole RUNNING 1         onboot, webserver 10.0.3.151 -    true         
    [ ... ]
    lxc-proxy     RUNNING 1         onboot, webserver 10.0.3.50  -    true         
    [ ... ]

6.3. Reverse proxy

Il s'agit de définir le routage des flux à destination du service Guacamole vers le container éponyme. On va donc intervenir dans le container reverse proxy lxc-proxy. On va y définir un nouvel «hôte virtuel» par l’intermédiaire d'un nouveau fichier de configuration Nginx.

  • On se connecte au CT lxc-proxy depuis le serveur:
    visto@wasabi:~$ ssh admin@lxc-proxy
  • On augmente nos privilèges pour modifier notre configuration:
    lxc-proxy:~$ sudo -i
    [sudo] password for admin:
  • On créé notre vhost avec:
    lxc-proxy:~# nano /etc/nginx/http.d/guac.wasabi.conf
  • On y copie ces lignes:
    server {
        listen                     80;
        server_name                guac.wasabi;
        include                    includes/redirect_https.inc;
    }
    
    server {
        listen                     443 ssl http2;
        server_name                guac.wasabi;
        ssl_certificate            /etc/nginx/nginx-selfsigned.crt;
        ssl_certificate_key        /etc/nginx/nginx-selfsigned.key;
    
        access_log /var/log/nginx/guac.wasabi.access.log customiZeMe;
        error_log /var/log/nginx/guac.wasabi.error.log;
    
        location / {
            proxy_buffering off;
            proxy_http_version 1.1;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $http_connection;
            access_log off;
            client_max_body_size 1g;
            proxy_pass http://lxc-guacamole:8080;
        }
    
    }

    Ctrl+x et y pour enregistrer et sortir.

  • Pour prise en compte:
    lxc-proxy:~# nginx -s reload
  • On peut sortir:
    lxc-proxy:~# exit
    lxc-proxy:~$ logout
    visto@wasabi:~$ 

Et quand on a tout fini, on s'assure que ça marche, é pis woula: https://guac.wasabi/guacamole/ (il faudra accepter les risque d'un certificat auto-signé)


services/web/tuto/guac_tuto1.txt · Dernière modification : 13/03/2022 10:26 de Cram