Cet article fait suite à l'article de la semaine dernière indiquant comment installer Libervia en moins de 10 min. Nous allons voir aujourd'hui comment utiliser un certificat TLS existant, intégrer le conteneur dans une configuration Apache, ou lancer automatiquement le service au démarrage de la machine.
Utiliser votre certificat TLS existant
Au premier lancement des conteneurs, un certificat auto-signé est automatiquement créé pour pouvoir utiliser Prosody ou le serveur HTTPS de Libervia. Ce genre de certificat est très bien pour du test, mais d'une part provoquera un avertissement dans les navigateurs, et d'autre part son authenticité n'est assurée par aucun organisme (les certificats TLS sont signés par des organismes que votre navigateur et/ou système connaissent, ce qui permet de les valider – principe qui n'est pas idéal, mais c'est un autre sujet –).
Pour utiliser votre propre certificat plutôt que celui généré par les conteneurs, il faut utiliser la variable d’environnement SAT_CONT_TLS_DIR avec un chemin absolu vers vos certificats.
Il faut qu'à l'intérieur de ce dossier se trouvent les fichiers « libervia.key » pour votre clef privée, et « libervia.crt » pour votre certificat public. Ces noms de fichiers sont fixés car déjà configurés dans Libervia et Prosody, si vous voulez les changer il faudra changer les 2 configurations à l'aide de ./libervia_cont.sh config et ./libervia_cont.sh config prosody, comme indiqué dans le dernier article.
Au niveau des permissions des certificats, vous pouvez les laisser accessibles uniquement au « group ID » 9999 qui correspond au groupe « tls-cert » sur les conteneurs.
Let's Encrypt
Comme Let's Encrypt est (à juste titre) à la mode, voyons voir de plus près ce cas particulier.
Le but ici est de ne pas avoir à changer la configuration à chaque renouvellement, qui ont lieu au plus tard tous les 3 mois. Let's Encrypt met ses certificats (par défaut, adaptez au besoin) dans /etc/letsencrypt/archive/<votre_nom_de_domaine>, mais les noms de fichiers changent à chaque renouvellement, et met un lien symbolique vers les certificats en cours dans /etc/letsencrypt/live/<votre_nom_de_domaine>.
Vous ne pouvez pas utiliser directement /etc/letsencrypt/live/ car vous auriez des liens symboliques pointant dans le vide, il va falloir monter le dossier archive également.
La variable d'environement SAT_CONT_DK_EXTRA permet de spécifier des paramètres pour la commande « docker run » qui seront utilisés pour tous les conteneurs (sauf sat_data). Nous allons l'utiliser pour monter toute l'arborescence letsencrypt, comme suit :
export SAT_CONT_DK_EXTRA="-v /etc/letsencrypt:/etc/letsencrypt"
Il va falloir éditer les configurations de Libervia et Prosody pour pointer vers les bons fichiers.
Pour Libervia, utilisez ./libervia_cont.sh config puis spécifiez dans la section [libervia] :
[libervia]
tls_private_key = /etc/letsencrypt/live/<nom_domaine>/privkey.pem
tls_certificate = /etc/letsencrypt/live/<nom_domaine>/cert.pem
tls_chain = /etc/letsencrypt/live/<nom_domaine>/chain.pem
N'oubliez pas l'option tls_chain qui permet de spécifier la chaîne de validation.
Pour prosody, c'est ./libervia_cont.sh config prosody qu'il faut utiliser, vous devez avoir modifié votre option ssl pour qu'elle ressemble à :
ssl = {
key = "/etc/letsencrypt/live/<nom_domaine>/privkey.pem";
certificate = "/etc/letsencrypt/live/<nom_domaine>/fullchain.pem";
}
dans les 2 cas il faut bien évidemment remplacer <nom_domaine> par votre nom de domaine tel qu'il apparaît dans /etc/letsencrypt/live. Assurez vous aussi que les permissions sont correctes, vous verrez si Prosody ou Libervia n'arrivent pas à lire les fichiers à l'aide de docker logs -f prosody et docker logs -f libervia respectivement.
Intégration à un serveur Apache
Si vous avez déjà un serveur Apache qui tourne, vous préfèrez sans doute intégrer Libervia à la configuration existante plutôt que sur un port séparé.
Pour cela nous allons utiliser un « proxy inverse » (reverse proxy) qui va rediriger une adresse de votre domaine sur le serveur de Libervia.
Si vous avez une configuration HTTPS, elle sera gérée par Apache lui-même, donc commençons par désactiver le serveur HTTPS de Libervia, et par supprimer le message d'avertissement en cas de connexion HTTP. Éditez sat.conf à l'aide de ./libervia_cont.sh config, et mettez ceci dans la section [libervia] :
[libervia]
connection_type = http
security_warning = 0
Désormais seul le port HTTP sera disponible.
Maintenant, nous allons configurer apache pour qu'il redirige les URL correspondant à votre instance de Libervia vers le serveur. Dans le répertoire /etc/apache2/mods-available/ créez un fichier libervia.conf qui ressemble à peu près à ça :
<VirtualHost *:80>
ServerName www.<votre-serveur.tld>
ServerAlias <votre-serveur.tld> libervia.<votre-serveur.tld>
ServerAdmin webmaster@votre-server.tld
ErrorLog /var/log/apache2/libervia-error.log
CustomLog /var/log/apache2/libervia-access.log
ProxyPass / http://127.0.0.1:8080/ nocanon
ProxyPassReverse / 127.0.0.1
AllowEncodedSlashes On
RequestHeader set X-Forwarded-Proto "http"
<proxy *>
Require all granted
</proxy>
</VirtualHost>
Il faut bien entendu remplacer <votre-serveur.tld> par votre nom de domaine, adapter SeverName et ServerAlias à ce que vous souhaitez utiliser, ainsi que les ports pour qu'ils correspondent à ceux que vous utilisez en pratique (si vous avez tout laissé par défaut, les ports indiqués sont valables).
Quelques explications sur la configuration : Passons sur les premières lignes et VirtualHost qui sont des classiques de configuration Apache, vous trouverez les informations nécessaires facilement sur le web au besoin. Les directives qui nous intéressent ici sont à partir de ProxyPass.
- ProxyPass indique à Apache de rediriger les connexions sur le serveur local au port 8080, soit l'instance en cours de Libervia. Notez bien le « nocanon » qui est très important, il indique à Apache de ne pas utiliser des adresses canoniques, soit en d'autres terme de ne pas modifier les URLs envoyées à Libervia.
- ProxyPassReverse concerne les redirections
- AllowEncodedSlashes est nécessaire pour accepter les URLs contenant des « / » (%2F), qui sont utilisées dans Libervia.
- RequestHeader permet d'ajouter l'en-tête « X-Forwarded-Proto » indiquant à Libervia le protocol utilisé au niveau du proxy
Quand un proxy est utilisé, l'adresse utilisée « vue » de l'extérieur (http(s)://www.<votre-serveur.tld>/[…]) n'est pas la même que celle utilisée pour accéder par Libervia, qui est ici http://127.0.0.1:8080. Or Libervia a besoin de connaître cette adresse pour construire des chemins absolus vers les documents, par exemple dans le flux Atom.
Normalement, ceci est fait automatiquement et vous n'avez besoin de toucher à rien pour que Libervia utilise les bonnes URL ; mais si jamais les URL produites n'étaient pas correctes, vous pourriez utiliser l'option « base_url_ext » pour forcer l'utilisation de la base indiquée. Ainsi pour forcer l'utilisation de http://www.goffi.org, je peux indiquer ceci dans ma configuration Libervia :
base_url_ext = http://www.goffi.org
Ou même « //www.goffi.org » pour laisser Libervia gérer le schema (c.-à-d. le protocol : http ou https). Encore une fois tout ceci devrait être géré automatiquement (*), et il est très peu probable que vous ayez à utiliser cette option. Venez me contacter sur sat@chat.jabberfr.org pour plus d'explications si nécessaire.
Une fois la configuration faite, il vous suffit pour activer le proxy de demander à Apache de prendre en compte la nouvelle configuration. Nous allons également nous assurer que le mode proxy_http est activé, aussi nous allons utiliser les commandes suivantes (en root) :
# a2enmod headers
# a2enmod proxy_http
# a2ensite libervia.cont
# systemctl reload apache2
(*) si vous avez téléchargé les images la dernière fois, ce comportement a été modifié depuis, c'est l'occasion de tester « ./libervia_cont.sh update ».
Utilisation d'un cache
Apache a des modules permettant la gestion d'un cache, qui permettra à la fois d'économiser les ressources, et de fournir la dernière page connue en cas d'indisponibilité du serveur (lors d'une maintenance par exemple). Dans le cas de Libervia, c'est principalement utile pour le blog statique.
Assurez-vous d'abord que le cache est activé à l'aide de :
# a2enmod cache_disk
qui activera à la fois les modules cache et cache_disk. Ensuite à l'intérieur de la configuration du VirtualHost que nous avons faites plus haut :
<IfModule mod_cache_disk.c>
CacheEnable disk /
CacheRoot "/var/cache/apache2/mod_cache_disk/libervia/"
CacheDirLevels 3
CacheDirLength 5
CacheIgnoreHeaders Set-Cookie
CacheMaxFileSize 200000000
CacheIgnoreNoLastMod On
CacheDefaultExpire 300
</IfModule>
Vous pourrez vous reporter à la documentation pour la plupart des directives utilisées ici, mais il est nécessaire d’en préciser quelques-unes :
- CacheIgnoreHeaders Set-Cookie évitera de mettre en cache les cookies qui sont utilisés pour la session dynamique de Libervia, cette directive est essentielle pour la sécurité
- CacheIgnoreNoLastMod On permet de mettre en cache des documents qui ne possèdent pas de date de dernière modification, ce qui est le cas actuellement des pages servies par Libervia
- CacheDefaultExpire indique un cache qui expire après 10 min. Libervia ne gère pas (encore) les indications nécessaires à une gestion automatique du cache, aussi on indique ici la durée voulue. Le cache étant essentiellement utilisé pour le blog statique, j'ai mis 10 min pour qu'une mise à jour apparaîsse suffisament vite.
À moins d'avoir un site extrêmement populaire, il ne devrait pas y avoir de problème de performance pour le blog statique même sans cache, il est à mon sens surtout utile ici pour continuer à servir les pages pendant les maintenances.
Utilisation de tls
L'utilisation de TLS n'est pas plus compliquée que pour un autre site Apache.
Voici à quoi peut ressembler une configuration si vous activez le proxy, le chiffrement TLS, et un cache :
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName www.<votre_site.tld>
ServerAlias <votre_site.tld> libervia.<votre_site.tld>
ServerAdmin webmaster@<votre_site.tld>
LogFormat "h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\" %{cache-status}e" with_cache
ErrorLog /var/log/apache2/libervia-error.log
CustomLog /var/log/apache2/libervia-access.log with_cache
ProxyPass / http://127.0.0.1:8080/ nocanon
ProxyPassReverse / http://127.0.0.1:8080/
AllowEncodedSlashes On
<proxy *>
Require all granted
</proxy>
SSLCertificateFile /etc/letsencrypt/live/<votre_site.tld>/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/<votre_site.tld>/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/<votre_site.tld>/chain.pem
<IfModule mod_cache_disk.c>
CacheEnable disk /
CacheRoot "/var/cache/apache2/mod_cache_disk/libervia/"
CacheDirLevels 3
CacheDirLength 5
CacheIgnoreHeaders Set-Cookie
CacheMaxFileSize 200000000
CacheIgnoreNoLastMod On
CacheDefaultExpire 300
</IfModule>
</VirtualHost>
</IfModule>
Notez que le « RequestHeader set X-Forwarded-Proto » a désormais la valeur "https" ainsi que le « with_cache » dans les logs, ajoutant des informations utiles (est-ce que la page est servie par le cache ou Libervia ?).
Pour le reste, reportez-vous à la documentation Apache.
Démarrage automatique
Dernier point de cette partie sur la configuration avancée, nous allons voir comment lancer automatiquement notre instance de Libervia au démarrage de la machine. Nous allons pour cela utiliser SystemD qui est désormais le gestionnaire de démarrage par défaut de la plupart des distributions, donc probablement de la vôtre.
Il vous suffit d'utiliser une configuration similaire à la suivante, dans un fichier libervia.service à placer dans /etc/systemd/system :
[Unit]
Description=Libervia (Salut à Toi) XMPP Docker service
After=docker.service
Requires=docker.service
[Service]
User=libervia
Environment= \
SAT_CONT_DOMAIN=votre_domain.tld \
SAT_CONT_PORT_8080=8000
ExecStartPre=/home/goffi/dev/sat_docs/docker/libervia_cont.sh start -p
ExecStart=/usr/bin/docker wait libervia
ExecStop=/home/goffi/dev/sat_docs/docker/libervia_cont.sh stop
[Install]
WantedBy=multi-user.target
Ce fichier indique que le containeur doit attendre que Docker soit lancé. L'utilisateur ici est libervia, changez-le pour celui que vous avez ajouté au groupe « docker ».
Environment vous permet de configurer les options comme le port ou le nom de domaine utilisé, notez bien le "\" en fin de ligne (dernier caractère avant le retour à la ligne, sans espace) qui indique de considérer la ligne suivante comme la suite de la commande.
Le serveur est en fait lancé avec la directive ExecStartPre, afin de pouvoir connaître sont état avec « docker wait ». C'est une petite astuce qui évite des complications, car les conteneurs sont lancés par le démon Docker et non le script lui-même.
À suivre…
Voilà pour cette seconde partie de la série sur l'installation d'un blog Libervia. Ce n'était pas la partie la plus amusante, mais vous n'avez a priori à faire cette configuration qu'une seule fois, et elle n'est pas si compliquée que cela.
La prochaine fois nous importerons un blog depuis Dotclear.