Avant c’était pas si mieux

Combien de fois en voulant installer un logiciel quelconque sur une machine debian, je suis tomber sur une instruction du genre: curl https://www.closeyoureye.org/random_script.sh | bash

La seule attitude décente face à une telle ligne de commande est de:

1. lever les yeux au ciel;
2. télécharger le script random dont l’url est fournie;
3. ouvrir le script téléchargé avec son éditeur préféré;
4. extraire les instructions qui concernent notre distribution;
5. les exécuter manuellement, ou depuis un nouveau script.

La découverte

Et puis un jour, en voulant installer une alternative à Firefox, je tombe sur autre chose. Cette fois-ci les instructions sont:

sudo apt update && sudo apt install extrepo -y
sudo extrepo enable librewolf
sudo apt update && sudo apt install librewolf -y

Comme son nom l’indique, extrepo est un paquet debian qui permet d’ajouter facilement des dépôts extérieurs. Les dépôts pris en charge par cet outil sont gérés dans un répertoire git dédié. On peut y voir la liste des logiciels rendus ainsi disponibles. En voici un petit extrait appétissant:

• Crowdsec
• Docker
• Fai
• HAProxy
• Kubernetes
• Nodejs
• Postgresql
• Signal
• Wine HQ

Avant de commencer il vous faudra peut-être jouer avec la configuration du logiciel dans /etc/extrepo/config.yaml pour viser la bonne version de debian et éventuellement ajouter les dépôts contrib ou non-free. Vous pourrez aussi installer extrepo-offline-data pour éviter des requêtes web à chaque utilisation de l’outil.

Les deux commandes principales à connaître sont extrepo search et extrepo enable.

En guise de conclusion j’espère juste que le répertoire git contenant la liste des dépôts et leurs clefs publiques est surveillé comme du petit lait sur le feu par les équipes debian. La sécurité de bien des serveurs en ligne est dépend.

Nouveaux serveurs à gérer

Je viens de récupérer plusieurs machines à gérer. Je n’ai qu’un accès ssh à chaque machine, et une description sommaire de son rôle. Hors j’aimerais savoir rapidement de quoi est capable chaque serveur:

• combien a-t-il de RAM?
• les partitions,
• l’espace disponible sur les disques,
• le nombre de processeurs,
• etc.

L’outil

Après quelques recherches je suis tombé sur l’outil magique qui fait tout ça: inxi. Écris en perl, inxi va récupérer toutes les informations dans l’arborescence /proc/ et /dev/ pour nous présenter une synthèse lisible par nous, pauvres humains.

Pour mes serveurs, je l’utilise avec les options -C -D -j -m -p -S -n -o -R

inxi -C -D -j -m -p -S -n -o -R

Mais il existe d’autres options pour afficher à peu près tout: les besoins ne sont pas les même pour un desktop et pour un serveur.

L’avantage qu’il soit écrit en perl, c’est qu’on peut simplement copier l’exécutable sur un serveur et le lancer ensuite directement, sans avoir à installer tout le paquet.

Besoin de tunnel

La dernière mode chez les développeurs, c’est d’exposer publiquement son environnement local, généralement une application web en cours d’écriture. De mon côté, il m’a été demandé de travailler sur un système de paiement dont la configuration nécessitait que ma machine de développement soit accessible au service de paiement.

Il m’a été proposé d’utiliser les tunnels Cloudflare, ou bien d’installer ngrok. Mais ces deux solutions, ainsi que leurs multiples alternatives, me semblaient «/overkill/» pour mon simple besoin. J’ai donc préféré m’amuser à implémenter une solution plus modeste et sur mesure, que je vais présenter ci-après.

Solution maison

Je contrôle déjà un serveur web qui est accessible publiquement sur internet. C’est le serveur web qui héberge le blog sur lequel vous êtes certainement en train de lire cet article. Mon objectif va être d’utiliser ce serveur comme proxy web sur un nom de domaine dédié, qui transmettra toutes les requêtes vers mon serveur de développement, qui lui tournera sur mon portable dans des containers configurés avec docker-compose.

Configuration DNS

La première étape consiste donc à faire pointer le nom de domaine sous lequel on veut rendre accessible notre environnement de développement vers ce serveur.

Par convention je vais utiliser les noms suivants:

• my-web-server.net: le nom de domaine de mon serveur web public;
• dev1.devs.my-web-server.net: le nom de domaine sous lequel l’environnement de développement sera accessible.

L’enregistrement DNS à créer ressemblera à quelque chose comme: *.devs.my-web-server.net CNAME my-web-server.net

Configuration Caddy

Mon serveur web utilise Caddy. Ici je vais utiliser deux fonctionnalités de cet outil particulièrement pratiques:

1. en déclarant un nom de domaine ouvert sur le port 443, Caddy récupère automatiquement le certificat Letsencrypt!
2. Un reverse proxy se configure en une seule ligne.

La section de ma configuration Caddy dédiée au tunnel ressemble à ceci:

dev1.devs.my-web-server.net:80,
dev1.devs.my-web-server.net:443 {
    log {
        output file /var/log/caddy/dev1-devs.log
    }
    reverse_proxy {
        to 127.0.0.1:8888
   }
}

Configuration Docker avec le certificat

Lorsque mon application web sera accessible depuis l’extérieur, Caddy va utiliser le certificat généré par Letsencrypt pour sécuriser la connexion. Mais lorsque j’accède à cette même application en local depuis mon portable, c’est au serveur web qui tourne dans Docker de s’en occuper. Pour cela ce serveur a aussi besoin des fichiers du certificat.

Ces fichiers (la clé publique et la clé privée) se trouvent dans le sous répertoire dev1.devs.my-web-server.net du répertoire /var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/ Il faut les copier en local, puis les insérer dans le container qui fera tourner le serveur web.

Dans le Dockerfile du serveur web on trouvera donc quelque chose qui ressemble à:

COPY certs/dev1.devs.my-web-server.net.crt /usr/local/apache2/conf/dev1.devs.my-web-server.net.crt
COPY certs/dev1.devs.my-web-server.net.key /usr/local/apache2/conf/dev1.devs.my-web-server.net.key

Dans mon cas particulier l’application en local est servie par un serveur apache. La configuration de ce serveur ressemble à ceci:

<VirtualHost _default_:443>
    DocumentRoot "/var/www/my-app/"
    ServerName dev1.devs.my-web-server.net

    SSLEngine on
    <Directory "/var/www/my-app/">
        AllowOverride All
        Require all granted
    </Directory>

    SSLCertificateFile "/usr/local/apache2/conf/dev1.devs.my-web-server.net.crt"
    SSLCertificateKeyFile "/usr/local/apache2/conf/dev1.devs.my-web-server.net.key"
    Protocols h2 http/1.1
</VirtualHost>

Modification du fichier /etc/hosts

Pour pouvoir travailler localement, sans passer par le proxy, il faut associer l’adresse IP du container apache au nom de domaine dev1.devs.my-web-server.net. On récupère cette adresse avec la commande suivante:

docker inspect \
     --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' \
    $(docker compose ps -q apache)

Connexion ssh

La dernière étape consiste à créer le tunnel, avec SSH, entre notre machine locale et le serveur web:

ssh -R 8888:127.0.0.1:8351 my-web-server.net

Ici on a:

• 8351 le port ouvert de notre serveur web dans votre docker-compose;
• 8888 le port qui est dans la configuration reverse proxy de Caddy.

Et voilà!

Aller plus loin

Il ne semble pas trop difficile de bricoler une solution qui automatise un peu toutes ces étapes. D’ailleurs c’est pour cela que j’ai déclaré le domaine *.devs.my-web-server.net dans ma configuration dns, au lieu de dev1.my-web-server.net. Ainsi je peux ajouter plus facilement d’autres domaines sans modifier mon serveur DNS. Je n’aurais ensuite que les modifications de la configuration Caddy et de docker à programmer. Pour le moment, avec un seul environnement à rendre accessible, je n‘ai pas besoin d’automatiser plus.

Post Scriptum

Après avoir écrit cet article, je découvre un projet qui met en œuvre exactement le même procédé que moi, avec un début d’automatisation.