Fix spelling and grammar mistakes across EN and FR content (chapter C)

2026-09-07 21:25:08 +02:00
parent de3498fa65
commit db30198450
30 changed files with 65 additions and 65 deletions
@@ -6,7 +6,7 @@ description: Un script bash pour détecter et corriger les fichiers médias en d

 :ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}

-Six mois après avoir téléchargé des térabytes de media, je me suis rendu compte que Sonarr et Radarr les copaient dans ma biblio Plex au lieu de créer des hardlinks. C'est dû à un mécanisme contre intuitif qui est que si vous montez plusieurs dossiers dans Sonarr/Radarr, il les voit comme deux systemes de fichiers différents. Et ne peut donc pas créer de hardlinks. C'est pour cela qu'il ne faut monter qu'un seul dossier parent, qui contient tous les enfants (`downloads`, `movies`, `tvseries` dans le dossier parent `media` par exemple).
+Six mois après avoir téléchargé des térabytes de media, je me suis rendu compte que Sonarr et Radarr les copaient dans ma biblio Plex au lieu de créer des hardlinks. C'est dû à un mécanisme contre intuitif qui est que si vous montez plusieurs dossiers dans Sonarr/Radarr, il les voit comme deux systèmes de fichiers différents. Et ne peut donc pas créer de hardlinks. C'est pour cela qu'il ne faut monter qu'un seul dossier parent, qui contient tous les enfants (`downloads`, `movies`, `tvseries` dans le dossier parent `media` par exemple).

 J'ai donc restructuré mes dossiers, remis à la main chaque chemin dans qBittorrent, Plex, et autres. Il restait à trouver un moyen de détecter les doublons existants et d'automatiquement les supprimer et de créer des hardlinks à la place, pour économiser de l'espace.

@@ -6,16 +6,16 @@ description: Un script bash pour extraire automatiquement les headers LUKS de to

 :ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}

-Je me suis rendu compte il y a peu qu'il ne suffisait pas d'avoir le mot de passe pour deverouiller un volume luks apres une panne ou une corruption. J'ai ainsi appris à dump les headers luks des disques/volumes et à utiliser les numéros de série + noms de partitions pour pouvoir bien identifier quel header correspond à quel disque/partition (j'en ai 10 !).
+Je me suis rendu compte il y a peu qu'il ne suffisait pas d'avoir le mot de passe pour déverrouiller un volume luks après une panne ou une corruption. J'ai ainsi appris à dump les headers luks des disques/volumes et à utiliser les numéros de série + noms de partitions pour pouvoir bien identifier quel header correspond à quel disque/partition (j'en ai 10 !).

-Après avoir bien galéré à la main, j'avoue avoir demandé à Qwen3 (llm hebergé sur ma RTX 5090) de me faire un script qui automatise le listing et identification des disques, dump les headers et les stock dans une archive chiffrée prete à etre backupée sur mon serveur de sauvegarde.
+Après avoir bien galéré à la main, j'avoue avoir demandé à Qwen3 (llm hébergé sur ma RTX 5090) de me faire un script qui automatise le listing et identification des disques, dump les headers et les stocke dans une archive chiffrée prête à être sauvegardée sur mon serveur de sauvegarde.

 Ainsi, ce script :

 * Liste et identifie les disques avec leur numéro de série
-* Liste les partition
+* Liste les partitions
 * Dump les headers dans un dossier dans `/root` (dossier sécurisé)
-* Cree une archive temporaire
+* Crée une archive temporaire
 * Prompt pour saisir un mot de passe
 * Chiffre avec le mot de passe
 * Détruit l'archive non chiffrée
@@ -8,18 +8,18 @@ description: Utiliser socat pour proxifier le socket Docker via Docker Socket Pr
 Ce projet répond à un cas d'usage problématique :

 - J'ai [Beszel](https://beszel.dev/), un conteneur de monitoring en mode host, nécessitant d'exposer le socket de Docker afin qu'il récupère les stats des conteneurs
- Afin de ne pas laisser le socket complètement ouvert pour Beszel, j'ai [Docker Socket Proxy](https://github.com/Tecnativa/docker-socket-proxy), un conteneur qui se place entre le scoket de docker et le conteneur qui en a besoin, et qui filtre le requêtes en paramétrant les bonnes permissions pour ne pas tout exposer au conteneur qui l'utilise.
+- Afin de ne pas laisser le socket complètement ouvert pour Beszel, j'ai [Docker Socket Proxy](https://github.com/Tecnativa/docker-socket-proxy), un conteneur qui se place entre le socket de docker et le conteneur qui en a besoin, et qui filtre les requêtes en paramétrant les bonnes permissions pour ne pas tout exposer au conteneur qui l'utilise.

 Problème, si __Beszel__ est en mode host, il doit contacter __Docker Socket Proxy__ directement sur un port de l'host, c'est à dire en exposant un port de __Docker Socket Proxy__. Ce qui fait que n'importe quel conteneur/application sur mon host peut l'appeler et utiliser le socket docker.

 C'est là qu'intervient [Socat Proxy](https://git.djeex.fr/Djeex/socat-proxy). Ce dernier est un conteneur qui :

 - Crée un socket UNIX
- Ecoute ce socket
- Envoie les requetes vers Docker Socket Proxy et vice versa
+- Écoute ce socket
+- Envoie les requêtes vers Docker Socket Proxy et vice versa
 - Permet de remplacer le vrai socket docker en exposant le socket proxy créé, dans le conteneur final via un bind mount (ici, Beszel)

-Ainsi, un filtre comme Docker Socket Proxy dialogue avec Socat Proxy dans leur propre réseau isolé (en mode bridge), et le bind mount du socket UNIX créé est localisé sur l'host dans un dossier avec les permissions nécessaires pour ne pas etre visible des autres conteneurs/applicatifs.
+Ainsi, un filtre comme Docker Socket Proxy dialogue avec Socat Proxy dans leur propre réseau isolé (en mode bridge), et le bind mount du socket UNIX créé est localisé sur l'host dans un dossier avec les permissions nécessaires pour ne pas être visible des autres conteneurs/applicatifs.

 En gros :

@@ -8,7 +8,7 @@ description: Un script bash qui surveille la température des disques durs et é

 Quand on a un NAS avec plusieurs disques dans une buanderie, les températures peuvent vite grimper.  
 Un disque dur est très sensible à la chaleur et peut subir de gros dommages s'il dépasse une température seuil trop longtemps.  
-Après un été très chaud qui a fournit son lot de sueur froide en regardant la température de mes disques, j'ai cherché un moyen de pouvoir automatiser l'extinction du serveur en cas de dépassement prolonger de la température maximale supportée par mes disques.
+Après un été très chaud qui a fourni son lot de sueur froide en regardant la température de mes disques, j'ai cherché un moyen de pouvoir automatiser l'extinction du serveur en cas de dépassement prolongé de la température maximale supportée par mes disques.

 N'ayant rien trouvé de convaincant, je l'ai donc fait moi-même.

@@ -34,7 +34,7 @@ Le script d'installation permet aussi de régler différents paramètres :
 Il exécute aussi un autre script qui paramètre **logrotate** avec les éléments configurés précédemment.  
 Et enfin, le script d'installation peut être exécuté directement via un simple `curl` suivi d'un dernier script de configuration, parfait pour les plus flemmards.

-Il a fallu également gérer le sujet du root sans sudo, du sudo seul, de l'utilisateur sans sudo, les divers cas d'erreur (dépendances manquantes, erreur dans les permissions, créations de fichier, de lecture des données des disques, etc...)
+Il a fallu également gérer le sujet du root sans sudo, du sudo seul, de l'utilisateur sans sudo, les divers cas d'erreur (dépendances manquantes, erreur dans les permissions, créations de fichier, de lecture des données des disques, etc.)

 Et l'acces concurrent au fichier de statuts.

@@ -8,16 +8,16 @@ description: Un script bash qui arrête les conteneurs Docker avant une sauvegar

 [Backrest](https://github.com/garethgeorge/backrest) est un formidable outil de backup. Dans le cas de [Serveex](/serveex/introduction), la majeure partie des données à sauvegarder sont des conteneurs, et souvent ces conteneurs possèdent des bases de données.

-Le problème ? On ne peut pas sauvegarder proprement une BDD qui est en route. Alors, il existe plein de solutions complexe à base de dump des bases de données, mais souvent le plus simple cela reste de stopper les conteneurs, de sauvegarder, et de redémarrer les conteneurs.
+Le problème ? On ne peut pas sauvegarder proprement une BDD qui est en route. Alors, il existe plein de solutions complexes à base de dump des bases de données, mais souvent le plus simple cela reste de stopper les conteneurs, de sauvegarder, et de redémarrer les conteneurs.

-**Backrest** ne propose pas de solutions native, mais il propose d'executer des scripts customisés à déclencher sur des évenements, comme le démarrage et la fin de la sauvegarde par exemple. Notre besoin est donc de stopper les conteneurs dont on veut sauvegarder la BDD, à chaque démarrage du plan de sauvegarde, et de les redémarrer à la fin de l'execution du plan de sauvegarde. Pour cela nous allons avoir besoin d'un script bash et d'une connexion sécurisée entre Backrest et le socket de Docker, afin d'avoir la cinématique suivante :
+**Backrest** ne propose pas de solutions natives, mais il propose d'exécuter des scripts customisés à déclencher sur des événements, comme le démarrage et la fin de la sauvegarde par exemple. Notre besoin est donc de stopper les conteneurs dont on veut sauvegarder la BDD, à chaque démarrage du plan de sauvegarde, et de les redémarrer à la fin de l'exécution du plan de sauvegarde. Pour cela nous allons avoir besoin d'un script bash et d'une connexion sécurisée entre Backrest et le socket de Docker, afin d'avoir la cinématique suivante :

 - Le plan de sauvegarde se met en route
- L'evenement déclenche l'execution d'un script custom
+- L'événement déclenche l'exécution d'un script custom
 - Le script contacte docker et demande la liste des conteneurs qui comportent le label `backrest.backup.stop=true`
 - Il récupère cette liste et leur envoie une commande d'extinction
 - Le plan de sauvegarde s'arrête
- L'evenement déclenche l'execution d'un script custom
+- L'événement déclenche l'exécution d'un script custom
 - Le script recontacte docker, récupère la même liste, et redémarre ces conteneurs

 ## Faire communiquer Backrest et Docker en toute sécurité
@@ -67,7 +67,7 @@ Et voilà, Backrest pourra ainsi communiquer avec Docker en toute sécurité.

 ## Les scripts

-Vous trouverez ci-dessous les scripts à renseigner en action pour les évèvenements de démarrage et d'arrêt de la sauvegarde dans **Backrest**.
+Vous trouverez ci-dessous les scripts à renseigner en action pour les événements de démarrage et d'arrêt de la sauvegarde dans **Backrest**.

 ::code-group
 ```sh [Stop]