Weblate est une plateforme de traduction. Khaganat dispose de sa propre instance accessible depuis l'adresse https://locale.khaganat.net/.

Weblate utilise le framework Django et PostgreSQL comme base de données. Il existe plusieurs manières de déployer une application Django, ici nous utiliserons nginx et uWsgi. Nginx est le serveur web de base, c'est lui qui accepte les requêtes HTTP. Son rôle est, d'un côté, de servir les fichiers statiques présents dans un dossier (images, CSS, etc) et, de l'autre, de faire appel à uWsgi pour l'application en elle-même. Tout comme nginx, uWsgi est un démon qu'il convient de lancer. Son rôle est d'exécuter des applications web présentant une interface standard, comme par exemple Django. Bien que uWsgi soit capable de gérer lui-même des requêtes HTTP, nous n'utiliserons pas cette option car elle n'est pas suffisante : en effet, uWsgi n'est pas capable d'aller chercher les ressources statiques et notre application web n'aurait donc ni image ni feuilles de styles.

nginx
├── ressources statiques
└── uWsgi
    └── Django
        └── PostgreSQL

Cette page n'a pas vocation à traiter de la mise en place d'un serveur PostgreSQL ni de la gestion des bases de données, utilisatrices et permissions sur ce serveur.

Tout d'abord, assurons-nous que les paquets python3 et pipenv sont bien installés.

Ensuite, la liste des dépendances spécifiques à Weblate est disponible dans sa documentation. Notez qu'à cela il faut ajouter le paquet libacl1-dev.

Enfin, pour notre déploiement, nous installons les paquets nginx-full, uwsgi et uwsgi-plugin-python3. Vérifions également que nous disposons d'un serveur PostgreSQL accessible avec un utilisateur et et une base de données dédiée. Assurons-nous également que le reverse-proxy redirige correctement les requêtes HTTP sur l'adresse et le port prévus.

Afin d'installer Weblate en elle-même, il nous faut commencer par choisir un dossier dans lequel réaliser l'installation. Sur Jukni3, c'est /home/khaganat/weblate.

Installons Weblate ainsi que la bibliothèque permettant d'utiliser PostgreSQL :

pipenv --three install Weblate psycopg2-binary

Cette commande créé deux fichiers, Pipfile et Pipfile.lock. Notez que la version de python est inscrite dans Pipfile et qu'il est possible de l'enlever afin de simplifier les mises à jour futures de Python.

En plus de ces deux fichiers, pipenv a créé un environnement virtuel dans un dossier spécifique. Bien entendu , nous aurons besoin de ce chemin pour configurer nginx, uWsgi et Weblate. Or, ce chemin est susceptible de changer lors de la mise à jour de Python et, de plus, doit pouvoir être détruit et reconstruit de zéro. Afin de ne pas avoir besoin de modifier sans cesse la configuration, nous allons créer deux liens symboliques qui pointeront vers ce dossier. Ainsi, si nous détruisons cet environnement virtuel, nous aurons simplement besoin de mettre à jour ces liens.

ln -s "$(pipenv --venv)" weblate-venv
ln -s "$(pipenv --venv)/lib/$(pipenv run python -c 'import sys; print(f"python{sys.version_info.major}.{sys.version_info.minor}")')/site-packages/weblate" weblate-src

Nous avons donc maintenant weblate-venv et weblate-srv qui pointent respectivement vers la racine de l'environnement virtuel et l’installation de Weblate dans cet environnement virtuel. Si cet environnement virtuel venait à changer, il faudrait alors supprimer cet deux liens symboliques et les recréer.

Configurons maintenant Weblate. Pour ce faire, il faut créer un fichier dans l'environnement virtuel. Comme nous avons vu que les environnements virtuels sont jetables, nous n'allons pas le créer directement dedans mais dans notre dossier de travail et utiliser à nouveau l'astuce des liens symboliques, mais dans l'autre sens.

cp weblate-src/settings_example.py settings.py
ln -s "$(pwd)/settings.py" weblate-src/settings.py

Nous avons donc maintenant le fichier settings.py servant à configurer Weblate. Dans l'environnement virtuel, un lien symbolique pointe dessus. Nous pouvons désormais configurer Weblate en modifiant les options à notre guise, en particulier les suivantes :

• DEBUG doit etre mis à False
• SECRET_KEY doit etre mis à une valeur génée par la commande pipenv run python -c 'from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())'
• ALLOWED_HOSTS doit etre mis à [“locale.khaganat.net”]
• Dans DATABASES il faut indiquer l'adresse du serveur PostgreSQL, le nom de la base de données, le nom d'utilisateur et le mot de passe associé.
• La liste ADMINS doit contenir (“Khaganat”, “contact@khaganat.net”), (ce n'est pas un compte utilisateur !)
• DATA_DIR doit etre mis à “/home/khaganat/weblate/data”
• DEFAULT_FROM_EMAIL et SERVER_EMAIL doit etre mis à weblate@khaganat.net ou similaire
• Toujours pour les emails, il peut être utile de spécifier EMAIL_HOST et les variables qui suivent.

Pour connaître l'ensemble des directives de configuration qu'il est possible de définir, rendez-vous dans la documentation de Django ainsi que dans celle de Weblate.

Nous n'oublions pas de créer un dossier data qui, comme indiqué dans la configuration, stockera tous nos fichiers statiques :

mkdir -p data/media
mkdir -p data/static

Maintenant que tout est prêt, nous pouvons créer la base de données :

pipenv run weblate migrate

Nous pouvons maintenant collecter les fichiers statiques afin de remplir le dossier correspondant :

pipenv run weblate collectstatic

Afin de tester que tout fonctionne, nous pouvons lancer le serveur de debug et accéder à l'URL :

pipenv run weblate runserver 0.0.0.0:8000

Enfin, si tout fonctionne, nous pouvons créer un compte administratrice sur Weblate :

pipenv run weblate createadmin

pipenv run weblate createadmin --update

Pour une raison inconnue, Debian n'inclue pas de fichiers de service uWsgi avec le paquet. Nous allons donc créer nous-meme le fichier /etc/systemd/system/uwsgi-socket@.service :

[Unit]
Description=uWSGI service unit
After=syslog.target

[Service]
ExecStart=/usr/bin/uwsgi --ini /etc/uwsgi/%I.ini
ExecReload=/bin/kill -HUP $MAINPID
ExecStop=/bin/kill -INT $MAINPID
Type=notify
SuccessExitStatus=15 17 29 30
StandardError=syslog
NotifyAccess=all
KillSignal=SIGQUIT

[Install]
WantedBy=multi-user.target

Ce fichier de service nous permet de lancer différents services uWsgi avec des configurations spécifiques. Pour ce faire, nous créons un fichier /etc/uwsgi/weblate.ini :

[uwsgi]
uid=khaganat
gid=khaganat
virtualenv=/home/khaganat/weblate/weblate-venv
wsgi-file=/home/khaganat/weblate/weblate-src/wsgi.py
buffer-size=8192
close-on-exec=True
enable-threads=True
master=True
max-requests=5000
pidfile=/tmp/weblate.pid
plugins=python3
protocol=uwsgi
reload-on-rss=250
socket=127.0.0.1:8000
vacuum=True

Nous pouvons activer et lancer le service correspondant :

systemctl enable --now uwsgi-socket@weblate.service

Créons le fichier /etc/nginx/sites-available/weblate.conf :

server {
        listen 192.168.20.39:8000 default_server;
        server_name locale.khaganat.net;

        root /var/www/html;

        location /static/ {
                alias /home/khaganat/weblate/data/static/;
        }

        location /media/ {
                alias /home/khaganat/weblate/data/media/;
        }

        location / {
                include uwsgi_params;
                uwsgi_read_timeout 3600;
                uwsgi_pass 127.0.0.1:8000;
        }
}

Dans le dossier /etc/nginx/sites-enabled, créons un lien symbolique vers ce fichier afin de l'activer :

ln -s /etc/nginx/sites-available/weblate.conf /etc/nginx/sites-enabled/weblate.conf

Si besoin, désactivons le site par défaut :

rm /etc/nginx/sites-enabled/default

Enfin, redémarons nginx :

systemctl restart nginx.service

En cas de mise à jour de Weblate et/ou de Python, il faut l'appliquer sur l'environnement virtuel. Une mise à jour de Python rendant généralement ce dernier inutilisable en l'état, la méthode Léodagan est alors recommandée : tout cramer pour repartir sur des bases saines. C'est pour cela que, lors de l'installation, nous avons bien fait attention à différencier :

• l'environnement virtuel considéré comme jetable
• la configuration qui est dans un dossier spécifique
• les fichiers statiques qui sont également dans un dossier spécifique

Et je n'ose pas préciser la base de données qui est, comme tout le monde le sait, un élément totalement à part avec son propre logiciel.

Bref, commençons par arreter uWsgi :

systemctl stop uwsgi-socket@weblate.service

Ensuite, la mise à jour « virile » du virtualenv :

pipenv --rm
pipenv --three install

Comme vu lors de l'installation, il nous faut recréer quelques liens symboliques. Là encore, on détruit pour reconstruire :

rm -f weblate-venv weblate-src
ln -s "$(pipenv --venv)" weblate-venv
ln -s "$(pipenv --venv)/lib/$(pipenv run python -c 'import sys; print(f"python{sys.version_info.major}.{sys.version_info.minor}")')/site-packages/weblate" weblate-src
ln -s "$(pwd)/settings.py" weblate-src/settings.py

Maintenant que la mise à jour est effectuée, nous pouvons relancer uWsgi :

systemctl start uwsgi-socket@weblate.service

Afin de permettre à Weblate de communiquer avec notre gitlab, il faut tout d'abord installer un programme externe : lab. Ce paquet devrait arriver prochainement sur Debian sous le nom de git-lab.

Une fois lab installé, il faut créer la configuration dédiée dans le dossier des fichiers statiques. La documentation de Weblate détaille la base de cette procédure. Il devrait y avoir une option pour spécifier une instance de GitLab autre que l'instance officielle.

Il ne reste plus qu'à actualiser la valeur de GITLAB_USERNAME dans la configuration de Weblate (settings.py).