Blog de Chapoline

Infrastructure, 3ème itération

2024-09-18T00:00:00+00:00

Je viens de mettre en production la 3ème itération de mon infrastructure personnelle, et j’en profite pour présenter ici un résumé des itérations précédentes, ainsi que de décrire son état actuel.

Première itération : 2020-2023

J’ai commencé à héberger mes propres services en avril 2020, pendant le premier confinement. J’avais à l’époque décidé d’acheter un nom de domaine et d’héberger une stack mail, en suivant le célèbre tutoriel de workaround.org, le tout sur le VPS OVH le moins cher possible (Didi).

J’ai ajouté en mars 2022 un deuxième VPS, Zii, celui-là chez Infomaniak, afin d’avoir un débit nettement plus élevé pour pouvoir m’en servir de serveur VPN, et d’avoir une ip de meilleure réputation (j’avais eu des problèmes avec Didi). Enfin, en octobre 2022, j’ai ajouté un troisième VPS, Izz, chez Contabo, avec pour intention de remplacer Zii. En effet, Infomaniak ne propose pas de contrôler le reverse DNS de l’ip de ses VPS, ce qui baissait la réputation des mails que j’envoyais. Elle me permettait également d’avoir beaucoup plus de stockage, pour un prix deux fois moins élevé. Elle n’a cependant jamais remplacé Zii.

Au fur et à mesure, j’ai ajouté plusieurs services sur ces serveurs : Dashy, bot Telegram, Icinga, Keycloak, et d’autres que j’oublie. Les 3 étaient reliées entre elles par un Wireguard, qui me servait également à faire sortir mon trafic par Zii en Suisse.

J’ai essayé au départ de gérer mon infrastructure avec Ansible, mais ce fut globalement un échec. Je n’arrivais pas à maintenir correctement les playbooks pour qu’ils continuent de correspondre à l’état réel des serveurs, et j’avais une tendance beaucoup trop grande à aller bidouiller dessus à la main pour résoudre les soucis. De plus, les 3 serveurs avaient des configurations assez hétérogènes, avec notamment Izz qui utilisait Traefik (dont je n’ai jamais vraiment été convaincue, mais que j’ai continué à utiliser dessus jusqu’au bout). Enfin, l’envie de jouer avec un serveur physique, et de pouvoir créer des VM ou des LXC à la demande sur un Proxmox, me faisait très envie.

Deuxième itération : 2023-2024

En février 2023, j’ai sauté le pas et j’ai acheté sur Leboncoin un Dell PowerEdge R710 (72Go de RAM, 2 CPU), Montreal, dans lequel j’ai mis 2 disques de 2To en RAID, et j’ai commencé à migrer mon infrastructure dessus. J’ai également pris un 4ème VPS, Amber, également chez Contabo, pour me servir d’ip externe, en la reliant avec un pont Wireguard vers mon infra.

                             +-----------+                          
                             |           |                          
                             |  Freebox  |                          
                             |           |                          
                             +-----+-----+            +------------+
                                   |                  |            |
                                   +------------------+  Montreal  |
                                   |                  |            |
                                   |                  +------------+
                                   |  192.168.1.0/24                
                                   |                  +------------+
                                   |                  |            |
                                   +------------------+  Laptops   |
                                   |                  |            |
+---------+                  +-----+-----+            +------------+
|         |        VPN       |           |                          
|  Amber  +------------------+  Gateway  |                          
|         |   172.31.0.0/24  |           |                          
+---------+                  +-----+-----+                          
                                   |                                
                                   |  10.255.0.0/24                 
                                   |                                
                             +-----+-----+                          
                             |           |                          
                             |  Servers  |                          
                             |           |                          
                             +-----------+                          

Le serveur gateway me servait de routeur, de DNS et de DHCP grace à dnsmasq. Afin d’éviter de faire du routage asymétrique, et de ne pas trop faire fuiter l’ip publique de ma Freebox, j’ai routé tout le trafic sortant des serveurs à travers le pont VPN. Mais parce que je ne voulais pas m’embêter à faire du source-based routing, j’ai simplement défini deux passerelles différentes pour mes deux réseaux : le réseau “client” utilisait la Freebox comme passerelle, et le réseau “serveur” le serveur gateway. Afin que les clients puisse quand même accéder aux serveurs, je poussais dessus une route statique en utilisant l’option 131 du protocol DHCP ; cependant, cette option n’est pas supportée par Android…

En terme d’automatisation d’infra, j’avais décidé d’utiliser une nouvelle approche, pour pallier aux soucis que j’avais eu avec Ansible sur l’itération précédente. Je suis partie d’un template LXC custom, généré grace à DAB, qui pré-installait et pré-configurait ce que j’aurais déployé par Ansible en tant que configuration initiale (paquets standard, mon compte et ma clé ssh…). Ensuite, je centralisais toutes mes configurations avec Stow dans un monorepo.

Sur chaque nouvelle machine, je commençais par cloner le monorepo à /usr/local/stow-files, puis créer dedans un dossier pour ma machine. Ensuite, je mettais tous les fichiers de configuration modifiés pour cette machine dans ce dossier, en respectant l’arborescence par rapport à /etc, pour pouvoir utiliser stow pour les déployer (ou plutôt, pour créer des liens symboliques aux bons endroits qui pointent vers ces fichiers). L’intérêt principal de cette approche était de pouvoir travailler sur les fichiers du serveur sans me poser de question au quotidien ; si j’avais besoin de rajouter une machine dans la configuration du DHCP, je modifiais directement /etc/dnsmasqs.d/leases.conf, qui était réellement /usr/local/stow-files/gateway/dnsmasq/dnsmasq.d/leases.conf. L’inconvénient était de n’avoir aucune visibilité sur si j’avais bien push toutes les machines…

Lors de cette itération, j’ai également commencé à m’intéresser à NixOS, que j’ai également utilisé sur mon PC principal pendant quelques mois. J’ai envisagé de me faire une infrastructure principalement basée dessus, pour au final rester sur une majorité de Debian. J’ai tout de même conservé quelques LXC sous NixOS, principalement pour gérer le reverse-proxy de mon infrastructure avec Nginx.

Enfin, l’infrastructure était monitorée grâce à une stack Grafana + Prometheus + Netdata, installé sur tous mes serveurs et LXC.

Malgré le but initial de ce serveur, qui était de remplacer tous mes VPS (sauf Amber), je ne les ai résiliées qu’en mai 2024, plus d’un an après la mise en production de Montreal.

Troisième itération : 2024-?

Le problème principal de ce serveur était très prévisible : il consomme beaucoup, et chauffe pas mal aussi (ou plutôt, devient très bruyant pour ne pas chauffer…). Pour réduire très fortement son bruit au repos, j’ai retiré dès le départ le contrôle automatique de la vitesse des ventilos, pour les mettre à 10% de leur vitesse maximale (contre 30% au minimum en automatique), ce qui suffisait largement à mes besoins. Mais en ayant retiré tout contrôle automatique de leur vitesse, je gardais un stress qu’il se mette à trop chauffer et à s’abimer, voire à abimer mon appartement… Et sa consommation était très loin d’être négligeable : 120W dans le BIOS, 150W avec mon infrastructure au repos (et facilement 180W avec une CI qui tournait), soit environ 35€/mois d’électricité… Soit le prix combiné de Zii, Didi et Izz.

J’ai donc décidé en août 2024 de le remplacer par un serveur monté moi-même, avec des composants de PC (plus de détails ici), Gandalf. J’en ai également profité pour acheter un routeur physique (un EdgeRouter X), Cirdan.

                             +-----------+                   
                             |           |                   
                             |  Freebox  |                   
                             |           |                   
                             +-----+-----+                   
                                   |                         
                                   |                         
                                   |                         
                                   |                         
                                   |  192.168.1.0/24         
                                   |   gw.chapo.li           
                                   |                         
                                   |                         
                                   |                         
+---------+                  +-----+-----+                   
|         |        VPN       |           |                   
|  Amber  +------------------+  Cirdan   |                   
|         |   172.31.0.0/24  |           |                   
+---------+    wg.chapo.li   +--+--+--+--+                   
                                |  |  |                      
                                |  |  |                      
                                |  |  |                      
                                |  |  |                      
                                |  |  |                      
                +---------------+  |  +---------------+      
                |                  |                  |      
                |                  |                  |      
          +-----+-----+      +-----+-----+      +-----+-----+
          |           |      |           |      |           |
          |  Clients  |      |  Hardware |      |  Servers  |
          |           |      |           |      |           |
          +-----------+      +-----------+      +-----------+
          10.255.1.0/24      10.255.2.0/24      10.255.3.0/24
         client.chapo.li      hw.chapo.li        vm.chapo.li 

Plutôt que d’utiliser un nom de domaine unique pour toutes mes ip (en .home), j’ai décidé d’utiliser un sous-domaine d’un domaine public par sous-réseau, ce qui me permet également de générer des certificats TLS valides.

EdgeOS me permet également d’enfin faire du source-based routing sans effort, ce qui me permet enfin d’avoir proprement uniquement les serveurs qui sortent par le VPN, tout en pouvant facilement définir des exceptions (par exemple, mon runner Forgejo n’utilise pas le VPN, à cause d’un soucis que je n’ai jamais réussi à comprendre avec le pull de dépendences Ruby…).

En terme de gestion de la configuration des serveurs, je suis revenue sur Ansible, avec des playbooks plus simples et plus standards qu’à l’époque de la première itération. Au lieu de chercher à ansibliser tous mes services, je n’ansiblise que les structures récurrentes (déploiement des utilisateurs, installation de docker, configuration de cerbot avec challenge DNS…), ainsi que quelques services plus complexes (comme la stack mail). Pour les autres services, qui sont généralement un docker-compose.yml et un éventuel fichier de configuration, ainsi que pour le routeur, j’utilise un simple script bash qui scp les fichiers pertinents, puis je git le résultat. Peu élégant, mais efficace.

#!/bin/bash

echo -e "[cirdan.hw.chapo.li]"
scp ubnt@cirdan.hw.chapo.li:/config/config.boot cirdan.hw.chapo.li/config.boot
...

Oui, ce repo contient beaucoup de secrets en clair. Oui, il est privé et protégé. Oui, ce n’est pas très propre…

Afin de gérer l’accès à mes services depuis l’extérieur, j’utilise deux serveurs : Amber, mon VPS externe, qui utilise un firewalld pour gérer un NAT Masquerade et le port-forward vers les machines pertinentes à travers un pont Wireguard vers Cirdan, et Dillon, mon reverse-proxy Nginx sous NixOS. C’est lui qui s’occupe de distribuer les requêtes vers les services pertinents, et de faire la terminaison TLS pour mes services externes.

Enfin, pour gérer les mises à jour des machines, j’utilise, en plus de unattended-upgrades, apt-dater.

Apt-dater est très peu disponible sur d’autres plateformes que Debian et ses dérivés, et n’est plus vraiment maintenu par d’autres personnes que les mainteneurs de Debian… Pro tip si vous voulez l’utiliser depuis un Arch par exemple, il tourne très bien dans un Docker !

Je suis pour l’instant très satisfaite de cette nouvelle itération, qui me parait beaucoup plus robuste et facile à maintenir que les précédentes. À voir sur la longueur !

Workflow de déploiement de mon blog avec Forgejo Actions

2024-09-08T00:00:00+00:00

Ce blog est un blog statique, construit à partir de Jekyll. Il peut donc être construit à l’avance, afin de générer des fichiers entièrement statiques, qui seront déployés sur un serveur web qui les servira sur internet. C’est donc une excellente occasion pour mettre en place une CI avec Forgejo Actions, afin d’automatiser le build de ce blog.

Je ne fais ici que de la CI, pas de CD (je ne déploie pas automatiquement sur mon serveur web), car j’utilise NixOS pour mon serveur web, et je préfère donc définir manuellement le commit exact du blog que je déploie.

Je travaille avec deux dépots de code : blog, qui contient les sources du blog, et blog-static, qui contient le résultat du build du blog (et qui est concrètement ce qui est servi par mon serveur web). La CI a donc pour but de récupérer les sources, compiler le blog, et push le résultat sur le deuxième dépot.

# .forgejo/workflows/main.yml

# We execute this workflow on each commit pushed
on:
  push:

jobs:
  build:
    runs-on: docker
    container:
      # the Checkout Action needs node to run
      image: node:bookworm

    steps:
      # First, clone the source repo
      - name: Clone repo
        uses: actions/checkout@v4

      # Then, clone the static repo on the build output path
      - name: Clone static repo
        uses: actions/checkout@v4
        with:
          repository: chapeau/blog-static
          path: _site
          # This repo needs a token because we will push on it later
          token: ${{ secrets.GH_PAT }}
          ref: main

      - name: Setup
        env:
          MAIL: ${{ secrets.MAIL }}
        shell: bash
        run: |
          # Install some dependencies for the blog
          apt update
          apt install -y bundler git apt-utils

          # This configuration is mandatory to make commits
          git config --global user.email "$MAIL"
          git config --global user.name "CI Builder"
          
          # Install ruby dependencies
          bundle install

          # Build the blog
          bundle exec jekyll build
          
          # Commit and push
          cd _site
          git add --all
          git commit -m "Build"
          git push -u origin main     

Pour utiliser ce workflow, deux choses sont nécessaires : un runner Forgejo bien sur, et quelques secrets.

J’utilise un simple runner docker, installé en suivant la documentation officielle.

Les secrets se définissent dans l’interface web de Forgejo, pour le projet, dans Paramètres -> Actions -> Secrets. Deux sont nécessaires pour ce workflow : MAIL, qui contient simplement l’adresse mail utilisée pour les commits, et GH_PAT, qui contient un token d’authentification associé à votre compte, avec des droits d’accès en écriture sur les dépots. Pour le générer, allez dans Configuration -> Applications.

Remplacer la conversation Whatsapp familiale par un serveur XMPP

2024-08-28T00:00:00+00:00

Tout le monde aujourd’hui a, dans sa famille, une conversation Whatsapp/Telegram/Messenger/autre, en remplacement des SMS de la décennie précédente. Mais avec l’enshitification ambiante d’Internet, il devient de plus en plus essentiel d’avoir des options pour rester en contact avec ses proches sans passer par des applications propriétaires peu respectueuses de la vie privée. XMPP est une excellente solution à ça, et en installer un serveur est un projet sympathique et assez facile.

XMPP est un protocol décentralisé d’échange de données en temps réel. Plus simplement, c’est un très bon protocol pour construire des systèmes fédérés de discussion instantannée, ce qui est exactement ce que l’on va faire. Le protocol est défini via quelques RFC, et définit également des extensions à travers des XEP. Plusieurs de ces XEP sont aujourd’hui très standard et sont installées et activées par défaut (comme la XEP-0012). Enfin, XMPP propose aujourd’hui du chiffrement bout-en-bout mature et automatique (XEP-0384).

Les différentes étapes de cet article sont :

Une description de l’environnement dans lequel le serveur XMPP va être déployé

L’installation et la configuration du serveur XMPP en lui-même

La configuration de quelques fonctionnalités supplémentaires (partage de fichier et rooms)

La configuration finale du serveur

Environnement

Pour monter un serveur XMPP, il est nécessaire d’avoir au moins un nom de domaine public, et si possible plusieurs sous-domaines dédiés au projet. Il est également nécessaire d’avoir une ip publique, avec a minima les ports tcp 5222 et 5269 accessibles.

Dans cet article, je prends comme noms de domaines example.org et ses sous-domaines, et comme ip publique 198.51.100.5. Le serveur lui-même est sur l’ip 192.168.1.200/24, derrière un NAT. J’utilise également un reverse-proxy dédié (puisque je n’ai qu’une ip publique), dont l’ip privée est 192.168.1.100.

Prosody et edjabberd sont deux implémentations modernes de serveur XMPP, et les deux sont des choix très pertinents. Pour ma part, j’ai choisi Prosody.

Pour installer Prosody, j’utilise un serveur Debian 11, avec 2 vCPU, 2Go de ram et 32Go de disque (à titre purement indicatif, je n’ai pas fait de benchmark pour vérifier la pertinence de ces ressources).

Installation et configuration initiale

L’installation sous debian se fait via le repo officiel de Prosody :

echo deb http://packages.prosody.im/debian $(lsb_release -sc) main | sudo tee /etc/apt/sources.list.d/prosody.list
sudo wget https://prosody.im/files/prosody-debian-packages.key -O /etc/apt/trusted.gpg.d/prosody.gpg
sudo apt update
sudo apt install prosody

Toute la configuration se fait ensuite dans /etc/prosody/prosody.cfg.lua.

Le fichier de configuration complet est disponible à la fin du guide. J’ai enlevé les commentaires du fichier par défaut par soucis de clareté, mais je vous conseille de les laisser !

La configuration commence par charger une liste de modules. La liste par défaut est un bon point de départ ; j’ai simplement décommenté le module mam, qui permet de conserver un historique des messages sur le serveur.

On peut ensuite indiquer à Prosody quelle ip publique est utilisée pour accéder au service, ce qui lui permet de vérifier lui même si la configuration DNS est correcte :

external_addresses = { "198.51.100.5" }

Enfin, il faut créer un VirtualHost, ce qui correspond à un domaine sur lequel Prosody va écouter (en gros, un serveur XMPP séparé). Attention, toutes les options de configuration définies après ne s’appliqueront qu’au VirtualHost !

VirtualHost "chat.example.org"

Et voilà, juste avec ça, on a un serveur XMPP fonctionnel ! Mais avant de l’utiliser, nous allons au moins mettre en place un certificat TLS pour sécuriser les connexions entre les clients et le serveur, et entre notre serveur et les autres. Pour cela, un peu de DNS et de reverse proxy s’impose. Faisons donc pointer chat.example.org sur notre ip publique, puis ajoutons juste ce qu’il faut de reverse proxy :

J’utilise NixOS pour gérer mon reverse proxy. Je vous laisse adapter cette configuration pour nginx si ce n’est pas votre cas.

services.nginx."chat.example.org" = {
  locations = {
    "/".proxyPass = "http://192.168.1.200:80";
  };
};

Cette configuration de nginx n’écoute que sur le port 80, et reverse-proxyfie les requêtes sur le port 80 de la VM Prosody. Elle ne sert qu’à faire fonctionner le challenge Let’s Encrypt qui va venir :

$ certbot certonly --standalone -d chat.example.org
$ prosodyctl --root cert import /etc/letsencrypt/live

Pour vérifier que tout fonctionne, on peut utiliser prosodyctl :

$ prosodyctl check certs
Checking certificates...
Checking certificate for chat.example.org
  Certificate: /etc/prosody/certs/chat.example.org.crt

Et voilà ! N’oubliez pas de forward les ports tcp 5222 et 5269 sur votre firewall, et votre serveur XMPP devrait être fonctionnel. Pour ajouter des utilisateurs, utilisez la cli :

$ prosodyctl adduser user@chat.example.org

File sharing et MUC

Afin de rajouter quelques fonctionnalités à notre serveur, nous allons rajouter un vrai service de partage de fichier (actuellement, le partage de fichiers fonctionne, mais uniquement en peer-to-peer), ainsi que la possibilité de créer des rooms de discussion.

Ces deux fonctionnalités s’ajoutent via des Components, qui se configurent à la suite du VirtualHost :

disco_items = {
    { "file.example.org", "file sharing service" },
}

http_paths = {
    file_share = "/";
}

Component "file.example.org" "http_file_share"
    http_file_share_global_quota = 16*1024*1024*1024 -- 16 Go
    http_external_url = "https://file.example.org/"
    trusted_proxies = { "192.168.1.100", }

Component "rooms.chat.example.org" "muc"
    modules_enabled = { "muc_mam" }
    name = "Chatrooms"
    restrict_room_creation = "local"
    muc_room_default_public = false

Le service de partage de fichier, qui va être configuré derrière le reverse proxy, a besoin de connaitre son url d’accès pour générer correctement les liens. On lui configure également son quota global, et l’adresse ip du serveur proxy afin de l’autoriser.

Pour éviter que les liens générés soient préfixés par file_share/, on redéfinit son http_path. Enfin, pour que les clients puisse découvrir le service et parce qu’il n’est pas sur un sous-domaine de chat.example.org, on le définit dans la liste des services à découvrir.

Côté MUC, on active également le stockage des messages récents sur le serveur, on autorise uniquement les comptes locaux à créer de nouvelles rooms (même si n’importe qui peut ensuite les rejoindre), et on crée les rooms comme étant privées par défaut.

Afin que le reverse proxy fonctionne, il faut également faire écouter le port HTTP de Prosody sur 0.0.0.0 au lieu de localhost par défaut :

http_interfaces = { "*", "::" }

On peut à présent configurer notre reverse proxy, cette fois avec HTTPS :

services.nginx."file.example.org" = {
  enableACME = true;
  forceSSL = true;
  locations = {
    "/".proxyPass = "http://192.168.1.200:5280";
  };
};

Fichier de configuration final

external_addresses = { "198.51.100.5" }

modules_enabled = {
    "disco"; -- Service discovery
    "roster"; -- Allow users to have a roster. Recommended ;)
    "saslauth"; -- Authentication for clients and servers. Recommended if you want to log in.
    "tls"; -- Add support for secure TLS on c2s/s2s connections

    "blocklist"; -- Allow users to block communications with other users
    "bookmarks"; -- Synchronise the list of open rooms between clients
    "carbons"; -- Keep multiple online clients in sync
    "dialback"; -- Support for verifying remote servers using DNS
    "limits"; -- Enable bandwidth limiting for XMPP connections
    "pep"; -- Allow users to store public and private data in their account
    "private"; -- Legacy account storage mechanism (XEP-0049)
    "smacks"; -- Stream management and resumption (XEP-0198)
    "vcard4"; -- User profiles (stored in PEP)
    "vcard_legacy"; -- Conversion between legacy vCard and PEP Avatar, vcard

    "csi_simple"; -- Simple but effective traffic optimizations for mobile devices
    "invites"; -- Create and manage invites
    "invites_adhoc"; -- Allow admins/users to create invitations via their client
    "invites_register"; -- Allows invited users to create accounts
    "ping"; -- Replies to XMPP pings with pongs
    "register"; -- Allow users to register on this server using a client and change passwords
    "time"; -- Let others know the time here on this server
    "uptime"; -- Report how long server has been running
    "version"; -- Replies to server version requests
    "mam"; -- Store recent messages to allow multi-device synchronization

    "admin_adhoc"; -- Allows administration via an XMPP client that supports ad-hoc commands
    "admin_shell"; -- Allow secure administration via 'prosodyctl shell'
}

s2s_secure_auth = true
limits = {
    c2s = {
        rate = "10kb/s";
    };
    s2sin = {
        rate = "30kb/s";
    };
}
pidfile = "/var/run/prosody/prosody.pid"
authentication = "internal_hashed"
archive_expires_after = "1w"

log = {
    info = "/var/log/prosody/prosody.log";
    error = "/var/log/prosody/prosody.err";
}

certificates = "certs"

http_interfaces = { "*", "::" }

VirtualHost "chat.example.org"

disco_items = {
    { "file.example.org", "file sharing service" },
}

http_paths = {
    file_share = "/";
}

Component "file.example.org" "http_file_share"
    http_file_share_global_quota = 16*1024*1024*1024 -- 16 Go
    http_external_url = "https://file.example.org/"
    trusted_proxies = { "192.168.1.100", }

Component "rooms.chat.example.org" "muc"
    modules_enabled = { "muc_mam" }
    name = "Chatrooms"
    restrict_room_creation = "local"
    muc_room_default_public = false

Utiliser Firefox comme lecteur minimaliste

2024-07-27T00:00:00+00:00

Je cherchais un moyen minimaliste pour pouvoir lire un pdf ou un manga dans Firefox, en épurant au maximum ma fenêtre. Deux options sont courantes : mettre la fenêtre en plein écran, ou utiliser une extension de navigateur dédiée. Mais ça ne doit pas être si difficile à faire à la main ? Voyons comment faire cela.

Création d’un profil dédié

Afin de pouvoir continuer à utiliser Firefox normalement, nous allons créer un profil Firefox dédié. Les profils Firefox permettent d’isoler entièrement tous les marques-page, configurations, extensions, etc. Pour cela, rien de plus simple : allez sur about:profiles, puis créez en un (dans mon exemple, je l’ai appelé pdf). Remettez le profil default comme profil par défaut (puisqu’il restera notre profil principal), et notez bien le chemin de “Root Directory” du nouveau profil. Vous pouvez enuite ouvrir une fenêtre avec ce profil en cliquant sur le bouton “Launch profile in new browser” de cette page.

Vous pouvez dès à présent configurer ce nouveau profil à votre goût : installation d’extension, paramètres de vie privée, thème… Une fois cela fait, nous allons épurer très fortement l’interface, en supprimant complètement les barres d’onglets et d’URL. Pour pouvoir modifier l’interface de Firefox elle même, nous allons devoir activer l’option toolkit.legacyUserProfileCustomizations.stylesheets, qui se trouve sur la page about:config.

Modification de l’interface de Firefox

A présent, allons dans le dossier de configuration du profile (chez moi, ~/.mozilla/firefox/yrafg6j1.pdf/). La configuration de l’interface va se faire en utilisant userChrome. Pour cela, créez le fichier chrome/userChrome.css, en créant le dossier si besoin. Mettez le contenu suivant dans le fichier :

/* Cache la barre des onglets */
#TabsToolbar
{
    visibility: collapse;
}

/* Cache la barre de l'URL*/
#navigator-toolbox {
    visibility: collapse;
}

Les changements seront effectifs au prochain démarrage du profil.

Astuces

Pour lancer Firefox directement sur le profil pdf, lancez le avec firefox -P pdf [file.pdf].
Sans interface, la navigation au clavier est très utile : ctrl+tab pour cycler les onglets ouverts, ctrl+t pour ouvrir un nouvel onglet, ctrl+o pour ouvrir un fichier, ou alt+left pour revenir à la page précédente par exemple.
Attention, la barre d’URL est totalement inaccessible dans ce mode, y compris avec F6. Pensez à utiliser des marques-page (ctrl+shift+o pour ouvrir le menu), ou à épingler des pages sur la page de nouvel onglet.

Faire du Backup-as-a-Service avec Restic et Minio

2024-06-11T00:00:00+00:00

Pour mon infrastructure de backups, j’utilise depuis plusieurs années BorgBackup, un excellent outil pour chiffrer et dédupliquer ses sauvegardes, puis les stocker via SSH. Pour les sauvegardes de mes serveurs, il m’offre une complète satisfaction. Mais je voulais explorer un nouvel outil dont on m’avait dit beaucoup de bien, et je voulais essayer de faire du Backup-as-a-Service.

Les besoins sont simple : les utilisateurs ayant un compte sur mon service de SSO devraient pouvoir se connecter sur un service, créer une clé dédiée à une application, puis utiliser cette clé pour backup une machine, serveur ou PC, et envoyer les données sur mon serveur central. Les backups créés devraient être chiffrés, dédupliqués, et avec une gestion des droits pour ne pas permettre à un utilisateur d’écraser ou de modifier les backups des autres (tout étant chiffré, l’accès en lecture est moins critique). Si possible, le service devrait pouvoir définir des quotas par utilisateur ; malheureusement, la solution que j’ai trouvée ne le permet pas.

Les différentes étapes de l’article sont :

Installer restic et écrire un script pour le lancer

Installer MinIO, et tester que restic fonctionne avec MinIO

Configurer restic pour fonctionner avec MinIO en SSO

Faire ses backups simplement

Restic est une excellente alternative à BorgBackup, implémentée en Go. Il permet l’utilisation de plusieurs types de backend de stockage, dont du SFTP, une API REST, ou divers protocols cloud comme AWS S3 et l’équivalent chez la concurrence, au prix d’une compression moindre et d’un plus gros usage en ressources, notamment en RAM, que BorgBackup.

Sur chaque machine, nous allons installer Restic, puis écrire un petit script backup.sh autour du binaire pour backup facilement la machine. Je suis repartie de mes scripts existants, eux-même basés sur celui proposé dans la doc de BorgBackup :

$ sudo apt install restic

#!/bin/sh

info() { printf "\n%s %s\n\n" "$( date )" "$*" >&2; }
trap 'echo $( date ) Backup interrupted >&2; exit 2' INT TERM
info "Starting backup"

source .env

# Prehook start
# You can write here some commands to run before the backup
# For example, a database dump, or a service stop
# Prehook end

restic backup /path/to/folder1 /path/to/folder2
backup_exit=$?

restic forget --prune --keep-daily 7 --keep-weekly 4 --keep-monthly 12
prune_exit=$?

# Posthook start
# You can write cleanup commands here, or you can restart your services
# Posthook end

# use highest exit code as global exit code
global_exit=$(( backup_exit > prune_exit ? backup_exit : prune_exit ))
if [ ${global_exit} -eq 0 ]; then
    echo "Backup and Prune finished successfully"
    curl -m 10 --retry 5 https://health.chapoline.me/ping/<UUID>
elif [ ${global_exit} -eq 1 ]; then
    echo "Backup and/or Prune finished with warnings"
    curl -m 10 --retry 5 https://health.chapoline.me/ping/<UUID>/1
else
    echo "Backup and/or Prune finished with errors"
    curl -m 10 --retry 5 https://health.chapoline.me/ping/<UUID>/2
fi
exit ${global_exit}

$ chmod +x backup.sh

J’utilise une instance de healthchecks pour monitorer mes backups. Je vous encourage à y jeter un coup d’oeil, c’est très pratique pour monitorer les tâches ponctuelles.

Le fichier .env, qui contient les informations de connexion au backend de stockage, sera créé par la suite. Il est justement temps de choisir ce backend.

Stocker ses backups quelque part

Parmi les différents backends possible, j’ai fait le choix d’utiliser MinIO. Ce n’est pas un outil que j’aime beaucoup utiliser, mais sa compatibilité à l’API S3 le rend très pratique, et je voulais construire une solution entièrement auto-hébergée.

Son installation n’est pas très simple sous Debian, mais une installation par Docker est possible (et beaucoup plus facile). Pour ma part, je l’ai installé sur un serveur sous NixOS :

{ config, lib, pkgs, ... }:

{
  services.minio = {
    enable = true;
  };

  networking.firewall = {
    enable = true;
    allowedTCPPorts = [ 22 9000 9001 ];
  };
}

Dans un premier temps, nous allons utiliser les identifiants du compte minioadmin, pour vérifier que tout fonctionne. Attention, ne faites pas cela en production. On peut revenir sur l’autre machine, et créer le fichier .env :

export RESTIC_PASSWORD=<mot de passe de chiffrement des backups>
export RESTIC_REPOSITORY=s3:http://<url de minio>:9000/<bucket>
export AWS_ACCESS_KEY_ID=minioadmin
export AWS_SECRET_ACCESS_KEY=<Mot de passe du compte minioadmin>

Enfin, on peut tester ces informations de connexion :

$ source .env
$ restic init
created restic repository f1c6108821 at [url]
Please note that knowledge of your password is required to access the repository.
Losing your password means that your data is irrecoverably lost.
$ ./backup.sh

Tue Jun 11 08:55:41 UTC 2024 Starting backup

repository f1c6108821 opened successfully, password is correct

...

Tue Jun 11 08:55:45 UTC 2024 Backup and Prune finished successfully

Le source .env est nécessaire pour lancer restic init la première fois, ou pour faire des opérations manuelles sur les backups, mais pas pour lancer ./backup.sh.

Une fois que tout fonctionne, on peut créer un cron pour lancer automatiquement le backup :

0 4 * * * /path/to/backup.sh

Techniquement, un Timer Systemd est mieux et a plus de fonctionnalités, mais la force de l’habitude est forte.

Et ma SSO dans tout ça ?

Une fois un service de SSO configuré sur MinIO (laissé à titre d’exercice au lecteur),

Modification au 20/06/2024 :
La configuration du SSO sur MinIO est moins simple que je le pensais et mériterait sa propre section. Il est en effet nécessaire de rédiger une Policy, associée à la configuration OpenID, pour définir les droits d’accès des utilisateurs connectés via SSO. Par exemple, pour reprendre la méthode utilisée ici et autoriser chaque utilisateur à créer un bucket en son nom, vous pouvez donner les droits s3:* sur arn:aws:s3:::${aws:username}, et s3:List* sur arn:aws:s3:::*.
A noter cependant, que Gitlab a un bug qui l’empêche d’être utilisé pour cet usage.

la solution précédente, en plus de ne pas être sécurisée, n’est plus possible : MinIO ne manipule plus de mot de passe pour le compte utilisateur. Il faut donc utiliser une Access Key. Malheureusement, utiliser directement l’Access Key dans la configuration précédente à la place des identifiants du compte ne fonctionne pas. Il va falloir rajouter un outil : aws-cli. Rassurez vous, bien que développé par AWS pour ses API, cet outil fonctionne parfaitement avec les autres solutions compatibles S3 et n’envoie aucune information à AWS.

Commençons par nous connecter avec notre compte SSO à MinIO, puis par y générer une Access Key. Installons ensuite aws-cli sur la machine à backup, et configurons le :

Cette section est basée sur https://min.io/docs/minio/linux/integrations/aws-cli-with-minio.html.

$ sudo apt install awscli
$ aws configure
AWS Access Key ID [None]: Q3AM3UQ867SPQQA43P2F
AWS Secret Access Key [None]: zuf+tfteSlswRu7BJ86wekitnifILbZam1KYY3TG
Default region name [None]: ENTER
Default output format [None]: ENTER
$ aws configure set default.s3.signature_version s3v4

Enfin, éditez le fichier .env, pour remplacer les informations de connexion par le profile AWS que l’on vient de créer :

export RESTIC_PASSWORD=<mot de passe de chiffrement des backups>
export RESTIC_REPOSITORY=s3:http://<url de minio>:9000/<bucket>
export AWS_PROFILE=default

Vous pouvez retester que tout fonctionne comme précédemment. Il faudra probablement utiliser un autre bucket, ou supprimer le bucket du test précédent.

Concernant les quotas, MinIO ne propose pas de quota par utilisateur, uniquement des quotas par bucket, et ne permet pas de définir des quotas par défaut pour tout nouveau bucket créé. Cette solution n’est donc possible qu’avec des utilisateurs de confiance, et nécessite un monitoring de l’espace de stockage du serveur MinIO.

Pour des backups encore plus sûrs, vous pouvez mettre en place un cluster MinIO, et/ou répliquer les buckets vers un autre serveur de stockage (auto-hébergé ou dans le Cloud) avec rclone.